On Tue, Jun 15, 2004 at 12:31:04AM -0400, John Todd reportedly typed:
[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.