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: ;tag=2 To: Call-ID: 12345600@example.com CSeq: 1 INVITE History-Info: ;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 . The forwarded INVITE request would be as follows: F3 (INVITE) û Proxy -> Gateway INVITE sip:12345@gateway.example.com SIP/2.0 From: ;tag=2 To: Call-ID: 12345600@example.com CSeq: 1 INVITE History-Info: ;index=1, ;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: ;tag=2 To: Call-ID: 12345600@example.com CSeq: 1 INVITE History-Info: ;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: ;tag=2 To: ;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 . 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: ;tag=2 To: Call-ID: 12345600@example.com CSeq: 1 INVITE History-Info: ;index=1, ;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: ;tag=2 To: Call-ID: 12345600@example.com CSeq: 1 INVITE History-Info: ;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 in a 302 response. The response would be as follows: F4 (302 Moved Temporarily) Bob -> Proxy SIP/2.0 302 Moved temporarily From: ;tag=2 To: ;tag=3 Call-ID: 12345600@example.com CSeq: 1 INVITE Contact: Reason=Redirection;cause=3;text="Forward busy" à The call then undergoes recursion to the contact URI . The forwarded INVITE request would be as follows: F6 (INVITE) û Proxy -> Gateway INVITE sip:12345@gateway.example.com SIP/2.0 From: ;tag=2 To: Call-ID: 12345600@example.com CSeq: 1 INVITE History-Info: ;index=1, ;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: ;tag=2 To: Call-ID: 12345600@example.com CSeq: 1 INVITE History-Info: ;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 in a 302 response. The response would be as follows: F4 (302 Moved Temporarily) Gateway -> Proxy SIP/2.0 302 Moved temporarily From: ;tag=2 To: ;tag=3 Call-ID: 12345600@example.com CSeq: 1 INVITE Contact: 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 . The forwarded INVITE request would be as follows: F6 (INVITE) û Proxy -> Gateway INVITE sip:Bob@example.com SIP/2.0 From: ;tag=2 To: Call-ID: 12345600@example.com CSeq: 1 INVITE History-Info: ;index=1, ;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]