| Network Working Group | A. Johnston |
| Internet-Draft | Avaya |
| Intended status: Standards Track | J. Rafferty |
| Expires: March 23, 2012 | Dialogic |
| September 20, 2011 |
A Mechanism for Transporting User to User Call Control Information in SIP
draft-ietf-cuss-sip-uui-02
There is a need for applications using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. This data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI, along with an extension mechanism.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 23, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
This document describes the transport of User to User Information (UUI) using SIP [RFC3261]. Specifically, we discuss a mechanism for the transport of general application UUI and also for the transport of call control related ITU-T Q.931 User to User Information Element (UU IE) [Q931] and ITU-T Q.763 User to User Information Parameter [Q763] data in SIP. UUI is widely used in the PSTN today in contact centers and call centers which are transitioning away from ISDN to SIP. This extension will also be used for native SIP endpoints implementing similar services and interworking with ISDN services.
This mechanism was designed to meet the use cases, requirements, and call flows for SIP call control UUI detailed in [I-D.ietf-cuss-sip-uui-reqs]. All references to requirement numbers (REQ-N) and figure numbers refer to this document.
The mechanism chosen is a new SIP header field, along with a new SIP option tag. The header field carries the UUI information, along with parameters indicating the encoding of the UUI, the application user of the UUI, and optionally the content of the UUI. The header field can be escaped into URIs supporting referral and redirection scenarios. In these scenarios, History-Info is used to indicate the inserter of the UUI. The SIP option tag is used to indicate support for the header field. Support for the header field indicates that a UA is able to extract the information in the UUI and pass it up the protocol stack. Individual applications using the UUI mechanism will utlize media feature tags to indicate that a UA supports a particular application user of UUI. Guidelines for defininig usages of this mechanism are provided.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
This section describes how the User-to-User header field meets the requirements in [I-D.ietf-cuss-sip-uui-reqs]. The header field can be included in INVITE requests and responses and BYE requests and responses, meeting REQ-1 and REQ-2.
For redirection and referral use cases and REQ-3, the header field would be escaped into the Contact or Refer-To URI. Currently, UAs that support attended transfer support the ability to escape a Replaces header field into a Refer-To URI, and when acting upon this URI add the Replaces header field to the triggered INVITE. This logic and behavior is identical for the UUI header field. The UA processing the REFER or the 3xx to the INVITE will need to support the UUI mechanism, as UAs in general do not process unknown escaped header fields.
Since SIP proxy forwarding and retargeting does not affect header fields, the header field meets REQ-4.
The UUI header field will carry the UUI data and not a pointer to the data, so REQ-5 is met.
Since the basic design of the UUI header field is similar to the ISDN UUI service, interworking with PSTN protocols will be straightforward and will be documented in a separate specification, meeting REQ-6.
Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the mechanism and supported applications. REQ-7 relates to support of the UUI header field, while REQ-8 relates to routing based on support of the UUI header field. REQ-7 is met by defining a new SIP option tag 'uui'. The use of a 'Require: uui' in a request, or 'Supported: uui' in an OPTIONS response could be used to require or discover support of the mechanism. The presence of a Supported:uui or Require:uui header field can be used by proxies to route to an appropriate UA, meeting REQ-8. REQ-10 is met by creating a new class of SIP feature tags. For example, the feature tag 'sip.uui-isdn' could be used to indicate support of the ISDN UUI service, or 'sip.uui-app1' could be used to indicate support for a particular application, app1.
Proxies commonly apply policy to the presence of certain SIP header fields in requests by either passing them or removing them from requests. REQ-9 is met by allowing proxies and other intermediaries to remove UUI header fields in a request or response based on policy.
Carrying UUI data elements of at least 129 octets is trivial in the UUI header field, meeting REQ-11. Note that very large UUI elements should be avoided, as SIP header fields have traditionally not been large.
To meet REQ-12 in redirection and referral use cases, History-Info [I-D.ietf-sipcore-rfc4244bis] can be used. In these retargeting cases, the changed Request-URI will be recorded in the History-Info header field along with the identity of the element that performed the retargeting.
The requirement for integrity protection in REQ-13 could be met by the use of an S/MIME signature over a subset of header fields, as defined in Section 23.4 of RFC 3261 "SIP Header Privacy and Integrity using S/MIME: Tunneling SIP". The requirement of REQ-14 for end-to-end privacy could be met using S/MIME or using encryption at the application layer. Note that the use of S/MIME to secure the UUI will result in an additional body being added to the request. Hopwise TLS allows the header field to meet REQ-15 for hop-by-hop security.
This document defines a new SIP header field "User-to-User" to transport call control UUI to meet the requirements in [I-D.ietf-cuss-sip-uui-reqs].
To help tag and identify the UUI used with this header field, "app", "content", and "encoding" parameters are defined. The "app" parameter identifies the application which generates and consumes the UUI information. For the case of interworking with the ISDN UUI Service, the application is unknown, so a value to indicate ISDN UUI Service interworking will be defined. If the "app" parameter is not present, interworking with the ISDN UUI Service MUST be assumed. The "content" parameter identifies the actual content of the UUI data. If not present, the content MUST be assumed to be unknown as it is in the ISDN UUI Service. For newly defined applications using the SIP UUI service, a "content" value MUST be defined and SHOULD be used. The "encoding" parameter indicates the method of encoding the information in the UUI. This specification only defines "encoding=hex". If the "encoding" parameter is not present, "hex" MUST be assumed.
UUI data is considered an opaque series of octets. This mechanism SHOULD NOT be used to convey a URL or URI: the Call-Info header field [RFC3261] is used for this purpose.
The User-to-User header field can be present in INVITE requests and responses only and in BYE requests and responses. Note that only end-to-end responses can be used, e.g. 1xx, 2xx, and 3xx responses.
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 and extends RFC 3261.
UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param)
uui-data = token
uui-param = enc-param / cont-param / app-param / generic-param
enc-param = "encoding" EQUAL ("hex" / token)
cont-param = "content" EQUAL token
app-param = "app" EQUAL token
A single User-to-User header field may be present in a request or a response. Any size limitations on the UUI for a particular purpose must be defined by that application.
It is important for the recipient of UUI to know the identity of the UA that inserted the UUI. In a request without any History-Info [I-D.ietf-sipcore-rfc4244bis] header field, the inserter of the UUI will be the UA identified by the URI in the From header field. In a request with a History-Info header field, the recipient needs to parse the Targeted-to-URIs present (hi-targeted-to-uri) to see if any escaped User-to-User header fields are present. If an escaped User-to-User header field is present and matches the UUI in the request, it indicates that redirection has taken place which has resulted in the UUI inclusion in the request. The inserter of the UUI will be the UA identified by the Targeted-to-URI of the History-Info element prior to the element with the escaped UUI. In a response, the inserter of the UUI will be the UA identified in the To header field of the response. Note that any updates to this identity by use of the SIP Connected Identity extension [RFC4916] will update this information.
For an example of History-Info and redirection, consider Figure 2 from [I-D.ietf-cuss-sip-uui-reqs] where the Originating UA is Carol, the Redirector Bob, and the Terminating UA Alice. The INVITE F4 containing UUI could be:
INVITE sips:alice@example.com SIP/2.0 Via: SIP/2.0/TLS lab.example.com:5061 ;branch=z9hG4bKnashds9 To: Bob <sips:bob@example.com> From: Carol <sips:carol@example.com>;tag=323sf33k2 Call-ID: dfaosidfoiwe83ifkdf Max-Forwards: 70 Contact: <sips:carol@lab.example.com> Supported: histinfo User-to-User: 342342ef34;encoding=hex History-Info: <sips:bob@example.com>;index=1 <allOneLine> History-Info: <sips:alice@example.com?Reason=SIP%3Bcause%3D302 &User-to-User=342342ef34%3Bencoding%3Dhex>;index=1.1;rc=1 </allOneLine>
Without the redirection captured in the History-Info, Alice would conclude the UUI was inserted by Carol. However, the History-Info containing UUI (index=1.1) indicates that the inserter was Bob (index=1).
To enable the inserter identity of UUI, UAs supporting this mechanism SHOULD support History-Info [I-D.ietf-sipcore-rfc4244bis] and include Supported: histinfo in all requests and responses.
All applications using this SIP UUI mechanism must publish a standards track RFC which describes the usage. The SIP UUI mechanism is applicable in the following situations:
This mechanism is not applicable in the following situations:
This specification defines only the value of "hex" for the "encoding" parameter. New values can be defined and added to the IANA registry with a standards track RFC, which needs to discuss the issues in this section.
New "encoding" values must reference a common encoding scheme or define the exact new encoding scheme.
New "content" values must describe the content of the UUI and give some example use cases. The default "encoding" and other allowed encoding methods must be defined for this new content.
New "app" values must describe the new application which is utilizing the UUI data and give some example use cases. The default "content" value and other allowed contents must be defined for this new purpose. Any restrictions on the size of the UUI data must be described for the new application. In addition, it is recommended that a Media Feature tag be defined per RFC 3840 [RFC3840] to indicate support for this application usage of UUI. For example, the media feature tag sip.uui-app1 could be defined to indicate support for an app named app1. The definition of a new SIP feature tag for this application is NOT RECOMMENDED unless there are other SIP behaviors needed to implement this feature.
For an example UUI usage definition, see [I-D.drage-cuss-sip-uui-isdn].
This document defines a new SIP header field named "User-to-User".
The following row shall be added to the "Header Fields" section of the SIP parameter registry:
+------------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| User-to-User | | [RFCXXXX] |
+------------------+--------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of this document.
This document defines the parameters for the header field defined in the preceding section. The header field "User-to-User" can contain the parameters "encoding", "content", and "purpose".
The following rows shall be added to the "Header Field Parameters and Parameter Values" section of the SIP parameter registry:
+------------------+----------------+-------------------+-----------+ | Header Field | Parameter Name | Predefined Values | Reference | +------------------+----------------+-------------------+-----------+ | User-to-User | encoding | hex | [RFCXXXX] | +------------------+----------------+-------------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of this document.
This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of [RFC3261].
This document defines the SIP option tag "uui".
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
+------------+------------------------------------------+-----------+ | Name | Description | Reference | +------------+------------------------------------------+-----------+ | uui | This option tag is used to indicate that | [RFCXXXX] | | | a UA supports and understands the | | | | User-to-User header field. | | +------------+------------------------------------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of this document.
User to user information can potentially carry sensitive information that might require privacy or integrity protection. Standard deployed SIP security mechanisms such as TLS transport, offer these properties on a hop-by-hop basis. To preserve multi-hop or end-to-end confidentiality and integrity of UUI, approaches using S/MIME can be used, as discussed in the draft. However, the lack of deployment of these mechanisms means that applications can not in general rely on them. As such, applications are encouraged to utilize their own security mechanisms.
Two other possible mechanisms for transporting UUI will be described: MIME body and URI parameter transport.
Since the INFO method [RFC6086], was developed for ISUP interworking of user-to-user information, it might seem to be the logical choice here. For non-call control user-to-user information, INFO can be utilized for end to end transport. However, for transport of call control user-to-user information, INFO can not be used. As the call flows in [I-D.ietf-cuss-sip-uui-reqs] show, the information is related to an attempt to establish a session and must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases.
Other protocols have the ability to transport UUI information. For example, consider the ITU-T Q.931 User to User Information Element (UU IE) [Q931] and the ITU-T Q.763 User to User Information Parameter [Q763]. In addition, NSS (Narrowband Signaling System) [Q1980] is also able to transport UUI information. Should one of these protocols be in use, and present in both User Agents, then utilizing these other protocols to transport UUI might be a logical solution. Essentially, this is just adding an additional layer in the protocol stack. In these cases, SIP is not transporting the UUI; it is encapsulating another protocol, and that protocol is transporting the UUI. Once a mechanism to transport that other protocol using SIP exists, the UUI transport function is essentially obtained without any additional effort or work.
However, the authors believe that SIP needs to have its own native UUI transport mechanism. It is not reasonable for a SIP UA to have to implement another entire protocol (either ISDN or NSS, for example) just to get the very simple UUI transport service. Of course, this work does not preclude anyone from using other protocols with SIP to transport UUI information.
One method of transport is to use a MIME body. This is in keeping with the SIP-T architecture [RFC3372] in which MIME bodies are used to transport ISUP information. Since the INVITE will normally have an SDP message body, the resulting INVITE with SDP and UUI will be multipart MIME. This is not ideal as many SIP UAs do not support multipart MIME INVITEs.
A bigger problem is the insertion of a UUI message body by a redirect server or in a REFER. The body would need to be encoded in the Contact URI of the 3xx response or the Refer-To URI of a REFER. Currently, the authors are not aware of any UAs that support this capability today for any body type. As such, the complete set of semantics for this operation would need to be determined and defined. Some issues will need to be resolved, such as, do all the Content-* header fields have to be escaped as well? And, what if the escaped Content-Length does not agree with the escaped body?
Since proxies cannot remove a body from a request or response, it is not at all clear how this mechanism could meet REQ-9.
The requirement for integrity protection could be met by the use of an S/MIME signature over the body, as defined in Section 23.3 of RFC 3261 "Securing MIME bodies". Alternatively, this could be achieved using RFC 4474 [RFC4474]. The requirement for end-to-end privacy could be met using S/MIME encryption or using encryption at the application layer. However, note that neither S/MIME or RFC 4474 enjoys deployment in SIP today.
An example:
<allOneLine> Contact: <sip:+12125551212@gateway.example.com?Content-Type= application/uui&body=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs> </allOneLine>
Note that the <allOneLine> tag convention from SIP Torture Test Messages [RFC4475] is used to show that there are no line breaks in the actual message syntax.
As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5, REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible, although the authors do not have a specific mechanism to propose. Meeting REQ-3 is problematic, but not impossible for this mechanism. However, this mechanism does not seem to be able to meet REQ-9.
Another proposed approach is to encode the UUI as a URI parameter. This UUI parameter could be included in a Request-URI or in the Contact URI or Refer-To URI. It is not clear how it could be transported in a responses which does not have a Request-URI, or in BYE requests or responses.
<allOneLine> Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT6 F5iJ90m6mvuTS4OK05M0vDk0Q4Xs> </allOneLine>
An INVITE sent to this Contact URI would contain UUI in the Request-URI of the INVITE. The URI parameter has a drawback in that a URI parameter carried in a Request-URI will not survive retargeting by a proxy as shown in Figure 2 of [I-D.ietf-cuss-sip-uui-reqs]. That is, if the URI is included with an Address of Record instead of a Contact URI, the URI parameter in the Reqeuest-URI will not be copied over to the Contact URI, resulting in the loss of the information. Note that if this same URI was present in a Refer-To header field, the same loss of information would occur.
The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and REQ-11. It is possible the approach could meet REQ-12 and REQ-13. The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and REQ-14.
Joanne McMillen was a major contributor and co-author of earlier versions of this document. Thanks to Spencer Dawkins, Keith Drage, Vijay Gurbani, and Laura Liess for their review of the document. The authors wish to thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for their comments.