draft-ietf-cuss-sip-uui-isdn-00.txt   draft-ietf-cuss-sip-uui-isdn-01.txt 
Network Working Group K. Drage, Ed. Network Working Group 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 6, 2012 Avaya Expires: April 3, 2012 Avaya
October 4, 2011 October 2011
Interworking ISDN Call Control User Information with SIP Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-00 draft-ietf-cuss-sip-uui-isdn-01
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 the DSS1 User-user information element data in SIP are described in the
"Problem Statement and Requirements for Transporting User to User "Problem Statement and Requirements for Transporting User to User
Call Control Information in SIP" document. As networks move to SIP Call Control Information in SIP" document. As networks move to SIP
it is important that applications requiring this data can continue to it is important that applications requiring this data can continue to
function in SIP networks as well as the ability to interwork with function in SIP networks as well as the ability to interwork with
this ISDN service for end-to- end transparency. This document this ISDN service for end-to- end transparency. This document
defines a usage of the User-to-User header field to enable defines a usage of the User-to-User header field to enable
interworking with this ISDN service. interworking with this ISDN service.
This document is covers the interworking with both public ISDN and This document covers the interworking with both public ISDN and
private ISDN capabilities, so the interworking with QSIG will also be private ISDN capabilities, so the potential interworking with QSIG
addressed. will also be addressed.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 6, 2012. This Internet-Draft will expire on April 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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 . . . . . . . . . 6 6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7
7. UAC requirements . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . 10 10. Considerations for ISDN interworking gateways . . . . . . . . 11
11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 11 11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 11
12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 11 12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
14. Security Considerations . . . . . . . . . . . . . . . . . . . 12 14. Security Considerations . . . . . . . . . . . . . . . . . . . 13
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
16. Changes since previous versions . . . . . . . . . . . . . . . 13 16. Changes since previous versions . . . . . . . . . . . . . . . 14
17. Normative References . . . . . . . . . . . . . . . . . . . . . 15 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 17.1. Normative References . . . . . . . . . . . . . . . . . . . 16
17.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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 BCP 14, RFC 2119
[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 [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 discuss the interworking of [RFC3261]. Specifically, this document discuss the interworking of
call control related ITU-T DSS1 User-user information element [Q931], call control related ITU-T DSS1 User-user information element [Q931],
[Q957.1] and ITU-T Q.763 User-to-user information parameter [Q763] [Q957.1] and ITU-T Q.763 User-to-user information parameter [Q763]
data in SIP. UUI is widely used in the PSTN today in contact centers data in SIP. UUI is widely used in the PSTN today in contact centers
and call centers which are transitioning away from ISDN to SIP. 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
skipping to change at page 4, line 31 skipping to change at page 4, line 31
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 and indeed the one that matches the requirements specified in
draft-ietf-cuss-sip-uui-reqs. draft-ietf-cuss-sip-uui-reqs [I-D.ietf-cuss-sip-uui-reqs].
The above come from the ISDN specifications defined for public
networks. There are a parallel set of ISDN specifications defined
for private networks (QSIG}. These specifications do not define a
UUS1 implicit supplementary service. However, implementation of such
a UUS1 implicit supplementary service for private networks can
readily be constructed in a proprietary fashion based on the
specifications for public networks, and evidence suggests that some
vendors have done so. On this basis, there is not reason why this
package cannot also be used to support interworking with such a
private network service, on the assumption that the constraints are
exactly the same as those for the public network.
The ISDN UUS1 service has the following additional characteristics as The ISDN UUS1 service has the following additional characteristics as
to the data that can be transported: to the data that can be transported:
The maximum number of octets of user information that can be The maximum number of octets of user information that can be
transported in 128 octets plus a protocol discriminator. It is transported in 128 octets plus a protocol discriminator. It is
noted that some early ISDN implementations had a limitation of 32 noted that some early ISDN implementations had a limitation of 32
octets, but it is understood that these are not currently octets, but it is understood that these are not currently
deployed. While this package does not prohibit longer data deployed. While this package does not prohibit longer data
fields, the mechanism at any interworking point is to discard data fields, the mechanism at any interworking point is to discard data
skipping to change at page 6, line 12 skipping to change at page 6, line 23
does have the choice of sending data to either or both remote does have the choice of sending data to either or both remote
users. users.
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.
Contributors note: The above list needs to be studied further in
regard to private ISDN service definitions, e.g. for the interworking
of SIP and QSIG.
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, this SIP-T. However, if true ISDN interworking is being done, this
approach is not reasonable. Instead, the better approach is to approach is not reasonable. Instead, the better approach is to
interwork the ISDN UUI using the native SIP UUI transport mechanism, interwork the ISDN UUI using the native SIP UUI transport mechanism,
the User-to-User header field. The rest of this document describes the User-to-User header field. The rest of this document describes
this approach. 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 [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 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. This will permit the other endpoint some other package in parallel. This will permit the other endpoint
to use the UUI according to the ISDN package if it is an ISDN gateway to use the UUI according to the ISDN package if it is an ISDN gateway
or the enhanced package if it is a native SIP endpoint. or the enhanced package if it is a native SIP endpoint.
6. ISDN Usage of the User-to-User Header Field 6. ISDN Usage of the User-to-User Header Field
skipping to change at page 7, line 12 skipping to change at page 7, line 19
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 signalling channel in association with a call to the other ISDN
user.. 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].
The general principals of this package of the UUI mechanism are as One objective of the design of this package has been to keep the
follows: functionality at the interworking point as simple as possible.
Therefore responsibility for respecting the limits has been
transferred to the end UA. If an interworking point is reached, and
the limitations are not met, then the UUI data will not be
transferred, although he SIP request will otherwise be interworked.
As a result there is also only one encoding value specified.
The general principals of this package of the UUI mechanism are
therefore as follows:
That the sending application is expected limit their sending That the sending application is expected limit their sending
requirements to the subset provided by the ISDN UUI service. requirements to the subset provided by the ISDN UUI 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 of the "isdn-uui" package in the same User-to-User header field of the "isdn-uui" package in the same
SIP request or response, and will only allow it in a request or SIP request or response, and will only allow it in a request or
response of the appropriate method (INVITE or BYE). What happens response of the appropriate method (INVITE or BYE). What happens
to User-to-User header fields relating to different packages is to User-to-User header fields relating to different packages is
outside the scope of this document. outside the scope of this document.
skipping to change at page 7, line 36 skipping to change at page 8, line 4
too long will discard the UUI data, but proceed with the too long will discard the UUI data, but proceed with the
interworking. There is no notification of such discard back to interworking. There is no notification of such discard back to
the sending user. If the SIP user knows that it is interworking the sending user. If the SIP user knows that it is interworking
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-user data into the ISDN SETUP message (when discard occurs)
will result in the service being unavailable for the remainder of will result in the service being unavailable for the remainder of
the call when UUS1 implicit operation is used. the call when UUS1 implicit operation is used.
7. UAC requirements 7. UAC requirements
The UAC MUST meet the requirements of [ietf-cuss-sip-uui] in addition The UAC MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in
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
is precluded. is precluded.
If the UAC wishes to user or permit the sending of UUI data at any If the UAC wishes to user or permit the sending of UUI data at any
point in the dialog, the UAC MUST include in the INVITE request for point in the dialog, the UAC MUST include in the INVITE request for
that dialog a User-to-User header field with an "package" header that dialog a User-to-User header field with an "package" header
skipping to change at page 8, line 40 skipping to change at page 9, line 8
intended data packet so all are discarded. intended data packet 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
service restrictions; failure to do so can result in information service restrictions; failure to do so can result in information
being discarded at any interworking point with the ISDN. This being discarded at any interworking point with the ISDN. This
document makes no further normative requirements based on those document makes no further normative requirements based on those
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 payloads longer than this will never reach the destination therefore payloads longer than this will never reach the destination
if such interworking occurs. if such interworking occurs. Note that the 128 octet limit (plus a
protocol discriminator) applies before the encoding (or after the
decoding) using the "hex" encoding. The "hex" encoding is defined in
[I-D.ietf-cuss-sip-uui].
[ietf-cuss-sip-uui] defines a "uui" option tag for use with the UUI [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the
mechanism extension. Because for the ISDN UUI service, the service UUI mechanism extension. Because for the ISDN UUI service, the
is service 1 implicit, the inclusion of the "uui" option tag in a service is service 1 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 of the User-to-User header field with the and above the presence of the User-to-User header field with the
"package" header field parameter to "isdn-uui" in the INVITE request. "package" header field parameter to "isdn-uui" in the INVITE request.
While there is no harm in including the "uui" option tag, and 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 [ietf-cuss-sip-uui] in addition The UAS MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in
to the requirements defined in this document. addition to the requirements defined in this document.
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. is precluded.
The UAS MUST NOT include the User-to-User header field with an The UAS MUST NOT include the User-to-User header field with an
"package" header field parameter set to "isdn-uui" in any message of "package" header field parameter set to "isdn-uui" in any message of
an INVITE dialog if the original INVITE request did not include the an INVITE dialog if the original INVITE request did not include the
skipping to change at page 10, line 44 skipping to change at page 11, line 13
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 interworking 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 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-
User header field. In the reverse direction, it will take valid uui-
data according to the "hex" encoding scheme, and decode it to octet
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
defined table 4-26 of ITU-T Recommendation Q.931 [Q931] as the first defined table 4-26 of ITU-T Recommendation Q.931 [Q931] as the first
octet of the payload information; the interworking gateway will not octet of the payload information; the interworking gateway will not
perform any additional checking of this value. perform any additional checking of this value.
[ietf-cuss-sip-uui] defines a "uui" option tag for use with the UUI [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the
mechanism extension. The option tag is not interworked at an ISDN UUI mechanism extension. The option tag is not interworked at an
interworking gateway. The ISDN interworking gateways MUST NOT take ISDN interworking gateway. The ISDN interworking gateways MUST NOT
the omission of the "uui" option tag in a received INVITE request to take the omission of the "uui" option tag in a received INVITE
indicate that interworking of a received header field is not to be request to indicate that interworking of a received header field is
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
"package" header field parameter. "package" header field parameter.
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. "content" header field parameter. A content value of "isdn-uui"
indicates that the contents have a first octet that is a protocol
discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931]
followed by uui-data that can be subject to a length limitation
(before encoding or after decoding) that is generally 128 octets.
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
This document adds the following row to the "UUI package values" This document adds the following row to the "UUI packages" sub-
section of the SIP parameter registry: registry of the SIP parameter registry:
Value: isdn-uui Value: isdn-uui
Meaning: The associated application is being used with constraints Description: The associated application is being used with
suitable for interworking with the ISDN user-to-user service, and constraints suitable for interworking with the ISDN user-to-user
therefore can be interworked at ISDN gateways. service, and therefore can be interworked at ISDN gateways.
Reference: RFCXXXX Reference: RFCXXXX
Contact: Contact:
This document adds the following row to the "UUI content values" This document adds the following row to the "UUI content" subregistry
section of the SIP parameter registry: of the SIP parameter registry:
Value: isdn-uui Value: isdn-uui
Meaning: 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 "package" header field parameter set to "isdn-uui" this is the the "package" header field parameter set to "isdn-uui" 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: Contact:
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 12, line 43 skipping to change at page 13, line 21
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 RFC 3840 [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 This document contains no specific requirements in regard to security
security. The overlying use case will define the security measures over and above those specified in [I-D.ietf-cuss-sip-uui]. The
required. The underlying user-to-user extension provides a number of overlying use case will define the security measures required. The
tools that can meet certain security requirements. As a level of underlying user-to-user extension provides a number of tools that can
guidance, data that is used to assist in selecting which SIP UA meet certain security requirements. As a level of guidance, data
should respond to the call would not be expected to carry any higher that is used to assist in selecting which SIP UA should respond to
level of security than a media feature tag. Information that might the call would not be expected to carry any higher level of security
otherwise reveal private information about an individual, or where a than a media feature tag. Information that might otherwise reveal
level of authenticity needs to be guaranteed, may need a higher level private information about an individual, or where a level of
of protection, and may indeed not be suitable for this package, authenticity needs to be guaranteed, may need a higher level of
protection, and may indeed not be suitable for this package,
particularly taking into account the statement in the following particularly taking into account the statement in the following
paragraph. paragraph.
As this capability to is defined to interwork with the ISDN, if the As this capability to is defined to interwork with the ISDN, if the
ISDN forms part of the route, any usage needs to assume that the ISDN forms part of the route, any usage needs to assume that the
security level of the ISDN is the highest level of security security level of the ISDN is the highest level of security
available. As the ISDN security is itself not definable on an end- available. As the ISDN security is itself not definable on an end-
to-end basis, this can be an unknown quantity. This is because ISDN to-end basis, this can be an unknown quantity. This is because ISDN
security exists on a hop-by-hop basis, and is only as secure as the security exists on a hop-by-hop basis, and is only as secure as the
least secure component. This can be high in some places (e.g. it can least secure component. This can be high in some places (e.g. it can
skipping to change at page 13, line 37 skipping to change at page 14, line 21
review of earlier versions of this document. The authors wish to review of earlier versions of this document. The authors wish to
thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen
Jennings, and Mahalingam Mani for their comments. Jennings, and Mahalingam Mani for their comments.
16. Changes since previous versions 16. Changes since previous versions
Note to RFC editor: This section is to be deleted before final Note to RFC editor: This section is to be deleted before final
publication. publication.
Changes since made in the creation of the 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-ietf-cuss-sip-uui-isdn-00 version from the
draft-drage-cuss-sip-uui-isdn-01 version. draft-drage-cuss-sip-uui-isdn-01 version.
Removed overburdening of the word "application". Changed the name Removed overburdening of the word "application". Changed the name
of the "app" header field parameter in the mechanism draft to of the "app" header field parameter in the mechanism draft to
"package" header field parameter. This had a consequential impact "package" header field parameter. This had a consequential impact
on the ISDN document. The word "application" is now solely on the ISDN document. The word "application" is now solely
reserved for the name of the functionality that passes the UUI to reserved for the name of the functionality that passes the UUI to
the SIP functionality to send, and to which the UUI is delivered 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 on receipt by the SIP functionality. As well as the change of the
skipping to change at page 15, line 6 skipping to change at page 16, line 16
Corrected the short title for the draft. Corrected the short title for the draft.
Changes since made in the creation of the Changes since made in the creation of the
draft-drage-cuss-sip-uui-isdn-01 version from the draft-drage-cuss-sip-uui-isdn-01 version from the
draft-drage-cuss-sip-uui-isdn-00 version. draft-drage-cuss-sip-uui-isdn-00 version.
Closure of a number of open issues identified in the -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 creation of appropriate procedures for the UAC, the UAS,
and the ISDN interworking gateway. and the ISDN interworking gateway.
17. Normative References 17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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
for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[I-D.ietf-cuss-sip-uui]
Johnston, A. and J. Rafferty, "A Mechanism for
Transporting User to User Call Control Information in
SIP", draft-ietf-cuss-sip-uui-04 (work in progress),
October 2011.
[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 . http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
17.2. Informative References
[I-D.ietf-cuss-sip-uui-reqs]
Johnston, A. and L. Liess, "Problem Statement and
Requirements for Transporting User to User Call Control
Information in SIP", draft-ietf-cuss-sip-uui-reqs-07 (work
in progress), October 2011.
[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 . 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 . http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
[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".
[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".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[ietf-cuss-sip-uui-reqs]
Johnston, A., McMillen, J., and L. Liess, "Problem
Statement and Requirements for Transporting User to User
Call Control Information in SIP",
draft-ietf-cuss-sip-uui-reqs-00 .
[ietf-cuss-sip-uui]
Johnston, A. and J. Rafferty, "A Mechanism for
Transporting User to User Call Control Information in
SIP", draft-ietf-cuss-sip-uui-00 .
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
 End of changes. 30 change blocks. 
84 lines changed or deleted 152 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/