One document matched: draft-johnston-cuss-sip-uui-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<rfc ipr="trust200811" docName="draft-johnston-cuss-sip-uui-00" 
category="std">

<front>

<title abbrev="SIP UUI for CC">A Mechanism for Transporting User to User Call Control Information in SIP</title>

<author initials="A." surname="Johnston" fullname="Alan Johnston" role="editor">
<organization>Avaya</organization>
 <address>
  <postal>
   <city>St. Louis</city><region>MO</region><code>63124</code> 
  </postal>
  <email>alan.b.johnston@gmail.com</email>
  </address>
</author>

<author initials="J." surname="McMillen" fullname="Joanne McMillen">
<organization>Unaffiliated</organization>
<address>
<email> 
c.joanne.mcmillen@gmail.com
</email>
</address>
</author>

<author initials="J." surname="Rafferty" fullname="James Rafferty">
<organization>Dialogic</organization>
<address>
<email> 
james.rafferty@dialogic.com
</email>
</address>
</author>

<date month="September" year="2010"/>

<abstract>
 <t>
The need for applications using SIP to exchange User to User Information (UUI) data during session establishment has been discussed.  Several approaches to transporting call control User to User Information (UUI) data in SIP have been proposed. As networks move to SIP it is 
important that applications requiring this data can continue to function in SIP 
networks as well as the ability to interwork with this ISDN service for end-to-
end transparency. This document discusses three mechanisms to meet the 
requirements defined in the Requirements for SIP Call Control UUI document.  A 
new SIP header field which bests meets these requirements is proposed.</t>
</abstract>

</front>
<middle>

<section title="Overview">
 <t>  
This document describes the transport of User to User Information (UUI) using SIP <xref target="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) <xref target="Q931" /> and ITU-T Q.763 User to User 
Information Parameter <xref target="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. 
</t><t>
The definition, use cases, requirements, and call flows for SIP call control UUI is 
discussed in <xref target="johnston-cuss-sip-uui-reqs" />.  All references to 
requirement numbers (REQ-N) and figure numbers refer to this draft.  

</t>
</section>

<section title="Terminology">
<t>
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 <xref 
target="RFC2119"/>.
</t>
</section>


 <section title="Possible Mechanisms">
  <t> 
Three possible mechanisms for transporting UUI will be described: MIME body, URI 
parameter, and header field transport.
</t>
<section title="Why INFO is Not Used">
<t>
Since the INFO method <xref target="RFC2976" />, 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 the previous section 
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.
</t>
</section>

<section title="Why Other Protocol Encapsulation UUI Mechanisms are Not Used">
<t>
Other protocols have the ability to transport UUI information.  For example, consider ITU-T Q.931 User to User 
Information  Element (UU IE) <xref target="Q931" /> and ITU-T Q.763 User to User 
Information Parameter <xref target="Q763"/>, as discussed in the requirements draft.  In addition, NSS (Narrowband Signaling System) <xref target="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 make a lot of sense.  Essentially, this is just adding an additional layer in the protocol stack.  SIP is not transporting the UUI, it is encapsulating another protocol, and that protocol is transporting the UUI.  Once there is a mechanism to transport that other protocol using SIP, the UUI transport function is essentially obtained without any additional effort or work.
</t><t>
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.
</t>

</section>

<section title="MIME body Approach">
<t>
One method of transport is to transport the UUI information as a MIME body.  
This is in keeping with the SIP-T architecture <xref target="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.
</t><t>
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, no UAs support this 
capability today, and even defining this is problematic.  For example, do all 
the Content-* header fields have to be escaped as well?  What if the escaped 
Content-Length does not agree with the escaped body? 
</t><t>
An example:
</t>
<figure><artwork><![CDATA[
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?Content-Type=
application/uui&body=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
]]></artwork></figure>
<t>
Note that the <allOneLine> tag convention from <xref target="RFC4475">SIP 
Torture Test Messages</xref> is used to show that there are no line breaks in 
the actual message syntax.
</t><t>
The MIME body approach meets REQs 1-5.  However, it does not meet REQ-6 as 
support for Multipart MIME and escaped bodies in URIs is uncommon in SIP UAs.  

</t>
</section>

<section title="URI Parameter">
<t>
Another proposed approach is to encode the UUI as a URI parameter into the 
Contact or Refer-To URI.
</t>

<figure><artwork><![CDATA[
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT6
F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
]]></artwork></figure>

<t>
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 
<xref target="johnston-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. As a result, this approach does not meet REQ-4.  Note that 
if this same URI was present in a Refer-To header field, the same loss of 
information would occur.
</t>

</section>


<section title="Header Field Approach">
<t>
Another approach that has been proposed is to use a header field to transport 
the UUI information.  The header field would be included in INVITE requests and 
responses and BYE requests and responses, and would pass transparently through 
proxies. For redirection, the header field would be escaped into the Contact or 
Refer-To URI.  This is commonly supported in UAs due to call transfer use cases.  
As a result, the header field approach supports REQs 1-7.  In order to meet REQ-
8, a SIP feature tag is needed which can be included in Supported and Require 
header fields.
</t><t>
The Call-Info header field is related to the UUI information.  However, there 
are a number of important differences:
</t>
<t>
  <list style="symbols"> 
<t>
Call-Info is typically used for rendering to the user.  While some of the UUI 
information may ultimately be rendered to the user, most of the UUI information 
will be consumed by the end device or by an application server.  
</t><t>
Call-Info usually contains a URI pointer to the information instead of the 
actual information itself which does not meet REQ-5. It could be possible to use 
a data URI to carry the UUI directly in this header field.
</t><t>
The use of Call-Info for interworking to and from ISDN networks seems 
problematic.
</t>

</list></t>
<t>
Overall, the overloading of the Call-Info header field for carrying interworked 
UUI does not seem like a good idea.  A separate header field allows for clear 
policy and authorization rules to be used.  For these reasons, a separate header 
field needs to be defined, described here as User-to-User.  
For example, here is an example User-to-User header field from message F1 in 
Figure 1 of <xref target="johnston-cuss-sip-uui-reqs" />:
</t>

<figure><artwork><![CDATA[
User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
 ;content=isdn-uui
]]></artwork></figure>

<t>

For example, here is an escaped User-to-User header field from the redirection 
response F2 of Figure 3:
</t>

<figure><artwork><![CDATA[
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?User-to-User=
56a390f3d2b7310023a%3Bencoding%3Dhex%3Bpurpose%3Disdn-interwork%3B
content%3Disdn-uui>
</allOneLine>
]]></artwork></figure>

<t>
The resulting INVITE F5 would contain:
</t>
<figure><artwork><![CDATA[
User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
 ;content=isdn-uui
]]></artwork></figure>

<t>
An escaped User-to-User header field from the REFER message response F1 of 
Figure 4:
</t>

<figure><artwork><![CDATA[
<allOneLine>
Refer-To: <sip:+12125551212@gateway.example.com?User-to-User=
56a390f3d2b7310023a%3Bencoding%3Dhex%3Bpurpose%3Disdn-interwork%3B
content%3Disdn-uui>
</allOneLine>
]]></artwork></figure>

<t>This would result in the INVITE F4 containing:
</t>
<figure><artwork><![CDATA[
User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
 ;content=isdn-uui
]]></artwork></figure>

</section>


</section>

<section title="Recommendation">
<t>
The recommendation is to define a new SIP header field "User-to-User" to 
transport call control UUI since this mechanism 
best supports the requirements in <xref target="johnston-cuss-sip-uui-reqs" />. 
There are also existing implementations and running code for this header field approach.  A SIP feature tag 
"uui" also needs to be defined so that it can be used in Supported and Require 
header fields to meet REQ-8.
</t>
<t>
To help tag and identify the UUI used with this header field, "purpose", 
"content", and "encoding" parameters are defined.  This specification only 
defines encodings of hex and IA5.  Other 
specifications can define other purposes and contents for this header field per 
the requirements of this document.
</t>
</section>

<section title="Syntax for UUI Header Field">
<t>
   The User-to-User header field can be present in INVITE requests and responses 
only and in BYE requests and responses.
</t>
<t>
   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC 2234 and extends RFC 3261.
</t>
<figure><artwork><![CDATA[
      UUI         = "User-to-User" HCOLON uui-data *(SEMI uui-param)
      uui-data    = token
      uui-param   = enc-param | cont-param | purp-param | generic-param
      enc-param   = "encoding=" ("hex" | "IA5" | token)
      cont-param  = "content=" token
      purp-param  = "purpose=" token
]]></artwork></figure>
<t>
The parameter "encoding=hex" means hexadecimal encoding.  The parameter "encoding=IA5" means Internet Alphabet Number 5 encoding, also known as ITU-T T.50 <xref target="ia5" />.  If the encoding parameter is not present, the default 
value of "hex" MUST be assumed.   Other encoding methods of encoding MAY 
also be standardized.  
</t><t>
User-to-User header fields with different purpose parameters may be present in a request or response.  The number of User-to-User header fields which may be present in a 
request or response is defined for a particular purpose (application).   Any size limitations on the UUI for a particular purpose must be defined by that purpose.  
</t>

<section title="Definition of New Parameter Values">

<t>
This specification defines only the values of "hex", "IA5", and 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.
</t>
<t>
New "encoding" values must reference a common encoding scheme or define the 
exact new encoding scheme.
</t>
<t>
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.
</t>
<t>
New "purpose" values must describe the new purpose 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 purpose. 
</t>

</section>

</section>

<section title="IANA Considerations">

<section title="Registration of Header Field">
<t>

   This document defines a new SIP header field named "User-to-User".
</t><t>
   The following row shall be added to the "Header Fields" section of
   the SIP parameter registry:
</t>
<figure><artwork><![CDATA[

              +------------------+--------------+-----------+
              | Header Name      | Compact Form | Reference |
              +------------------+--------------+-----------+
              | User-to-User     |              | [RFCXXXX] |
              +------------------+--------------+-----------+
]]></artwork></figure>
<t>

   Editor's Note: [RFCXXXX] should be replaced with the designation of
   this document.
</t>
</section>


<section title="Registration of Header Field Parameters">
<t>

   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".
</t><t>
   The following rows shall be added to the "Header Field Parameters and
   Parameter Values" section of the SIP parameter registry:
</t>
<figure><artwork><![CDATA[

   +------------------+----------------+-------------------+-----------+
   | Header Field     | Parameter Name | Predefined Values | Reference |
   +------------------+----------------+-------------------+-----------+
   | User-to-User     | encoding       | hex               | [RFCXXXX] |
   +------------------+----------------+-------------------+-----------+
   | User-to-User     | encoding       | IA5               | [RFCXXXX] |
   +------------------+----------------+-------------------+-----------+
]]></artwork></figure>
<t>

   Editor's Note: [RFCXXXX] should be replaced with the designation of
this document.

</t>
</section>

<section title="Registration of SIP Option Tag">
<t>

This specification registers a new SIP option tag, as per the
   guidelines in Section 27.1 of <xref target="RFC3261" />.
</t>
<t>
   This document defines the SIP option tag "uui".
</t>
<t>
   The following row has been added to the "Option Tags" section of the
   SIP Parameter Registry:
</t>
<figure><artwork><![CDATA[
   +------------+------------------------------------------+-----------+
   | Name       | Description                              | Reference |
   +------------+------------------------------------------+-----------+
   | uui        | This option tag is used to indicate that | [RFCXXXX] |
   |            | a UA supports and understands the        |           |
   |            | User-to-User header field.               |           |
   +------------+------------------------------------------+-----------+
]]></artwork></figure>
<t>

   Editor's Note: [RFCXXXX] should be replaced with the designation of
this document.

</t>
</section>

</section>

<section title="Security Considerations">
<t>
User to user information can be exchanged over SIP on a hop-by-hop or end-to-end 
basis. In some cases, UUI may carry privacy information that would require 
confidentiality and message integrity.  Standard SIP security mechanisms, viz., 
based on TLS, offer these properties per-hop. To preserve multi-hop or
end-end confidentiality and integrity, S/MIME profile MUST be utilized.  Since 
the security requirements and key management of the UUI information are likely 
to be quite different from the SIP signaling transport, another approach would 
be for the UUI information to be encrypted before being passed to SIP for 
transport.
</t>
<t>
Received User-to-User information should only be trusted if it is authenticated 
or if it is received within a trust domain.  For example, Spec-T, defined in 
<xref target="RFC3324" /> could be used to define a trust domain.  When utilized 
by a gateway to map information to or from ISDN Q.931 and ISUP Q.763, 
appropriate policy should be applied based on the PSTN trust domain.
</t>
</section>

<section title="Acknowledgements">
<t>
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.
</t>
</section>

</middle>
<back>

<references title="Informative References">

<reference anchor='Q763'>
<front>
<title>ITU-T Q.763 Signaling System No. 7 - ISDN user part formats and 
codes</title>
</front>
<seriesInfo name='http://www.itu.int/rec/T-REC-Q.931-199805-I/en' value='' />
<format type='HTML' target='http://www.itu.int/rec/T-REC-Q.763-199912-I/en' />
</reference>

<reference anchor='Q931'>
<front>
<title>ITU-T Q.931 User to User Information  Element (UU IE)</title>
</front>
<seriesInfo name='http://www.itu.int/rec/T-REC-Q.931-199805-I/en' value='' />
<format type='HTML' target='http://www.itu.int/rec/T-REC-Q.931-199805-I/en' />
</reference>

<reference anchor='ETSI'>
<front>
<title>ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services Digital Network 
(ISDN); Diversion supplementary services</title>
</front>
</reference>

<?rfc include="reference.RFC.3372" ?>
<?rfc include="reference.RFC.2976" ?>
<?rfc include="reference.RFC.4475" ?>

<reference anchor='Q1980'>
<front>
<title>ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) - Syntax Definition</title>
</front>
<seriesInfo name='http://www.itu.int/itudoc/itu-t/aap/sg11aap/history/q1980.1/q1980.1.html' value='' />
<format type='HTML' target='http://www.itu.int/itudoc/itu-t/aap/sg11aap/history/q1980.1/q1980.1.html' />
</reference>

</references>

<references title="Normative References">

<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.3324" ?>

<reference anchor='johnston-cuss-sip-uui-reqs'>
<front>
<title>Problem Statement and Requirements for Transporting User to User Call Control Information in 
SIP</title>
   <author initials='A.' surname='Johnston' fullname='Alan Johnston'></author>
   <author initials='J.' surname='McMillen' fullname='Joanne McMillen'></author>
   <author initials='L.' surname='Liess' fullname='Laura Liess'></author>
</front>
<seriesInfo name= 'draft-johnston-cuss-sip-uui-reqs-00' value=''/>
<format type='HTML' target='http://www.tools.ietf.org/html/draft-johnston-cuss-sip-uui-reqs' />
</reference>

<reference anchor='ia5'>
<front>
<title>T.50 : International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) - Information technology - 7-bit coded character set for information interchange</title>
</front>
<seriesInfo name='http://www.itu.int/rec/T-REC-T.50-199209-I/en' value='' />
<format type='HTML' target='http://www.itu.int/rec/T-REC-T.50-199209-I/en' />
</reference>

</references>

</back>
</rfc>