draft-ietf-cuss-sip-uui-isdn-08.txt   draft-ietf-cuss-sip-uui-isdn-09.txt 
CUSS 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: September 6, 2014 Avaya Expires: January 22, 2015 Avaya
March 5, 2014 July 21, 2014
Interworking ISDN Call Control User Information with SIP Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-08 draft-ietf-cuss-sip-uui-isdn-09
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 RFC
"Problem Statement and Requirements for Transporting User to User 6567. As networks move to SIP, it is important that applications
Call Control Information in SIP" document. As networks move to SIP requiring this data can continue to function in SIP networks as well
it is important that applications requiring this data can continue to as the ability to interwork with this ISDN service for end-to-end
function in SIP networks as well as the ability to interwork with transparency. This document defines a usage (a new package) of the
this ISDN service for end-to-end transparency. This document defines User-to-User header field to enable interworking with this ISDN
a usage (a new package) of the User-to-User header field to enable 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 45
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 September 6, 2014. This Internet-Draft will expire on January 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 33 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . . . . . . 12 11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 12
12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12 12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
16. Changes since previous versions . . . . . . . . . . . . . . . 14 16. Changes since previous versions . . . . . . . . . . . . . . . 15
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
17.1. Normative References . . . . . . . . . . . . . . . . . . . 18 17.1. Normative References . . . . . . . . . . . . . . . . . . . 19
17.2. Informative References . . . . . . . . . . . . . . . . . . 19 17.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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 6, line 27 skipping to change at page 6, line 27
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
or QSIG message) as a MIME body. If the SIP-T method of or QSIG message) as a MIME body. If the SIP-T method of
encapsulation of ISDN instead of interworking is used, this is a encapsulation of ISDN instead of interworking is used, this is a
reasonable mechanism and does not require any extensions to existing reasonable mechanism and does not require any extensions to existing
SIP-T. However, if true ISDN interworking is being done, this SIP-T. However, if true ISDN interworking is being done, and
approach is not reasonable. Instead, the better approach is to therefore SIP-T would not otherwise be used, this approach is not
interwork the ISDN UUI using the native SIP UUI transport mechanism, reasonable, because then implementation of the many elements of ISUP
the User-to-User header field. The rest of this document describes syntax would be required to understand one element of data. Instead,
this approach. the better approach is to interwork the ISDN UUI using the native SIP
UUI transport mechanism, the User-to-User header field. The rest of
this document describes this approach.
5. Transition away from ISDN 5. Transition away from ISDN
This interworking usage of the SIP UUI mechanism will likely begin This interworking usage of the SIP UUI mechanism will likely begin
with one User Agent being an ISDN gateway while the other User Agent with one User Agent being an ISDN gateway while the other User Agent
is a native SIP endpoint. As networks transition away from ISDN, it is a native SIP endpoint. As networks transition away from ISDN, it
is possible that both User Agents could become native SIP endpoints. is possible that both User Agents could become native SIP endpoints.
In this case, there is an opportunity to transition away from this In this case, there is an opportunity to transition away from this
ISDN usage to a more general usage of [I-D.ietf-cuss-sip-uui]. ISDN usage to a more general usage of [I-D.ietf-cuss-sip-uui].
skipping to change at page 7, line 17 skipping to change at page 7, line 19
This document defines the package for the ISDN interworking of UUI This document defines the package for the ISDN interworking of UUI
which is to interoperate with ISDN User to User Signaling (UUS), a which is to interoperate with ISDN User to User Signaling (UUS), a
supplementary service in which the user is able to send/receive a supplementary service in which the user is able to send/receive a
limited amount of information to/from another ISDN user over the limited amount of information to/from another ISDN user over the
signalling channel in association with a call to the other ISDN user. signalling channel in association with a call to the other ISDN 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. As a
Therefore responsibility for respecting the limits has been result there is also only one encoding value specified.
transferred to the end UA. If an interworking point is reached, and Responsibility for respecting the limits has been transferred to the
the limitations are not met, then the UUI data will not be end UA. If an interworking point is reached, and the limitations of
transferred, although the SIP request will otherwise be interworked. the ISDN (see section 3.1) are not met, then the UUI data will not be
As a result there is also only one encoding value specified. transferred, although the SIP request will otherwise be interworked,
rather than have the interworking point attempt to resolve the non-
compliance with the limitations of ISDN.
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
skipping to change at page 8, line 46 skipping to change at page 9, line 5
is included, the UAC MUST set the User-to-User "purpose" header field is included, the UAC MUST set the User-to-User "purpose" header field
parameter to "isdn-uui". The UAC MUST NOT include more than one parameter to "isdn-uui". The UAC MUST NOT include more than one
User-to-User header field for this package in any SIP request or User-to-User header field for this package in any SIP request or
response. 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 "purpose" header field received in the same response with the "purpose" header field
parameter to "isdn-uui", or with no "purpose" header field parameter, parameter to "isdn-uui", or with no "purpose" header field parameter,
or with some combination of these, the UAC MUST discard all these or with some combination of these, the UAC MUST discard all these
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 UUI data 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 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 UUS1 implicit, the inclusion of the "uui" option tag in a
in a Supported header field conveys no additional information over Supported header field conveys no additional information over and
and above the presence, in the INVITE request, of the User-to-User above the presence, in the INVITE request, of the User-to-User header
header field with the "purpose" header field parameter set to "isdn- field with the "purpose" header field parameter set to "isdn-uui".
uui". While there is no harm in including the "uui" option tag, and While there is no harm in including the "uui" option tag, and
strictly it should be included if the extension is supported, it strictly it should be included if the extension is supported, it
performs no function. The presence of the "uui" option tag in the performs no function. The presence of the "uui" option tag in the
Require header field of an INVITE request will cause the request to Require header field of an INVITE request will cause the request to
fail if it reaches a UAS or ISDN interworking gateway that does not fail if it reaches a UAS or ISDN interworking gateway that does not
support this extension; such a usage is not precluded although it support this extension; such a usage is not precluded although it
does not form part of the package. does not form part of the package.
8. UAS requirements 8. UAS requirements
The UAS MUST meet the requirements of [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 10, line 39 skipping to change at page 10, line 45
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 UAS 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 UAS 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 UUI data 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.
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 than "isdn-uui". other value than "isdn-uui".
skipping to change at page 13, line 13 skipping to change at page 13, line 18
registry of the SIP parameter registry: registry of the SIP parameter registry:
Value: isdn-uui Value: isdn-uui
Description: The associated application is being used with Description: The associated application is being used with
constraints suitable for interworking with the ISDN user-to-user constraints suitable for interworking with the ISDN user-to-user
service, and therefore can be interworked at ISDN gateways. service, and therefore can be interworked at ISDN gateways.
Reference: RFCXXXX Reference: RFCXXXX
Contact: Contact: Keith Drage
This document adds the following row to the "UUI content" subregistry This document adds the following row to the "UUI content" subregistry
of the SIP parameter registry: of the SIP parameter registry:
Value: isdn-uui Value: isdn-uui
Description: The associated contents conforms to the content Description: The associated contents conforms to the content
associated with the ISDN user-to-user service. In the presence of associated with the ISDN user-to-user service. In the presence of
the "purpose" header field parameter set to "isdn-uui" (or the the "purpose" header field parameter set to "isdn-uui" (or the
absence of any "purpose" header field parameter) this is the absence of any "purpose" header field parameter) this is the
default meaning and therefore need not be included in this case. default meaning and therefore need not be included in this case.
Reference: RFCXXXX Reference: RFCXXXX
Contact: Contact: Keith Drage
This document defines the following media feature tag which is added This document defines the following media feature tag which is added
to the features.sip-tree of the Media Feature tags registry: to the features.sip-tree of the Media Feature tags registry:
Media feature-tag name: sip.uui-isdn Media feature-tag name: sip.uui-isdn
ASN.1 Identifier: 1.3.6.1.8.4.x ASN.1 Identifier: 1.3.6.1.8.4.x
Summary of the media feature indicated by this tag: This media Summary of the media feature indicated by this tag: This media
feature-tag when used in a Contact header field of a SIP request feature-tag when used in a Contact header field of a SIP request
skipping to change at page 14, line 12 skipping to change at page 14, line 19
Editor's Note: [RFCXXXX] should be replaced with the designation of Editor's Note: [RFCXXXX] should be replaced with the designation of
this document. this document.
14. Security Considerations 14. Security Considerations
This document contains no specific requirements in regard to security This document contains no specific requirements in regard to security
over and above those specified in [I-D.ietf-cuss-sip-uui]. The over and above those specified in [I-D.ietf-cuss-sip-uui]. The
overlying use case will define the security measures required. The overlying use case will define the security measures required. The
underlying user-to-user extension provides a number of tools that can underlying user-to-user extension provides a number of tools that can
meet certain security requirements. As a level of guidance, data meet certain security requirements.
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 Information that might otherwise reveal private information about an
than a media feature tag. Information that might otherwise reveal individual, or where a level of authenticity needs to be guaranteed,
private information about an individual, or where a level of may need a higher level of protection, and may indeed not be suitable
authenticity needs to be guaranteed, may need a higher level of for this package, particularly taking into account the statement in
protection, and may indeed not be suitable for this package, the following paragraph.
particularly taking into account the statement in the following
paragraph.
As this capability is defined to interwork with the ISDN, if the ISDN As this capability is defined to interwork with the ISDN, if the ISDN
forms part of the route, any usage needs to assume that the security forms part of the route, any usage needs to assume that the security
level of the ISDN is the highest level of security available. As the level of the ISDN is the highest level of security available. As the
ISDN security is itself not definable on an end-to-end basis, this ISDN security is itself not definable on an end-to-end basis, this
can be an unknown quantity. This is because ISDN security exists on can be an unknown quantity. This is because ISDN security exists on
a hop-by-hop basis, and is only as secure as the least secure a hop-by-hop basis, and is only as secure as the least secure
component. This can be high in some places (e.g. it can require component. This can be high in some places (e.g. it can require
physical access to a secure building) and in other places it can be physical access to a secure building) and in other places it can be
low (e.g. the point where an ISDN access enters a building). If this low (e.g. the point where an ISDN access enters a building). If this
skipping to change at page 14, line 46 skipping to change at page 15, line 5
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, Mahalingam Mani and Celine Serrut-Valette for their Jennings, Mahalingam Mani and Celine Serrut-Valette for their
comments. comments.
The death of Francois Audet occurred before this document was
finalised, and the authors would like to identify the significant
contribution of Francois to this and a number of important RFCs, and
to express their condolences to his family. It was always a pleasure
to work with Francois.
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-09 version from the
draft-ietf-cuss-sip-uui-isdn-08 version.
Additional text in section 4 added justifying why SIP(T) would not
directly be a solution to this problem.
Clarification added in section 5 to clarify that the limititations
are the ISDN limitations.
Terminology "data packet" changed to "UUI data" to align with
[I-D.ietf-cuss-sip-uui]
Contact added in IANA considerations.
Text relating to comparision with feature tag removed from
security considerations as the text was not understandable and the
authors could not identify what it was originally intended to
mean.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-08 version from the draft-ietf-cuss-sip-uui-isdn-08 version from the
draft-ietf-cuss-sip-uui-isdn-07 version. draft-ietf-cuss-sip-uui-isdn-07 version.
In section 7, one instance of UAS corrected to UAC. In section 7, one instance of UAS corrected to UAC.
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-07 version from the
draft-ietf-cuss-sip-uui-isdn-06 version. draft-ietf-cuss-sip-uui-isdn-06 version.
In the UAS requirements section, a new requirement has been added In the UAS requirements section, a new requirement has been added
skipping to change at page 19, line 13 skipping to change at page 19, line 43
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-13 (work in progress), SIP", draft-ietf-cuss-sip-uui-17 (work in progress),
March 2014. June 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. 19 change blocks. 
49 lines changed or deleted 78 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/