Supporting Multiple Path Routing in the Session Initiation Protocol (SIP)
draft-worley-redundancy-response-04
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Dale R. Worley | ||
| Last updated | 2009-03-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)