Network Working Group K. Drage, Ed.
Internet-Draft Alcatel-Lucent
Intended status: Standards Track A. Johnston
Expires: April 6, 2012 Avaya
October 4, 2011
Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-00
Abstract
The motivation and use cases for interworking and transporting ITU-T
DSS1 User-user information element data in SIP are described in the
"Problem Statement and Requirements for Transporting User to User
Call Control Information in SIP" document. As networks move to SIP
it is important that applications requiring this data can continue to
function in SIP networks as well as the ability to interwork with
this ISDN service for end-to- end transparency. This document
defines a usage of the User-to-User header field to enable
interworking with this ISDN service.
This document is covers the interworking with both public ISDN and
private ISDN capabilities, so the interworking with QSIG will also be
addressed.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 6, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Drage & Johnston Expires April 6, 2012 [Page 1]
Internet-Draft SIP UUI for ISDN October 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Summary of the ISDN User-to-User Service . . . . . . . . . . . 3
3.1. The service . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Impacts of the ISDN service on SIP operation . . . . . . . 5
4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6
5. Transition away from ISDN . . . . . . . . . . . . . . . . . . 6
6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 6
7. UAC requirements . . . . . . . . . . . . . . . . . . . . . . . 7
8. UAS requirements . . . . . . . . . . . . . . . . . . . . . . . 9
9. UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Considerations for ISDN interworking gateways . . . . . . . . 10
11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 11
12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 11
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
14. Security Considerations . . . . . . . . . . . . . . . . . . . 12
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
16. Changes since previous versions . . . . . . . . . . . . . . . 13
17. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Drage & Johnston Expires April 6, 2012 [Page 2]
Internet-Draft SIP UUI for ISDN October 2011
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
2. Overview
This document describes a usage of the User-to-User header field
defined in [ietf-cuss-sip-uui] to enable the transport of User to
User Information (UUI) in ISDN interworking scenarios using SIP
[RFC3261]. Specifically, this document discuss the interworking of
call control related ITU-T DSS1 User-user information element [Q931],
[Q957.1] and ITU-T Q.763 User-to-user information parameter [Q763]
data in SIP. UUI is widely used in the PSTN today in contact centers
and call centers which are transitioning away from ISDN to SIP.
This usage is not limited to scenarios where interworking will occur.
Rather it describes a usage where interworking is possible if
interworking is met. That does not preclude its usage directly
between two SIP terminals.
3. Summary of the ISDN User-to-User Service
3.1. The service
ISDN defines a number of related services. Firstly there is a user
signalling bearer service, which uses the information elements /
parameters in the signalling channel to carry the data, and does not
establish a related circuit-switched connection. For DSS1, this is
specified in ITU-T Recommendation Q.931 section 3.3 and section 7
[Q931]. It also defines a user-to-user signalling supplementary
service, which uses the information elements / parameters in the
signalling channel to carry additional data, but which is used in
conjunction with the establishment of a related circuit-switched
connection. This reuses the same information elements / parameters
as the user signalling bearer service, with the addition of other
signalling information, and for DSS1 this is specified in ITU-T
Recommendation Q.957.1 [Q957.1].
ISDN defines three variants of the user-to-user signalling
supplementary service as follows:
Drage & Johnston Expires April 6, 2012 [Page 3]
Internet-Draft SIP UUI for ISDN October 2011
UUS1: User-to-user information exchanged during the setup and
clearing phases of a call, by transporting User-to-user
information element within call control messages. This in itself
has two subvariants, UUS1 implicit and UUS1 explicit. UUS1
explicit uses additional supplementary service control information
to control the request and granting of the service, as in USS2 and
UUS3. In UUS1 implicit, it is the presence of the user signalling
data itself that constitutes the request for the service. UUS1
explicit as a result also allows the requester to additionally
specify whether the parallel circuit-switched connection should
proceed if the UUS1 service cannot be provided (preferred or
required).
UUS2: User-to-user information exchanged from the sender's point of
view during call establishment, between the DSS1 ALERTING and DSS1
CONNECT messages, within DSS1 USER INFORMATION messages; and
UUS3: User-to-user information exchanged while a call is in the
Active state, within DSS1 USER INFORMATION messages.
The service is always requested by the calling user.
This document defines only the provision of the ISDN UUS1 implicit
supplementary service to interworking scenarios, this being the most
widely deployed and used of the various ISDN user-to-user services,
and indeed the one that matches the requirements specified in
draft-ietf-cuss-sip-uui-reqs.
The ISDN UUS1 service has the following additional characteristics as
to the data that can be transported:
The maximum number of octets of user information that can be
transported in 128 octets plus a protocol discriminator. It is
noted that some early ISDN implementations had a limitation of 32
octets, but it is understood that these are not currently
deployed. While this package does not prohibit longer data
fields, the mechanism at any interworking point is to discard data
elements that are too long to handle. The handled length can
normally be assumed to be 128 octets.
The content of the user information octets is described by a
single octet protocol discriminator (see table 4-26 of ITU-T
Recommendation Q.931) [Q931]. That protocol descriminator may
describe the protocol used within the user data, the structure of
the user data, or leave it entirely open. Note that not all
values within the protocol discriminator necessarily make sense
for use in the user to user service, as the content is aligned
with the protocol discriminator that appears at the start of all
Drage & Johnston Expires April 6, 2012 [Page 4]
Internet-Draft SIP UUI for ISDN October 2011
DSS1 messages (see table 4-1 of ITU-T Recommendation Q.931)
[Q931]. The protocol discriminator value has no impact on the
interworking capability.
Only a single user information package can be transported in each
message.
The ISDN service works without encryption or integrity protection.
The user trusts the intermediate network elements, and therefore
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,
message contents are protected at layer 2 by standard CRC
mechanisms - this allows loss on a link level basis to be
detected, but does not guard against fraudulent attacks on the
link itself. This does not prevent the use of additional
encryption or integrity protection within the payload itself,
although the limit on the size of the payload (128 octets) will
restrict this.
3.2. Impacts of the ISDN service on SIP operation
The ISDN service has the following impacts that need to be understood
within the SIP environment.
Call transfer ISDN call transfer cancels all user-to-user
supplementary services. In the ISDN, if user-to-user data is
required after call transfer, then UUS3 has to be renegotiated,
which is not provided by this SIP extension. The impact of this
restriction on the SIP environment is that UUI header fields
cannot be exchanged in transactions clearing down the SIP dialog
after call transfer has occurred.
Conference ISDN conferencing allows the user to still exchange user-
to-user data after the conference is created. As far as UUS1 is
concerned, this means that when an individual party clears, those
clearing messages can still contain user-to-user data. As a
conferee this is sent to the conference controller. As the
conference controller, as this effectively clears the conference,
it can be broadcast to all conferees, or sent to individual
conferees [OPEN ISSUE - CHECK THIS IN THE PROTOCOL - DOES IT
REQUIRE EXPLICIT].
The ISDN three-party supplementary service is similar in many ways
to conferencing, but is signalled using a different mechanism.
This means that on clearing, the controller using UUS1 implicit
does have the choice of sending data to either or both remote
users.
Drage & Johnston Expires April 6, 2012 [Page 5]
Internet-Draft SIP UUI for ISDN October 2011
Diversion When ISDN diversion occurs, any UUS1 user-to-user data is
sent to the forwarded-to-user (assuming that the call meets
requirements for providing the service - this is impacted by the
explicit service only). If the type of diversion is such that the
call is also delivered to the forwarding user, they will also
receive any UUS1 user-to-user data.
Contributors note: The above list needs to be studied further in
regard to private ISDN service definitions, e.g. for the interworking
of SIP and QSIG.
4. Relation to SIP-T
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
or QSIG message) as a MIME body. If the SIP-T method of
encapsulation of ISDN instead of interworking is used, this is a
reasonable mechanism and does not require any extensions to existing
SIP-T. However, if true ISDN interworking is being done, this
approach is not reasonable. Instead, 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
This interworking usage of the SIP UUI mechanism will likely begin
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 possible that both User Agents could become native SIP endpoints.
In this case, there is an opportunity to transition away from this
ISDN usage to a more general usage of [ietf-cuss-sip-uui].
The SIP UUI mechanism provides a way to achieve this transition. As
an endpoint moves from being an ISDN gateway to a native SIP
endpoint, and a package for some form of enhanced UUI has been
standardized, the endpoint can carry the UUI data both as ISDN and as
some other package in parallel. This will permit the other endpoint
to use the UUI according to the ISDN package if it is an ISDN gateway
or the enhanced package if it is a native SIP endpoint.
6. ISDN Usage of the User-to-User Header Field
This document defines the package for the ISDN interworking of UUI
which is to interoperate with ISDN User to User Signaling (UUS), a
Drage & Johnston Expires April 6, 2012 [Page 6]
Internet-Draft SIP UUI for ISDN October 2011
supplementary service in which the user is able to send/receive a
limited amount of information to/from another ISDN user over the
signalling channel in association with a call to the other ISDN
user..
Two examples of ISDN UUI with redirection (transfer and diversion)
are defined in [ANSII] and [ETSI].
The general principals of this package of the UUI mechanism are as
follows:
That the sending application is expected limit their sending
requirements to the subset provided by the ISDN UUI service.
That the SIP UA will not allow the reception of more that one
User-to-User header field of the "isdn-uui" package in the same
SIP request or response, and will only allow it in a request or
response of the appropriate method (INVITE or BYE). What happens
to User-to-User header fields relating to different packages is
outside the scope of this document.
That an interworking point trying to interwork UUI data that is
too long will discard the UUI data, but proceed with the
interworking. There is no notification of such discard back to
the sending user. If the SIP user knows that it is interworking
with the ISDN, then the UUI application at the SIP endpoint should
limit its communication to 128 octet packets plus the protocol
discriminator, in the knowledge that discard will occur if it does
not. The UUI application at the SIP endpoint has complete control
over what occurs. It should be noted that this was exactly the
envisaged operation when early ISDN implementations that only
supported 32 octets interworked with those supporting 128 octets.
It also corresponds to the interworking with ISDNs that do not
support the supplementary service at all, as discard will occur in
these circumstances as well. Note that failure to include the
user-user data into the ISDN SETUP message (when discard occurs)
will result in the service being unavailable for the remainder of
the call when UUS1 implicit operation is used.
7. UAC requirements
The UAC MUST meet the requirements of [ietf-cuss-sip-uui] in addition
to the requirements defined in this document.
The UAC MUST only use this package of the UUI mechanism extension in
association with the initial INVITE method and the BYE method
relating to an INVITE dialog. Usage on transactions associated with
Drage & Johnston Expires April 6, 2012 [Page 7]
Internet-Draft SIP UUI for ISDN October 2011
any other type of dialog, or on methods not associated with a dialog
is precluded.
If the UAC wishes to user or permit the sending of UUI data at any
point in the dialog, the UAC MUST include in the INVITE request for
that dialog a User-to-User header field with an "package" header
field parameter set to "isdn-uui". This initial header field
constitutes the implicit request to use the UUI service, and is
therefore included even when there is no data except the protocol
discriminator octet to send at that point in time.
The UAC MUST NOT include the User-to-User header field with an
"package" header field parameter set to "isdn-uui" in any message of
an INVITE dialog if the original INVITE request did not include the
User-to-User header field with an "package" header field parameter
set to "isdn-uui"
When sending UUI for the ISDN package, the UAC MUST set the User-to-
User "package" header field 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 response.
When receiving UUI, when multiple User-to-User header fields are
received in the same response with the "package" header field
parameter to "isdn-uui", the UAS MUST discard all these header
fields. There are no mechanisms for determining which was the
intended data packet so all are discarded.
The application designer will need to take into account the ISDN
service restrictions; failure to do so can result in information
being discarded at any interworking point with the ISDN. This
document makes no further normative requirements based on those
constraints, because those constraints may vary from one ISDN to
another. It is reasonable to expect that a limitation of 128 octets
(plus a protocol discriminator) can be imposed by the ISDN, and
therefore payloads longer than this will never reach the destination
if such interworking occurs.
[ietf-cuss-sip-uui] defines a "uui" option tag for use with the UUI
mechanism extension. Because for the ISDN UUI service, the service
is service 1 implicit, the inclusion of the "uui" option tag in a
Supported header field conveys no additional information over and
above the presence of the User-to-User header field with the
"package" header field parameter to "isdn-uui" in the INVITE request.
While there is no harm in including the "uui" option tag, and
strictly it should be included if the extension is supported, it
performs no function. The presence of the "uui" option tag in the
Require header field of an INVITE request will cause the request to
Drage & Johnston Expires April 6, 2012 [Page 8]
Internet-Draft SIP UUI for ISDN October 2011
fail if it reaches a UAS or ISDN interworking gateway that does not
support this extension; such a usage is not precluded although it
does not form part of the package.
8. UAS requirements
The UAS MUST meet the requirements of [ietf-cuss-sip-uui] in addition
to the requirements defined in this document.
The UAS MUST only use this package of the UUI mechanism extension in
association with the initial INVITE method and the BYE method
relating to an INVITE dialog. Usage on transactions associated with
any other type of dialog, or on methods not associated with a dialog
is precluded.
The UAS MUST NOT include the User-to-User header field with an
"package" header field parameter set to "isdn-uui" in any message of
an INVITE dialog if the original INVITE request did not include the
User-to-User header field with an "package" header field parameter
set to "isdn-uui"
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
dialog, only where the original INVITE request included a User-to-
User header field with the "package" header field parameter to "isdn-
uui". When sending UUI for the ISDN package, the UAS MUST set the
User-to-User "package" 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.
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
a 3xx response to an incoming request.
When receiving UUI, when a User-to-User header field is received in a
request that is not from the originating user with the "package"
header field parameter to "isdn-uui", the UAC MUST discard this
header fields.
When receiving UUI, when multiple User-to-User header fields are
received from the originating user in the same request with the
"package" header field parameter to "isdn-uui", the UAC MUST discard
all these header fields. There are no mechanisms for determining
which was the intended data packet so all are discarded.
Drage & Johnston Expires April 6, 2012 [Page 9]
Internet-Draft SIP UUI for ISDN October 2011
9. UUI contents
These requirements apply when the "package" header field parameter is
set to "isdn-uui". Processing for User-to-User header fields sent or
received with values other than this value are outside the scope of
this document, and the appropriate package document for that value
applies.
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
SIP entity MUST ignore a received User-to-User header field if the
"content" header field parameter is present and the value is some
other value that "isdn-uui".
When sending UUI, the sending SIP entity MAY, but need not, include
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
"encoding" header field parameter is present and the value is some
other value that "hex".
When sending UUI, the sending application MUST include a protocol
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
to the receiving application what it does with this value. This
document places no other normative requirement on the use of the
protocol discriminator; it is required at interworking gateways to
allow mapping into the appropriate fields in the ISDN protocols, but
otherwise the usage is entirely up to the application, and outside
the scope of this document. Valid values are identified and
documented by ITU-T, and there is no IANA registry for these values.
10. Considerations for ISDN interworking gateways
ISDN interworking gateways MUST support the requirements defined for
UAS and UAC operation.
ISDN interworking gateways MUST support only the "isdn-uui" package
on dialogs that are interworked.
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
content is octet structured binary, irrespective of the value of the
received protocol discriminator. There are no requirements in the
ISDN to ensure that the content matches the value of the protocol
discriminator, and it is for the application usage to sort out any
discrepancy. The same applies to the ISDN protocol discrimination
defined table 4-26 of ITU-T Recommendation Q.931 [Q931] as the first
Drage & Johnston Expires April 6, 2012 [Page 10]
Internet-Draft SIP UUI for ISDN October 2011
octet of the payload information; the interworking gateway will not
perform any additional checking of this value.
[ietf-cuss-sip-uui] defines a "uui" option tag for use with the UUI
mechanism extension. The option tag is not interworked at an ISDN
interworking gateway. The ISDN interworking gateways MUST NOT take
the omission of the "uui" option tag in a received INVITE request to
indicate that interworking of a received header field is not to be
performed.
11. Coding requirements
This document defines "isdn-uui" as a new value of the User-to-User
"package" header field parameter.
This document defines "isdn-uui" as a new value of the User-to-User
"content" header field parameter.
12. Media Feature Tag
This document defines a new media feature tag "sip.uui-isdn". This
feature tag indicates that this UUI package is supported by the
sender, and its usage is entirely in accordance with RFC 3840
[RFC3840]. This document makes no additional provisions for the use
of this feature tag.
13. IANA Considerations
This document adds the following row to the "UUI package values"
section of the SIP parameter registry:
Value: isdn-uui
Meaning: The associated application is being used with constraints
suitable for interworking with the ISDN user-to-user service, and
therefore can be interworked at ISDN gateways.
Reference: RFCXXXX
Contact:
This document adds the following row to the "UUI content values"
section of the SIP parameter registry:
Drage & Johnston Expires April 6, 2012 [Page 11]
Internet-Draft SIP UUI for ISDN October 2011
Value: isdn-uui
Meaning: The associated contents conforms to the content
associated with the ISDN user-to-user service. In the presence of
the "package" header field parameter set to "isdn-uui" this is the
default meaning and therefore need not be included in this case.
Reference: RFCXXXX
Contact:
This document defines the following media feature tag which is added
to the features.sip-tree of the Media Feature tags registry:
Media feature-tag name: sip.uui-isdn
ASN.1 Identifier: 1.3.6.1.8.4.x
Summary of the media feature indicated by this tag: This media
feature-tag when used in a Contact header field of a SIP request
or a SIP response indicates that the entity sending the SIP
message supports the UUI package "uui-isdn".
Values appropriate for use with this feature-tag: none
Examples of typical use: Indicating that a mobile phone supports
SRVCC for calls in alerting phase.
Related standards or documents: RFCXXXX
Security Considerations: Security considerations for this media
feature-tag are discussed in section 11.1 of RFC 3840 [RFC3840]
Editor's Note: [RFCXXXX] should be replaced with the designation of
this document.
14. Security Considerations
This document contains no specific requirements in regard to
security. The overlying use case will define the security measures
required. The underlying user-to-user extension provides a number of
tools that can meet certain security requirements. As a level of
guidance, data 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 than a media feature tag. Information that might
otherwise reveal private information about an individual, or where a
level of authenticity needs to be guaranteed, may need a higher level
Drage & Johnston Expires April 6, 2012 [Page 12]
Internet-Draft SIP UUI for ISDN October 2011
of protection, and may indeed not be suitable for this package,
particularly taking into account the statement in the following
paragraph.
As this capability to is defined to interwork with the ISDN, if the
ISDN 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 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 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 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 level of security is not sufficient, then either a different
user-to-user package, or indeed, a different method of data transfer,
needs to be selected by the application user.
15. Acknowledgements
Joanne McMillen was a major contributor and co-author of earlier
versions of this document.
Thanks to Spencer Dawkins, Vijay Gurbani, and Laura Liess for their
review of earlier versions of this document. The authors wish to
thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen
Jennings, and Mahalingam Mani for their comments.
16. Changes since previous versions
Note to RFC editor: This section is to be deleted before final
publication.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-00 version from the
draft-drage-cuss-sip-uui-isdn-01 version.
Removed overburdening of the word "application". Changed the name
of the "app" header field parameter in the mechanism draft to
"package" header field parameter. This had a consequential impact
on the ISDN document. The word "application" is now solely
reserved for the name of the functionality that passes the UUI to
the SIP functionality to send, and to which the UUI is delivered
on receipt by the SIP functionality. As well as the change of the
name of the header field parameter, this resulted in a number of
instances of the word "application" becoming "package". A couple
of instances relating to the coding of the "content" header field
Drage & Johnston Expires April 6, 2012 [Page 13]
Internet-Draft SIP UUI for ISDN October 2011
parameter have become "SIP entity".
Section 5 needed substantial rewording as it no longer applied in
this manner. Modified the text to indicate that if one wants to
use an enhanced UUI where both endpoints are SIP, but still work
with the ISDN, then one will have to same information using two
different packages, one the ISDN one, and the other some enhanced
package.
In section 8, a couple of requirements relating to the "content"
header field parameter really related to the "package" header
field parameter (formerly "app" header field parameter). These
are corrected.
Updated references from "draft-johnston-cuss-sip-uui" to
"draft-ietf-cuss-sip-uui".
Made clear throughout the document that the UUI payload is a
protocol discriminator plus 128 octets of data.
Made clearer that it is the initial INVITE request and responses
and the BYE request and responses only that carry the information
in this package.
Made clear that there are no normative requirements on the
protocol discriminator. In particular text is added to the end of
section 9.
Removed the following text from section 7, as it is a duplicate of
the text in section 9:
" When sending UUI, the sending application MUST include a
protocol discriminator octet, conforming to table 4-26 of ITU-T
Recommendation Q.931 [Q931] as the first octet of the payload
information."
Defined a media feature tag specific for the package. It has been
proposed to do this for all packages. "sip.uui-isdn" has been
added.
Corrected the short title for the draft.
Changes since made in the creation of the
draft-drage-cuss-sip-uui-isdn-01 version from the
draft-drage-cuss-sip-uui-isdn-00 version.
Closure of a number of open issues identified in the -00 version
and the creation of appropriate procedures for the UAC, the UAS,
Drage & Johnston Expires April 6, 2012 [Page 14]
Internet-Draft SIP UUI for ISDN October 2011
and the ISDN interworking gateway.
17. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling
System No. 1 - Network layer; ISDN user-network interface
layer 3 specification for basic call control",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
[Q957.1] "ITU-T Recommendation Q.957.1: Digital subscriber
Signalling System No. 1 - Stage 3 description for
supplementary services using DSS 1; Stage 3 description
for additional information transfer supplementary services
using DSS 1: User-to-User Signalling (UUS)",
http://www.itu.int/rec/T-REC-Q.957.1-199607-I .
[Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part
formats and codes",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
[ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services
Digital Network (ISDN)-Explicit Call Transfer
Supplementary Service".
[ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
Digital Network (ISDN); Diversion supplementary
services".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[ietf-cuss-sip-uui-reqs]
Johnston, A., McMillen, J., and L. Liess, "Problem
Statement and Requirements for Transporting User to User
Drage & Johnston Expires April 6, 2012 [Page 15]
Internet-Draft SIP UUI for ISDN October 2011
Call Control Information in SIP",
draft-ietf-cuss-sip-uui-reqs-00 .
[ietf-cuss-sip-uui]
Johnston, A. and J. Rafferty, "A Mechanism for
Transporting User to User Call Control Information in
SIP", draft-ietf-cuss-sip-uui-00 .
Authors' Addresses
Keith Drage (editor)
Alcatel-Lucent
Quadrant, Stonehill Green, Westlea
Swindon
UK
Email: keith.drage@alcatel-lucent.com
Alan Johnston
Avaya
St. Louis, MO 63124
United States
Email: alan.b.johnston@gmail.com
Drage & Johnston Expires April 6, 2012 [Page 16]
