> -----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. -hadriel _______________________________________________ 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
