draft-ietf-cuss-sip-uui-isdn-10.txt   draft-ietf-cuss-sip-uui-isdn-11.txt 
CUSS K. Drage, Ed. CUSS K. Drage, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track A. Johnston Intended status: Standards Track A. Johnston
Expires: April 27, 2015 Avaya Expires: May 15, 2015 Avaya
October 24, 2014 November 11, 2014
Interworking ISDN Call Control User Information with SIP Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-10 draft-ietf-cuss-sip-uui-isdn-11
Abstract Abstract
The motivation and use cases for interworking and transporting ITU-T The motivation and use cases for interworking and transporting ITU-T
DSS1 User to User information element data in SIP are described in DSS1 User-user information element data in SIP are described in RFC
RFC 6567. As networks move to SIP, it is important that applications 6567. As networks move to SIP, it is important that applications
requiring this data can continue to function in SIP networks as well 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 as the ability to interwork with this ISDN service for end-to-end
transparency. This document defines a usage (a new package) of the transparency. This document defines a usage (a new package called
User-to-User header field to enable interworking with this ISDN the ISDN UUI package) of the User-to-User header field to enable
service. interworking with this ISDN service.
This document covers the interworking with both public ISDN and This document covers the interworking with both public ISDN and
private ISDN capabilities, so the potential interworking with QSIG private ISDN capabilities, so the potential interworking with QSIG
will also be addressed. will also be addressed.
The package is identified by a new value "isdn-uui" of the "purpose" The package is identified by a new value "isdn-uui" of the "purpose"
header field parameter. header field parameter.
Status of this Memo Status of this Memo
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2015. This Internet-Draft will expire on May 15, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Summary of the ISDN User to User Service . . . . . . . . . . . 3 3. Summary of the ISDN User-to-User Service . . . . . . . . . . . 3
3.1. The service . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. The service . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Impacts of the ISDN service on SIP operation . . . . . . . 5 3.2. Impacts of the ISDN service on SIP operation . . . . . . . 5
4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6 4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6
5. Transition away from ISDN . . . . . . . . . . . . . . . . . . 6 5. Transition away from ISDN . . . . . . . . . . . . . . . . . . 6
6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7 6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7
7. UAC requirements . . . . . . . . . . . . . . . . . . . . . . . 8 7. UAC requirements . . . . . . . . . . . . . . . . . . . . . . . 8
8. UAS requirements . . . . . . . . . . . . . . . . . . . . . . . 9 8. UAS requirements . . . . . . . . . . . . . . . . . . . . . . . 9
9. UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Considerations for ISDN internetworking gateways . . . . . . . 11 10. Considerations for ISDN internetworking gateways . . . . . . . 11
11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 12 11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 3, line 14 skipping to change at page 3, line 14
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Overview 2. Overview
This document describes a usage of the User-to-User header field This document describes a usage of the User-to-User header field
defined in [I-D.ietf-cuss-sip-uui] to enable the transport of User to defined in [I-D.ietf-cuss-sip-uui] to enable the transport of User-
User Information (UUI) in ISDN interworking scenarios using SIP to-User Information (UUI) in ISDN interworking scenarios using SIP
[RFC3261]. Specifically, this document discusses the interworking of [RFC3261]. Specifically, this document discusses the interworking of
call control related ITU-T DSS1 User to User information element Q931 call control related ITU-T DSS1 User-user information element Q931
[Q931], Q957.1 [Q957.1] and ITU-T Q.763 User to User information [Q931], Q957.1 [Q957.1] and ITU-T Q.763 User-to-user information
parameter [Q763] data in SIP. UUI is widely used in the PSTN today parameter [Q763] data in SIP. UUI is widely used in the PSTN today
in contact centers and call centers which are transitioning away from in contact centers and call centers which are transitioning away from
ISDN to SIP. ISDN to SIP.
This usage is not limited to scenarios where interworking will occur. This usage is not limited to scenarios where interworking will occur.
Rather it describes a usage where interworking is possible if Rather it describes a usage where interworking is possible if
interworking is met. That does not preclude its usage directly interworking is met. That does not preclude its usage directly
between two SIP terminals. between two SIP terminals.
3. Summary of the ISDN User to User Service 3. Summary of the ISDN User-to-User Service
3.1. The service 3.1. The service
ISDN defines a number of related services. Firstly there is a user ISDN defines a number of related services. Firstly there is a user
signalling bearer service, which uses the information elements / signalling bearer service, which uses the information elements /
parameters in the signalling channel to carry the data, and does not parameters in the signalling channel to carry the data, and does not
establish a related circuit-switched connection. For DSS1, this is establish a related circuit-switched connection. For DSS1, this is
specified in ITU-T Recommendation Q.931 section 3.3 and section 7 specified in ITU-T Recommendation Q.931 section 3.3 and section 7
[Q931]. It also defines a User to User signalling supplementary [Q931]. It also defines a User-to-User signalling supplementary
service, which uses the information elements / parameters in the service, which uses the information elements / parameters in the
signalling channel to carry additional data, but which is used in signalling channel to carry additional data, but which is used in
conjunction with the establishment of a related circuit-switched conjunction with the establishment of a related circuit-switched
connection. This reuses the same information elements / parameters connection. This reuses the same information elements / parameters
as the user signalling bearer service, with the addition of other as the user signalling bearer service, with the addition of other
signalling information, and for DSS1 this is specified in ITU-T signalling information, and for DSS1 this is specified in ITU-T
Recommendation Q.957.1 [Q957.1]. Recommendation Q.957.1 [Q957.1].
ISDN defines three variants of the User to User signalling ISDN defines three variants of the User-to-User signalling
supplementary service as follows: supplementary service as follows:
UUS1: User to User information exchanged during the setup and UUS1: User-to-User information exchanged during the setup and
clearing phases of a call, by transporting User to User clearing phases of a call, by transporting DSS1 User-user
information element within call control messages. This in itself information elements within call control messages. This in itself
has two subvariants, UUS1 implicit and UUS1 explicit. In UUS1 has two subvariants, UUS1 implicit and UUS1 explicit. In UUS1
implicit, it is the presence of the user signalling data itself implicit, it is the presence of the user signalling data itself
that constitutes the request for the service. UUS1 explicit uses that constitutes the request for the service. UUS1 explicit uses
additional supplementary service control information to control additional supplementary service control information to control
the request and granting of the service, as in UUS2 and UUS3. the request and granting of the service, as in UUS2 and UUS3.
UUS1 explicit as a result also allows the requester to UUS1 explicit as a result also allows the requester to
additionally specify whether the parallel circuit-switched additionally specify whether the parallel circuit-switched
connection should proceed if the UUS1 service cannot be provided connection should proceed if the UUS1 service cannot be provided
(preferred or required); (preferred or required);
UUS2: User to User information exchanged from the sender's point of UUS2: DSS1 User-user information elements exchanged from the
view during call establishment, between the DSS1 ALERTING and DSS1 sender's point of view during call establishment, between the DSS1
CONNECT messages, within DSS1 USER INFORMATION messages; and ALERTING and DSS1 CONNECT messages, within DSS1 USER INFORMATION
messages; and
UUS3: User to User information exchanged while a call is in the UUS3: DSS1 User-user information elements exchanged while a call is
Active state, within DSS1 USER INFORMATION messages. in the Active state, within DSS1 USER INFORMATION messages.
The service is always requested by the calling user. The service is always requested by the calling user.
This document defines only the provision of the ISDN UUS1 implicit This document defines only the provision of the ISDN UUS1 implicit
supplementary service to interworking scenarios, this being the most supplementary service to interworking scenarios, this being the most
widely deployed and used of the various ISDN User to User services, widely deployed and used of the various ISDN User-to-User services,
and indeed the one that matches the requirements specified in RFC6567 and indeed the one that matches the requirements specified in RFC6567
[RFC6567]. [RFC6567].
The above come from the ISDN specifications defined for public The above come from the ISDN specifications defined for public
networks. There are a parallel set of ISDN specifications defined networks. There are a parallel set of ISDN specifications defined
for private networks (QSIG}. These specifications do not define a for private networks (QSIG}. These specifications do not define a
UUS1 implicit supplementary service. However, implementation of such UUS1 implicit supplementary service. However, implementation of such
a UUS1 implicit supplementary service for private networks can a UUS1 implicit supplementary service for private networks can
readily be constructed in a proprietary fashion based on the readily be constructed in a proprietary fashion based on the
specifications for public networks, and evidence suggests that some specifications for public networks, and evidence suggests that some
skipping to change at page 5, line 14 skipping to change at page 5, line 15
fields, the mechanism at any interworking point is to discard data fields, the mechanism at any interworking point is to discard data
elements that are too long to handle. The handled length can elements that are too long to handle. The handled length can
normally be assumed to be 128 octets. normally be assumed to be 128 octets.
The content of the user information octets is described by a The content of the user information octets is described by a
single octet protocol discriminator (see table 4-26 of ITU-T single octet protocol discriminator (see table 4-26 of ITU-T
Recommendation Q.931) [Q931]. That protocol descriminator may Recommendation Q.931) [Q931]. That protocol descriminator may
describe the protocol used within the user data, the structure of describe the protocol used within the user data, the structure of
the user data, or leave it entirely open. Note that not all the user data, or leave it entirely open. Note that not all
values within the protocol discriminator necessarily make sense values within the protocol discriminator necessarily make sense
for use in the User to User service, as the content is aligned for use in the ISDN User-to-User service, as the content is
with the protocol discriminator that appears at the start of all aligned with the protocol discriminator that appears at the start
DSS1 messages (see table 4-1 of ITU-T Recommendation Q.931) of all DSS1 messages (see table 4-1 of ITU-T Recommendation Q.931)
[Q931]. The protocol discriminator value has no impact on the [Q931]. The protocol discriminator value has no impact on the
interworking capability. interworking capability.
Only a single user information can be transported in each message. Only a single user information can be transported in each message.
The ISDN service works without encryption or integrity protection. The ISDN service works without encryption or integrity protection.
The user trusts the intermediate network elements, and therefore The user trusts the intermediate network elements, and therefore
the operator of those elements, not to modify the data, and to 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, deliver all the data to the remote user. On a link by link basis,
message contents are protected at layer 2 by standard CRC message contents are protected at layer 2 by standard CRC
skipping to change at page 5, line 39 skipping to change at page 5, line 40
link itself. This does not prevent the use of additional link itself. This does not prevent the use of additional
encryption or integrity protection within the UUI data itself, encryption or integrity protection within the UUI data itself,
although the limit on the size of the UUI data (protocol although the limit on the size of the UUI data (protocol
discriminator plus 128 octets) will restrict this. discriminator plus 128 octets) will restrict this.
3.2. Impacts of the ISDN service on SIP operation 3.2. Impacts of the ISDN service on SIP operation
The ISDN service has the following impacts that need to be understood The ISDN service has the following impacts that need to be understood
within the SIP environment. within the SIP environment.
Call transfer: ISDN call transfer cancels all User to User Call transfer: ISDN call transfer cancels all ISDN User-to-User
supplementary services. In the ISDN, if User to User data is supplementary services. In the ISDN, if User-to-User data is
required after call transfer, then UUS3 has to be renegotiated, required after call transfer, then UUS3 has to be renegotiated,
which is not provided by this SIP extension. The impact of this which is not provided by this SIP extension. The impact of this
restriction on the SIP environment is that UUI header fields restriction on the SIP environment is that UUI header fields
cannot be exchanged in transactions clearing down the SIP dialog cannot be exchanged in transactions clearing down the SIP dialog
after call transfer has occurred. after call transfer has occurred.
Conference: ISDN conferencing allows the user to still exchange User Conference: ISDN conferencing allows the user to still exchange
to User data after the conference is created. As far as UUS1 is User-to-User data after the conference is created. As far as UUS1
concerned, it is not permitted. The ISDN three-party is concerned, it is not permitted. The ISDN three-party
supplementary service is similar in many ways to conferencing, but supplementary service is similar in many ways to conferencing, but
is signalled using a different mechanism. This means that on is signalled using a different mechanism. This means that on
clearing, the controller using UUS1 implicit does have the choice clearing, the controller using UUS1 implicit does have the choice
of sending data to either or both remote users. Because SIP of sending data to either or both remote users. Because SIP
conferencing cannot completely emulate the ISDN three-party conferencing cannot completely emulate the ISDN three-party
supplementary service at the served user, UUS1 implicit is not supplementary service at the served user, UUS1 implicit is not
possible. possible.
Diversion: When ISDN diversion occurs, any UUS1 User to User data is Diversion: When ISDN diversion occurs, any UUS1 User-to-User data is
sent to the forwarded-to-user (assuming that the call meets sent to the forwarded-to-user (assuming that the call meets
requirements for providing the service - this is impacted by the requirements for providing the service - this is impacted by the
explicit service only). If the type of diversion is such that the explicit service only). If the type of diversion is such that the
call is also delivered to the forwarding user, they will also call is also delivered to the forwarding user, they will also
receive any UUS1 User to User data. receive any UUS1 User-to-User data.
4. Relation to SIP-T 4. Relation to SIP-T
A method of transport of ISDN UUI is to use SIP-T [RFC3372] and A method of transport of ISDN User-to-User data is to use SIP-T
transport the UUI information end-to-end, as part of an ISUP message [RFC3372] and transport the UUI information end-to-end, as part of an
or QSIG message) as a MIME body. If the SIP-T method of 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 encapsulation of ISDN instead of interworking is used, this is a
reasonable mechanism and does not require any extensions to existing reasonable mechanism and does not require any extensions to existing
SIP-T. However, if true ISDN interworking is being done, and SIP-T. However, if true ISDN interworking is being done, and
therefore SIP-T would not otherwise be used, this approach is not therefore SIP-T would not otherwise be used, this approach is not
reasonable, because then implementation of the many elements of ISUP reasonable, because then implementation of the many elements of ISUP
syntax would be required to understand one element of data. Instead, syntax would be required to understand one element of data. Instead,
the better approach is to interwork the ISDN UUI using the native SIP the better approach is to interwork the ISDN User-to-User data using
UUI transport mechanism, the User-to-User header field. The rest of the native SIP UUI transport mechanism, the User-to-User header
this document describes this approach. field. The rest of this document describes this approach.
5. Transition away from ISDN 5. Transition away from ISDN
This interworking usage of the SIP UUI mechanism will likely begin This interworking usage of the SIP UUI mechanism will likely begin
with one User Agent being an ISDN gateway while the other User Agent 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 a native SIP endpoint. As networks transition away from ISDN, it
is possible that both User Agents could become native SIP endpoints. is possible that both User Agents could become native SIP endpoints.
In this case, there is an opportunity to transition away from this In this case, there is an opportunity to transition away from this
ISDN usage to a more general usage of [I-D.ietf-cuss-sip-uui]. ISDN usage to a more general usage of [I-D.ietf-cuss-sip-uui].
The SIP UUI mechanism provides a way to achieve this transition. As The SIP UUI mechanism provides a way to achieve this transition. As
an endpoint moves from being an ISDN gateway to a native SIP an endpoint moves from being an ISDN gateway to a native SIP
endpoint, and a package for some form of enhanced UUI has been endpoint, and a future package for some form of enhanced UUI has been
standardized, the endpoint can carry the UUI data both as ISDN and as standardized, the endpoint can carry the UUI data both as ISDN and as
some other package in parallel, and in the same messages or in the future package in parallel, and in the same messages or in
different messages depending on the needs of the application. This different messages depending on the needs of the application. This
will permit the other endpoint to use the UUI according to the ISDN will permit the other endpoint to use the UUI according to the ISDN
package if it is an ISDN gateway or the enhanced package if it is a UUI package if it is an ISDN gateway or the future package if it is a
native SIP endpoint. native SIP endpoint.
6. ISDN Usage of the User-to-User Header Field 6. ISDN Usage of the User-to-User Header Field
This document defines the package for the ISDN interworking of UUI This document defines the package for the ISDN interworking of UUI
which is to interoperate with ISDN User to User Signaling (UUS), a which is to interoperate with ISDN User-to-User Signaling (UUS), a
supplementary service in which the user is able to send/receive a supplementary service in which the user is able to send/receive a
limited amount of information to/from another ISDN user over the limited amount of information to/from another ISDN user over the
signalling channel in association with a call to the other ISDN user. signalling channel in association with a call to the other ISDN user.
Two examples of ISDN UUI with redirection (transfer and diversion) Two examples of ISDN UUI with redirection (transfer and diversion)
are defined in [ANSII] and [ETSI]. are defined in [ANSII] and [ETSI].
One objective of the design of this package has been to keep the One objective of the design of this package has been to keep the
functionality at the interworking point as simple as possible. As a functionality at the interworking point as simple as possible. As a
result there is also only one encoding value specified. result there is also only one encoding value specified.
Responsibility for respecting the limits has been transferred to the Responsibility for respecting the limits has been transferred to the
end UA. If an interworking point is reached, and the limitations of end UA. If an interworking point is reached, and the limitations of
the ISDN (see section 3.1) are not met, then the UUI data will not be the ISDN (see section 3.1) are not met, then the UUI data will not be
transferred, although the SIP request will otherwise be interworked, transferred, although the SIP request will otherwise be interworked.
rather than have the interworking point attempt to resolve the non- This is rather than have the interworking point attempt to resolve
compliance with the limitations of ISDN. the non- compliance with the limitations of ISDN.
The general principals of this package of the UUI mechanism are The general principals of this package of the UUI mechanism are
therefore as follows: therefore as follows:
That the sending application is expected to limit their sending That the sending application is expected to limit their sending
requirements to the subset provided by the ISDN UUI service. requirements to the subset provided by the ISDN User-to-User
service.
That the SIP UA will not allow the reception of more that one That the SIP UA will not allow the reception of more that one
User-to-User header field relating to the "isdn-uui" package in User-to-User header field relating to the "isdn-uui" package in
the same SIP request or response, and will only allow it in a the same SIP request or response, and will only allow it in a
request or response of the appropriate method (INVITE or BYE). request or response of the appropriate method (INVITE or BYE).
What happens to User-to-User header fields relating to other What happens to User-to-User header fields relating to other
packages is outside the scope of this document. packages is outside the scope of this document.
That an interworking point trying to interwork UUI data that is That an interworking point trying to interwork UUI data that is
too long will discard the UUI data, but proceed with the too long will discard the UUI data, but proceed with the
skipping to change at page 8, line 4 skipping to change at page 8, line 8
with the ISDN, then the UUI application at the SIP endpoint should with the ISDN, then the UUI application at the SIP endpoint should
limit its communication to 128 octet packets plus the protocol limit its communication to 128 octet packets plus the protocol
discriminator, in the knowledge that discard will occur if it does discriminator, in the knowledge that discard will occur if it does
not. The UUI application at the SIP endpoint has complete control not. The UUI application at the SIP endpoint has complete control
over what occurs. It should be noted that this was exactly the over what occurs. It should be noted that this was exactly the
envisaged operation when early ISDN implementations that only envisaged operation when early ISDN implementations that only
supported 32 octets interworked with those supporting 128 octets. supported 32 octets interworked with those supporting 128 octets.
It also corresponds to the interworking with ISDNs that do not It also corresponds to the interworking with ISDNs that do not
support the supplementary service at all, as discard will occur in support the supplementary service at all, as discard will occur in
these circumstances as well. Note that failure to include the these circumstances as well. Note that failure to include the
User to User data into the ISDN SETUP message (when discard User-to-User data into the ISDN SETUP message (when discard
occurs) will result in the service being unavailable for the occurs) will result in the service being unavailable for the
remainder of the call when UUS1 implicit operation is used. remainder of the call when UUS1 implicit operation is used.
7. UAC requirements 7. UAC requirements
The UAC MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in The UAC MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in
addition to the requirements defined in this document. addition to the requirements defined in this document.
The UAC MUST only use this package of the UUI mechanism extension in The UAC MUST only use this package of the UUI mechanism extension in
association with the initial INVITE method and the BYE method association with the initial INVITE method and the BYE method
skipping to change at page 8, line 32 skipping to change at page 8, line 36
that dialog a User-to-User header field. The UAC SHOULD set the that dialog a User-to-User header field. The UAC SHOULD set the
"purpose" header field parameter to "isdn-uui". Non-inclusion of the "purpose" header field parameter to "isdn-uui". Non-inclusion of the
"purpose" header field parameter is permitted, but this is primarily "purpose" header field parameter is permitted, but this is primarily
to allow earlier implementations to support this package. This to allow earlier implementations to support this package. This
initial header field constitutes the implicit request to use the UUI initial header field constitutes the implicit request to use the UUI
service, and is therefore included even when there is no data except service, and is therefore included even when there is no data except
the protocol discriminator octet to send at that point in time. the protocol discriminator octet to send at that point in time.
The UAC MUST NOT include the User-to-User header field with a The UAC MUST NOT include the User-to-User header field with a
"purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter set to "isdn-uui", or with no
"purpose" header field parameter", in any message of an INVITE dialog "purpose" header field parameter, in any message of an INVITE dialog
if the original INVITE request did not include the User-to-User if the original INVITE request did not include the User-to-User
header field, either with a "purpose" header field parameter set to header field, either with a "purpose" header field parameter set to
"isdn-uui", or with no "purpose" header field parameter included. "isdn-uui", or with no "purpose" header field parameter included.
When sending UUI for the ISDN package, if the "purpose" header field When sending UUI for the ISDN UUI package, if the "purpose" header
is included, the UAC MUST set the User-to-User "purpose" header field field is included, the UAC MUST set the User-to-User "purpose" header
parameter to "isdn-uui". The UAC MUST NOT include more than one field parameter to "isdn-uui". The UAC MUST NOT include more than
User-to-User header field for this package in any SIP request or one User-to-User header field for this package in any SIP request or
response. response.
When receiving UUI, when multiple User-to-User header fields are When receiving UUI, when multiple User-to-User header fields are
received in the same response with the "purpose" header field received in the same response with the "purpose" header field
parameter to "isdn-uui", or with no "purpose" header field parameter, parameter to "isdn-uui", or with no "purpose" header field parameter,
or with some combination of these, the UAC MUST discard all these or with some combination of these, the UAC MUST discard all these
header fields. There are no mechanisms for determining which was the header fields. There are no mechanisms for determining which was the
intended UUI data so all are discarded. intended UUI data so all are discarded.
The application designer will need to take into account the ISDN The application designer will need to take into account the ISDN
skipping to change at page 9, line 17 skipping to change at page 9, line 21
constraints, because those constraints may vary from one ISDN to constraints, because those constraints may vary from one ISDN to
another. It is reasonable to expect that a limitation of 128 octets another. It is reasonable to expect that a limitation of 128 octets
(plus a protocol discriminator) can be imposed by the ISDN, and (plus a protocol discriminator) can be imposed by the ISDN, and
therefore UUI data longer than this will never reach the destination therefore UUI data longer than this will never reach the destination
if such interworking occurs. Note that the 128 octet limit (plus a if such interworking occurs. Note that the 128 octet limit (plus a
protocol discriminator) applies before the encoding (or after the protocol discriminator) applies before the encoding (or after the
decoding) using the "hex" encoding. The "hex" encoding is defined in decoding) using the "hex" encoding. The "hex" encoding is defined in
[I-D.ietf-cuss-sip-uui]. [I-D.ietf-cuss-sip-uui].
[I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the
UUI mechanism extension. Because for the ISDN UUI service, the UUI mechanism extension. Because for the ISDN User-to-User service,
service is UUS1 implicit, the inclusion of the "uui" option tag in a the service is UUS1 implicit, the inclusion of the "uui" option tag
Supported header field conveys no additional information over and in a Supported header field conveys no additional information over
above the presence, in the INVITE request, of the User-to-User header and above the presence, in the INVITE request, of the User-to-User
field with the "purpose" header field parameter set to "isdn-uui". header field with the "purpose" header field parameter set to "isdn-
While there is no harm in including the "uui" option tag, and uui". While there is no harm in including the "uui" option tag, and
strictly it should be included if the extension is supported, it strictly it should be included if the extension is supported, it
performs no function. The presence of the "uui" option tag in the performs no function. The presence of the "uui" option tag in the
Require header field of an INVITE request will cause the request to Require header field of an INVITE request will cause the request to
fail if it reaches a UAS or ISDN interworking gateway that does not fail if it reaches a UAS or ISDN interworking gateway that does not
support this extension; such a usage is not precluded although it support this extension; such a usage is not precluded although it
does not form part of the package. does not form part of the package.
8. UAS requirements 8. UAS requirements
The UAS MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in The UAS MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in
skipping to change at page 9, line 44 skipping to change at page 9, line 48
The UAS MUST only use this package of the UUI mechanism extension in The UAS MUST only use this package of the UUI mechanism extension in
association with the initial INVITE method and the BYE method association with the initial INVITE method and the BYE method
relating to an INVITE dialog. Usage on transactions associated with relating to an INVITE dialog. Usage on transactions associated with
any other type of dialog, or on methods not associated with a dialog any other type of dialog, or on methods not associated with a dialog
is precluded. Usage on other methods within the INVITE dialog, and is precluded. Usage on other methods within the INVITE dialog, and
on re-INVITE transactions with the INVITE dialog, is also precluded. on re-INVITE transactions with the INVITE dialog, is also precluded.
The UAS MUST NOT include the User-to-User header field with a The UAS MUST NOT include the User-to-User header field with a
"purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter set to "isdn-uui", or with no
"purpose" header field parameter", in any message of an INVITE dialog "purpose" header field parameter, in any message of an INVITE dialog
if the original INVITE request did not include the User-to-User if the original INVITE request did not include the User-to-User
header field, either with a "purpose" header field parameter set to header field, either with a "purpose" header field parameter set to
"isdn-uui", or with no "purpose" header field parameter included. "isdn-uui", or with no "purpose" header field parameter included.
The UAS MAY include the User-to-User header field in responses to the The UAS MAY include the User-to-User header field in responses to the
initial INVITE request, or the BYE requests or responses for the initial INVITE request, or the BYE requests or responses for the
dialog, only where the original INVITE request included a User-to- dialog, only where the original INVITE request included a User-to-
User header field with the "purpose" header field parameter set to User header field with the "purpose" header field parameter set to
"isdn-uui", or where no "purpose" header field parameter was "isdn-uui", or where no "purpose" header field parameter was
included. When sending UUI for the ISDN package, the UAS SHOULD set included. When sending UUI for the ISDN UUI package, the UAS SHOULD
the User-to-User "purpose" header field parameter to "isdn-uui". set the User-to-User "purpose" header field parameter to "isdn-uui".
Non-inclusion of the "purpose" header field parameter is permitted, Non-inclusion of the "purpose" header field parameter is permitted,
but this is primarily to allow earlier implementations to support but this is primarily to allow earlier implementations to support
this package. this package.
When sending UUI for the ISDN package, if the "purpose" header field When sending UUI for the ISDN UUI package, if the "purpose" header
is included, the UAS MUST set the User-to-User "purpose" header field field is included, the UAS MUST set the User-to-User "purpose" header
parameter to "isdn-uui". The UAS MUST NOT include more than one field parameter to "isdn-uui". The UAS MUST NOT include more than
User-to-User header field for this package in any SIP request or one User-to-User header field for this package in any SIP request or
response. response.
The "isdn-interwork" value for purpose parameter was used in The "isdn-interwork" value for "purpose" header field parameter was
Internet-Drafts that have led to the publication of the present used in Internet-Drafts that have led to the publication of the
document. Although these documents had no other status than "work in present document. Although these documents had no other status than
progress", this value is implemented by some vendors. While not "work in progress", this value is implemented by some vendors. While
defined by this document, implementations could find it useful for not defined by this document, implementations could find it useful
interoperability purposes to support parsing and interpreting "isdn- for interoperability purposes to support parsing and interpreting
interwork" the same way as "isdn-uui" when receiving messages. "isdn- interwork" the same way as "isdn-uui" when receiving messages.
Where the UAS is acting as a redirect server, the UAS MUST NOT Where the UAS is acting as a redirect server, the UAS MUST NOT
include the User-to-User header field in the header URI parameter in include the User-to-User header field in the header URI parameter in
a 3xx response to an incoming request. a 3xx response to an incoming request.
When receiving UUI, when a User-to-User header field is received in a When receiving UUI, when a User-to-User header field is received in a
request that is not from the originating user with the "purpose" request that is not from the originating user with the "purpose"
header field parameter to "isdn-uui", or with no "purpose" header header field parameter to "isdn-uui", or with no "purpose" header
field parameter, the UAS MUST discard this header field. field parameter, the UAS MUST discard this header field.
skipping to change at page 11, line 40 skipping to change at page 11, line 44
10. Considerations for ISDN internetworking gateways 10. Considerations for ISDN internetworking gateways
ISDN interworking gateways MUST support the requirements defined for ISDN interworking gateways MUST support the requirements defined for
UAS and UAC operation. UAS and UAC operation.
ISDN interworking gateways MUST support only the "isdn-uui" package ISDN interworking gateways MUST support only the "isdn-uui" package
on dialogs that are interworked. on dialogs that are interworked.
ISDN interworking gateways will take octet structured data from the ISDN interworking gateways will take octet structured data from the
ISDN side and encode it using the "hex" encoding scheme defined in ISDN side and encode it using the "hex" encoding scheme defined in
[I-D.ietf-cuss-sip-uui] for inclusion as the uui-data in the User-to- [I-D.ietf-cuss-sip-uui] for inclusion as the UUI data in the User-to-
User header field. In the reverse direction, it will take valid uui- User header field. In the reverse direction, it will take valid UUI
data according to the "hex" encoding scheme, and decode it to octet data according to the "hex" encoding scheme, and decode it to octet
structured data for sending to the ISDN side. structured data for sending to the ISDN side.
When mapping data content from the ISDN to the SIP signalling, or When mapping data content from the ISDN to the SIP signalling, or
from SIP signalling to the ISDN, the gateway needs to assume that all from SIP signalling to the ISDN, the gateway needs to assume that all
content is octet structured binary, irrespective of the value of the content is octet structured binary, irrespective of the value of the
received protocol discriminator. There are no requirements in the received protocol discriminator. There are no requirements in the
ISDN to ensure that the content matches the value of the protocol ISDN to ensure that the content matches the value of the protocol
discriminator, and it is for the application usage to sort out any discriminator, and it is for the application usage to sort out any
discrepancy. The same applies to the ISDN protocol discrimination discrepancy. The same applies to the ISDN protocol discrimination
skipping to change at page 12, line 27 skipping to change at page 12, line 31
This document defines "isdn-uui" as a new value of the User-to-User This document defines "isdn-uui" as a new value of the User-to-User
"purpose" header field parameter. The following ABNF adds to the "purpose" header field parameter. The following ABNF adds to the
production in [I-D.ietf-cuss-sip-uui]: production in [I-D.ietf-cuss-sip-uui]:
pkg-param-value =/ "isdn-uui" pkg-param-value =/ "isdn-uui"
This document defines "isdn-uui" as a new value of the User-to-User This document defines "isdn-uui" as a new value of the User-to-User
"content" header field parameter. A content value of "isdn-uui" "content" header field parameter. A content value of "isdn-uui"
indicates that the contents have a first octet that is a protocol indicates that the contents have a first octet that is a protocol
discriminator (see table 4-26 of ITU-T Recommendation Q.931 [Q931]) discriminator (see table 4-26 of ITU-T Recommendation Q.931 [Q931])
followed by uui-data that can be subject to a length limitation followed by UUI data that can be subject to a length limitation
(before encoding or after decoding) that is generally 128 octets. (before encoding or after decoding) that is generally 128 octets.
The following ABNF adds to the production in [I-D.ietf-cuss-sip-uui]. The following ABNF adds to the production in [I-D.ietf-cuss-sip-uui].
cont-param-value =/ "isdn-uui" cont-param-value =/ "isdn-uui"
12. Media Feature Tag 12. Media Feature Tag
This document defines a new media feature tag "sip.uui-isdn". This This document defines a new media feature tag "sip.uui-isdn". This
feature tag indicates that this UUI package is supported by the feature tag indicates that this ISDN UUI package is supported by the
sender, and its usage is entirely in accordance with RFC 3840 sender, and its usage is entirely in accordance with RFC 3840
[RFC3840]. This document makes no additional provisions for the use [RFC3840]. This document makes no additional provisions for the use
of this feature tag. of this feature tag.
13. IANA Considerations 13. IANA Considerations
This document adds the following row to the "UUI packages" sub- This document adds the following row to the "UUI packages" sub-
registry of the SIP parameter registry: registry of the SIP parameter registry:
Value: isdn-uui Value: isdn-uui
skipping to change at page 13, line 4 skipping to change at page 13, line 6
sender, and its usage is entirely in accordance with RFC 3840 sender, and its usage is entirely in accordance with RFC 3840
[RFC3840]. This document makes no additional provisions for the use [RFC3840]. This document makes no additional provisions for the use
of this feature tag. of this feature tag.
13. IANA Considerations 13. IANA Considerations
This document adds the following row to the "UUI packages" sub- This document adds the following row to the "UUI packages" sub-
registry of the SIP parameter registry: registry of the SIP parameter registry:
Value: isdn-uui Value: isdn-uui
Description: The associated application is being used with Description: The associated application is being used with
constraints suitable for interworking with the ISDN User to User constraints suitable for interworking with the ISDN User-to-User
service, and therefore can be interworked at ISDN gateways. service, and therefore can be interworked at ISDN gateways.
Reference: RFCXXXX Reference: RFCXXXX
Contact: Keith Drage Contact: Keith Drage
This document adds the following row to the "UUI content" subregistry This document adds the following row to the "UUI content" subregistry
of the SIP parameter registry: of the SIP parameter registry:
Value: isdn-uui Value: isdn-uui
Description: The associated contents conforms to the content Description: The associated contents conforms to the content
associated with the ISDN User to User service. In the presence of associated with the ISDN User-to-User service. In the presence of
the "purpose" header field parameter set to "isdn-uui" (or the the "purpose" header field parameter set to "isdn-uui" (or the
absence of any "purpose" header field parameter) this is the absence of any "purpose" header field parameter) this is the
default meaning and therefore need not be included in this case. default meaning and therefore need not be included in this case.
Reference: RFCXXXX Reference: RFCXXXX
Contact: Keith Drage Contact: Keith Drage
This document defines the following media feature tag which is added This document defines the following media feature tag which is added
to the features.sip-tree of the Media Feature tags registry: to the features.sip-tree of the Media feature tags registry:
Media feature-tag name: sip.uui-isdn Media feature tag name: sip.uui-isdn
ASN.1 Identifier: 1.3.6.1.8.4.x ASN.1 Identifier: 1.3.6.1.8.4.x
Summary of the media feature indicated by this tag: This media Summary of the media feature indicated by this tag: This media
feature-tag when used in a Contact header field of a SIP request feature tag when used in a Contact header field of a SIP request
or a SIP response indicates that the entity sending the SIP or a SIP response indicates that the entity sending the SIP
message supports the UUI package "uui-isdn". message supports the package "uui-isdn".
Values appropriate for use with this feature-tag: none Values appropriate for use with this feature tag: none
Examples of typical use: Indicating that a mobile phone supports Examples of typical use: Indicating that a mobile phone supports
SRVCC for calls in alerting phase. SRVCC for calls in alerting phase.
Related standards or documents: RFCXXXX Related standards or documents: RFCXXXX
Security Considerations: Security considerations for this media Security Considerations: Security considerations for this media
feature-tag are discussed in section 11.1 of [RFC3840] feature tag are discussed in section 11.1 of [RFC3840]
Editor's Note: [RFCXXXX] should be replaced with the designation of Editor's Note: [RFCXXXX] should be replaced with the designation of
this document. this document.
14. Security Considerations 14. Security Considerations
This document contains no specific requirements in regard to security This document contains no specific requirements in regard to security
over and above those specified in [I-D.ietf-cuss-sip-uui]. However, over and above those specified in [I-D.ietf-cuss-sip-uui]. However,
since this capability is designed to interwork with the ISDN, the since this capability is designed to interwork with the ISDN, the
general security considerations of SIP to ISUP (ISDN User Part) general security considerations of SIP to ISUP (ISDN User Part)
interworking defined in [RFC3398] apply. Any SIP/PSTN gateway interworking defined in [RFC3398] apply. Any SIP/PSTN gateway
implementing the ISDN UUI service should not blindly trust ISUP from implementing the ISDN User-to-User service should not blindly trust
the PSTN. In general, the overlying use case will define the ISUP from the PSTN. In general, the overlying use case will define
security measures required. The underlying User to User extension the security measures required. The underlying User-to-User header
provides a number of tools that can meet certain security field extension provides a number of tools that can meet certain
requirements. security requirements.
Information that might otherwise reveal private information about an Information that might otherwise reveal private information about an
individual, or where a level of authenticity needs to be guaranteed, individual, or where a level of authenticity needs to be guaranteed,
may need a higher level of protection, and may indeed not be suitable may need a higher level of protection, and may indeed not be suitable
for this package, particularly taking into account the statement in for this package, particularly taking into account the statement in
the following paragraph. the following paragraph.
As this capability is defined to interwork with the ISDN, if the ISDN As this capability is defined to interwork with the ISDN, if the ISDN
forms part of the route, any usage needs to be aware that the forms part of the route, any usage needs to be aware that the
security level of the ISDN service may be lower than the security of security level of the ISDN service may be lower than the security of
the SIP service. The ISDN security is itself not definable on an the SIP service. The ISDN security is itself not definable on an
end-to-end basis, and exists on a hop-by-hop basis. This can be high end-to-end basis, and exists on a hop-by-hop basis. This can be high
in some places (e.g. it can require physical access to a secure in some places (e.g. it can require physical access to a secure
building) and in other places it can be low (e.g. the point where an building) and in other places it can be low (e.g. the point where an
ISDN access enters a building). If this level of security is not ISDN access enters a building). If this level of security is not
sufficient, then either a different User to User package, or indeed, sufficient, then either a different package, or indeed, a different
a different method of data transfer, needs to be selected by the method of data transfer, needs to be selected by the application
application user. user.
15. Acknowledgments 15. Acknowledgments
Joanne McMillen was a major contributor and co-author of earlier Joanne McMillen was a major contributor and co-author of earlier
versions of this document. versions of this document.
Thanks to Spencer Dawkins, Vijay Gurbani, Laura Liess, and Roland Thanks to Spencer Dawkins, Vijay Gurbani, Laura Liess, and Roland
Jesske for their reviews of this document. The authors wish to thank Jesske for their reviews of this document. The authors wish to thank
Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings,
Mahalingam Mani and Celine Serrut-Valette for their comments. Mahalingam Mani and Celine Serrut-Valette for their comments.
 End of changes. 50 change blocks. 
96 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/