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
