Internet DRAFT - draft-elwell-sipping-redirection-reason
draft-elwell-sipping-redirection-reason
Internet Engineering Task Force J. Elwell
Internet Draft Siemens
R. Jesske
Deutsche Telekom
J. McMillen
Avaya Inc.
draft-elwell-sipping-redirection-reason-02.txt
Expires: December 2005 June 2005
SIP Reason header extension for indicating redirection reasons
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress. "
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This proposes an extension to the SIP Reason header to provide
additional information concerning retargeting in SIP, a particular
motivation being improved interoperability with PSTN diversion.
Elwell Expires - December 2005 [Page 1]
SIP Reason header extension for redirection reasons June 2005
Table of Contents
1 Introduction....................................................3
2 Requirements....................................................3
3 Overview of proposed solution...................................4
4 Extension to the Reason header..................................4
5 Inclusion of the Reason header in 3xx responses.................5
6 Examples........................................................6
6.1 Retargeting with reason "Forward Unconditional" to PSTN.......6
6.2 Retargeting with reason "Forward Busy"........................7
6.3 Recursion with reason "Forward Busy" to PSTN..................9
6.4 Redirection request from PSTN................................10
7 IANA considerations............................................12
8 Security Considerations........................................13
9 Author's Addresses.............................................13
10 Normative References..........................................13
Elwell Expires - December 2005 [Page 2]
SIP Reason header extension for redirection reasons June 2005
1 Introduction
Central to SIP [2] is the concept of redirecting or retargeting a
request by a proxy, whereby the Request-URI in the original request
is replaced before forwarding the request on the next hop. Sometimes
this is due to normal rerouting behaviour of the proxy (e.g.,
resolving an address-of-record URI to a contact URI). At other times
it is due to more application-related reasons, e.g., where a user has
made arrangements for calls to that user under certain conditions to
be forwarded to a different destination.
The History-Info header [3] provides a means for conveying
information about a retarget to the final destination UAS and also
back to the UAC. In addition to providing the retargeted-from and
retargeted-to URIs for each recorded retarget, this header also
conveys a reason by means of the Reason header. The Reason header
accompanies the retargeted-from URI and reflects the reason why
attempts to reach that target failed, normally in the form of the SIP
response code concerned.
However, the repertoire of reasons available for use in the Reason
header is sometimes insufficient to reflect application-related
reasons for retargeting. In particular it cannot reflect accurately
the range of reasons used in PSTN/ISDN for call "diversion". This
makes it difficult to provide interworking with PSTN/IDSN for calls
that undergo retargeting / diversion and also makes it difficult for
SIP-based networks to offer a behaviour similar to that of diversion
in PSTN/ISTN.
2 Requirements
REQ-1. Provide a means for a gateway to provide information in a SIP
INVITE request to reflect PSTN diversion reasons when mapping a
diverted PSTN call request to a SIP INVITE request.
REQ-2. Provide a means for a gateway to provide information in a
response to a SIP INVITE request to reflect PSTN diversion reasons
when mapping a response to a PSTN call establishment request to a
response to a SIP INVITE request.
REQ-3. Provide a means for a gateway to provide information in a 3xx
response to a SIP INVITE request to reflect PSTN diversion reasons
when mapping a PSTN call diversion request to a 3xx response to a SIP
INVITE request.
REQ-4. Provide a means for a gateway to obtain information from a SIP
retargeted or recursed SIP INVITE request for deriving PSTN diversion
Elwell Expires - December 2005 [Page 3]
SIP Reason header extension for redirection reasons June 2005
reasons when mapping the SIP INVITE request to a PSTN call
establishment request.
REQ-5. Provide a means for a gateway to obtain information from a
response to a retargeted or recursed SIP INVITE request for deriving
PSTN diversion reasons when mapping the SIP response to a response to
a PSTN call establishment request.
REQ-6. Provide a means for a gateway to obtain information from a 3xx
response to a SIP INVITE request for deriving PSTN diversion reasons
when mapping the SIP 3xx response to a PSTN call diversion request.
3 Overview of proposed solution
The proposed solution is to enhance the Reason header with new values
that reflect diversion reasons in PSTN/ISDN. This can be done by
defining a new "protocol" value and then defining specific new reason
values under the umbrella of the new "protocol" value. The enhanced
Reason header can then be used as a parameter of a History-Info
header field entry. This allows the forwarding of PSTN diversion
reasons when mapping an INVITE request or response containing a
History-Info header field to/from PSTN signalling.
In addition the enhanced Reason header can be used in a 3xx response
to an INVITE request. This fulfils two functions. First, it allows
the forwarding of PSTN diversion reasons when mapping a 3xx response
to an INVITE request to/from PSTN signalling. Secondly it provides
information to a proxy or UAC for inclusion in the History-Info
header field when the request undergoes recursion.
Candidate reasons include forward unavailable, forward busy, forward
no reply, forward unconditional, deflection immediate, deflection
alerting, hunting, mobile not reachable.
Note that selection of the new target may depend on several other
conditions (e.g., relating to date, time, the source of the request
or caller preferences), but the reasons suggested above should be
sufficient to convey the main circumstance leading to the retarget.
4 Extension to the Reason header
This document defines the following new protocol value for the
protocol field of the Reason header field in [1]:
Redirection: The cause parameter contains a reason for redirection
of a request.
This document defines the following redirection cause codes:
Elwell Expires - December 2005 [Page 4]
SIP Reason header extension for redirection reasons June 2005
Value Default Text Description
1 Normal redirection The call has been retargeted for
normal routing reasons
2 Forward unavailable The call has been retargeted
because the called user is
unavailable (no registered contact).
3 Forward busy The call has been retargeted
because the called user is busy.
4 Forward no reply The call has been retargeted
because the called user has been
alerted but has failed to reply.
5 Forward unconditional The call has been retargeted
immediately without determining
whether the called user is
unavailable or busy and without
alerting the user.
6 Deflection immediate The call has been retargeted as a
result of a request by the called
user's device without alerting the
called user.
7 Deflection alerting The call has been retargeted as a
result of action by the called user
in response to alerting.
8 Hunting The call has been retargeted to an
individual member of the hunt group
at which it was previously targeted.
9 Mobile not reachable The call has been retargeted
because the called mobile user is
not reachable
Example syntax is as follows:
Reason: redirection;cause=3 ;text="Forward busy"
5 Inclusion of the Reason header in 3xx responses
[1] states that the Reason header field is not usually needed in
responses because the status code and the reason phrase already
provide sufficient information. However, this is not so in the case
of a 3xx response, since there may be a need to provide a diversion
Elwell Expires - December 2005 [Page 5]
SIP Reason header extension for redirection reasons June 2005
reason in the 3xx response for inclusion in the History-Info header
field in the event of recursion or for mapping directly to/from PSTN.
Therefore in order to satisfy this need, a 3xx response MAY contain a
Reason header field.
NOTE. [1] states that the Reason header can appear in any response
whose status code explicitly allows the presence of this field. The
statement above performs this function.
6 Examples
6.1 Retargeting with reason "Forward Unconditional" to PSTN
Alice Proxy Bob Gateway
| | | |
| INVITE F1 | | |
|--------------->| | |
| | | |
|(100 Trying) F2 | | |
|<---------------| | |
| | | INVITE F3 |
| |--------------------------------->|
| | | 180 Ringing F4 |
| |<---------------------------------|
| 180 Ringing F5 | | |
|<---------------| | 200 OK F6 |
| | | |
| |<---------------------------------|
| 200 OK F7 | | |
|<---------------| | |
| ACK F8 | | |
|--------------->| | ACK F9 |
| |--------------------------------->|
Assuming the entity sending the INVITE supports the History-Info
header, the INVITE would look like this:
F1 (INVITE) Alice -> Proxy
INVITE sip:Bob@example.com; SIP/2.0
From: <sip:Alice@example.com>;tag=2
To: <sip:Bob@example.com >
Call-ID: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:Bob@example.com>;index=1
...
Elwell Expires - December 2005 [Page 6]
SIP Reason header extension for redirection reasons June 2005
The call is then retargeted to a contact URI
<sip:12345@gateway.example.com>. The forwarded INVITE request would
be as follows:
F3 (INVITE) û Proxy -> Gateway
INVITE sip:12345@gateway.example.com SIP/2.0
From: <sip:Alice@example.com>;tag=2
To: <sip:Bob@example.com>
Call-ID: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:Bob@example.com? Reason=Redirection%3B
cause%3D5%3Btext%3D%22Forward%20unconditional%22>;index=1,
<sip:12345@gateway.example.com>;index=2
Note that in accordance with [2] the following escape characters
are used within parameters of URL headers: %3B for semicolon, %3D
for equals, %22 for double quote and %20 for space.
The "index 1" entry indicates that the call to Bob was retargeted
because of redirection reason forward unconditional.
The "index 2" entry indicates that the call to 12345 has not yet been
further retargeted.
The Reason header field provides a diversion reason that can be
included in relevant PSTN messaging.
6.2 Retargeting with reason "Forward Busy"
Alice Proxy Bob Gateway
| | | |
| INVITE F1 | | |
|--------------->| INVITE F3 | |
| |------------->| |
|(100 Trying) F2 | | |
|<---------------| | |
| | 486 Busy | |
| | here F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
| | | INVITE F6 |
| |--------------------------------->|
| | | 180 Ringing F7 |
| |<---------------------------------|
| 180 Ringing F8 | | |
|<---------------| | 200 OK F9 |
| |<---------------------------------|
Elwell Expires - December 2005 [Page 7]
SIP Reason header extension for redirection reasons June 2005
| 200 OK F10 | | |
|<---------------| | |
| ACK F11 | | |
|--------------->| | ACK F12 |
| |--------------------------------->|
Assuming the entity sending the INVITE supports the History-Info
header, the INVITE would look like this:
F1 (INVITE) Alice -> Proxy
INVITE sip:Bob@example.com; SIP/2.0
From: <sip:Alice@example.com>;tag=2
To: <sip:Bob@example.com >
Call-ID: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:Bob@example.com>;index=1
...
Bob indicates a Busy so that a 486 response is send back.
F4 (486 Busy Here) Bob -> Proxy
SIP/2.0 486 Busy Here
From: <sip:Alice @example.com>;tag=2
To: <sip:Bob@example.com>;tag=3
Call-ID: 12345600@example.com
CSeq: 1 INVITE
à
On receipt of F4 (486 Busy Here) and because of forwarding on busy
provisioned at the proxy on behalf of Bob, the call is then
retargeted to a URI <sip:12345@gateway.example.com>. This URI is pre-
provisioned within the Proxy. The forwarded INVITE request would be
as follows:
F6 (INVITE) û Proxy -> Gateway
INVITE sip:12345@gateway.example.com SIP/2.0
From: <sip:Alice@example.com>;tag=2
To: <sip:Bob@example.com>
Call-ID: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:Bob@example.com? Reason=Redirection%3B
cause%3D3%3Btext%3D%22Forward%20busy%22>;index=1,
<sip:12345@gateway.example.com>;index=2
The "index 1" entry indicates that the call to Bob was retargeted.
Elwell Expires - December 2005 [Page 8]
SIP Reason header extension for redirection reasons June 2005
The "index 2" entry indicates that the call to 12345 has not yet been
further retargeted.
The Reason header field for index 1 provides a diversion reason that
can be included in relevant PSTN messaging.
6.3 Recursion with reason "Forward Busy" to PSTN
Alice Proxy Bob Gateway
| | | |
| INVITE F1 | | |
|--------------->| INVITE F3 | |
| |------------->| |
|(100 Trying) F2 | | |
|<---------------| | |
| | 302 Moved | |
| |Temporarily F4| |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
| | | INVITE F6 |
| |--------------------------------->|
| | | 180 Ringing F7 |
| |<---------------------------------|
| 180 Ringing F8 | | |
|<---------------| | 200 OK F9 |
| |<---------------------------------|
| 200 OK F10 | | |
|<---------------| | |
| ACK F11 | | |
|--------------->| | ACK F12 |
| |--------------------------------->|
Assuming the entity sending the INVITE supports the History-Info
header, the INVITE would look like this:
F1 (INVITE) Alice -> Proxy
INVITE sip:Bob@example.com; SIP/2.0
From: <sip:Alice@example.com>;tag=2
To: <sip:Bob@example.com >
Call-ID: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:Bob@example.com>;index=1
...
Elwell Expires - December 2005 [Page 9]
SIP Reason header extension for redirection reasons June 2005
Because of forwarding on busy at Bob, the call is then redirected to
a contact URI <sip:12345@gateway.example.com> in a 302 response. The
response would be as follows:
F4 (302 Moved Temporarily) Bob -> Proxy
SIP/2.0 302 Moved temporarily
From: <sip:Alice @example.com>;tag=2
To: <sip:Bob@example.com>;tag=3
Call-ID: 12345600@example.com
CSeq: 1 INVITE
Contact: <sip:12345@gateway.example.com>
Reason=Redirection;cause=3;text="Forward busy"
à
The call then undergoes recursion to the contact URI
<sip:12345@gateway.example.com>. The forwarded INVITE request would
be as follows:
F6 (INVITE) û Proxy -> Gateway
INVITE sip:12345@gateway.example.com SIP/2.0
From: <sip:Alice@example.com>;tag=2
To: <sip:Bob@example.com>
Call-ID: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:Bob@example.com? Reason=Redirection%3B
cause%3D3%3Btext%3D%22Forward%20busy%22>;index=1,
<sip:12345@gateway.example.com>;index=2
The "index 1" entry indicates that the call to Bob was retargeted
(recursed).
The "index 2" entry indicates that the call to 12345 has not yet been
further retargeted.
The Reason header field for index 1 provides a diversion reason that
can be included in relevant PSTN messaging.
6.4 Redirection request from PSTN
Alice Proxy Gateway Bob
| | | |
| INVITE F1 | | |
|--------------->| INVITE F3 | |
| |------------->| |
|(100 Trying) F2 | | |
|<---------------| | |
| | 302 Moved | |
Elwell Expires - December 2005 [Page 10]
SIP Reason header extension for redirection reasons June 2005
| |Temporarily F4| |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
| | | INVITE F6 |
| |--------------------------------->|
| | | 180 Ringing F7 |
| |<---------------------------------|
| 180 Ringing F8 | | |
|<---------------| | 200 OK F9 |
| |<---------------------------------|
| 200 OK F10 | | |
|<---------------| | |
| ACK F11 | | |
|--------------->| | ACK F12 |
| |--------------------------------->|
Assuming the entity sending the INVITE supports the History-Info
header, the INVITE would look like this:
F1 (INVITE) Alice -> Proxy
INVITE sip:12345@gateway.example.com; SIP/2.0
From: <sip:Alice@example.com>;tag=2
To: <sip:12345@gateway.example.com >
Call-ID: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:12345@gateway.example.com>;index=1
...
Because of forwarding on busy in the PSTN to a number that the
gateway is able to resolve to Bob, the call is then redirected to a
contact URI <sip:Bob@example.com> in a 302 response. The response
would be as follows:
F4 (302 Moved Temporarily) Gateway -> Proxy
SIP/2.0 302 Moved temporarily
From: <sip:Alice @example.com>;tag=2
To: <sip:12345@gateway.example.com>;tag=3
Call-ID: 12345600@example.com
CSeq: 1 INVITE
Contact: <sip:Bob@example.com>
Reason=Redirection;cause=3;text="Forward busy"
à
The Reason header field is derived from PSTN messaging.
Elwell Expires - December 2005 [Page 11]
SIP Reason header extension for redirection reasons June 2005
The call then undergoes recursion to the contact URI
<sip:Bob@example.com>. The forwarded INVITE request would be as
follows:
F6 (INVITE) û Proxy -> Gateway
INVITE sip:Bob@example.com SIP/2.0
From: <sip:Alice@example.com>;tag=2
To: <sip:12345@gateway.example.com>
Call-ID: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:12345@gateway.example.com? Reason=Redirection%3B
cause%3D3%3Btext%3D%22Forward%20busy%22>;index=1,
<sip:Bob@example.com>;index=2
The "index 1" entry indicates that the call to the PSTN was
retargeted (recursed) with reason Forward busy, the Reason header
field having been copied from the 302 response.
The "index 2" entry indicates that the call to Bob has not yet been
further retargeted.
7 IANA considerations
This document defines one new value for the SIP Reason header [1]
protocol namespace. The new value is "Redirection" and indicates the
use of cause value defined in this document.
This document also creates an IANA registry for cause values that
populate the cause field of the Reason header when protocol value
"Redirection" is used and corresponding default values that populate
the text field. The current cause and text values in this new
registry are as follows:
Cause value Default text value Reference
----------- ------------------------------
1 Normal redirection This document
2 Forward unavailable This document
3 Forward busy This document
4 Forward no reply This document
5 Forward unconditional This document
6 Deflection immediate This document
7 Deflection alerting This document
8 Hunting This document
9 Mobile not reachable This document
New values for this registry can only be defined by means of a
published standard.
Elwell Expires - December 2005 [Page 12]
SIP Reason header extension for redirection reasons June 2005
8 Security Considerations
The security considerations of [1] apply. When the Reason header
field is embedded within a History-Info header field, the security
considerations of [3] apply.
Unauthorised insertion, deletion of modification of the Reason header
field can provide misleading information to users and applications.
Eavesdropping on this header field can reveal information about a
user. Securing of SIP connections by TLS can combat this problem.
A SIP entity that can provide a redirection reason in a Reason header
field SHOULD be able to suppress this in accordance with privacy
requirements of the user concerned.
9 Author's Addresses
John Elwell
Siemens Communications
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
email: john.elwell@siemens.com
Roland Jesske
Deutsch Telekom
Am Kavalleriesand 3
Germany-64295 Darmstadt
email: r.jesske@t-com.net
Joanne McMillen
Avaya Inc.
1300 W. 120th Ave.
Westminster, CO 80234-2726
email: joanne@avaya.com
10 Normative References
[1] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header for the
Session Initiation Protocol (SIP)", RFC 3326.
[2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
protocol", RFC 3261.
[3] M. Barnes, "An Extension to the Session Initiation Protocol for
Request History Information", draft-ietf-sipping-history-info-03
(work in progress).
Intellectual Property Statement
Elwell Expires - December 2005 [Page 13]
SIP Reason header extension for redirection reasons June 2005
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Elwell Expires - December 2005 [Page 14]
