draft-ietf-cuss-sip-uui-isdn-09.txt   draft-ietf-cuss-sip-uui-isdn-10.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: January 22, 2015 Avaya Expires: April 27, 2015 Avaya
July 21, 2014 October 24, 2014
Interworking ISDN Call Control User Information with SIP Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-09 draft-ietf-cuss-sip-uui-isdn-10
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-user information element data in SIP are described in RFC DSS1 User to User information element data in SIP are described in
6567. As networks move to SIP, it is important that applications RFC 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) of the
User-to-User header field to enable interworking with this ISDN User-to-User header field to enable interworking with this ISDN
service. 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.
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 January 22, 2015. This Internet-Draft will expire on April 27, 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 interworking gateways . . . . . . . . 11 10. Considerations for ISDN internetworking gateways . . . . . . . 11
11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 12 11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 12
12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12 12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
16. Changes since previous versions . . . . . . . . . . . . . . . 15 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 16.1. Normative References . . . . . . . . . . . . . . . . . . . 15
17.1. Normative References . . . . . . . . . . . . . . . . . . . 19 16.2. Informative References . . . . . . . . . . . . . . . . . . 15
17.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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 BCP 14, RFC 2119 document are to be interpreted as described in [RFC2119].
[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 to
User Information (UUI) in ISDN interworking scenarios using SIP 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-user information element [Q931], call control related ITU-T DSS1 User to User information element Q931
[Q957.1] and ITU-T Q.763 User-to-user information parameter [Q763] [Q931], Q957.1 [Q957.1] and ITU-T Q.763 User to User information
data in SIP. UUI is widely used in the PSTN today in contact centers parameter [Q763] data in SIP. UUI is widely used in the PSTN today
and call centers which are transitioning away from ISDN to SIP. in contact centers and call centers which are transitioning away from
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 User to User
information element within call control messages. This in itself information element within call control messages. This in itself
has two subvariants, UUS1 implicit and UUS1 explicit. UUS1 has two subvariants, UUS1 implicit and UUS1 explicit. In UUS1
explicit uses additional supplementary service control information implicit, it is the presence of the user signalling data itself
to control the request and granting of the service, as in UUS2 and that constitutes the request for the service. UUS1 explicit uses
UUS3. In UUS1 implicit, it is the presence of the user signalling additional supplementary service control information to control
data itself that constitutes the request for the service. UUS1 the request and granting of the service, as in UUS2 and UUS3.
explicit as a result also allows the requester to additionally UUS1 explicit as a result also allows the requester to
specify whether the parallel circuit-switched connection should additionally specify whether the parallel circuit-switched
proceed if the UUS1 service cannot be provided (preferred or connection should proceed if the UUS1 service cannot be provided
required); (preferred or required);
UUS2: User-to-user information exchanged from the sender's point of UUS2: User to User information exchanged from the sender's point of
view during call establishment, between the DSS1 ALERTING and DSS1 view during call establishment, between the DSS1 ALERTING and DSS1
CONNECT messages, within DSS1 USER INFORMATION messages; and CONNECT messages, within DSS1 USER INFORMATION messages; and
UUS3: User-to-user information exchanged while a call is in the UUS3: User to User information exchanged while a call is in the
Active state, within DSS1 USER INFORMATION messages. 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 RFC and indeed the one that matches the requirements specified in RFC6567
6567 [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
vendors have done so. On this basis, there is no reason why this vendors have done so. On this basis, there is no reason why this
package cannot also be used to support interworking with such a package cannot also be used to support interworking with such a
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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 User to User service, as the content is aligned
with the protocol discriminator that appears at the start of all with the protocol discriminator that appears at the start of all
DSS1 messages (see table 4-1 of ITU-T Recommendation Q.931) 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
skipping to change at page 5, line 39 skipping to change at page 5, line 39
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 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 Conference: ISDN conferencing allows the user to still exchange User
user-to-user data after the conference is created. As far as UUS1 to User data after the conference is created. As far as UUS1 is
is concerned, it is not permitted. concerned, it is not permitted. The ISDN three-party
supplementary service is similar in many ways to conferencing, but
The ISDN three-party supplementary service is similar in many ways is signalled using a different mechanism. This means that on
to conferencing, but is signalled using a different mechanism. clearing, the controller using UUS1 implicit does have the choice
This means that on clearing, the controller using UUS1 implicit of sending data to either or both remote users. Because SIP
does have the choice of sending data to either or both remote conferencing cannot completely emulate the ISDN three-party
users. Because SIP conferencing cannot completely emulate the supplementary service at the served user, UUS1 implicit is not
ISDN three-party supplementary service at the served user, UUS1 possible.
implicit is not 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 UUI is to use SIP-T [RFC3372] and
transport the UUI information end-to-end, as part of an ISUP message 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 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
skipping to change at page 8, line 8 skipping to change at page 8, line 4
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-user data into the ISDN SETUP message (when discard occurs) User to User data into the ISDN SETUP message (when discard
will result in the service being unavailable for the remainder of occurs) will result in the service being unavailable for the
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
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
skipping to change at page 11, line 34 skipping to change at page 11, line 30
discriminator octet, conforming to table 4-26 of ITU-T Recommendation discriminator octet, conforming to table 4-26 of ITU-T Recommendation
Q.931 [Q931] as the first octet of the UUI data. It is up to the Q.931 [Q931] as the first octet of the UUI data. It is up to the
receiving application what it does with this value. This document receiving application what it does with this value. This document
places no other normative requirement on the use of the protocol places no other normative requirement on the use of the protocol
discriminator; it is required at interworking gateways to allow discriminator; it is required at interworking gateways to allow
mapping into the appropriate fields in the ISDN protocols, but mapping into the appropriate fields in the ISDN protocols, but
otherwise the usage is entirely up to the application, and outside otherwise the usage is entirely up to the application, and outside
the scope of this document. Valid values are identified and the scope of this document. Valid values are identified and
documented by ITU-T, and there is no IANA registry for these values. documented by ITU-T, and there is no IANA registry for these values.
10. Considerations for ISDN interworking 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-
skipping to change at page 12, line 23 skipping to change at page 12, line 19
UUI mechanism extension. The option tag is not interworked at an UUI mechanism extension. The option tag is not interworked at an
ISDN interworking gateway. The ISDN interworking gateways MUST NOT ISDN interworking gateway. The ISDN interworking gateways MUST NOT
take the omission of the "uui" option tag in a received INVITE take the omission of the "uui" option tag in a received INVITE
request to indicate that interworking of a received header field is request to indicate that interworking of a received header field is
not to be performed. not to be performed.
11. Coding requirements 11. Coding requirements
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 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
skipping to change at page 13, line 11 skipping to change at page 13, line 4
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:
skipping to change at page 14, line 8 skipping to change at page 13, line 47
message supports the UUI package "uui-isdn". message supports the UUI 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 RFC 3840 [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]. The over and above those specified in [I-D.ietf-cuss-sip-uui]. However,
overlying use case will define the security measures required. The since this capability is designed to interwork with the ISDN, the
underlying user-to-user extension provides a number of tools that can general security considerations of SIP to ISUP (ISDN User Part)
meet certain security requirements. interworking defined in [RFC3398] apply. Any SIP/PSTN gateway
implementing the ISDN UUI service should not blindly trust ISUP from
the PSTN. In general, the overlying use case will define the
security measures required. The underlying User to User extension
provides a number of tools that can meet certain 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 assume that the security forms part of the route, any usage needs to be aware that the
level of the ISDN is the highest level of security available. As the security level of the ISDN service may be lower than the security of
ISDN security is itself not definable on an end-to-end basis, this the SIP service. The ISDN security is itself not definable on an
can be an unknown quantity. This is because ISDN security exists on end-to-end basis, and exists on a hop-by-hop basis. This can be high
a hop-by-hop basis, and is only as secure as the least secure in some places (e.g. it can require physical access to a secure
component. This can be high in some places (e.g. it can require building) and in other places it can be low (e.g. the point where an
physical access to a secure building) and in other places it can be ISDN access enters a building). If this level of security is not
low (e.g. the point where an ISDN access enters a building). If this sufficient, then either a different User to User package, or indeed,
level of security is not sufficient, then either a different user-to- a different method of data transfer, needs to be selected by the
user package, or indeed, a different method of data transfer, needs application user.
to be selected by the application user.
15. Acknowledgements 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, and Laura Liess for their Thanks to Spencer Dawkins, Vijay Gurbani, Laura Liess, and Roland
review of earlier versions of this document. The authors wish to Jesske for their reviews of this document. The authors wish to thank
thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings,
Jennings, Mahalingam Mani and Celine Serrut-Valette for their Mahalingam Mani and Celine Serrut-Valette for their comments.
comments.
The death of Francois Audet occurred before this document was The death of Francois Audet occurred before this document was
finalised, and the authors would like to identify the significant finalised, and the authors would like to identify the significant
contribution of Francois to this and a number of important RFCs, and contribution of Francois to this and a number of important RFCs, and
to express their condolences to his family. It was always a pleasure to express their condolences to his family. It was always a pleasure
to work with Francois. to work with Francois.
16. Changes since previous versions 16. References
Note to RFC editor: This section is to be deleted before final
publication.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-09 version from the
draft-ietf-cuss-sip-uui-isdn-08 version.
Additional text in section 4 added justifying why SIP(T) would not
directly be a solution to this problem.
Clarification added in section 5 to clarify that the limititations
are the ISDN limitations.
Terminology "data packet" changed to "UUI data" to align with
[I-D.ietf-cuss-sip-uui]
Contact added in IANA considerations.
Text relating to comparision with feature tag removed from
security considerations as the text was not understandable and the
authors could not identify what it was originally intended to
mean.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-08 version from the
draft-ietf-cuss-sip-uui-isdn-07 version.
In section 7, one instance of UAS corrected to UAC.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-07 version from the
draft-ietf-cuss-sip-uui-isdn-06 version.
In the UAS requirements section, a new requirement has been added
to set the purpose parameter to "uui-isdn" if it is included.
This matches an equivalent requirement for the UAC.
In the UAS requirements section, two instances of UAC have been
corrected to UAS.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-06 version from the
draft-ietf-cuss-sip-uui-isdn-05 version.
A new paragraph of informative material has been added in section
8 relating to older implementations generating "ISDNinterwork" as
a purpose value.
A number of editorial changes have been made.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-05 version from the
draft-ietf-cuss-sip-uui-isdn-04 version.
ABNF provided for definition of values of package and content to
correspond to ABNF in current version of [I-D.ietf-cuss-sip-uui]
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-04 version from the
draft-ietf-cuss-sip-uui-isdn-03 version.
Change of the "package" header field parameter back to the
"purpose" header field parameter in alignment with change in
draft-ietf-cuss-sip-uui.
Identification of the package name in the abstract.
Minor change to IANA registration of "content" header field
parameter value to align with main text such that absence of
"package" header field parameter and absence of "content" header
field parameter implies this package and therefore this content,
as a default.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-03 version from the
draft-ietf-cuss-sip-uui-isdn-02 version.
Clarification added that the default content is "isdn-uui".
Clarification added that the default encoding is "hex".
Changeout of "payload" terminology to "UUI data".
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-02 version from the
draft-ietf-cuss-sip-uui-isdn-01 version.
The inclusion of the "package" header field parameter has be
downgraded to "RECOMMENDED", with the purpose stated as being for
interworking. Changes have been made to the procedures at the
receiving side to allow for the non-inclusion of the "package"
header field parameter. The effect of this is that the absence of
the "package" header field parameter means by default the use of
the "uui-isdn" package.
Clarification that the package is not to be used on re-INVITE
transactions or on other transations within an INVITE dialog.
Further clarification on using this package in conjunction with
other packages.
Closure of the remaining open issue relating to use of UUS1 in
conjunction with the ISDN conference service - UUS1 is not
possible after the conference is created.
A number of editorial changes have been made.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-01 version from the
draft-ietf-cuss-sip-uui-isdn-00 version.
QSIG does not define a UUS service. As such changes are made to
indicate that it is possible to support a proprietary service on
QSIG based on the public ISDN standards, and interworking with
such proprietary versions is supported. The associated
contributors note regarding interactions with other QSIG services
has therefore been removed with this amendment.
Added additional paragraph above the objectives of the
interworking design.
Made clear that the 128 octets apply before encoding in "hex".
Reference added to the generic UUI document for the ecoding of
"hex".
Indicated that it is the "content" header field parameter set to
"isdn-uui" that defines the structure of the uui-data, with the
first octet being a protocol discriminator and the remaining
octets potentially being limited to 128 octets.
Aligned the IANA registration section with the registries created
by the generic UUI document.
Added reference to the generic UUI document to the security
considerations section.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-00 version from the
draft-drage-cuss-sip-uui-isdn-01 version.
Removed overburdening of the word "application". Changed the name
of the "app" header field parameter in the mechanism draft to
"package" header field parameter. This had a consequential impact
on the ISDN document. The word "application" is now solely
reserved for the name of the functionality that passes the UUI to
the SIP functionality to send, and to which the UUI is delivered
on receipt by the SIP functionality. As well as the change of the
name of the header field parameter, this resulted in a number of
instances of the word "application" becoming "package". A couple
of instances relating to the coding of the "content" header field
parameter have become "SIP entity".
Section 5 needed substantial rewording as it no longer applied in
this manner. Modified the text to indicate that if one wants to
use an enhanced UUI where both endpoints are SIP, but still work
with the ISDN, then one will have to same information using two
different packages, one the ISDN one, and the other some enhanced
package.
In section 8, a couple of requirements relating to the "content"
header field parameter really related to the "package" header
field parameter (formerly "app" header field parameter). These
are corrected.
Updated references from "draft-johnston-cuss-sip-uui" to
"draft-ietf-cuss-sip-uui".
Made clear throughout the document that the UUI payload is a
protocol discriminator plus 128 octets of data.
Made clearer that it is the initial INVITE request and responses
and the BYE request and responses only that carry the information
in this package.
Made clear that there are no normative requirements on the
protocol discriminator. In particular text is added to the end of
section 9.
Removed the following text from section 7, as it is a duplicate of
the text in section 9:
" When sending UUI, the sending application MUST include a
protocol discriminator octet, conforming to table 4-26 of ITU-T
Recommendation Q.931 [Q931] as the first octet of the payload
information."
Defined a media feature tag specific for the package. It has been
proposed to do this for all packages. "sip.uui-isdn" has been
added.
Corrected the short title for the draft.
Changes since made in the creation of the
draft-drage-cuss-sip-uui-isdn-01 version from the
draft-drage-cuss-sip-uui-isdn-00 version.
Closure of a number of open issues identified in the -00 version
and the creation of appropriate procedures for the UAC, the UAS,
and the ISDN interworking gateway.
17. References
17.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
skipping to change at page 19, line 49 skipping to change at page 15, line 34
[I-D.ietf-cuss-sip-uui] [I-D.ietf-cuss-sip-uui]
Johnston, A. and J. Rafferty, "A Mechanism for Johnston, A. and J. Rafferty, "A Mechanism for
Transporting User to User Call Control Information in Transporting User to User Call Control Information in
SIP", draft-ietf-cuss-sip-uui-17 (work in progress), SIP", draft-ietf-cuss-sip-uui-17 (work in progress),
June 2014. June 2014.
[Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling [Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling
System No. 1 - Network layer; ISDN user-network interface System No. 1 - Network layer; ISDN user-network interface
layer 3 specification for basic call control", layer 3 specification for basic call control",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en . ITU-T http://www.itu.int/rec/T-REC-Q.931-199805-I/en.
17.2. Informative References [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong,
"Integrated Services Digital Network (ISDN) User Part
(ISUP) to Session Initiation Protocol (SIP) Mapping",
RFC 3398, December 2002.
[RFC6567] Johnston, A. and L. Liess, "Problem Statement and 16.2. Informative References
Requirements for Transporting User-to-User Call Control
Information in SIP", RFC 6567, April 2012.
[Q957.1] "ITU-T Recommendation Q.957.1: Digital subscriber [Q957.1] "ITU-T Recommendation Q.957.1: Digital subscriber
Signalling System No. 1 - Stage 3 description for Signalling System No. 1 - Stage 3 description for
supplementary services using DSS 1; Stage 3 description supplementary services using DSS 1; Stage 3 description
for additional information transfer supplementary services for additional information transfer supplementary services
using DSS 1: User-to-User Signalling (UUS)", using DSS 1: User-to-User Signalling (UUS)",
http://www.itu.int/rec/T-REC-Q.957.1-199607-I . ITU-T http://www.itu.int/rec/T-REC-Q.957.1-199607-I.
[Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part
formats and codes", formats and codes",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en . ITU-T http://www.itu.int/rec/T-REC-Q.931-199805-I/en.
[RFC6567] Johnston, A. and L. Liess, "Problem Statement and
Requirements for Transporting User-to-User Call Control
Information in SIP", RFC 6567, April 2012.
[ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services [ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services
Digital Network (ISDN)-Explicit Call Transfer Digital Network (ISDN)-Explicit Call Transfer
Supplementary Service". Supplementary Service", ANSI T1.643-1995 .
[ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services [ETSI] ""ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
Digital Network (ISDN); Diversion supplementary Digital Network (ISDN); Diversion supplementary
services". services"", ETSI ETF 300 207-1 .
Authors' Addresses Authors' Addresses
Keith Drage (editor) Keith Drage (editor)
Alcatel-Lucent Alcatel-Lucent
Quadrant, Stonehill Green, Westlea Quadrant, Stonehill Green, Westlea
Swindon Swindon
UK UK
Email: keith.drage@alcatel-lucent.com Email: keith.drage@alcatel-lucent.com
Alan Johnston Alan Johnston
Avaya Avaya
St. Louis, MO 63124 St. Loius, MO
United States US
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
 End of changes. 49 change blocks. 
306 lines changed or deleted 109 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/