Hi, Forking at the sip proxy level, I guess, was not intended for redundancy usage. Can the gw itself forward to another gateway? It knows best if the failure came from it, the pstn network or the end point. Hisham 2009/3/8 Dale Worley <dworley@xxxxxxxxxx>: > 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. > > Dale > > > A new version of I-D, draft-worley-redundancy-response-04.txt has been successfuly submitted by Dale Worley and posted to the IETF repository. > > Filename: draft-worley-redundancy-response > Revision: 04 > Title: Supporting Multiple Path Routing in the Session Initiation Protocol (SIP) > Creation_date: 2009-03-06 > WG ID: Independent Submission > Number_of_pages: 10 > > Abstract: > An increasing number of SIP architectures implement multiple path > routing (MPR), which is the providing of more than one path for a > call to reach a destination user agent (UA). A typical example is a > redundant pair of gateways from a SIP system to the PSTN. A call > from the SIP system to the PSTN can pass through either gateway to > ultimately reach the destination telephone. In order to gain the > benefits of redundancy in case one of the gateways fails or reaches > capacity, a proxy forks INVITEs serially to both gateways. > > Unfortunately, if the call passes through one gateway but fails at > the destination phone (e.g., ring-no-answer), the proxy will then > fork the call to the other gateway, because the proxy has no way to > know that the call failed at the destination phone rather than at the > first gateway. The second fork will fail in the same way at the same > destination phone. This annoys both the caller (because the call > takes twice as long as it should before failing) and anyone within > earshot of the destination phone. Similar failures plague any other > SIP architecture where a request can reach a destination through > multiple paths. > > To gain the benefits of MPR without suffering from this problem, the > proxy which forks a request onto the redundant paths needs to be able > to determine if a fork that failed reached the destination UA and was > rejected by the UA (and so an alternate path should not be tried), or > if the fork failed before reaching the UA (and so an alternate path > should be attempted). This document is to begin a discussion of > strategies for making this determination. > > > > The IETF Secretariat. > > > > > _______________________________________________ > 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 > _______________________________________________ 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
