One document matched: draft-ietf-cuss-sip-uui-reqs-00.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-00" 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" 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="L." surname="Liess" fullname="Laura Liess">
<organization>Deutsche Telekom AG</organization>
<address>
<email>
laura.liess.dt@gmail.com
</email>
</address>
</author>
<date month="November" year="2010"/>
<workgroup>CUSS WG</workgroup>
<abstract>
<t>
This document introduces the transport of call control related User to User Information (UUI) in 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. A common example in another protocol is the ISDN User to User Information Service. 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 requirements and approaches. This extension will also be used for native SIP endpoints implementing similar services and interworking with ISDN services. Example use cases include an exchange between two user agents, retargeting by a proxy, and redirection. An example application is an Automatic Call Distributor (ACD) in a contact center. </t>
</abstract>
</front>
<middle>
<section title="Overview">
<t>
This document describes the transport of User to User Information (UUI) during session setup. This section will introduce UUI and explain 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 the originator of the session and the terminator of the session. That is, the application interacts with the User Agent Client (UAC) and User Agent Server (UAS). In order to function, the application needs 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 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 would not provide any benefits and instead could create cross layer coupling. Secondly, it is neither feasible nor desirable for a SIP User Agent to understand the information but instead the goal is for the User Agent to pass the information as efficiently as possible to an 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 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>
In the rest of this document, the requirements are discussed with use cases. Five different use case call flows are then discussed.
</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="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 shown in Figure 2.
</t>
<figure><artwork><![CDATA[
Originator Proxy Terminator 2
| | |
| INVITE (UUI) F1 | |
|------------------->| INVITE (UUI) F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
]]></artwork></figure>
<t>
Figure 2. Call flow with Proxy Retargeting.</t>
<t>
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.
</t>
<t>
In redirection scenarios, if the Redirect Server is not in the same administrative domain as the Terminator, the Redirect Server must not remove or replace any UUI in the initial INVITE. In Figure 3, this means that if F1 included UUI, the Redirect Server could not modify or replace the UUI in F2. However, if the Redirect Server and the Terminator are part of the same administrative domain, they may have a policy allowing the Redirect Server to modify or rewrite UUI information. In fact, many UUI uses within an Enterprise rely on this feature to work today in ISDN.
</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 3. Call flow with UUI exchanged between Redirect Server and Terminator</t>
<t>
A common 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 rendered 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 maintain UUI in these scenarios is critical.
</t>
</section>
<section title="Referral">
<t>
In this scenario, application uses a UA 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 call control. In some cases, this call flow is used in place of the redirection call flow, but where immediately upon answer, the REFER is sent. This scenario is shown in Figure 4.
</t>
<figure><artwork><![CDATA[
Originator Referrer Terminator
| | |
| REFER (UUI) F1 | |
|<-------------------| |
| 202 Accepted F2 | |
|------------------->| |
| NOTIFY (100 Trying) F3 |
|------------------->| |
| 200 OK F4 | |
|<-------------------| |
| INVITE (UUI) F5 | |
|---------------------------------------->|
| 200 OK F6 |
|<----------------------------------------|
| ACK F7 |
|---------------------------------------->|
| NOTIFY (200 OK) F8 | |
|------------------->| |
| 200 OK F9 | |
|<-------------------| |
]]></artwork></figure>
<t>Figure 4. Call flow with transfer after answer.</t>
</section>
</section>
<section title="Requirements">
<t>
This section discusses the requirements for the transport of call control related user to user information (UUI). We define call control UUI as information that is generated, transported, and consumed at the time of call setup (i.e. during a pending INVITE transaction). The information can be used for call routing, alerting, call distribution, or simply rendering. The exact usage and semantics of call control UUI is out of scope - SIP is simply providing the transport function for this, in the same manner as the ISDN service provides in the PSTN. Non-call control UUI can be sent using the INFO method, and is outside the scope of this work.
</t><t>
REQ-1: The mechanism will allow user agents (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 and 200 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 to INVITEs.
</t>
<t><list><t>
SIP messages covered by this include 3xx responses to INVITE and REFER 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 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 will complicate interworking with the PSTN.
</t></list></t>
<t>
REQ-6: The mechanism will minimize reliance on SIP extensions or uncommon SIP behavior.
</t>
<t><list><t>
OPEN ISSUE: Does this requirement need to be reworked, or does it not provide any useful value?
</t></list></t>
<t>
REQ-7: The mechanism will support interworking with call control related DSS1 information elements or QSIG information elements or ISUP parameters.
</t>
<t>
REQ-8: The mechanism will allow the inserter of UUI to be sure that the UAS understands the call control UUI mechanism.
</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 ISDN UUI service. This mechanism is related to REQ-10.
</t></list></t>
<t>
REQ-9: The mechanism will allow proxies to remove a particular type 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 types or application usages of UUI another UA understands or supports.
</t>
<t><list><t>
OPEN ISSUE: For the ISDN Service, is there value in extending this down the protocol discriminator, which is the first octet of the ISDN UUI information?
</t></list></t>
<t>
REQ-11: The solution MUST 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>
REQ-12: The recipient of UUI MUST 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>
</section>
<section title="Security Considerations">
<t>
UUI information can contain sensitive information. UUI transported over SIP may need integrity protection, confidentiality, and the ability to determine the identity of the source of the UUI.
</t><t>
Since the security requirements and key management of the UUI information are likely to be quite different from the SIP signaling transport, applications using this mechanism to transport information requiring confidentiality will likely perform their own encryption at the application layer before being passed to SIP for transport.
</t>
</section>
<section title="Acknowledgements">
<t>
Thanks to Spencer Dawkins, Keith Drage, 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>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3372" ?>
<?rfc include="reference.RFC.2976" ?>
<?rfc include="reference.RFC.3515"?>
<?rfc include="reference.RFC.3324" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:57:15 |