I strongly support the Issue that is addressed in the Draft need to be addressed. With the increase in the SIP Networks in the field this issue will not only be in SIP PBX's but also in SIP Networks. I feel to address this issue addressing response_from_UA vs response_from_proxy is difficult as it may need change in exsisting proxies to understand the response codes and implement them. so Instead we can create a new header:(like)Entitysource. This will be inserted in all the response codes. This can have the Values UA/Proxy/token. Based on that value of the new header the behavior can be determined by the originating UA. IMHO,this will be better than response codes as we can have this Header optional and so when will not have any impact on the present implementations. The main problem with the error codes in the SIP is, we cannot determine today directly looking at the response code if it is from the end UA or Proxy and this need to be addressed!! -Sreeram. -----Original Message----- From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Dale Worley Sent: Saturday, March 07, 2009 6: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. 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
