One document matched: draft-ietf-cuss-sip-uui-isdn-10.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3261 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC6567 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6567.xml">
<!ENTITY RFC3372 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3372.xml">
<!ENTITY RFC3840 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3840.xml">
<!ENTITY cuss-sip-uui SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-cuss-sip-uui.xml">
<!ENTITY RFC3398 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3398.xml">
]>
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="no" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-cuss-sip-uui-isdn-10"
ipr="trust200902">
<front>
<title abbrev="ISDN Call Control UUI">
Interworking ISDN Call Control User Information with SIP
</title>
<author initials="K. E." surname="Drage" fullname="Keith Drage" role="editor">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Quadrant, Stonehill Green, Westlea</street>
<city>Swindon</city>
<country>UK</country>
</postal>
<email> keith.drage@alcatel-lucent.com</email>
</address>
</author>
<author initials="A.B." surname="Johnston" fullname="Alan Johnston">
<organization>Avaya</organization>
<address>
<postal>
<street></street>
<city>St. Loius</city>
<region>MO</region>
<country>US</country>
</postal>
<email>alan.b.johnston@gmail.com</email>
</address>
</author>
<date year="2014"/>
<area>RAI</area>
<workgroup>CUSS</workgroup>
<abstract>
<t>The motivation and use cases for interworking and transporting ITU-T
DSS1 User to User information element data in SIP are described in RFC
6567. 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 (a new package) of the
User-to-User header field to enable interworking with this ISDN
service.</t>
<t>This document covers the interworking with both public ISDN and
private ISDN capabilities, so the potential interworking with QSIG
will also be addressed.</t>
<t>The package is identified by a new value "isdn-uui" of the "purpose"
header field parameter.</t>
</abstract>
</front>
<middle>
<section title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
</section> <!-- Terminology -->
<section title="Overview">
<t>This document describes a usage of the User-to-User header field
defined in <xref target="I-D.ietf-cuss-sip-uui"/> to enable the
transport of User to User Information (UUI) in ISDN interworking scenarios
using SIP <xref target="RFC3261"/>. Specifically, this document discusses
the interworking of call control related ITU-T DSS1 User to User information
element Q931 <xref target="Q931"/>, Q957.1 <xref target="Q957.1"/>
and ITU-T Q.763 User to User information parameter <xref target="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.</t>
<t>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.</t>
</section> <!-- Overview -->
<section title="Summary of the ISDN User to User Service" anchor="sec:sum">
<section title="The service">
<t>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
<xref target="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 <xref target="Q957.1"/>.</t>
<t>ISDN defines three variants of the User to User signalling
supplementary service as follows:</t>
<t><list style="hanging">
<t hangText="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.
In UUS1 implicit, it is the presence of the user signalling
data itself that constitutes the request for the service. UUS1
explicit uses additional supplementary service control information
to control the request and granting of the service, as in UUS2 and
UUS3. 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);</t>
<t hangText="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</t>
<t hangText="UUS3:">User to User information exchanged while a call
is in the Active state, within DSS1 USER INFORMATION messages.</t>
</list></t>
<t>The service is always requested by the calling user.</t>
<t>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
<xref target="RFC6567">RFC6567</xref>.</t>
<t>The above come from the ISDN specifications defined for public
networks. There are a parallel set of ISDN specifications defined
for private networks (QSIG}. These specifications do not define a
UUS1 implicit supplementary service. However, implementation of such
a UUS1 implicit supplementary service for private networks can
readily be constructed in a proprietary fashion based on the
specifications for public networks, and evidence suggests that some
vendors have done so. On this basis, there is no reason why this
package cannot also be used to support interworking with such a
private network service, on the assumption that the constraints are
exactly the same as those for the public network.</t>
<t>The ISDN UUS1 service has the following additional characteristics as
to the data that can be transported:</t>
<t><list style="empty">
<t>The maximum number of octets of user information that can be
transported is 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.</t>
<t>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) <xref target="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
DSS1 messages (see table 4-1 of ITU-T Recommendation Q.931)
<xref target="Q931"/>. The protocol discriminator value has no
impact on the interworking capability.</t>
<t>Only a single user information can be transported in each message.</t>
<t>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 UUI data itself,
although the limit on the size of the UUI data (protocol
discriminator plus 128 octets) will restrict this.</t>
</list></t>
</section> <!-- The service -->
<section title="Impacts of the ISDN service on SIP operation">
<t>The ISDN service has the following impacts that need to be understood
within the SIP environment.</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="Conference:">ISDN conferencing allows the user to still
exchange User to User data after the conference is created. As far as
UUS1 is concerned, it is not permitted. 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. Because SIP conferencing cannot completely emulate the
ISDN three-party supplementary service at the served user, UUS1
implicit is not possible.</t>
<t hangText="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.</t>
</list></t>
</section> <!-- Impacts of the ... -->
</section> <!-- sec:sum -->
<section title="Relation to SIP-T">
<t>A method of transport of ISDN UUI is to use
<xref target="RFC3372">SIP-T</xref> 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, and
therefore SIP-T would not otherwise be used, this approach is not
reasonable, because then implementation of the many elements of ISUP
syntax would be required to understand one element of data. 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.</t>
</section> <!-- Relation to SIP-T -->
<section title="Transition away from ISDN">
<t>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
<xref target="I-D.ietf-cuss-sip-uui"/>.</t>
<t>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, and in the same messages or in
different messages depending on the needs of the application. 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.</t>
</section> <!-- Transition away from ISDN -->
<section title="ISDN Usage of the User-to-User Header Field">
<t>This document defines the package for the ISDN interworking of UUI
which is to interoperate with ISDN User to User Signaling (UUS), a
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.</t>
<t>Two examples of ISDN UUI with redirection (transfer and diversion)
are defined in <xref target="ANSII"/> and <xref target="ETSI"/>.</t>
<t>One objective of the design of this package has been to keep the
functionality at the interworking point as simple as possible. As a
result there is also only one encoding value specified.
Responsibility for respecting the limits has been transferred to the
end UA. If an interworking point is reached, and the limitations of
the ISDN (see section 3.1) are not met, then the UUI data will not be
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.</t>
<t>The general principals of this package of the UUI mechanism are
therefore as follows:</t>
<t><list style="empty">
<t>That the sending application is expected to limit their sending
requirements to the subset provided by the ISDN UUI service.</t>
<t>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
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 other
packages is outside the scope of this document.</t>
<t>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 to 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.</t>
</list></t>
</section> <!-- ISDN usage of ... -->
<section title="UAC requirements">
<t>The UAC MUST meet the requirements of
<xref target="I-D.ietf-cuss-sip-uui"/> in addition to the requirements
defined in this document.</t>
<t>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
any other type of dialog, or on methods not associated with a dialog
is precluded. Usage on other methods within the INVITE dialog, and
on re-INVITE transactions with the INVITE dialog, is also precluded.</t>
<t>If the UAC wishes to use or permit the sending of UUI data at any
point in the dialog, the UAC MUST include in the INVITE request for
that dialog a User-to-User header field. The UAC SHOULD set the
"purpose" header field parameter to "isdn-uui". Non-inclusion of the
"purpose" header field parameter is permitted, but this is primarily
to allow earlier implementations to support this package. 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.</t>
<t>The UAC 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", in any message of an INVITE dialog
if the original INVITE request did not include the User-to-User
header field, either with a "purpose" header field parameter set to
"isdn-uui", or with no "purpose" header field parameter included.</t>
<t>When sending UUI for the ISDN package, if the "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
User-to-User header field for this package in any SIP request or
response.</t>
<t>When receiving UUI, when multiple User-to-User header fields are
received in the same response with the "purpose" header field
parameter to "isdn-uui", or with no "purpose" header field parameter,
or with some combination of these, the UAC MUST discard all these
header fields. There are no mechanisms for determining which was the
intended UUI data so all are discarded.</t>
<t>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 UUI data longer than this will never reach the destination
if such interworking occurs. Note that the 128 octet limit (plus a
protocol discriminator) applies before the encoding (or after the
decoding) using the "hex" encoding. The "hex" encoding is defined in
<xref target="I-D.ietf-cuss-sip-uui"/>.</t>
<t><xref target="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 service is UUS1 implicit, the inclusion of the "uui" option
tag in a Supported header field conveys no additional information over and
above the presence, in the INVITE request, of the User-to-User header
field with the "purpose" header field parameter set to "isdn-uui".
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
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.</t>
</section> <!-- UAC requirements -->
<section title="UAS requirements">
<t>The UAS MUST meet the requirements of
<xref target="I-D.ietf-cuss-sip-uui"/> in
addition to the requirements defined in this document.</t>
<t>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. Usage on other methods within the INVITE dialog, and
on re-INVITE transactions with the INVITE dialog, is also precluded.</t>
<t>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", in any message of an INVITE dialog
if the original INVITE request did not include the User-to-User
header field, either with a "purpose" header field parameter set to
"isdn-uui", or with no "purpose" header field parameter included.</t>
<t>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 "purpose" header field parameter set to
"isdn-uui", or where no "purpose" header field parameter was
included. When sending UUI for the ISDN package, the UAS SHOULD set
the User-to-User "purpose" header field parameter to "isdn-uui".
Non-inclusion of the "purpose" header field parameter is permitted,
but this is primarily to allow earlier implementations to support
this package.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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"
header field parameter to "isdn-uui", or with no "purpose" header
field parameter, the UAS MUST discard this header field.</t>
<t>When receiving UUI, when multiple User-to-User header fields are
received from the originating user in the same request with the
"purpose" header field parameter to "isdn-uui", or with no "purpose"
header field parameter, or with some combination of these, the UAS
MUST discard all these header fields. There are no mechanisms for
determining which was the intended UUI data so all are discarded.</t>
</section> <!-- UAS requirements -->
<section title="UUI contents">
<t>These requirements apply when the "purpose" header field parameter is
set to "isdn-uui", or with no "purpose" header field parameter.</t>
<t>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.</t>
<t>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
"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 than "isdn-uui".</t>
<t>The default and only encoding defined for this package is "hex".
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".</t>
<t>When sending UUI, the sending application MUST include a protocol
discriminator octet, conforming to table 4-26 of ITU-T Recommendation
<xref target="Q931">Q.931</xref> as the first octet of the UUI data.
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.</t>
</section> <!-- UUI contents -->
<section title="Considerations for ISDN internetworking gateways">
<t>ISDN interworking gateways MUST support the requirements defined for
UAS and UAC operation.</t>
<t>ISDN interworking gateways MUST support only the "isdn-uui" package
on dialogs that are interworked.</t>
<t>ISDN interworking gateways will take octet structured data from the
ISDN side and encode it using the "hex" encoding scheme defined in
<xref target="I-D.ietf-cuss-sip-uui"/> for inclusion as the uui-data
in the User-to-User header field. In the reverse direction, it will take
valid uui-data according to the "hex" encoding scheme, and decode it to octet
structured data for sending to the ISDN side.</t>
<t>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 <xref target="Q931">Q.931</xref>
as the first octet of the UUI data; the interworking gateway will not
perform any additional checking of this value.</t>
<t><xref target="I-D.ietf-cuss-sip-uui"/> defines a "uui" option tag
for use with the
UUI mechanism extension. The option tag is not interworked at an
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.</t>
</section> <!-- Considerations for ISDN inter ... -->
<section title="Coding requirements">
<t>This document defines "isdn-uui" as a new value of the User-to-User
"purpose" header field parameter. The following ABNF adds to the
production in <xref target="I-D.ietf-cuss-sip-uui"/>:</t>
<figure><artwork><![CDATA[
pkg-param-value =/ "isdn-uui"
]]></artwork></figure>
<t>This document defines "isdn-uui" as a new value of the User-to-User
"content" header field parameter. A content value of "isdn-uui"
indicates that the contents have a first octet that is a protocol
discriminator (see table 4-26 of ITU-T Recommendation Q.931 <xref
target="Q931"/>) followed by uui-data that can be subject to a length
limitation (before encoding or after decoding) that is generally 128 octets.
The following ABNF adds to the production in
<xref target="I-D.ietf-cuss-sip-uui"/>.</t>
<figure><artwork><![CDATA[
cont-param-value =/ "isdn-uui"
]]></artwork></figure>
</section> <!-- Coding reqs -->
<section title="Media Feature Tag">
<t>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
<xref target="RFC3840"/>. This document makes no additional provisions
for the use of this feature tag.</t>
</section> <!-- Media feature tag -->
<section anchor="IANA" title="IANA Considerations">
<t>This document adds the following row to the "UUI packages" sub-
registry of the SIP parameter registry:</t>
<t><list style="empty">
<t>Value: isdn-uui</t>
<t>Description: 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.</t>
<t>Reference: RFCXXXX</t>
<t>Contact: Keith Drage</t>
</list></t>
<t>This document adds the following row to the "UUI content" subregistry
of the SIP parameter registry:</t>
<t><list style="empty">
<t>Value: isdn-uui</t>
<t>Description: The associated contents conforms to the content
associated with the ISDN User to User service. In the presence of
the "purpose" header field parameter set to "isdn-uui" (or the
absence of any "purpose" header field parameter) this is the
default meaning and therefore need not be included in this case.</t>
<t>Reference: RFCXXXX</t>
<t>Contact: Keith Drage</t>
</list></t>
<t>This document defines the following media feature tag which is added
to the features.sip-tree of the Media Feature tags registry:</t>
<t><list style="empty">
<t>Media feature-tag name: sip.uui-isdn</t>
<t>ASN.1 Identifier: 1.3.6.1.8.4.x</t>
<t>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".</t>
<t>Values appropriate for use with this feature-tag: none</t>
<t>Examples of typical use: Indicating that a mobile phone supports
SRVCC for calls in alerting phase.</t>
<t>Related standards or documents: RFCXXXX</t>
<t>Security Considerations: Security considerations for this media
feature-tag are discussed in section 11.1 of <xref target="RFC3840"/></t>
</list></t>
<t>Editor's Note: [RFCXXXX] should be replaced with the designation of
this document.</t>
</section> <!-- IANA cons. -->
<section title="Security Considerations" anchor="sec-cons">
<t>This document contains no specific requirements in regard to security
over and above those specified in <xref target="I-D.ietf-cuss-sip-uui"/>. However, since this capability is designed to interwork with the ISDN, the general security considerations of SIP to ISUP (ISDN User Part) interworking defined in <xref target="RFC3398" /> apply. Any SIP/PSTN gateway implementing the ISDN UUI service should not blindly trust ISUP from the PSTN.
In general, 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.</t>
<t>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 of protection, and may indeed not be suitable
for this package, particularly taking into account the statement in
the following paragraph.</t>
<t>
As this capability is defined to interwork with the ISDN, if the ISDN forms part of the route, any usage needs to be aware that the security level of the ISDN service may be lower than the security of the SIP service. The ISDN security is itself not definable on an end-to-end basis, and exists on a hop-by-hop basis. 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.</t>
</section> <!-- Security Considerations -->
<section title="Acknowledgments">
<t>Joanne McMillen was a major contributor and co-author of earlier
versions of this document.</t>
<t>Thanks to Spencer Dawkins, Vijay Gurbani, Laura Liess, and Roland Jesske for their
reviews of this document. The authors wish to
thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen
Jennings, Mahalingam Mani and Celine Serrut-Valette for their
comments.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3261;
&RFC3372;
&RFC3840;
&cuss-sip-uui;
<reference anchor="Q931">
<front>
<title>ITU-T Recommendation Q.931: Digital subscriber Signalling
System No. 1 - Network layer; ISDN user-network interface
layer 3 specification for basic call control</title>
<author></author>
</front>
<seriesInfo name="ITU-T"
value="http://www.itu.int/rec/T-REC-Q.931-199805-I/en"/>
</reference>
&RFC3398;
</references>
<references title="Informative References">
<reference anchor="Q957.1">
<front>
<title>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)</title>
<author></author>
</front>
<seriesInfo name="ITU-T"
value="http://www.itu.int/rec/T-REC-Q.957.1-199607-I"/>
</reference>
<reference anchor="Q763">
<front>
<title>ITU-T Q.763 Signaling System No. 7 - ISDN user part formats and
codes</title>
<author></author>
</front>
<seriesInfo name="ITU-T"
value="http://www.itu.int/rec/T-REC-Q.931-199805-I/en"/>
</reference>
&RFC6567;
<reference anchor="ANSII">
<front>
<title>ANSI T1.643-1995, Telecommunications-Integrated Services
Digital Network (ISDN)-Explicit Call Transfer Supplementary Service
</title>
<author></author>
</front>
<seriesInfo name="ANSI T1.643-1995" value=""/>
</reference>
<reference anchor="ETSI">
<front>
<title>"ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
Digital Network (ISDN); Diversion supplementary services"</title>
<author></author>
</front>
<seriesInfo name="ETSI ETF 300 207-1" value=""/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:35:31 |