On Sat, 2009-03-07 at 13:36 -0500, Hadriel Kaplan wrote: > > > -----Original Message----- > > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf > > Of Dale Worley > > Sent: Saturday, March 07, 2009 9:03 AM > > To: SIPPING > > Subject: Supporting Multiple Path Routing > > > > In our SIP PBX (called "sipXecs"), we consistently run into a problem > > when a PBX has two gateway devices into the PSTN -- there's no good way > > to configure a SIP proxy to use both gateways as a redundant pair. Once > > you tell the proxy to fork the call serially to both gateways, if the > > call gets ring-no-answer or busy when going out the first gateway, the > > proxy sends the call out the second gateway, to receive the same > > response. For practical PBX deployments, we need to solve this problem. > > So I'm restarting the draft I wrote a while ago that describes the > > problem. I'm interested in hearing from anyone who has suggestions how > > to fix the problem. > > There *are* failure responses already which have the semantic of > "don't bother rerouting": the 6xx series. It's just that they're > rarely sent. The reasons they aren't sent would be the same reasons > any new response code with those semantics wouldn't be sent, no? > > Also, separating it into "response from proxy" vs. "response from UA" > is not that simple, and won't fix that much. There are plenty of > proxies that represent the ONLY path to get to that UA, and plenty of > UA's which do NOT represent the only path to get to the user. I think > what you really want to know is if the request got to the domain > responsible for the AoR and it got routed within that domain to the > UA, or not. Right? ISTM the real hard part there is due to the scope > of the AoR - if it's an E.164 username, the domain is not relevant and > the scope is bigger than SIP (it's semantically a tel URI), so the > domain reached doesn't always know if it's really solely authoritative > for that user or not globally. You're right, but I think that there are many cases in which intermediaries _do_ know what the real situation is but report it in a way that's ambiguous. If the intermediate device is a PSTN/SIP gateway, then in at least some cases it can distinguish between: * it has attempted to reach the PSTN number it extracted from the SIP request and gotten a response from the PSTN terminal (no such number or busy), or * it has encountered an error somewhere before reaching that PSTN terminal (gateway is out of channels, trunk busy from the PSTN) Granted that not all intermediate systems can know for every request whether what they are returning is an end-to-end response or an intermediate-to-end response. But sometimes they do, and when they do they should be clearer about it than we find them to be today (some gateways return 486 when they are out of local DSP resources and have not attempted a PSTN call at all, for example). When they can't be sure, that should (I think) be returned as an intermediate failure (because if it really was intermediate, then alternate routes will be tried to attempt to get an end-to-end result). _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
