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

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

<front>

<title abbrev="SIP UUI for CC">Interworking ISDN Call Control User Information with SIP</title>

<author initials="K." surname="Drage" fullname="Keith Drage">
<organization>Alcatel-Lucent</organization>
<address>
  <postal>
   <street>Quadrant, Stonehill Green, Westlea</street>
   <city>Swindon</city><country>UK</country> 
  </postal>
<email> 
keith.drage@alcatel-lucent.com
</email>
</address>
</author>

<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="J." surname="McMillen" fullname="Joanne McMillen">
<organization>Unaffiliated</organization>
<address>
<email> 
c.joanne.mcmillen@gmail.com
</email>
</address>
</author>


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

<abstract>
 <t>
The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. 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 defines a usage of the User-to-User header field to enable interworking with this ISDN service.
</t>
<t>
This document is covers the interworking with both public ISDN and private ISDN capabilities, so the interworking with QSIG will also be addressed.
</t>

</abstract>

</front>
<middle>

<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="Overview">
 <t>  
This document describes a usage of the User-to-User header field defined in <xref target="johnston-cuss-sip-uui" />  to enable the transport of User to User Information (UUI) in ISDN interworking scenarios using SIP <xref target="RFC3261" />.    Specifically, this document discuss the interworking of call control related ITU-T DSS1 User-user information element<xref target="Q931" />, <xref target="Q957.1" /> 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.
</t>
</section>

<section title="Summary of the ISDN User-to-User Service">

<section title="The service">
<t>
ISDN defines a number of related services. Firstly there is a user signalling bearer service, which uses the information elements / parameters in the signalling channel to carry the data, and does not establish a related circuit-switched connection. For DSS1, this is specified in ITU-T Recommendation Q.931 section 3.3 and section 7 <xref target="Q931" />. It also defines a user-to-user signalling supplementary service, which uses the information elements / parameters in the signalling channel to carry additional data, but which is used in conjunction with the establishment of a related circuit-switched connection. This reuses the same information elements / parameters as the user signalling bearer service, with the addition of other signalling information, and for DSS1 this is specified in ITU-T Recommendation Q.957.1 <xref target="Q957.1" />.
</t>

<t>
ISDN defines three variants of the user-to-user signalling supplementary service as follows:
</t>

    <list style='hanging'>
        <t hangText="UUS1:">
User-to-user information exchanged during the setup and clearing phases of a call, by transporting User-to-user information element within call control messages. This in itself has two subvariants, UUS1 implicit and UUS1 explicit. UUS1 explicit uses additional supplementary service control information to control the request and granting of the service, as in USS2 and UUS3. In UUS1 implicit, it is the presence of the user signalling data itself that constitutes the request for the service. UUS1 explicit as a result also allows the requester to additionally specify whether the parallel circuit-switched connection should proceed if the UUS1 service cannot be provided (preferred or required).
        </t>

        <t hangText="UUS2:">
User-to-user information exchanged from the sender's point of view during call establishment, between the DSS1 ALERTING and DSS1 CONNECT messages, within DSS1 USER INFORMATION messages; and
        </t>

        <t hangText="UUS3:">
User-to-user information exchanged while a call is in the Active state, within DSS1 USER INFORMATION messages.
        </t>
    </list>

<t>
The service is always requested by the calling user.
</t>

<t>
This document defines only the application of the ISDN UUS1 implicit supplementary service to interworking scenarios, this being the most widely deployed and used of the various ISDN user-to-user services, and indeed the one that matches the requirements specified in draft-johnston-cuss-sip-uui-reqs.
</t>

<t>
The ISDN UUS1 service has the following additional characteristics as to the data that can be transported:
</t>
    <list>
        <t>
The maximum number of octets of user information that can be transported in 128 octets. It is noted that some early ISDN implementations had a limitation of 32 octets, but it is understood that these are not currently deployed.
        </t>
        <t>
The content of the user information octets is described by a single octet protocol discriminator (see table 4-26 of ITU-T Recommendation Q.931) <xref target="Q931" />. That protocol descriminator may describe the protocol used within the user data, the structure of the user data, or leave it entirely open. Note that not all values within the protocol discriminator necessarily make sense for use in the user to user service, as the content is aligned with the protocol discriminator that appears at the start of all DSS1 messages (see table 4-1 of ITU-T Recommendation Q.931) <xref target="Q931" />.
        </t>
        <t>
Only a single user information package can be transported in each message.
        </t>

        <t>
The ISDN service works without encryption or integrity protection. The user trusts the intermediate network elements, and therefore the operator of those elements, not to modify the data, and to deliver all the data to the remote user. On a link by link basis, message contents are protected at layer 2 by standard CRC mechanisms - this allows loss on a link level basis to be detected, but does not guard against fraudulent attacks on the link itself. This does not prevent the use of additional encryption or integrity protection within the payload itself, although the limit on the size of the payload (128 octets) will restrict this.
        </t>

    </list>
</section>

<section title="Impacts of the ISDN service on SIP operation">

<t>
The ISDN service has the following impacts that need to be understood within the SIP environment.
</t>

    <list style='hanging'>
        <t hangText="Call transfer">
ISDN call transfer cancels all user-to-user supplementary services. In the ISDN, if user-to-user data is required after call transfer, then UUS3 has to be renegotiated, which is not provided by this SIP extension. The impact of this restriction on the SIP environment is that UUI header fields cannot be exchanged in transactions clearing down the SIP dialog after call transfer has occurred.
        </t>

        <t hangText="Conference">
ISDN conferencing allows the user to still exchange user-to-user data after the conference is created. As far as UUS1 is concerned, this means that when an individual party clears, those clearing messages can still contain user-to-user data. As a conferee this is sent to the conference controller. As the conference controller, as this effectively clears the conference, it can be broadcast to all conferees, or sent to individual conferees [OPEN ISSUE - CHECK THIS IN THE PROTOCOL - DOES IT REQUIRE EXPLICIT].
        </t>

        <t>
The ISDN three-party supplementary service is similar in many ways to conferencing, but is signalled using a different mechanism. This means that on clearing, the controller using UUS1 implicit does have the choice of sending data to either or both remote users.
        </t>

        <t hangText="Diversion">
When ISDN diversion occurs, any UUS1 user-to-user data is sent to the forwarded-to-user (assuming that the call meets requirements for providing the service - this is impacted by the explicit service only). If the type of diversion is such that the call is also delivered to the forwarding user, they will also receive any UUS1 user-to-user data.
        </t>

    </list>

<t>
Contributors note: The above list needs to be studied further in regard to private ISDN service definitions, e.g. for the interworking of SIP and QSIG.
</t>
</section>
</section>

<section title="Relation to SIP-T">
<t>
A method of transport of ISDN UUI is to use SIP-T <xref target="RFC3372" /> and transport the UUI information end-to-end, as part of an ISUP message or QSIG message) as a MIME body.  If the SIP-T method of encapsulation of ISDN instead of interworking is used, this is a reasonable mechanism and does not require any extensions to existing SIP-T.  However, if true ISDN interworking is being done, this approach is not reasonable.  Instead, the better approach is to interwork the ISDN UUI using the native SIP UUI transport mechanism, the User-to-User header field.  The rest of this document describes this approach.
</t>
</section>

<section title="Transition away from ISDN">
<t>
This interworking usage of the SIP UUI mechanism will likely begin with one User Agent being an ISDN gateway while the other User Agent is a native SIP endpoint.  As networks transition away from ISDN, it is possible that both User Agents could become native SIP endpoints.  In this case, there is an opportunity to transition away from this ISDN usage to a more general usage of <xref target="johnston-cuss-sip-uui" />.  This will be possible when both endpoints are aware of the actual application using the UUI.  
</t>
<t>
The SIP UUI mechanism provides a way to achieve this transition.  As an endpoint moves from being an ISDN gateway to a native SIP endpoint, and a usage application for the UUI has been standardized, the endpoint can carry the UUI both as ISDN and application encoding.  This will permit the other endpoint to utlize the UUI if it is an ISDN gateway or a native SIP endpoint.  When all the endpoints have moved away from ISDN, the ISDN encoding usage can be discontinued.
</t>
</section>

<section title="ISDN Usage of the User-to-User Header Field">
<t>
This document defines the purpose usage of the ISDN interworking application of UUI which is to 
interoperate with ISDN User to User Signaling (UUS), a supplementary service in 
which the user is able to send/receive a limited amount of information to/from another ISDN user over the signalling channel in association with a call to the other ISDN user..  
</t>
<t>
Two examples of ISDN UUI with redirection (transfer and diversion) are defined in <xref target="ANSII" /> and <xref target="ETSI" />.

</t>
<t>
OPEN ISSUE 1: Key to defining such an application is to understand how the capabilities of the generic SIP User-to-User header field extension relate to those provide by the ISDN user-to-user signalling supplementary service. If they are the same as the ISDN User-to-user signalling supplementary service then interworking is solely a matter of mapping the construct in one protocol into the equivalent construct in the other protocol. As the ISDN user-to-user signalling supplementary service is a somewhat restricted service, it is unlikely that the capabilities will be more than the generic SIP User-to-User header field extension. So we need to deal with the question of what occurs when (and if) the generic SIP User-to-User header field extension has wider capabilities than those of the ISDN user-to-user signalling supplementary service. The capabilities of the ISDN user-to-user signalling supplementary service have been outlined in section 3. The following open issues target what could occur if each of these capabilities are exceeded.
</t>

<t>
OPEN ISSUE 2: The maximum number of octets defined for the generic SIP User-to-User header field extension exceeds the 128 octets supported by the ISDN user-to-user signalling supplementary service. Obviously if the SIP sender sends more than that allowed, then mapping of the entire contents is impossible. Truncation should not occur (as the truncation cannot be signalled in the ISDN and the contents will probably end up meaningless) and therefore the only option is to discard the information and proceed without it. Mapping in the opposite direction will never be a problem. Is extra signalling needed to allow for this discard; it is believed that the answer is no. If the SIP user knows that it is interworking with the ISDN, then the UUI application at the SIP endpoint should limit its communication to 128 octet packets, in the knowledge that discard will occur if it does not. The UUI application at the SIP endpoint has complete control over what occurs. It should be noted that this was exactly the envisaged operation when early ISDN implementations that only supported 32 octets interworked with those supporting 128 octets. It also corresponds to the interworking with ISDNs that do not support the supplementary service at all, as discard will occur in these circumstances as well. Note that failure to include the user-user data into the ISDN SETUP message (when discard occurs) will result in the service being unavailable for the remainder of the call when UUS1 implicit operation is used.
</t>

<t>
OPEN ISSUE 3: The generic SIP User-to-User header field extension supports the description of more "protocol discriminators" that that supported by the ISDN user-to-user signalling supplementary service. Part of this depends on how these additional application identifiers (if any) are carried, and as a result whether the existing ISDN protocol discriminator is carried "as is". At the moment this is assumed, and therefore if a valid protocol discriminator value exists, then it is mapped. If one does not exist then it is not mapped, and discard of the entire user data occurs as in open issue 2. It is believed that many of the considerations of Issue 2 apply, and therefore the sole reason for any additional signalling support is to identify a protocol discriminator that can be mapped (i.e. one that forms part of the set that exists in ISDN), from those that cannot. Note that failure to include the user-user data into the ISDN SETUP message (when discard occurs) will result in the service being unavailable for the remainder of the call when UUS1 implicit operation is used.
</t>

<t>
OPEN ISSUE 4: It could be that more than one payload is allowed to be included in the generic SIP User-to-User header field extension whereas only one payload is supported by the ISDN user-to-user signalling supplementary service. It is believed the considerations are identical to open issue 2.
</t>

<t>
OPEN ISSUE 5: If integrity protection or encryption is supported in the generic SIP User-to-User header field extension then it is unlikely this can be supported in the ISDN. It is assumed that the gateway will support nothing but the transparent mapping of payload, and indeed fulfils no useful function by performing any capability in regard to integrity protection or encryption. Similar considerations apply as for open issue 2, i.e. that the UUI application at the SIP endpoint has complete control over what occurs.
</t>

<t>
OPEN ISSUE 6: Interworking depends on there being equivalent functionality existing in both protocols. The mapping for ISDN basic call to SIP is well established and deployed. It is believed that there is no issue in mapping the generic SIP User-to-User header field extension as supported in RFC 3261 to the ISDN user-to-user signalling supplementary service in this respect. Issues may occur when more complex SIP transactions are used such as the 3xx response and the REFER method. This is of course dependent on there being a mapping at the ISDN gateway of the the 3xx response or the REFER method in the first place. Many SIP deployments rely on some server converting REFER transactions to INVITE transactions within the SIP environment, therefore the interworking requirements are merely those of the INVITE dialog itself. Are there other more complex scenarios that need to be studied for interworking?
</t>

</section>

<section title="IANA Considerations">

</section>

<section title="Security Considerations">
</section>

<section title="Acknowledgements">
<t>
Thanks to Spencer Dawkins, Vijay Gurbani, and Laura Liess for their 
review of earlier versions of this 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="Normative References">

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

<reference anchor='Q931'>
<front>
<title>ITU-T Recommendation Q.931: Digital subscriber Signalling System No. 1 - Network layer; ISDN user-network interface layer 3 specification for basic call control </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='Q957.1'>
<front>
<title>ITU-T Recommendation Q.957.1: Digital subscriber Signalling System No. 1 - Stage 3 description for supplementary services using DSS 1; Stage 3 description for additional information transfer supplementary services using DSS 1: User-to-User Signalling (UUS)</title>
</front>
<seriesInfo name=' http://www.itu.int/rec/T-REC-Q.957.1-199607-I' value='' />
<format type='HTML' target=' http://www.itu.int/rec/T-REC-Q.957.1-199607-I' />
</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.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='johnston-cuss-sip-uui'>
<front>
<title>A Mechanism 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='J.' surname='Rafferty' fullname='Laura Liess'></author>
</front>
<seriesInfo name= 'draft-johnston-cuss-sip-uui-00' value=''/>
<format type='HTML' target='http://www.tools.ietf.org/html/draft-johnston-cuss-sip-uui' />
</reference>



</references>

</back>
</rfc>