draft-ietf-cuss-sip-uui-isdn-01.txt   draft-ietf-cuss-sip-uui-isdn-02.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 3, 2012 Avaya Expires: August 29, 2012 Avaya
October 2011 February 26, 2012
Interworking ISDN Call Control User Information with SIP Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-01 draft-ietf-cuss-sip-uui-isdn-02
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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 3, 2012. This Internet-Draft will expire on August 29, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
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 interworking gateways . . . . . . . . 11
11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 11 11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 11
12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12 12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
14. Security Considerations . . . . . . . . . . . . . . . . . . . 13 14. Security Considerations . . . . . . . . . . . . . . . . . . . 13
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
16. Changes since previous versions . . . . . . . . . . . . . . . 14 16. Changes since previous versions . . . . . . . . . . . . . . . 14
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
17.1. Normative References . . . . . . . . . . . . . . . . . . . 16 17.1. Normative References . . . . . . . . . . . . . . . . . . . 17
17.2. Informative References . . . . . . . . . . . . . . . . . . 16 17.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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 [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 discuss 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-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
between two SIP terminals. between two SIP terminals.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
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. UUS1
explicit uses additional supplementary service control information explicit uses additional supplementary service control information
to control the request and granting of the service, as in USS2 and to control the request and granting of the service, as in UUS2 and
UUS3. In UUS1 implicit, it is the presence of the user signalling UUS3. In UUS1 implicit, it is the presence of the user signalling
data itself that constitutes the request for the service. UUS1 data itself that constitutes the request for the service. UUS1
explicit as a result also allows the requester to additionally explicit as a result also allows the requester to additionally
specify whether the parallel circuit-switched connection should specify whether the parallel circuit-switched connection should
proceed if the UUS1 service cannot be provided (preferred or proceed if the UUS1 service cannot be provided (preferred or
required). 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.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
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 [I-D.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 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 not 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
private network service, on the assumption that the constraints are private network service, on the assumption that the constraints are
exactly the same as those for the public network. 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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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 package can be transported in each Only a single user information can be transported in each message.
message.
The ISDN service works without encryption or integrity protection. The ISDN service works without encryption or integrity protection.
The user trusts the intermediate network elements, and therefore The user trusts the intermediate network elements, and therefore
the operator of those elements, not to modify the data, and to the operator of those elements, not to modify the data, and to
deliver all the data to the remote user. On a link by link basis, deliver all the data to the remote user. On a link by link basis,
message contents are protected at layer 2 by standard CRC message contents are protected at layer 2 by standard CRC
mechanisms - this allows loss on a link level basis to be mechanisms - this allows loss on a link level basis to be
detected, but does not guard against fraudulent attacks on the detected, but does not guard against fraudulent attacks on the
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 payload itself, encryption or integrity protection within the payload itself,
skipping to change at page 5, line 50 skipping to change at page 5, line 49
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 user- Conference ISDN conferencing allows the user to still exchange user-
to-user data after the conference is created. As far as UUS1 is to-user data after the conference is created. As far as UUS1 is
concerned, this means that when an individual party clears, those concerned, it is not permitted.
clearing messages can still contain user-to-user data. As a
conferee this is sent to the conference controller. As the
conference controller, as this effectively clears the conference,
it can be broadcast to all conferees, or sent to individual
conferees [OPEN ISSUE - CHECK THIS IN THE PROTOCOL - DOES IT
REQUIRE EXPLICIT].
The ISDN three-party supplementary service is similar in many ways The ISDN three-party supplementary service is similar in many ways
to conferencing, but is signalled using a different mechanism. to conferencing, but is signalled using a different mechanism.
This means that on clearing, the controller using UUS1 implicit This means that on clearing, the controller using UUS1 implicit
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. Because SIP conferencing cannot completely emulate the
ISDN three-party supplementary service at the served user, UUS1
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
skipping to change at page 6, line 49 skipping to change at page 6, line 46
with one User Agent being an ISDN gateway while the other User Agent with one User Agent being an ISDN gateway while the other User Agent
is a native SIP endpoint. As networks transition away from ISDN, it is a native SIP endpoint. As networks transition away from ISDN, it
is possible that both User Agents could become native SIP endpoints. is possible that both User Agents could become native SIP endpoints.
In this case, there is an opportunity to transition away from this In this case, there is an opportunity to transition away from this
ISDN usage to a more general usage of [I-D.ietf-cuss-sip-uui]. ISDN usage to a more general usage of [I-D.ietf-cuss-sip-uui].
The SIP UUI mechanism provides a way to achieve this transition. As The SIP UUI mechanism provides a way to achieve this transition. As
an endpoint moves from being an ISDN gateway to a native SIP an endpoint moves from being an ISDN gateway to a native SIP
endpoint, and a package for some form of enhanced UUI has been endpoint, and a 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, and in the same messages or in
to use the UUI according to the ISDN package if it is an ISDN gateway different messages depending on the needs of the application. This
or the enhanced package if it is a native SIP endpoint. will permit the other endpoint to use the UUI according to the ISDN
package if it is an ISDN gateway or the enhanced package if it is a
native SIP endpoint.
6. ISDN Usage of the User-to-User Header Field 6. ISDN Usage of the User-to-User Header Field
This document defines the package for the ISDN interworking of UUI This document defines the package for the ISDN interworking of UUI
which is to interoperate with ISDN User to User Signaling (UUS), a which is to interoperate with ISDN User to User Signaling (UUS), a
supplementary service in which the user is able to send/receive a supplementary service in which the user is able to send/receive a
limited amount of information to/from another ISDN user over the limited amount of information to/from another ISDN user over the
signalling channel in association with a call to the other ISDN 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].
One objective of the design of this package has been to keep the One objective of the design of this package has been to keep the
functionality at the interworking point as simple as possible. functionality at the interworking point as simple as possible.
Therefore responsibility for respecting the limits has been Therefore responsibility for respecting the limits has been
transferred to the end UA. If an interworking point is reached, and transferred to the end UA. If an interworking point is reached, and
the limitations are not met, then the UUI data will not be the limitations are not met, then the UUI data will not be
transferred, although he SIP request will otherwise be interworked. transferred, although the SIP request will otherwise be interworked.
As a result there is also only one encoding value specified. As a result there is also only one encoding value specified.
The general principals of this package of the UUI mechanism are The general principals of this package of the UUI mechanism are
therefore as follows: therefore as follows:
That the sending application is expected limit their sending That the sending application is expected to limit their sending
requirements to the subset provided by the ISDN UUI service. requirements to the subset provided by the ISDN 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.
That an interworking point trying to interwork UUI data that is That an interworking point trying to interwork UUI data that is
skipping to change at page 8, line 21 skipping to change at page 8, line 15
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
is precluded. is precluded. Usage on other methods within the INVITE dialog, and
on re-INVITE transactions with the INVITE dialog, is also precluded.
If the UAC wishes to user or permit the sending of UUI data at any If the UAC wishes to use 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. The UAC WSHOULD set the
field parameter set to "isdn-uui". This initial header field "package" header field parameter to "isdn-uui". Non-inclusion of the
constitutes the implicit request to use the UUI service, and is "package" header field parameter is permitted, but this is primarily
therefore included even when there is no data except the protocol to allow earlier implementations to support this package. This
discriminator octet to send at that point in time. initial header field constitutes the implicit request to use the UUI
service, and is therefore included even when there is no data except
the protocol discriminator octet to send at that point in time.
The UAC MUST NOT include the User-to-User header field with an The UAC MUST NOT include the User-to-User header field with a
"package" header field parameter set to "isdn-uui" in any message of "package" header field parameter set to "isdn-uui", or with no
an INVITE dialog if the original INVITE request did not include the "package" header field parameter", in any message of an INVITE dialog
User-to-User header field with an "package" header field parameter if the original INVITE request did not include the User-to-User
set to "isdn-uui" header field, either with a "package" header field parameter set to
"isdn-uui", or with no "package" header field parameter included.
When sending UUI for the ISDN package, the UAC MUST set the User-to- When sending UUI for the ISDN package, if the "package" header field
User "package" header field parameter to "isdn-uui". The UAC MUST is included, the UAC MUST set the User-to-User "package" header field
NOT include more than one User-to-User header field for this package parameter to "isdn-uui". The UAC MUST NOT include more than one
in any SIP request or response. User-to-User header field for this package in any SIP request or
response.
When receiving UUI, when multiple User-to-User header fields are When receiving UUI, when multiple User-to-User header fields are
received in the same response with the "package" header field received in the same response with the "package" header field
parameter to "isdn-uui", the UAS MUST discard all these header parameter to "isdn-uui", or with no "package" header field parameter,
fields. There are no mechanisms for determining which was the or with some combination of these, the UAS MUST discard all these
header fields. There are no mechanisms for determining which was the
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
skipping to change at page 9, line 36 skipping to change at page 9, line 37
8. UAS requirements 8. UAS requirements
The UAS MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in The UAS MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in
addition 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. Usage on other methods within the INVITE dialog, and
on re-INVITE transactions with the INVITE dialog, is also 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 a
"package" header field parameter set to "isdn-uui" in any message of "package" header field parameter set to "isdn-uui", or with no
an INVITE dialog if the original INVITE request did not include the "package" header field parameter", in any message of an INVITE dialog
User-to-User header field with an "package" header field parameter if the original INVITE request did not include the User-to-User
set to "isdn-uui" header field, either with a "package" header field parameter set to
"isdn-uui", or with no "package" header field parameter included.
The UAS MAY include the User-to-User header field in responses to the The UAS MAY include the User-to-User header field in responses to the
initial INVITE request, or the BYE requests or responses for the initial INVITE request, or the BYE requests or responses for the
dialog, only where the original INVITE request included a User-to- dialog, only where the original INVITE request included a User-to-
User header field with the "package" header field parameter to "isdn- User header field with the "package" header field parameter to "isdn-
uui". When sending UUI for the ISDN package, the UAS MUST set the uui", or where no "package" header field parameter was included.
User-to-User "package" header field parameter to "isdn-uui". The UAS When sending UUI for the ISDN package, the UAS SHOULD set the User-
MUST NOT include more than one User-to-User header field for this to-User "package" header field parameter to "isdn-uui". Non-
package in any SIP request or response. inclusion of the "package" header field parameter is permitted, but
this is primarily to allow earlier implementations to support this
package. The UAS MUST NOT include more than one User-to-User header
field for this package in any SIP request or response.
Where the UAS is acting as a redirect server, the UAS MUST NOT Where the UAS is acting as a redirect server, the UAS MUST NOT
include the User-to-User header field in the header URI parameter in include the User-to-User header field in the header URI parameter in
a 3xx response to an incoming request. a 3xx response to an incoming request.
When receiving UUI, when a User-to-User header field is received in a When receiving UUI, when a User-to-User header field is received in a
request that is not from the originating user with the "package" request that is not from the originating user with the "package"
header field parameter to "isdn-uui", the UAC MUST discard this header field parameter to "isdn-uui", or with no "package" header
header fields. field parameter, the UAC MUST discard this header field.
When receiving UUI, when multiple User-to-User header fields are When receiving UUI, when multiple User-to-User header fields are
received from the originating user in the same request with the received from the originating user in the same request with the
"package" header field parameter to "isdn-uui", the UAC MUST discard "package" header field parameter to "isdn-uui", or with no "package"
all these header fields. There are no mechanisms for determining header field parameter, or with some combination of these, the UAC
which was the intended data packet so all are discarded. MUST discard all these header fields. There are no mechanisms for
determining which was the intended data packet so all are discarded.
9. UUI contents 9. UUI contents
These requirements apply when the "package" header field parameter is These requirements apply when the "package" header field parameter is
set to "isdn-uui". Processing for User-to-User header fields sent or set to "isdn-uui", or with no "package" header field parameter.
received with values other than this value are outside the scope of Processing for User-to-User header fields sent or received with
this document, and the appropriate package document for that value values other than this value are outside the scope of this document,
applies. and the appropriate package document for that value applies.
When sending UUI, the sending SIP entity MAY, but need not, include a When sending UUI, the sending SIP entity MAY, but need not, include a
"content" header field with a value set to "isdn-uui". A receiving "content" header field with a value set to "isdn-uui". A receiving
SIP entity MUST ignore a received User-to-User header field if the SIP entity MUST ignore a received User-to-User header field if the
"content" header field parameter is present and the value is some "content" header field parameter is present and the value is some
other value that "isdn-uui". other value that "isdn-uui".
When sending UUI, the sending SIP entity MAY, but need not, include When sending UUI, the sending SIP entity MAY, but need not, include
an "encoding" header field with a value set to "hex". A receiving an "encoding" header field with a value set to "hex". A receiving
SIP entity MUST ignore a received User-to-User header field if the SIP entity MUST ignore a received User-to-User header field if the
skipping to change at page 13, line 35 skipping to change at page 13, line 43
meet certain security requirements. As a level of guidance, data meet certain security requirements. As a level of guidance, data
that is used to assist in selecting which SIP UA should respond to that is used to assist in selecting which SIP UA should respond to
the call would not be expected to carry any higher level of security the call would not be expected to carry any higher level of security
than a media feature tag. Information that might otherwise reveal than a media feature tag. Information that might otherwise reveal
private information about an individual, or where a level of private information about an individual, or where a level of
authenticity needs to be guaranteed, may need a higher level of authenticity needs to be guaranteed, may need a higher level of
protection, and may indeed not be suitable for this package, 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 is defined to interwork with the ISDN, if the ISDN
ISDN forms part of the route, any usage needs to assume that the forms part of the route, any usage needs to assume that the security
security level of the ISDN is the highest level of security level of the ISDN is the highest level of security available. As the
available. As the ISDN security is itself not definable on an end- ISDN security is itself not definable on an end-to-end basis, this
to-end basis, this can be an unknown quantity. This is because ISDN can be an unknown quantity. This is because ISDN security exists on
security exists on a hop-by-hop basis, and is only as secure as the a hop-by-hop basis, and is only as secure as the least secure
least secure component. This can be high in some places (e.g. it can component. This can be high in some places (e.g. it can require
require physical access to a secure building) and in other places it physical access to a secure building) and in other places it can be
can be low (e.g. the point where an ISDN access enters a building). low (e.g. the point where an ISDN access enters a building). If this
If this level of security is not sufficient, then either a different level of security is not sufficient, then either a different user-to-
user-to-user package, or indeed, a different method of data transfer, user package, or indeed, a different method of data transfer, needs
needs to be selected by the application user. to be selected by the application user.
15. Acknowledgements 15. Acknowledgements
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, and Laura Liess for their
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, Mahalingam Mani and Celine Serrut-Valette 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-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-01 version from the
draft-ietf-cuss-sip-uui-isdn-00 version. draft-ietf-cuss-sip-uui-isdn-00 version.
QSIG does not define a UUS service. As such changes are made to QSIG does not define a UUS service. As such changes are made to
indicate that it is possible to support a proprietary service on indicate that it is possible to support a proprietary service on
QSIG based on the public ISDN standards, and interworking with QSIG based on the public ISDN standards, and interworking with
such proprietary versions is supported. The associated such proprietary versions is supported. The associated
contributors note regarding interactions with other QSIG services contributors note regarding interactions with other QSIG services
has therefore been removed with this amendment. has therefore been removed with this amendment.
skipping to change at page 17, line 5 skipping to change at page 17, line 38
[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 17.2. Informative References
[I-D.ietf-cuss-sip-uui-reqs] [I-D.ietf-cuss-sip-uui-reqs]
Johnston, A. and L. Liess, "Problem Statement and Johnston, A. and L. Liess, "Problem Statement and
Requirements for Transporting User to User Call Control Requirements for Transporting User to User Call Control
Information in SIP", draft-ietf-cuss-sip-uui-reqs-07 (work Information in SIP", draft-ietf-cuss-sip-uui-reqs-09 (work
in progress), October 2011. in progress), January 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 . 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",
 End of changes. 32 change blocks. 
82 lines changed or deleted 115 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/