draft-ietf-cuss-sip-uui-isdn-02.txt   draft-ietf-cuss-sip-uui-isdn-03.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: August 29, 2012 Avaya Expires: September 14, 2012 Avaya
February 26, 2012 March 13, 2012
Interworking ISDN Call Control User Information with SIP Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-02 draft-ietf-cuss-sip-uui-isdn-03
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 August 29, 2012. This Internet-Draft will expire on September 14, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
Only a single user information can be transported in each message. Only a single user information can be transported in each message.
The ISDN service works without encryption or integrity protection. The ISDN service works without encryption or integrity protection.
The user trusts the intermediate network elements, and therefore The user trusts the intermediate network elements, and therefore
the operator of those elements, not to modify the data, and to the operator of those elements, not to modify the data, and to
deliver all the data to the remote user. On a link by link basis, deliver all the data to the remote user. On a link by link basis,
message contents are protected at layer 2 by standard CRC message contents are protected at layer 2 by standard CRC
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 UUI data itself,
although the limit on the size of the payload (128 octets) will although the limit on the size of the UUI data (protocol
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
skipping to change at page 8, line 20 skipping to change at page 8, line 20
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. Usage on other methods within the INVITE dialog, and is precluded. Usage on other methods within the INVITE dialog, and
on re-INVITE transactions with the INVITE dialog, is also precluded. on re-INVITE transactions with the INVITE dialog, is also precluded.
If the UAC wishes to use 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. The UAC WSHOULD set the that dialog a User-to-User header field. The UAC SHOULD set the
"package" header field parameter to "isdn-uui". Non-inclusion of the "package" header field parameter to "isdn-uui". Non-inclusion of the
"package" header field parameter is permitted, but this is primarily "package" header field parameter is permitted, but this is primarily
to allow earlier implementations to support this package. This to allow earlier implementations to support this package. This
initial header field constitutes the implicit request to use the UUI initial header field constitutes the implicit request to use the UUI
service, and is therefore included even when there is no data except service, and is therefore included even when there is no data except
the protocol discriminator octet to send at that point in time. the protocol discriminator octet to send at that point in time.
The UAC MUST NOT include the User-to-User header field with a The UAC MUST NOT include the User-to-User header field with a
"package" header field parameter set to "isdn-uui", or with no "package" header field parameter set to "isdn-uui", or with no
"package" header field parameter", in any message of an INVITE dialog "package" header field parameter", in any message of an INVITE dialog
skipping to change at page 9, line 8 skipping to change at page 9, line 8
header fields. There are no mechanisms for determining which was the 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 UUI data longer than this will never reach the destination
if such interworking occurs. Note that the 128 octet limit (plus a if such interworking occurs. Note that the 128 octet limit (plus a
protocol discriminator) applies before the encoding (or after the protocol discriminator) applies before the encoding (or after the
decoding) using the "hex" encoding. The "hex" encoding is defined in decoding) using the "hex" encoding. The "hex" encoding is defined in
[I-D.ietf-cuss-sip-uui]. [I-D.ietf-cuss-sip-uui].
[I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the
UUI mechanism extension. Because for the ISDN UUI service, the UUI mechanism extension. Because for the ISDN UUI service, the
service is service 1 implicit, the inclusion of the "uui" option tag service is service 1 implicit, the inclusion of the "uui" option tag
in a Supported header field conveys no additional information over in a Supported header field conveys no additional information over
and 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
skipping to change at page 10, line 36 skipping to change at page 10, line 36
determining which was the intended data packet so all are discarded. 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", or with no "package" header field parameter. set to "isdn-uui", or with no "package" header field parameter.
Processing for User-to-User header fields sent or received with Processing for User-to-User header fields sent or received with
values other than this value are outside the scope of this document, values other than this value are outside the scope of this document,
and the appropriate package document for that value applies. and the appropriate package document for that value applies.
The default and only content defined for this package is "isdn-uui".
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".
The default and only encoding defined for this package is "hex".
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
"encoding" header field parameter is present and the value is some "encoding" header field parameter is present and the value is some
other value that "hex". other value that "hex".
When sending UUI, the sending application MUST include a protocol When sending UUI, the sending application MUST include a protocol
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 payload information. It is up Q.931 [Q931] as the first octet of the UUI data. It is up to the
to the receiving application what it does with this value. This receiving application what it does with this value. This document
document places no other normative requirement on the use of the places no other normative requirement on the use of the protocol
protocol discriminator; it is required at interworking gateways to discriminator; it is required at interworking gateways to allow
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 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
skipping to change at page 11, line 35 skipping to change at page 11, line 37
structured data for sending to the ISDN side. structured data for sending to the ISDN side.
When mapping data content from the ISDN to the SIP signalling, or When mapping data content from the ISDN to the SIP signalling, or
from SIP signalling to the ISDN, the gateway needs to assume that all from SIP signalling to the ISDN, the gateway needs to assume that all
content is octet structured binary, irrespective of the value of the content is octet structured binary, irrespective of the value of the
received protocol discriminator. There are no requirements in the received protocol discriminator. There are no requirements in the
ISDN to ensure that the content matches the value of the protocol ISDN to ensure that the content matches the value of the protocol
discriminator, and it is for the application usage to sort out any discriminator, and it is for the application usage to sort out any
discrepancy. The same applies to the ISDN protocol discrimination discrepancy. The same applies to the ISDN protocol discrimination
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 UUI data; the interworking gateway will not perform any
perform any additional checking of this value. additional checking of this value.
[I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the
UUI mechanism extension. 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
skipping to change at page 14, line 25 skipping to change at page 14, line 28
thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen
Jennings, Mahalingam Mani and Celine Serrut-Valette for their Jennings, Mahalingam Mani and Celine Serrut-Valette for their
comments. 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-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-02 version from the
draft-ietf-cuss-sip-uui-isdn-01 version. draft-ietf-cuss-sip-uui-isdn-01 version.
The inclusion of the "package" header field parameter has be The inclusion of the "package" header field parameter has be
downgraded to "RECOMMENDED", with the purpose stated as being for downgraded to "RECOMMENDED", with the purpose stated as being for
interworking. Changes have been made to the procedures at the interworking. Changes have been made to the procedures at the
receiving side to allow for the non-inclusion of the "package" receiving side to allow for the non-inclusion of the "package"
header field parameter. The effect of this is that the absence of header field parameter. The effect of this is that the absence of
the "package" header field parameter means by default the use of the "package" header field parameter means by default the use of
the "uui-isdn" package. the "uui-isdn" package.
skipping to change at page 17, line 25 skipping to change at page 17, line 38
for Telephones (SIP-T): Context and Architectures", for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002. BCP 63, RFC 3372, September 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[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-04 (work in progress), SIP", draft-ietf-cuss-sip-uui-05 (work in progress),
October 2011. March 2012.
[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
 End of changes. 12 change blocks. 
18 lines changed or deleted 30 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/