We (Pingtel) are running into an increasing number of customers who are having trouble with PSTN gateways. Specifically, they want to use more than one PSTN gateway, but it's difficult to have a proxy route calls reliably through multiple gateways, as there is no reliable rule to distinguish when a gateway returns a failure because it has no available lines vs. a failure at the destination phone.
In principle, a gateway should return 486 if the PSTN reports that the destination phone is busy, and return 503 if the gateway has no available lines. But some gateways return 486 for no-available-line. Worse, if the gateway is accessed through an intermediate proxy, a 503 response will be converted to 500 by the intermediate gateway (RFC 3261, section 16.7, step 6). And 500 is used to indicate quite a number of conditions (including "CSeq out of order"), as well as being allowed to mean "internal server error (not otherwise classified)".. As far as I can see, the way out of this mess is to have a more clear distinction of failure codes that mean the call failed at the destination UA vs. failure codes that mean the call failed during some transport step. This isn't all that difficult, but to make it work, we need to build a consensus. I've written an Internet-Draft, draft-worley-sip-redundancy-response-01, making such a classification, and pointing out the four or so ambuguous failure codes, with suggestions for splitting thost failure codes into two separate codes. It's available at http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-worley-sip-redundancy-response-01.txt until it gets into the official directories. I'd like to start a discussion between proxy builders and gateway builders to establish a set of conventions that will work well in practice. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
