Re: SIP-T and Q.Sig

[Dave Siegel <dave@siegelie.com>]

On Tue, Jun 15, 2004 at 12:31:04AM -0400, John Todd reportedly typed:
> At 12:54 PM -0700 on 6/14/04, Dave Siegel wrote:
> >On Mon, Jun 14, 2004 at 03:32:58PM -0400, Daniel Golding reportedly typed:
> >[snip]
> > > VoIP Transit? Is the SIP signaling sufficient to provide all the
> >> functionality you want?
> >
> >So far, but it's still early.  We don't yet have enough operational
> >experience with these protocols to know for sure.  The one issue that
> >I pointed out previously with translation of term codes to SIP error
> >messages is not a problem we have run into operationally because
> >we don't yet send calls to other carriers via IP.  We are anticipating
> >the problem, however.
> [snip]
> 
> Do you have opinions on RFC3398 (http://www.ietf.org/rfc/rfc3398.txt) 
> in it's method of addressing these mappings?  Do you see this as a 
> reasonable translation?   Or was that what you meant when you 
> described the 3 different term codes all mapping to "404 Not Found"?
> 
> RFC3398 may not be "complete" as it seems to only specify ISDN cause 
> codes, and I am blissfully un-aware of what more hideous and complex 
> messages may reside inside of SS7.  I'd be interested in hearing any 
> other comments on this topic, since the mismatch between ISUP and SIP 
> sometimes causes minor un-smoothness (but I have not yet had it be a 
> "problem" - merely an inconvenience.)

Here is an example.  

If we receive a Term Code 1, we terminate the call.
If we receive a Term Code 3, we advance to the next route
Both Term Code 1 and Term Code 3 map to SIP 404.
SIP 404 maps to Term Code 1.

So, if a carrier customer takes what was originally a Term Code 3
and maps it to a SIP 404, we get the SIP 404 and map it to a Term Code 1.
We will terminate the call when we would have normally done a route
advance. 

So what, you say?  Well, it may have the affect of lowering a stat 
known as CCR, or Call Completion Ratio.  This is a stat that the 
voice engineering and operations groups are measured on as an objective.
When it drops, there's a perception that we are doing something wrong
(I think the internal objective is 99.7% or something like that).
Also remember that if we don't set up the call, we don't get paid...

So, this is where the concern around this is.  I told the operational
folks to just "suck it up" for now, and when we start to see a pile
of TC1's/SIP404's, we'll need to investigate as many of them as possible
to identify root cause in the vendors network, to see if we should have/
could have done something on our end to deal with the failure in a 
better way.  Once I have this operational data, I intend to feed it
into the standards process.

My perception is that SIP-T may be viewed as the end-all be-all solution
rather than to improve either a) the mapping, or b) adding additional
error handling to the SIP standard.  In the end, I think it stems from
the fact that SIP was designed to be very generalized, and not VoIP
specific, but I don't think it will take too much tweaking to make SIP
more compliant with the icky voice world.

> To address Dan's more broad question of:
> 
> >> When connecting different vendor's softswitches together, what is the 
> >> common
> >> signaling now? Q.sig? IAX2?
> 
> I agree with Dave's comment about IAX2 being a toy protocol right now 
> in that it's not taken seriously, and anything that isn't used by the 
> adults (ILEC/CLEC/IXC) is considered a toy.  The spec needs some 
> work.  However, protocols like that sometimes grow legs in the 
> strangest ways when enough end users and small enterprises start to 
> advocate it's use.  An attempt at an RFC draft might be under way 
> this fall by several interested parties.

There are clearly some advantages.  Supposedly, it deals with NAT
traversal much more elegantly...no ALG required.

> The protocol used by the carriers I've now dealt with has been SIP, 
> and SIP has been sufficient for my signalling requirements.  (note: 
> my use of SIP auto-excludes H.323 carriers, even though that may 
> actually be more widespread for the moment.)   There are no special 
> tricks or routing protocols, as I've said - all the routes I've 
> programmed have been pre-loaded from CSV or Excel spreadsheets (or 
> worse) and the call control is handled by "plain vanilla" SIP.  I 
> anxiously await TLS on all the softswitches, but I'm not holding my 
> breath for the vendors there (<cough>BGPMD5<cough>).

What's TLS in this context?  Is that something like TRIP?

Dave

-- 
Dave Siegel                     http://www.siegelie.com/people/dsiegel/
Oro Valley, AZ
 "Let us be thankful for the fools. But for them, the rest of
  us could not succeed."  -- Mark Twain


--
To unsubscribe send a message to voip-peering-request@psg.com with
the word 'unsubscribe' in a single line as the message text body.
An archive is at <http://psg.com/lists/voip-peering/>.