Re: SIP-T and Q.Sig

[John Todd <jtodd@loligo.com>]

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.)

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.

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>).

JT


--
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/>.