< draft-ietf-cuss-sip-uui-isdn-05.txt   draft-ietf-cuss-sip-uui-isdn-06.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: February 5, 2014 Avaya Expires: June 19, 2014 Avaya
August 4, 2013 December 16, 2013
Interworking ISDN Call Control User Information with SIP Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-05 draft-ietf-cuss-sip-uui-isdn-06
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
defines a usage (a new package) of the User-to-User header field to a usage (a new package) of the User-to-User header field to enable
enable interworking with this ISDN service. interworking with this ISDN service.
This document covers the interworking with both public ISDN and This document covers the interworking with both public ISDN and
private ISDN capabilities, so the potential interworking with QSIG private ISDN capabilities, so the potential interworking with QSIG
will also be addressed. will also be addressed.
The package is identified by a new value "isdn-uui" of the "purpose" The package is identified by a new value "isdn-uui" of the "purpose"
header field parameter. header field parameter.
Status of this Memo Status of this Memo
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 February 5, 2014. This Internet-Draft will expire on June 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3. Summary of the ISDN User-to-User Service . . . . . . . . . . . 3 3. Summary of the ISDN User-to-User Service . . . . . . . . . . . 3
3.1. The service . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. The service . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Impacts of the ISDN service on SIP operation . . . . . . . 5 3.2. Impacts of the ISDN service on SIP operation . . . . . . . 5
4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6 4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6
5. Transition away from ISDN . . . . . . . . . . . . . . . . . . 6 5. Transition away from ISDN . . . . . . . . . . . . . . . . . . 6
6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7 6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 7
7. UAC requirements . . . . . . . . . . . . . . . . . . . . . . . 8 7. UAC requirements . . . . . . . . . . . . . . . . . . . . . . . 8
8. UAS requirements . . . . . . . . . . . . . . . . . . . . . . . 9 8. UAS requirements . . . . . . . . . . . . . . . . . . . . . . . 9
9. UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Considerations for ISDN interworking gateways . . . . . . . . 11 10. Considerations for ISDN interworking gateways . . . . . . . . 11
11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 11 11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
17.1. Normative References . . . . . . . . . . . . . . . . . . . 18 17.1. Normative References . . . . . . . . . . . . . . . . . . . 18
17.2. Informative References . . . . . . . . . . . . . . . . . . 18 17.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 4, line 49 skipping to change at page 4, line 49
specifications for public networks, and evidence suggests that some specifications for public networks, and evidence suggests that some
vendors have done so. On this basis, there is no reason why this vendors have done so. On this basis, there is no reason why this
package cannot also be used to support interworking with such a package cannot also be used to support interworking with such a
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 is 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
elements that are too long to handle. The handled length can elements that are too long to handle. The handled length can
normally be assumed to be 128 octets. normally be assumed to be 128 octets.
The content of the user information octets is described by a The content of the user information octets is described by a
single octet protocol discriminator (see table 4-26 of ITU-T single octet protocol discriminator (see table 4-26 of ITU-T
Recommendation Q.931) [Q931]. That protocol descriminator may Recommendation Q.931) [Q931]. That protocol descriminator may
skipping to change at page 5, line 39 skipping to change at page 5, line 39
link itself. This does not prevent the use of additional link itself. This does not prevent the use of additional
encryption or integrity protection within the UUI data itself, encryption or integrity protection within the UUI data itself,
although the limit on the size of the UUI data (protocol although the limit on the size of the UUI data (protocol
discriminator plus 128 octets) will restrict this. discriminator plus 128 octets) will restrict this.
3.2. Impacts of the ISDN service on SIP operation 3.2. Impacts of the ISDN service on SIP operation
The ISDN service has the following impacts that need to be understood The ISDN service has the following impacts that need to be understood
within the SIP environment. within the SIP environment.
Call transfer ISDN call transfer cancels all user-to-user Call transfer: ISDN call transfer cancels all user-to-user
supplementary services. In the ISDN, if user-to-user data is supplementary services. In the ISDN, if user-to-user data is
required after call transfer, then UUS3 has to be renegotiated, required after call transfer, then UUS3 has to be renegotiated,
which is not provided by this SIP extension. The impact of this which is not provided by this SIP extension. The impact of this
restriction on the SIP environment is that UUI header fields restriction on the SIP environment is that UUI header fields
cannot be exchanged in transactions clearing down the SIP dialog cannot be exchanged in transactions clearing down the SIP dialog
after call transfer has occurred. after call transfer has occurred.
Conference ISDN conferencing allows the user to still exchange user- Conference: ISDN conferencing allows the user to still exchange
to-user data after the conference is created. As far as UUS1 is user-to-user data after the conference is created. As far as UUS1
concerned, it is not permitted. is concerned, it is not permitted.
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. Because SIP conferencing cannot completely emulate the users. Because SIP conferencing cannot completely emulate the
ISDN three-party supplementary service at the served user, UUS1 ISDN three-party supplementary service at the served user, UUS1
implicit is not possible. implicit is not possible.
Diversion When ISDN diversion occurs, any UUS1 user-to-user data is Diversion: When ISDN diversion occurs, any UUS1 user-to-user data is
sent to the forwarded-to-user (assuming that the call meets sent to the forwarded-to-user (assuming that the call meets
requirements for providing the service - this is impacted by the requirements for providing the service - this is impacted by the
explicit service only). If the type of diversion is such that the explicit service only). If the type of diversion is such that the
call is also delivered to the forwarding user, they will also call is also delivered to the forwarding user, they will also
receive any UUS1 user-to-user data. receive any UUS1 user-to-user data.
4. Relation to SIP-T 4. Relation to SIP-T
A method of transport of ISDN UUI is to use SIP-T [RFC3372] and A method of transport of ISDN UUI is to use SIP-T [RFC3372] and
transport the UUI information end-to-end, as part of an ISUP message transport the UUI information end-to-end, as part of an ISUP message
skipping to change at page 7, line 34 skipping to change at page 7, line 34
The general principals of this package of the UUI mechanism are The general principals of this package of the UUI mechanism are
therefore as follows: therefore as follows:
That the sending application is expected to limit their sending That the sending application is expected to limit their sending
requirements to the subset provided by the ISDN UUI service. requirements to the subset provided by the ISDN 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 relating to the "isdn-uui" package in User-to-User header field relating to the "isdn-uui" package in
the same SIP request or response, and will only allow it in a the same SIP request or response, and will only allow it in a
request or response of the appropriate method (INVITE or BYE). request or response of the appropriate method (INVITE or BYE).
What happens to User-to-User header fields relating to different What happens to User-to-User header fields relating to other
packages is outside the scope of this document. packages is outside the scope of this document.
That an interworking point trying to interwork UUI data that is That an interworking point trying to interwork UUI data that is
too long will discard the UUI data, but proceed with the too long will discard the UUI data, but proceed with the
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
skipping to change at page 9, line 18 skipping to change at page 9, line 18
therefore UUI data longer than this will never reach the destination therefore UUI data longer than this will never reach the destination
if such interworking occurs. Note that the 128 octet limit (plus a if such interworking occurs. Note that the 128 octet limit (plus a
protocol discriminator) applies before the encoding (or after the protocol discriminator) applies before the encoding (or after the
decoding) using the "hex" encoding. The "hex" encoding is defined in decoding) using the "hex" encoding. The "hex" encoding is defined in
[I-D.ietf-cuss-sip-uui]. [I-D.ietf-cuss-sip-uui].
[I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the
UUI mechanism extension. Because for the ISDN UUI service, the UUI mechanism extension. Because for the ISDN 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, in the INVITE request, of the User-to-User
"purpose" header field parameter to "isdn-uui" in the INVITE request. header field with the "purpose" header field parameter set to "isdn-
While there is no harm in including the "uui" option tag, and uui". While there is no harm in including the "uui" option tag, and
strictly it should be included if the extension is supported, it strictly it should be included if the extension is supported, it
performs no function. The presence of the "uui" option tag in the performs no function. The presence of the "uui" option tag in the
Require header field of an INVITE request will cause the request to Require header field of an INVITE request will cause the request to
fail if it reaches a UAS or ISDN interworking gateway that does not fail if it reaches a UAS or ISDN interworking gateway that does not
support this extension; such a usage is not precluded although it support this extension; such a usage is not precluded although it
does not form part of the package. does not form part of the package.
8. UAS requirements 8. UAS requirements
The UAS MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in The UAS MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in
skipping to change at page 9, line 50 skipping to change at page 9, line 50
The UAS MUST NOT include the User-to-User header field with a The UAS MUST NOT include the User-to-User header field with a
"purpose" header field parameter set to "isdn-uui", or with no "purpose" header field parameter set to "isdn-uui", or with no
"purpose" header field parameter", in any message of an INVITE dialog "purpose" header field parameter", in any message of an INVITE dialog
if the original INVITE request did not include the User-to-User if the original INVITE request did not include the User-to-User
header field, either with a "purpose" header field parameter set to header field, either with a "purpose" header field parameter set to
"isdn-uui", or with no "purpose" header field parameter included. "isdn-uui", or with no "purpose" header field parameter included.
The UAS MAY include the User-to-User header field in responses to the The UAS MAY include the User-to-User header field in responses to the
initial INVITE request, or the BYE requests or responses for the initial INVITE request, or the BYE requests or responses for the
dialog, only where the original INVITE request included a User-to- dialog, only where the original INVITE request included a User-to-
User header field with the "purpose" header field parameter to "isdn- User header field with the "purpose" header field parameter set to
uui", or where no "purpose" header field parameter was included. "isdn-uui", or where no "purpose" header field parameter was
When sending UUI for the ISDN package, the UAS SHOULD set the User- included. When sending UUI for the ISDN package, the UAS SHOULD set
to-User "purpose" header field parameter to "isdn-uui". Non- the User-to-User "purpose" header field parameter to "isdn-uui".
inclusion of the "purpose" header field parameter is permitted, but Non-inclusion of the "purpose" header field parameter is permitted,
this is primarily to allow earlier implementations to support this but this is primarily to allow earlier implementations to support
package. The UAS MUST NOT include more than one User-to-User header this package. The UAS MUST NOT include more than one User-to-User
field for this package in any SIP request or response. header field for this package in any SIP request or response.
The "isdn-interwork" value for purpose parameter was used in
Internet-Drafts that have led to the publication of the present
document. Although these documents had no other status than "work in
progress", this value is implemented by some vendors. While not
defined by this document, implementations could find it useful for
interoperability purposes to support parsing and interpreting "isdn-
interwork" the same way as "isdn-uui" when receiving messages.
Where the UAS is acting as a redirect server, the UAS MUST NOT Where the UAS is acting as a redirect server, the UAS MUST NOT
include the User-to-User header field in the header URI parameter in include the User-to-User header field in the header URI parameter in
a 3xx response to an incoming request. a 3xx response to an incoming request.
When receiving UUI, when a User-to-User header field is received in a When receiving UUI, when a User-to-User header field is received in a
request that is not from the originating user with the "purpose" request that is not from the originating user with the "purpose"
header field parameter to "isdn-uui", or with no "purpose" header header field parameter to "isdn-uui", or with no "purpose" header
field parameter, the UAC MUST discard this header field. field parameter, the UAC MUST discard this header field.
skipping to change at page 10, line 41 skipping to change at page 10, line 49
set to "isdn-uui", or with no "purpose" header field parameter. set to "isdn-uui", or with no "purpose" 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". 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 than "isdn-uui".
The default and only encoding defined for this package is "hex". 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
skipping to change at page 14, line 40 skipping to change at page 14, line 47
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-06 version from the
draft-ietf-cuss-sip-uui-isdn-05 version.
A new paragraph of informative material has been added in section
8 relating to older implementations generating "ISDNinterwork" as
a purpose value.
A number of editorial changes have been made.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-05 version from the draft-ietf-cuss-sip-uui-isdn-05 version from the
draft-ietf-cuss-sip-uui-isdn-04 version. draft-ietf-cuss-sip-uui-isdn-04 version.
ABNF provided for definition of values of package and content to ABNF provided for definition of values of package and content to
correspond to ABNF in current version of [I-D.ietf-cuss-sip-uui] correspond to ABNF in current version of [I-D.ietf-cuss-sip-uui]
Changes since made in the creation of the Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-04 version from the draft-ietf-cuss-sip-uui-isdn-04 version from the
draft-ietf-cuss-sip-uui-isdn-03 version. draft-ietf-cuss-sip-uui-isdn-03 version.
skipping to change at page 18, line 25 skipping to change at page 18, line 39
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-10 (work in progress), SIP", draft-ietf-cuss-sip-uui-11 (work in progress),
April 2013. October 2013.
[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
[RFC6567] Johnston, A. and L. Liess, "Problem Statement and [RFC6567] Johnston, A. and L. Liess, "Problem Statement and
Requirements for Transporting User-to-User Call Control Requirements for Transporting User-to-User Call Control
 End of changes. 15 change blocks. 
29 lines changed or deleted 47 lines changed or added

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