Serial Forking and 605
draft-rajesh-sipping-605-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Rajesh Ramanathan | ||
| Last updated | 2007-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
The session initiation protocol (SIP) [2] allows users' end systems to decline calls for many reasons. 6xx response codes communicate global failures generated by callee's end system. It defines 6xx class response codes in the spirit of parallel forking scenarios only. There're scenarios where, authoritative server performs parallel forking of the call to callee's own set of endpoints, and then serially move on to fork call to alternate set of endpoints (callee's voice mail and/or team call). This draft clarifies behavior for existing 603 response code and proposes new 605 response code to handle complete rejection of the call, which halts any further processing of the call.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)