One document matched: draft-ietf-cuss-sip-uui-reqs-04.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<rfc ipr="trust200811" docName="draft-ietf-cuss-sip-uui-reqs-04" category="info">
<front>
<title abbrev="SIP UUI Reqs">Problem Statement and Requirements for Transporting User to User Call Control Information in SIP</title>
<author initials="A." surname="Johnston" fullname="Alan Johnston">
<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="L." surname="Liess" fullname="Laura Liess">
<organization>Deutsche Telekom AG</organization>
<address>
<email>
laura.liess.dt@gmail.com
</email>
</address>
</author>
<date month="August" year="2011"/>
<workgroup>CUSS WG</workgroup>
<abstract>
<t>
This document introduces the transport of call control related User to User Information (UUI) using
the Session Initiation Protocol (SIP), and develops several requirements for a new SIP mechanism.
Some SIP sessions are established by or related to a non-SIP application. This application may
have information that needs to be transported between the SIP User Agents during session
establishment. In addition to interworking with the ISDN UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. </t>
</abstract>
</front>
<middle>
<section title="Overview">
<t>
This document describes the transport of User to User Information (UUI) during SIP session setup.
This section introduces UUI and explains how it relates to SIP.
</t><t>
We define SIP UUI information as application-specific information that is related to a session being
established using SIP. It is assumed that the application is running in both endpoints in a two
party session. That is, the application interacts with both the User Agents in a SIP session. In order to function
properly, the application needs a small piece of information, the UUI, to be transported at the time
of session establishment. This
information is essentially opaque data to SIP - it is unrelated to SIP routing, authentication, or
any other SIP function. This application can be considered to be operating at a higher layer on the
protocol stack. As a result, SIP should not interpret, understand, or perform any operations on the
UUI. Should this not be the case, then the information being transported is not considered UUI, and
another SIP-specific mechanism will be needed to transport the information (such as a new header field).
</t><t>
UUI is defined this way for two reasons. Firstly, this supports a strict layering of protocols and data.
Providing information and understanding of the UUI to the transport layer (SIP in this case) would
not provide any benefits and instead could create cross layer coupling. Secondly, it is neither
feasible nor desirable for a SIP User Agent (UA) to understand the information; instead the goal
is for the UA to simply pass the information as efficiently as possible to the application which
does understand the information.
</t><t>
An important application is the interworking with User to User Information (UUI) in ISDN, specifically, the transport of the 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. ISDN UUI is widely used in the PSTN today in contact centers and call centers. These applications are currently transitioning away from using ISDN for session establishment to using SIP. Native SIP endpoints will need to implement a similar service and be able to interwork with this ISDN service.
</t><t>
Note that the distinction between call control UUI and non-call control UUI is very important. SIP already has a mechanism for sending arbitrary UUI information between UAs during a session or dialog - the SIP INFO <xref target="RFC2976" /> method. Call control UUI, in contrast, must be exchanged at the time of setup and needs to be carried in the INVITE and a few other methods and responses. Applications that exchange UUI but do not have a requirement that it be transported and processed during call setup can simply use SIP INFO and do not need a new SIP extension.
</t><t>
In this document, four different use case call flows are discussed. Next, the requirements for call control UUI transport are discussed.
</t>
</section>
<section title="Use Cases">
<t>
This section discusses four use cases for the transport of call control related user to user information. What is not discussed here is the transport of non-call control UUI which can be done using the SIP INFO method. These use cases will help motivate the requirements for SIP call control UUI.
</t>
<section title="User Agent to User Agent">
<t>
In this scenario, the originator UA includes UUI in the INVITE sent through a proxy to the terminating UA. The terminator can use the UUI in any way. If it is an ISDN gateway, it could map the UUI into the appropriate DSS1 information element or QSIG information element or ISUP parameter. Alternatively, the using application might render the information to the user, or use it during alerting or as a lookup for a screen pop. In this case, the proxy does not need to understand the UUI mechanism, but normal proxy rules should result in the UUI being forwarded without modification. This call flow is shown in Figure 1.
</t>
<figure><artwork><![CDATA[
Originator Proxy Terminator
| | |
| INVITE (UUI) F1 | |
|------------------->| INVITE (UUI) F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
]]></artwork></figure>
<t>
Figure 1. Call flow with UUI exchanged between Originator and Terminator. </t>
</section>
<section title="Proxy Retargeting">
<t>
In this scenario, the originator UA includes UUI in the INVITE sent through a proxy to the terminating
UA. The proxy retargets the INVITE, sending it to a different termination UA. The UUI information
is then received and processed by the terminating UA. This call flow is identical to Figure 1 but
with a different destination for the INVITE. The UUI in the INVITE needs to be passed unchanged
through this proxy retargeting operation.
</t>
</section>
<section title="Redirection">
<t>
In this scenario, UUI is inserted by an application which utilizes a SIP redirect server. The UUI is then included in the INVITE sent by the Originator to the Terminator. In this case, the Originator does not necessarily need to support the UUI mechanism but does need to support the SIP redirection mechanism used to include the UUI information. Two examples of UUI with redirection (transfer and diversion) are defined in <xref target="ANSII" /> and <xref target="ETSI" />.
</t>
<t>
Note that this case may not precisely map to an equivalent ISDN service use case. This is because there is no one-to-one mapping between elements in a SIP network and elements in an ISDN network. Also, there is not an exact one-to-one mapping between SIP call control and ISDN call control. However, this should not prevent the usage of SIP call control UUI in these cases. Instead, these slight differences between the SIP UUI service and the ISDN service need to be carefully noted and discussed in an interworking specification.
</t>
<t>
Figure 2 shows this scenario, with the Redirect inserting UUI which is then included in the INVITE F4 send to the Terminator.
</t>
<figure><artwork><![CDATA[
Originator Redirect Server Terminator
| | |
| INVITE F1 | |
|------------------->| |
| 302 Moved (UUI) F2 | |
|<-------------------| |
| ACK F3 | |
|------------------->| |
| INVITE (UUI) F4 | |
|---------------------------------------->|
| 200 OK F5 |
|<----------------------------------------|
| ACK F6 |
|---------------------------------------->|
]]></artwork></figure>
<t>
Figure 2. Call flow with UUI exchanged between Redirect Server and Terminator.</t>
<t>
A common example application of this call flow is an Automatic Call Distributer (ACD) in a PSTN contact center.
The originator would be a PSTN gateway. The ACD would act as a Redirect Server, inserting UUI based
on called number, calling number, time of day, and other information. The resulting UUI would be
passed to the agent's handset which acts as the Terminator. The UUI could be used to lookup
information for rendering to the agent at the time of call answering.
</t>
<t>
This redirection scenario, and the referral scenario in the next section, are the most important
scenarios for contact center applications. Incoming calls to a contact center almost always are
redirected or referred to a final destination, sometimes multiple times, based on collected
information and business logic. The ability to pass along UUI in these call redirection scenarios is critical.
</t>
</section>
<section title="Referral">
<t>
In this scenario, the application uses a UA to initiate a referral, which causes an INVITE to be
generated between the Originator and Terminator with UUI information inserted by the Referrer UA.
Note that this REFER <xref target="RFC3515" /> could be part of a transfer operation or it might be
unrelated to an existing call, such as out-of-dialog REFER. In some cases, this call
flow is used in place of the redirection call flow where immediately upon answer, the REFER is sent.
This scenario is shown in Figure 3.
</t>
<figure><artwork><![CDATA[
Originator Referrer Terminator
| | |
| REFER (UUI) F1 | |
|<-------------------| |
| 202 Accepted F2 | |
|------------------->| |
| INVITE (UUI) F3 | |
|---------------------------------------->|
| NOTIFY (100 Trying) F4 |
|------------------->| |
| 200 OK F5 | |
|<-------------------| |
| 200 OK F6 |
|<----------------------------------------|
| ACK F7 |
|---------------------------------------->|
| NOTIFY (200 OK) F8 | |
|------------------->| |
| 200 OK F9 | |
|<-------------------| |
]]></artwork></figure>
<t>Figure 3. Call flow with Referral and UUI.</t>
</section>
</section>
<section title="Requirements">
<t>
This section states the requirements for the transport of call control related user to user information (UUI).
</t><t>
REQ-1: The mechanism will allow UAs to insert and receive UUI data in SIP call setup requests and responses.
</t>
<t><list><t>
SIP messages covered by this include INVITE requests and end-to-end responses to the INVITE, which includes 18x, 200, and 3xx responses.
</t></list></t>
<t>
REQ-2: The mechanism will allow UAs to insert and receive UUI data in SIP dialog terminating requests and responses.
</t>
<t><list><t>
Q.931 UUI supports inclusion in release and release completion messages. SIP messages covered by this include BYE and 200 OK responses to a BYE.
</t></list></t>
<t>
REQ-3: The mechanism will allow UUI to be inserted and retrieved in SIP redirects and referrals.
</t>
<t><list><t>
SIP messages covered by this include REFER requests and 3xx responses to INVITE requests.
</t></list></t>
<t>
REQ-4: The mechanism will allow UUI to be able to survive proxy retargeting or any other form of redirection of the request.
</t>
<t><list><t>
Retargeting is a common method of call routing in SIP, and must not result in the loss of user to user information.
</t></list></t>
<t>
REQ-5: The mechanism should not require processing entities to dereference a URL in order to retrieve the UUI information.
</t>
<t><list><t>
Passing a pointer or link to the UUI information will not meet the real-time processing considerations and would complicate interworking with the PSTN.
</t></list></t>
<t>
REQ-6: The mechanism will support interworking with call control related DSS1 information elements or QSIG information elements or ISUP parameters.
</t>
<t>
REQ-7: The mechanism will allow a UAC to learn that a UAS understands the UUI mechanism.
</t><t>
REQ-8: The mechanism will allow a UAC to require that a UAS understands the call control UUI mechanism have a request routed based on this information. If the UAS does not understand the mechanism, the request will fail.
</t>
<t><list><t>
This could be useful in ensuring that a request destined for the PSTN is routed to a gateway that supports the UUI mechanism rather than an otherwise equivalent PSTN gateway that does not support the ISDN mechanism. Note that support of the UUI mechanism does not, by itself, imply that a particular application is supported - see REQ-10.
</t></list></t>
<t>
REQ-9: The mechanism will allow proxies to remove a particular application usage of UUI information from a request or response.
</t>
<t><list><t>
This is a common security function provided by border elements to header fields such as Alert-Info or Call-Info URIs.
</t></list></t>
<t>
REQ-10: The mechanism will provide the ability for a UA to discover which application usages of UUI another UA understands or supports.
</t>
<t><list><t>
The creation of a registry of application usages for the SIP UUI mechanism is implied by this requirement. The ISDN Service utilizes a field known as the protocol discriminator, which is the first octet of the ISDN UUI information, for this purpose.
</t></list></t>
<t>
REQ-11: The solution will provide a mechanism of transporting at least 128 octets of user data and a one octet protocol discriminator, i.e. 129 octets in total.
</t>
<t><list><t>
There is the potential for non-ISDN services to allow UUI to be larger than 128 octets. However, users of the mechanism will need be cognizant of the size of SIP messages and the ability of parsers to handle extremely large values.
</t></list></t>
<t>
REQ-12: The recipient of UUI will be able to determine the entity that inserted the UUI. It is acceptable that this is performed implicitly where it is known that there is only one other end UA involved in the dialog. Where that does not exist, some other mechanism will need to be provided.
</t>
<t><list><t>
This requirement comes into play during redirection, retargeting, and referral scenarios.
</t></list></t>
</section>
<section title="Security Considerations">
<t>
The security requirements for the SIP UUI mechanism are described in this section. It is important
to note that UUI security is jointly provided at the application layer and at the SIP layer. As
such, is important for application users of SIP UUI to know the realistic level of security used and
deployed in SIP, and not assume that some rarely deployed SIP level security mechanism is in place.</t>
<t>
There are two main security models that need to be addressed by the SIP UUI mechanism. One model
treats the SIP layer as untrusted and requires end-to-end integrity protection and/or encryption.
This model can be achieved by providing these security services at a layer above SIP. In this case,
the application integrity protects and/or encrypts the UUI information before passing it to the SIP
layer. This method has two advantages: it does not assume or rely on end-to-end security mechanisms
in SIP which have virtually no deployment, and allows the application which understands the contents
of the UUI to apply a proper level of security. The other approach is for the application to pass
the UUI without any protection to the SIP layer and require the SIP layer to provide this security.
This approach is possible in theory, although its practical use would be extremely limited. The SIP
UUI mechanisim should support both of these approaches.
</t>
<t>
The other model utilizes a trust domain and relies on perimeter security at the SIP layer. This is
the security model of the PSTN and ISDN where UUI is commonly used today. This approach uses hop-by-hop
security mechanisms and relies on border elements for filtering and application of policy. This approach
is used today in SIP UUI deployments. However, there is no requirement that an intermediary element
be able to read or interpret the UUI, as UUI only has end-to-end significance. An intermediary
element may remove a UUI element based on policy, however. This SIP UUI mechanism
needs to support this model.
</t>
<t>
The next three requirements capture the SIP UUI security requirements.
</t>
<t>
REQ-13: The mechanism will allow integrity protection of the UUI.
</t>
<t><list><t>
This allows the UAS to be able to know that the UUI has not been modified or tampered with by
intermediaries. This property is not guaranteed by the protocol in the ISDN application.
</t></list></t>
<t>
REQ-14: The mechanism will allow end-to-end privacy of the UUI.
</t>
<t><list><t>
Some UUI may contain private or sensitive information and may require different security handling
from the rest of the SIP message. Note that this property is not available in the ISDN application.
</t></list></t>
<t>
REQ-15: The mechanism will allow both end-to-end and hop-by-hop security models.
</t>
<t><list><t>
The hop-by-hop model is required by the ISDN UUI service.
</t></list></t>
</section>
<section title="Acknowledgements">
<t>
Thanks to Joanne McMillen who was a co-author of earlier versions of this specification. Thanks to Spencer Dawkins, Keith Drage, Dale Worley, and Vijay Gurbani for their review of earlier versions of this document. The authors wish to thank Christer Holmberg, Frederique Forestie, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for their comments on this topic.
</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.3261" ?>
<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='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='ANSII'>
<front>
<title>ANSI T1.643-1995, Telecommunications-Integrated Services Digital Network (ISDN)-Explicit Call Transfer Supplementary Service</title>
</front>
</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>
<reference anchor='QSIG'>
<front>
<title>ECMA-143 "Private Integrated Services Network (PISN) - Circuit Mode Bearer Services -
Inter-Exchange Signalling Procedures and Protocol" December 2001</title>
</front>
</reference>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2976" ?>
<?rfc include="reference.RFC.3372" ?>
<?rfc include="reference.RFC.3515" ?>
<?rfc include="reference.RFC.3324" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:55:31 |