draft-ietf-cuss-sip-uui-isdn-06.txt   draft-ietf-cuss-sip-uui-isdn-07.txt 
Network Working Group K. Drage, Ed. CUSS K. Drage, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track A. Johnston Intended status: Standards Track A. Johnston
Expires: June 19, 2014 Avaya Expires: August 18, 2014 Avaya
December 16, 2013 February 14, 2014
Interworking ISDN Call Control User Information with SIP Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-06 draft-ietf-cuss-sip-uui-isdn-07
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 defines this ISDN service for end-to-end transparency. This document defines
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 June 19, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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
skipping to change at page 10, line 9 skipping to change at page 10, line 9
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 set to User header field with the "purpose" header field parameter set to
"isdn-uui", or where no "purpose" header field parameter was "isdn-uui", or where no "purpose" header field parameter was
included. When sending UUI for the ISDN package, the UAS SHOULD set included. When sending UUI for the ISDN package, the UAS SHOULD set
the User-to-User "purpose" header field parameter to "isdn-uui". the User-to-User "purpose" header field parameter to "isdn-uui".
Non-inclusion of the "purpose" header field parameter is permitted, Non-inclusion of the "purpose" header field parameter is permitted,
but this is primarily to allow earlier implementations to support but this is primarily to allow earlier implementations to support
this package. The UAS MUST NOT include more than one User-to-User this package.
header field for this package in any SIP request or response.
When sending UUI for the ISDN package, if the "purpose" header field
is included, the UAS MUST set the User-to-User "purpose" header field
parameter to "isdn-uui". The UAS MUST NOT include more than one
User-to-User header field for this package in any SIP request or
response.
The "isdn-interwork" value for purpose parameter was used in The "isdn-interwork" value for purpose parameter was used in
Internet-Drafts that have led to the publication of the present Internet-Drafts that have led to the publication of the present
document. Although these documents had no other status than "work in document. Although these documents had no other status than "work in
progress", this value is implemented by some vendors. While not progress", this value is implemented by some vendors. While not
defined by this document, implementations could find it useful for defined by this document, implementations could find it useful for
interoperability purposes to support parsing and interpreting "isdn- interoperability purposes to support parsing and interpreting "isdn-
interwork" the same way as "isdn-uui" when receiving messages. 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 UAS 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
"purpose" header field parameter to "isdn-uui", or with no "purpose" "purpose" header field parameter to "isdn-uui", or with no "purpose"
header field parameter, or with some combination of these, the UAC header field parameter, or with some combination of these, the UAS
MUST discard all these header fields. There are no mechanisms for MUST discard all these header fields. There are no mechanisms for
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 "purpose" header field parameter is These requirements apply when the "purpose" header field parameter is
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.
skipping to change at page 14, line 47 skipping to change at page 15, line 7
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-07 version from the
draft-ietf-cuss-sip-uui-isdn-06 version.
In the UAS requirements section, a new requirement has been added
to set the purpose parameter to "uui-isdn" if it is included.
This matches an equivalent requirement for the UAC.
In the UAS requirements section, two instances of UAC have been
corrected to UAS.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-06 version from the draft-ietf-cuss-sip-uui-isdn-06 version from the
draft-ietf-cuss-sip-uui-isdn-05 version. draft-ietf-cuss-sip-uui-isdn-05 version.
A new paragraph of informative material has been added in section A new paragraph of informative material has been added in section
8 relating to older implementations generating "ISDNinterwork" as 8 relating to older implementations generating "ISDNinterwork" as
a purpose value. a purpose value.
A number of editorial changes have been made. A number of editorial changes have been made.
Changes since made in the creation of the Changes since made in the creation of the
skipping to change at page 18, line 39 skipping to change at page 19, line 10
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-11 (work in progress), SIP", draft-ietf-cuss-sip-uui-12 (work in progress),
October 2013. January 2014.
[Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling [Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling
System No. 1 - Network layer; ISDN user-network interface System No. 1 - Network layer; ISDN user-network interface
layer 3 specification for basic call control", layer 3 specification for basic call control",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 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. 12 change blocks. 
14 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/