One document matched: draft-ietf-mmusic-sdp-cs-12.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc compact="yes"?>
<?rfc sortrefs="yes"?>
<?rfc linkmailto="no"?>
<?rfc strict="no"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<rfc ipr="pre5378Trust200902" category="std">
<front>
<title abbrev="PSTN Circuit-Switched Bearers in SDP">
Session Description Protocol (SDP) Extension For Setting Up
Audio and Video Media Streams Over Circuit-Switched Bearers In
The Public Switched Telephone Network (PSTN)
</title>
<author initials="M" surname="Garcia-Martin" fullname="Miguel A. Garcia-Martin">
<organization>Ericsson</organization>
<address>
<postal>
<street>Calle Via de los Poblados 13</street>
<city>Madrid</city>
<region>ES</region>
<code>28033</code>
<country>Spain</country>
</postal>
<email>miguel.a.garcia@ericsson.com</email>
</address>
</author>
<author initials="S" surname="Veikkolainen" fullname="Simo Veikkolainen">
<organization>Nokia</organization>
<address>
<postal>
<street>P.O. Box 226</street>
<city>NOKIA GROUP</city>
<region>FI</region>
<code>00045</code>
<country>Finland</country>
</postal>
<phone>+358 50 486 4463 </phone>
<email>simo.veikkolainen@nokia.com</email>
</address>
</author>
<date day="8" month="October" year="2012" />
<area>RAI</area>
<workgroup>MMUSIC WG</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>PSTN</keyword>
<abstract>
<t>
This memo describes use cases, requirements, and protocol
extensions for using the Session Description Protocol (SDP)
Offer/Answer model for establishing audio and video media
streams over circuit-switched bearers in the Public Switched
Telephone Network (PSTN).
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
The <xref target="RFC4566">Session Description Protocol
(SDP)</xref> is intended for describing multimedia sessions
for the purposes of session announcement, session invitation,
and other forms of multimedia session initiation. SDP is most
commonly used for describing media streams that are
transported over the <xref target="RFC3550">Real-Time
Transport Protocol (RTP)</xref>, using the profiles for audio
and video media defined in <xref target="RFC3551">RTP Profile
for Audio and Video Conferences with Minimal Control</xref>.
</t>
<t>
However, SDP can be used to describe other transport protocols
than RTP. Previous work includes <xref target="RFC3108">SDP
conventions for describing ATM bearer connections</xref> and
the <xref target="RFC4975">Message Session Relay
Protocol</xref>.
</t>
<t>
SDP is commonly carried in <xref target="RFC3261">Session
Initiation Protocol (SIP)</xref> messages in order to agree on
a common media description among the endpoints. <xref
target="RFC3264">An Offer/Answer Model with Session
Description Protocol (SDP)</xref> defines a framework by which
two endpoints can exchange SDP media descriptions and come to
an agreement as to which media streams should be used, along
with the media related parameters.
</t>
<t>
In some scenarios it might be desirable to establish the media
stream over a circuit-switched bearer connection even if the
signaling for the session is carried over an IP bearer. An
example of such a scenario is illustrated with two mobile
devices capable of both circuit-switched and packet-switched
communication over a low-bandwidth radio bearer. The radio
bearer may not be suitable for carrying real-time audio or
video media, and using a circuit-switched bearer would offer
a better perceived quality of service. So, according
to this scenario, SDP and its higher layer session control
protocol (e.g., the <xref target="RFC3261">Session Initiation
Protocol (SIP) </xref>) are used over regular IP connectivity,
while the audio or video is received through the classical
circuit-switched bearer.
</t>
<t>
Setting up a signaling relationship in the IP domain instead
of just setting up a circuit-switched call offers also the
possibility of negotiating in the same session other IP based
media that is not sensitive to jitter and delay, for
example, text messaging or presence information.
</t>
<t>
At a later point in time the mobile device might move to an
area where a high-bandwidth packet-switched bearer, for
example a Wireless Local Area Network (WLAN) connection, is
available. At this point the mobile device may perform a
handover and move the audio or video media streams over to the
high-speed bearer. This implies a new exchange of SDP
Offer/Answer that lead to a re-negotiation of the media
streams.
</t>
<t>
Other use cases exist. For example, and endpoint might have at
its disposal circuit-switched and packet-switched
connectivity, but the same audio or video codecs are not
feasible for both access networks. For example, the
circuit-switched audio or video stream supports
narrow-bandwidth codecs, while the packet-switched access
allows any other audio or video codec implemented in the
endpoint. In this case, it might be beneficial for the
endpoint to describe different codecs for each access type and
get an agreement on the bearer together with the remote
endpoint.
</t>
<t>
There are additional use cases related to third party call
control where the session setup time is improved when the
circuit-switched bearer in the PSTN is described together with
one or more codecs.
</t>
<t>
The rest of the document is structured as follows: <xref
target="sec-conventions"/> provides the document conventions,
<xref target="sec-requirements"/> introduces the requirements,
<xref target="sec-overview"/> presents an overview of the
proposed solutions, and <xref
target="sec-protocol-description"/> contains the protocol
description. <xref target="sec-sdp-examples" /> provides an
example of descriptions of circuit-switched audio or
video streams in SDP. <xref target="sec-security" /> and <xref
target="sec-iana"/> contain the Security and IANA
considerations, respectively.
</t>
</section>
<section title="Conventions Used in This Document" anchor="sec-conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14, <xref target="RFC2119">RFC
2119</xref> and indicate requirement levels for compliant
implementations.
</t>
</section>
<section title="Requirements" anchor="sec-requirements">
<t>
This section presents the general requirements that are specific for
the audio or video media streams over circuit-switched bearers.
</t>
<t><list style='format REQ-%d:'>
<t>
A mechanism for endpoints to negotiate and agree on an audio
or video media stream established over a circuit-switched
bearer MUST be available.
</t>
<t>
The mechanism MUST allow the endpoints to combine
circuit-switched audio or video media streams with other
complementary media streams, for example, text messaging.
</t>
<t>
The mechanism MUST allow the endpoint to negotiate the
direction of the circuit-switched bearer, i.e., which
endpoint is active when initiating the circuit-switched
bearer.
</t>
<t>
The mechanism MUST be independent of the type of the
circuit-switched access (e.g., Integrated Services Digital
Network (ISDN), Global System for Mobile Communication
(GSM), etc.)
</t>
<t>
There MUST be a mechanism that helps an endpoint to
correlate an incoming circuit-switched bearer with the one
negotiated in SDP, as opposed to another incoming call that
is not related to that.
</t>
<t>
It MUST be possible for endpoints to advertise different
list of audio or video codecs in the circuit-switched audio
or video stream from those used in a packet-switched audio
or video stream.
</t>
<t>
It MUST be possible for endpoints to not advertise the list
of available codecs for circuit-switched audio or video
streams.
</t>
</list></t>
</section>
<section title="Overview of Operation" anchor="sec-overview">
<t>
The mechanism defined in this memo extends SDP and allows
describing an audio or video media stream established over a
circuit-switched bearer. A new network type ("PSTN") and a new
protocol type ("PSTN") are defined for the "c="
and "m=" lines to be able to describe a media
stream over a circuit-switched bearer. These SDP extensions
are described in <xref target="sec-sdp-extensions"/>. Since
circuit-switched bearers are connection-oriented media
streams, the mechanism re-uses the connection-oriented
extensions defined in <xref target="RFC4145">RFC 4145</xref>
to negotiate the active and passive sides of a connection
setup. This is further described in <xref
target="sec-connection-direction"/>.
</t>
<section title="Example Call Flow" anchor="sec-example">
<t>
Consider the example presented in <xref
target="fig-example-flow"/>. In this example, Alice is
located in an environment where she has access to both IP
and circuit-switched bearers for communicating with other
endpoints. Alice decides that the circuit-switched bearer
offers a better perceived quality of service for voice, and
issues an SDP Offer containing the description of an audio
media stream over circuit-switched bearer.
</t>
<figure anchor="fig-example-flow" title="Example Flow" align="center">
<artwork><![CDATA[
Alice Bob
| (1) SDP Offer (PSTN audio) |
|----------------------------------->|
| |
| (2) SDP Answer (PSTN audio) |
|<-----------------------------------|
| |
| PSTN call setup |
|<-----------------------------------|
| |
| |
|<===== media over PSTN bearer =====>|
| |
]]></artwork>
</figure>
<t>
Bob receives the SDP offer and determines that he is located
in an environment where the IP based bearer is not suitable
for real-time audio media. However he also has PSTN
circuit-switched bearer available for audio. Bob generates
an SDP answer containing a description of the audio media
stream over a circuit-switched bearer.
</t>
<t>
During the offer-answer exchange Alice and Bob also agree
the direction in which the circuit-switched bearer
should be established. In this example, Bob becomes the
active party, in other words, he establishes the
circuit-switched call to the other endpoint. The
Offer/Answer exchange contains identifiers or references
that can be used on the circuit-switched network for
addressing the other endpoint, as well as information that
is used to determine that the incoming circuit-switched
bearer establishment is related to the ongoing session
between Alice and Bob.
</t>
<t>
Bob establishes a circuit-switched bearer towards Alice
using whatever mechanisms are defined for the network type
in question. When receiving the incoming circuit-switched
connection attempt, Alice is able to determine that the
attempt is related to the session she is just establishing
with Bob.
</t>
<t>
Alice accepts the circuit-switched connection; the
circuit-switched bearer setup is completed. Bob and
Alice can now use the circuit-switched connection for
two-way audio media.
</t>
<t>
If, for some reason, Bob would like to reject the offered
stream, he would set the port number of the specific stream to
zero, as specified in <xref
target="RFC3264">RFC3264</xref>. Also, if Bob does not
understand some of the SDP attributes specified in this
document, he would ignore them, as specified in
<xref target="RFC4566">RFC4566</xref>.
</t>
</section>
</section>
<section title="Protocol Description"
anchor="sec-protocol-description">
<section title="Level of Compliance" anchor="sec-compliance">
<t>
Implementations according to this specification MUST
implement the SDP extensions described in
<xref target="sec-sdp-extensions"/>, and MUST implement the
considerations discussed in <xref
target="sec-correlation-negotiation"/>, <xref
target="sec-sdp-considerations"/> and <xref
target="sec-offer-answer-ext"/>.
</t>
</section>
<section title="Extensions to SDP" anchor="sec-sdp-extensions">
<t>
This section provides the syntax and semantics of the
extensions required for providing a description of audio
or video media streams over circuit-switched bearers in SDP.
</t>
<section title="Connection Data" anchor="sec-c-line">
<t>
According to <xref target="RFC4566">SDP</xref>, the
connection data line in SDP has the following syntax:
</t>
<t><list>
<t>
c=<nettype> <addrtype> <connection-address>
</t>
</list></t>
<t>
where <nettype> indicates the network type,
<addrtype> indicates the address type, and the
<connection-address> is the connection address, which
is dependent on the address type.
</t>
<t>
At the moment, the only network type defined is "IN", which
indicates Internet network type. The address types "IP4" and
"IP6" indicate the type of IP addresses.
</t>
<t>
This memo defines a new network type for describing a
circuit-switched bearer network type in the PSTN. The mnemonic
"PSTN" is used for this network type.
</t>
<t>
For the address type, we initially consider the
possibility of describing E.164 telephone numbers. We
define a new "E164" address type to be used within the
context of a "PSTN" network type. The "E164" address type
indicates that the connection address contains an
E.164 number represented according to the
<xref target="ITU.E164.1991">ITU-T E.164 </xref>
recommendation.
</t>
<t>
It is a common convention that an international E.164
number contains a leading '+' sign. For consistency's
sake, we also require the E.164 telephone is prepended
with a '+', even if that is not necessary for routing of
the call in the PSTN network.
</t>
<t>
There are cases, though, when the endpoint is merely aware
of a circuit-switched bearer, without having further
information about the address type or the E.164 number
allocated to it. In these cases a dash "-" is used to
indicate an unknown address type or connection
address. This makes the connection data line be according
to the SDP syntax.
</t>
<t>
Please note that this "E164" and "-" address type defined
in this memo are exclusively defined to be used in
conjunction with the "PSTN" network type. Usages of "E164"
or "-" address types in conjunction with other network
types may exist elsewhere.
</t>
<t>
This memo exclusively uses the international
representation of E.164 numbers, i.e., those initiated
with a '+' sign. The syntax (see <xref
target="sec-syntax"/>) refers to the representation of
a 'global-number' construction already specified in <xref
target="RFC3966">RFC 3966 </xref>. This representation
requires the presence of the '+' sign. Additionally, this
representation allows for the presence of one or more
'visual-separator' constructions. Implementations
confirming to this specification and using the "E164" address type
together with the "PSTN" network type MUST only use
international E.164, i.e., those starting with a '+' sign
and SHOULD NOT use visual-separators.
</t>
<t><list>
<t>
Note that <addrtype> and/or
<connection-address> MUST NOT be omitted when
unknown since this would violate basic syntax of <xref
target="RFC4566">SDP</xref>. In such cases, they MUST be
set to a "-".
</t>
</list></t>
<t>
The following are examples of the extension to the
connection data line:
</t>
<t><list>
<t>
c=PSTN E164 +35891234567
</t>
<t>
c=PSTN - -
</t>
</list></t>
<t>
When the <addrtype> is PSTN, the connection address
is defined as follows:
<list style="symbols">
<t>an international E.164 number</t>
</list>
</t>
<t>
When the <addrtype> is "-", the connection address
is defined as follows:
<list style="symbols">
<t>the value "-", signifying that the address is
unknown</t>
<t>any syntactically valid value, which is to be
ignored</t>
</list>
</t>
</section>
<section title="Media Descriptions" anchor="sec-m-line">
<t>
According to <xref target="RFC4566">SDP</xref>, the
media descriptions line in SDP has the following syntax:
</t>
<t><list>
<t>
m=<media> <port> <proto> <fmt> ...
</t>
</list>
</t>
<t>
The <media> subfield carries the media type. For
establishing an audio bearer, the existing "audio" media
type is used. For establishing a video bearer, the
existing "video" media type is used.
</t>
<t>
The <port> subfield is the transport port to which
the media stream is sent. Circuit-switched access lacks
the concept of a port number, and therefore the
<port> subfield does not carry any meaningful
value. In order to be compliant with SDP syntax,
implementations SHOULD set the <port> subfield to the
discard port value "9" and MUST ignore it on reception.
</t>
<t>
According to <xref target="RFC3264">RFC 3264 </xref>, a port
number of zero in the offer of a unicast stream indicates
that the stream is offered but must not be used. If a
port number of zero is present in the answer of a unicast
stream, it indicates that the stream is rejected. These
rules are still valid when the media line in SDP represents
a circuit-switched bearer.
</t>
<t>
The <proto> subfield is the transport protocol. The
circuit-switched bearer uses whatever transport protocol it
has available. This subfield SHOULD be set to the mnemonic
"PSTN" to be syntactically correct with <xref
target="RFC4566">SDP </xref> and to indicate the usage of
circuit-switched protocols in the PSTN.
</t>
<t>
The <fmt> subfield is the media format
description. In the classical usage of SDP to describe
RTP-based media streams, when the <proto> subfield is
set to "RTP/AVP" or "RTP/SAVP", the <fmt> subfield
contains the payload types as defined in the <xref
target="RFC3551">RTP audio profile</xref>.
</t>
<t>
When "RTP/AVP" is used in the <proto> field, the
<fmt> subfield contains the RTP payload type
numbers. We use the <fmt> subfield to indicate the
list of available codecs over the circuit-switched
bearer, by re-using the conventions and payload type
numbers defined for RTP/AVP. The RTP audio and video media
types, which, when applied to PSTN circuit-switched
bearers, represent merely an audio or video codec.
</t>
<t>
In some cases, the endpoint is not able to
determine the list of available codecs for circuit-switched
media streams. In this case, in order to be syntactically
compliant with <xref target="RFC4566">SDP </xref>, the
endpoint MUST include a single dash "-" in the <fmt>
subfield.
</t>
<t>
As per <xref target="RFC4566">RFC 4566</xref>, the media
format descriptions are listed in priority order.
</t>
<t>
Examples of media descriptions for circuit-switched audio
streams are:
</t>
<t>
<list>
<t>
m=audio 9 PSTN 3 0 8
</t>
<t>
m=audio 9 PSTN -
</t>
</list>
</t>
<t>
Similarly, an example of a media description for
circuit-switched video stream is:
</t>
<t>
<list>
<t>
m=video 9 PSTN 34
</t>
<t>
m=video 9 PSTN -
</t>
</list>
</t>
</section>
<section title="Correlating the PSTN Circuit-Switched Bearer with SDP"
anchor="sec-correlation">
<t>
The endpoints should be able to correlate the
circuit-switched bearer with the session negotiated with
SDP in order to avoid ringing for an incoming
circuit-switched bearer that is related to the session
controlled with SDP (and SIP).
</t>
<t>
Several alternatives exist for performing this
correlation. This memo provides three mutually non-exclusive
correlation mechanisms. Other correlation mechanisms may
exist, and their usage will be specified when need
arises. All mechanisms share the same principle: some
unique information is sent in the SDP and in the
circuit-switched signaling protocol. If these pieces of
information match, then the circuit-switched bearer is
part of the session described in the SDP
exchange. Otherwise, there is no guarantee that the
circuit-switched bearer is related to such session.
</t>
<t>
The first mechanism is based on the exchange of PSTN
caller-ID between the endpoints. The caller-ID is also
available as the Calling Party ID in the circuit-switched
signaling.
</t>
<t>
The second mechanism is based on the inclusion in
SDP of a value that is also sent in the User-to-User
Information Element that is part of the bearer setup
signaling in the PSTN.
</t>
<t>
The third mechanism is based on sending in SDP a string
that represents Dual Tone MultiFrequency (DTMF) digits
that will be later sent right after the circuit-switched
bearer is established. Implementations MAY use any of
these mechanisms and MAY use two or more mechanisms
simultaneously.
</t>
<section title="The "cs-correlation" attribute"
anchor="sec-corr-attr">
<t>
In order to provide support for the correlation
mechanisms, we define a new SDP attribute called
"cs-correlation". This "cs-correlation" attribute can
include any of the "callerid", "uuie", or "dtmf"
subfields, which specify additional information
required by the Caller-ID, User to User Information, or
DTMF correlation mechanisms, respectively. The list of
correlation mechanisms may be extended by other
specifications, see <xref target="sec-corr-extensions"/>
fore more details. There MUST be at most one
"cs-correlation" attribute per media description.
</t>
<t>
The following sections provide more detailed information
of these subfields. The "cs-correlation" attribute has the
following format:
</t>
<t>
<figure><artwork>
a=cs-correlation: <correlation-mechanisms>
correlation-mechanisms = corr-mech *(SP corr-mech)
corr-mech = caller-id-mech / uuie-mech /
dfmt-mech / ext-mech
caller-id-mech = "callerid" [":" caller-id-value]
uuie-mech = "uuie" [":" uuie-value]
dtmf-mech = "dtmf" [":" dtmf-value]
ext-mech = <ext-mech-name>[":"<ext-mech-value>]
</artwork></figure>
</t>
<t>
The values "callerid", "uuie" and "dtmf" refer to the
correlation mechanisms defined in <xref
target="sec-corr-caller-id"/>, <xref
target="sec-corr-uuie"/>, and <xref
target="sec-corr-dtmf"/>, respectively. The formal
Augmented Backus-Naur Format (ABNF) syntax of the
"cs-correlation" attribute is presented in <xref
target="sec-syntax"/>.
</t>
</section>
<section title="Caller-ID Correlation Mechanism" anchor="sec-corr-caller-id">
<t>
The Caller-ID correlation mechanisms consists of an
exchange of the calling party number as an international
E.164 number in SDP, followed by the availability of the
Calling Party Number information element in the call
setup signaling of the circuit switched connection. If
both pieces of information match, the circuit-switched
bearer is correlated to the session described in SDP.
</t>
<t>
Example of inclusion of an international E.164 number in
the "cs-correlation" attribute is:
</t>
<t>
<list>
<t>a=cs-correlation:callerid:+35891234567</t>
</list>
</t>
<t>
The presence of the "callerid" subfield indicates that
the endpoint supports use of the calling party number as
a means of correlating a PSTN call with the session
being negotiated. The "callerid" subfield MAY be
accompanied by the international E.164 number of the
party inserting the parameter.
<list>
<t>
Note that there are no warranties that this
correlation mechanism works or is even available, due a
number of problems:
</t>
</list>
</t>
<t>
<list style="symbols">
<t>
The endpoint might not be aware of its own E.164
number, in which case it cannot populate the SDP
appropriately.
</t>
<t>
The Calling Party Number information element in the
circuit-switched signaling might not be available,
e.g., due to policy restrictions of the network
operator or caller restriction due to privacy.
</t>
<t>
The Calling Party Number information element in the
circuit-switched signaling might be available, but
the digit representation of the E.164 number might
differ from the one expressed in the SDP. To
mitigate this problem implementations should
consider only some of the rightmost digits from the
E.164 number for correlation. For example, the
numbers +358-9-123-4567 and 09-123-4567 could be
considered as the same number. This is also the
behavior of some cellular phones, which correlate
the incoming calling party with a number stored in
the phone book, for the purpose of displaying the
caller's name.
</t>
</list>
</t>
</section>
<section title="User-User Information Element Correlation
Mechanism" anchor="sec-corr-uuie">
<t>
A second correlation mechanism is based on including in
SDP a string that represents the User-User Information
Element that is part of the call setup signaling of the
circuit-switched bearer. The User-User Information
Element is specified in <xref
target="ITU.Q931.1998">ITU-T Q.931 </xref> and <xref
target="TS.24.008">3GPP TS 24.008</xref>, among
others. The User-User Information Element has a maximum
size of 35 or 131 octets, depending on the actual
message of the PSTN protocol where it is included and
the network settings.
</t>
<t>
The mechanism works as follows: An endpoint creates a
User-User Information Element, according to the
requirements of the call setup signaling protocol. The
same value is included in the SDP offer or SDP answer,
in the "uuie" subfield of the "cs-correlation"
attribute. When the SDP Offer/Answer exchange is
completed, each endpoint has become aware of the value
that will be used in the User-User Information Element
of the call setup message of the PSTN protocol. The
endpoint that initiates the call setup attempt includes
this value in the User-User Information Element. The
recipient of the call setup attempt can extract the
User-User Information Element and correlate it with the
value previously received in the SDP. If both values
match, then the call setup attempt corresponds to that
indicated in the SDP.
</t>
<t>
According to <xref target="ITU.Q931.1998">ITU-T
Q.931</xref>, the User-User Information Element (UUIE)
identifier is composed of a first octet identifying this
as a User-User Information Element, a second octet
containing the Length of the user-user contents, a third
octet containing a Protocol Discriminator, and a value
of up to 32 or 128 octets (depending on network
settings) containing the actual User Information (see
Figure 4-36 in ITU-T Q.931). The first two octets of the
UUIE MUST NOT be used for correlation, only the octets
carrying the Protocol Discriminator and the User
Information value are input to the creation of the value
of the "uuie" subfield in the "cs-correlation"
attribute. Therefore, the value of the "uuie" subfield
in the "cs-correlation" attribute MUST start with the
Protocol Discriminator octet, followed by the User
Information octets. The value of the Protocol
Discriminator octet is not specified in this document;
it is expected that organizations using this technology
will allocate a suitable value for the Protocol
Discriminator.
</t>
<t>
Once the binary value of the "uuie" subfield in the
"cs-correlation" attribute is created, it MUST be
encoded in hexadecimal before it is inserted in SDP.
Each octet of binary data to be represented in the
hexadecimal encoding MUST be mapped to two hexadecimal
digits (represented by ASCII characters 0-9 and A-F,
each representing four bits within the octet. The four
bits appearing first in the binary data MUST be mapped
to the first hexadecimal digit and the four subsequent
bits in the binary data MUST be mapped to the second
hexadecimal digit. When mapping 4 bits to a hexadecimal
digit, the bit appearing first in the binary data SHALL
be most significant. Thus, the resulting hexadecimal
encoded value needs to have an even number of
hexadecimal digits, and MUST be considered invalid if it
has an odd number.
</t>
<t>
<list>
<t>
Note that the encoding of the "uuie" subfield of the
"cs-correlation" attribute is largely inspired by
the encoding of the same value in the User-to-User
header field in SIP, according to the document <xref
target="I-D.ietf-cuss-sip-uui"> A Mechanism for
Transporting User to User Call Control Information
in SIP</xref>.
</t>
</list>
</t>
<t>
As an example, an endpoint willing to send a UUIE
containing a protocol discriminator with the hexadecimal
value of %x56 and an hexadecimal User Information value
of %xA390F3D2B7310023 would include a "cs-correlation"
attribute line as follows:
</t>
<t>
<list>
<t>
a=cs-correlation:uuie:56A390F3D2B7310023
</t>
</list>
</t>
<t>
Note that, for correlation purposes, the value of the
User-User Information Element is considered as an opaque
string and only used for correlation purposes. Typically
call signaling protocols impose requirements on the
creation of User-User Information Element for end-user
protocol exchange. The details regarding the generation of
the User-User Information Element are outside the scope of
this specification.
</t>
<!--
<t>
An endpoint that is feasible to become the active party for
setting up the PSTN call and is willing to send the
User-User Information Element in the PSTN signaling SHOULD
add a "uuie" subfield in the "cs-correlation"
attribute of the SDP offer or answer. This "uuie"
subfield SHOULD include the value of the User-User
Information Element that will be used in the call setup
attempt as earlier described.
</t>
<t>
An endpoint that takes the role of the passive party for
setting up the circuit-switched bearer SHOULD include
include a "uuie" subfield in the "cs-correlation"
attribute in the SDP, if it supports the UUI
mechanism. It MAY also add a value for the "uuie"
subfield although it is not used for correlation
purposes.
</t>
-->
<t>
Please note that there are no warranties that this
correlation mechanism works. On one side, policy
restrictions might not make the User-User information
available end to end in the PSTN. On the other hand, the
generation of the User-User Information Element is
controlled by the PSTN circuit-switched call protocol, which
might not offer enough freedom for generating different
values from one endpoint to another one, or from one call to
another in the same endpoint. This might result in the same
value of the User-User Information Element for all calls.
</t>
</section>
<section title="DTMF Correlation Mechanism" anchor="sec-corr-dtmf">
<t>
We introduce a third mechanism for correlating the
circuit-switched bearer with the session described with
SDP. This is based on agreeing on a sequence of digits
that are negotiated in the SDP Offer/Answer exchange and
sent as Dual Tone Multifrequency (DTMF) tones over the
circuit-switched bearer once this bearer is
established. If the DTMF digit sequence received through
the circuit-switched bearer matches the digit string
negotiated in the SDP, the circuit-switched bearer is
correlated with the session described in the SDP. The
mechanism is similar to many voice conferencing systems
which require the user to enter a PIN code using DTMF
tones in order to be accepted in a voice conference.
</t>
<t>
The mechanism works as follows: An endpoint selects a
DTMF digit sequence. The same sequence is included in
the SDP offer or SDP answer, in a "dtmf" subfield of the
"cs-correlation" attribute. When the SDP Offer/Answer
exchange is completed, each endpoint has become aware of
the DTMF sequence that will be sent right after the
circuit-switched bearer is set up. The endpoint that
initiates the call setup attempt sends the DTMF digits
according to the procedures defined for the
circuit-switched bearer technology used. The recipient
(passive side of the bearer setup) of the call setup
attempt collects the digits and compares them with the
value previously received in the SDP. If the digits
match, then the call setup attempt corresponds to that
indicated in the SDP.
</t>
<t>
<list>
<t>
Implementations are advised to select a number of
DTMF digits that provide enough assurance that the
call is related, but on the other hand do not
prolong the bearer setup time unnecessarily.
</t>
</list>
</t>
<t>
As an example, an endpoint willing to send DTMF tone
sequence "14D*3" would include a "cs-correlation" attribute
line as follows:
</t>
<t>
<list>
<t>a=cs-correlation:dtmf:14D*3</t>
</list>
</t>
<!--
<t>
An endpoint that takes the role of the passive party for
setting up the circuit-switched bearer SHOULD include
include a "dtmf" subfield in the "cs-correlation"
attribute in the SDP, if it supports the mechanism. It
MAY also add a value for the "dtmf" subfield although
it is not used for correlation purposes.
</t>
<t>
If the answerer is willing to also use the DTMF tone
correlation mechanism, it MUST copy the "dtmf"
subfield and
its value from the SDP offer to the SDP answer.
</t>
<t>Action Point: We need to figure out all the cases
here. For example, what happens if the offerer is the
passive party? The answerer is the active, sets the
DTMF subfield but how does the negotiation take place
</t>
<t>
If the answerer it not willing to use the DTMF
correlation mechanism, it MUST NOT include a "dtmf"
subfield in the "correlation" attribute of the SDP
answer.
</t>
<t>
If the answer does not contain a "dtmf" attribute, it means
that the answerer either does not support the mechanism or is
not willing to use the mechanism at this point. In this
case, the offerer MUST NOT send DTMF tones during the
circuit-switched call setup, and MUST NOT wait to receive
any DTMF digits during circuit-switched bearer setup in case
it becomes selected as the passive side of the
circuit-switched bearer establishment.
</t>
<t>
If the offer contains an illegal value in the "dtmf"
attribute, the answerer SHOULD NOT include a "dtmf"
attribute in the answer. If the answer, as seen by the
offerer, contains an illegal value of the "dtmf" attribute,
the answerer SHOULD update the offer and omit the "dtmf"
attribute from the new offer.
</t>
<t>
If both the offer and the answer successfully agree to use
the DTMF digit correlation mechanism, the active party of
the connection setup MUST also become the active side when
sending the DTMF digits.
</t>
-->
<t>
If the endpoints successfully agree on the usage
of the DTMF digit correlation mechanism, but the passive
side does not receive any DTMF digits after successful
circuit-switched bearer setup, or receives a set of DTMF
digits that do not match the value of the "dtmf" attribute
(including receiving too many digits), the passive side
SHOULD treat the circuit-switched bearer as not correlated
to the ongoing session.
</t>
<t>
<list style="empty">
<t>
DTMF digits can only be sent once the circuit-switched
bearer is set up. In order to suppress alerting for an
incoming circuit-switched call, implementations may choose
various mechanisms. For example, alerting may be suppressed
for a certain time period for incoming call attempts that
originate from the number that was observed during the
offer/answer negotiation.
</t>
</list>
</t>
</section>
<section title="Extensions to correlation mechanisms" anchor="sec-corr-extensions">
<t>
New values for the "cs-correlation" attribute may be
specified. The registration policy for new values
is "Specification Required", see <xref
target="sec-iana"/>. Any such specification MUST include
a description of how SDP Offer/Answer mechanism is used
to negotiate the use of the new values, taking into
account how endpoints determine which side will become
active or passive (see <xref
target="sec-correlation-negotiation"/> for more details).
</t>
<t>
If, during the Offer/Answer negotiation, either endpoint
encounters an unknown value in the "cs-correlation"
attribute, it MUST consider that mechanism as unsupported,
and MUST NOT include that value in subsequent Offer/Answer
negotiation.
</t>
</section>
</section>
</section>
<section title="Negotiating the correlation mechanisms"
anchor="sec-correlation-negotiation">
<t>
The three correlation mechanisms presented above (based on
called party number, User-User Information Element and
DTMF digit sending) are non-exclusive, and can be used
independently of each other. In order to know how to
populate the "cs-correlation" attribute, the endpoints
need to agree which endpoint will become the active party,
i.e. the one that will set up the circuit-switched bearer.
</t>
<section title="Determining the Direction of the
Circuit-Switched Bearer Setup"
anchor="sec-connection-direction">
<t>
In order to avoid a situation where both endpoints attempt
to initiate a connection simultaneously, the direction in
which the circuit-switched bearer is set up MUST be
negotiated during the Offer/Answer exchange.
</t>
<t>
The framework defined in <xref target="RFC4145">RFC
4145</xref> allows the endpoints to agree which endpoint
acts as the active endpoint when initiating a TCP
connection. While <xref target="RFC4145">RFC 4145</xref>
was originally designed for establishing TCP connections,
it can be easily extrapolated to the connection
establishment of circuit-switched bearers. This
specification uses the concepts specified in <xref
target="RFC4145">RFC 4145</xref> for agreeing on the
direction of establishment of a circuit-switched bearer.
</t>
<t>
<xref target="RFC4145">RFC 4145 </xref> defines two new
attributes in SDP: "setup" and "connection". The "setup"
attribute indicates which of the endpoints should initiate
the connection establishment of the PSTN circuit-switched
bearer. Four values are defined in Section 4 of <xref
target="RFC4145">RFC 4145 </xref>: "active", "passive",
"actpass", "holdconn". Please refer to Section 4 of <xref
target="RFC4145">RFC 4145 </xref> for a detailed description
of this attribute.
</t>
<t>
The "connection" attribute indicates whether a new
connection is needed or an existing connection is
reused. The attribute can take the values "new" or
"existing". Please refer to Section 5 of <xref
target="RFC4145">RFC 4145 </xref> for a detailed description
of this attribute.
</t>
<t>
Implementations according to this specification MUST support
the "setup" and "connection" attributes specified in <xref
target="RFC4145">RFC 4145 </xref>, but applied to
circuit-switched bearers in the PSTN.
</t>
<t>
We define the active party as the one that initiates the
circuit-switched bearer after the Offer/Answer exchange. The
passive party is the one receiving the circuit-switched
bearer. Either party may indicate its desire to become the
active or passive party during the Offer/Answer exchange
using the procedures described in <xref
target="sec-offer-answer-ext"/>.
</t>
</section>
<section title="Populating the cs-correlation attribute"
anchor="sec-populating-the-cs-correlation-attribute">
<!-- <t>
In order to establish a circuit-switched connection in the
PSTN, the initiating endpoint needs to know the address
(E.164 number) of the other endpoint. Therefore, if an
endpoint wants to only receive incoming
circuit-switched calls (i.e., become the passive party),
it has to know its E.164 number and indicate it in
SDP. As a consequence, an endpoint that is not aware of
its own E.164 number cannot take the role of the passive
side with respect the establishment of the
circuit-switched connection.
</t>
-->
<t>
By defining values for the subfields in the
"a=cs-correlation" attribute, the endpoint indicates that
it is willing to become the active party, and that it
can use those values in the Calling party
number, User-User Information Element, or as DTMF tones
during the circuit-switched bearer setup.
</t>
<t>
Thus, the following rules apply:
<list>
<t>
An endpoint that can only become the active party in
the circuit-switched bearer setup MUST include all
correlation mechanisms it supports in the
"a=cs-correlation" attribute, and MUST also specify
values for the subfields.
</t>
<t>
An endpoint that can only become the passive party in the
circuit-switched bearer setup MUST include all correlation
mechanisms it supports in the "a=cs-correlation"
attribute, but MUST NOT specify values for the
subfields.
</t>
<t>
An endpoint that is willing to become either the active or
passive party (by including the "a=setup:actpass"
attribute in the Offer), MUST include all correlation
mechanisms it supports in the "a=cs-correlation"
attribute, and MUST also specify values for the
subfields.
</t>
</list>
</t>
</section>
<section title="Considerations on successful correlation"
anchor="sec-neg-endpoint-behaviour">
<t>
Note that, as stated above, it cannot be guaranteed that any given
correlation mechanism will succeed even if the usage of
those was agreed beforehand. This is due to the fact that
the correlation mechanisms require support from the
circuit-switched bearer technology used.
</t>
<t>
Therefore, even a single positive indication
using any of these mechanisms SHOULD be interpreted by the
passive endpoint so that the circuit-switched bearer
establishment is related to the ongoing session, even if
the other correlation mechanisms fail.
</t>
<t>
If, after negotiating one or more
correlation mechanisms in the SDP offer/answer
exchange, an endpoint receives a circuit-switched bearer
with no correlation information present, the
endpoint has two choices: it can either treat the call as
unrelated, or treat the call as related to the ongoing
session in the IP domain.
</t>
<t>
An endpoint may for example specify a time window after
SDP offer/answer exchange during which received calls are
treated as correlated even if the signaling in the
circuit-switched domain does not carry any correlation
information. In this case, there is a chance that the call
is erroneously treated as related to the ongoing session.
</t>
<t>
An endpoint may also choose to always treat an incoming
call as unrelated if the signaling in the
circuit-switched domain does not carry any correlation
information. In this case, there is a chance that the call
is erroneously treated as unrelated.
</t>
<t>
Since, in these cases, no correlation information can be
deduced from the signaling, it is up to the
implementation to decide how to behave. One option is also
to let the user decide whether to accept the call as
related, or to treat the call as unrelated.
</t>
</section>
</section>
<section title="Considerations for Usage of Existing SDP"
anchor="sec-sdp-considerations">
<section title="Originator of the Session" anchor="sec-originator">
<t>
According to <xref target="RFC4566">SDP</xref>, the
origin line in SDP has the following syntax:
</t>
<t><list>
<t>
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
</t>
</list>
</t>
<t>
Of interest here are the <nettype> and
<addrtype> fields, which indicate the type of network
and type of address, respectively. Typically, this field
carries the IP address of the originator of the
session. Even if the SDP was used to negotiate an audio or
video media stream transported over a circuit-switched
bearer, the originator is using SDP over an IP
bearer. Therefore, <nettype> and <addrtype>
fields in the "o=" line should be populated with the IP
address identifying the source of the signaling.
</t>
</section>
<section title="Contact information" anchor="sec-contact-info">
<t>
<xref target="RFC4566">SDP</xref> defines the "p=" line
which may include the phone number of the person
responsible for the conference. Even though this line can
carry a phone number, it is not suited for the purpose of
defining a connection address for the media. Therefore, we
have selected to define the PSTN specific connection
addresses in the "c=" line.
</t>
</section>
</section>
<section title="Considerations for Usage of Third Party Call Control (3PCC)"
anchor="sec-3pcc-considerations">
<t>
<xref target="RFC3725">Best Current Practices for Third
Party Call Control (3pcc) in the Session Initiation
Protocol (SIP)</xref> outlines several flows which are
possible in third party call control scenarios and
recommends some flows for specific situations.
</t>
<t>
One of the assumptions in <xref target="RFC3725"/> is that an
SDP Offer may include a "black hole" connection address,
which has the property that packets sent to it will never
leave the host which sent them. For IPv4, this "black
hole" connection address is 0.0.0.0, or a domain name
within the .invalid DNS top level domain.
</t>
<t>
When using an E.164 address scheme in the context of
third-party call control, when the User Agent needs to
indicate an unknown phone number, it MUST populate the
<addrtype> of the SDP "c=" line with a "-" string.
</t>
<t>
<list><t>Note that this may result in the recipient of the
initial Offer in rejecting the Offer if the recipient of
the Offer is not aware of its own E.164 number, and thus
concluding that it will not be possible to establish a
circuit-switched bearer since neither party is aware of
their E.164 number.</t></list>
</t>
</section>
<section title="Offer/Answer mode extensions"
anchor="sec-offer-answer-ext">
<t>
In this section, we define extensions to the Offer/Answer
model defined in <xref target="RFC3264">The Offer/Answer
Model in SDP</xref> to allow for PSTN addresses to
be used with the Offer/Answer model.
</t>
<section title="Generating the Initial Offer"
anchor="sec-generating-the-initial-offer">
<t>
The Offerer, wishing to use PSTN audio or video stream,
MUST populate the "c=" and "m=" lines as follows.
</t>
<t>
The endpoint MUST set the <nettype> in the "c=" line
to "PSTN", and the <addrtype> to
"E164". Furthermore, the endpoint SHOULD set the
<connection-address> field to its own international
E.164 number (with a leading "+"). If the endpoint is not
aware of its own E.164 number, it MUST set the
<connection-address> to "-".
</t>
<t>
In the "m=" line, the endpoint MUST set the <media>
subfield to "audio" or "video", depending on the media
type, and the <proto> subfield to "PSTN". The
<port> subfield SHOULD be set to "9" (the discard
port).
</t>
<t>
The <fmt> subfield carries the payload type
number(s) the endpoint is wishing to use. Payload type
numbers in this case refer to the codecs that the endpoint
wishes to use. For example, if the endpoint wishes to use
the GSM codec, it would add payload type number 3 in the
list of codecs.
</t>
<t>
For dynamic payload types, the endpoint MUST define the
set of valid encoding names and related parameters using
the "a=rtpmap" attribute line. See Section 6 of <xref
target="RFC4566">SDP</xref> for details.
</t>
<t>
When generating the Offer, if the Offerer supports any of
the correlation mechanisms defined in this memo, it MUST
include an attribute line "a=cs-correlation" in the SDP
offer. The Offerer MUST NOT include more than one
"cs-correlation" attribute per media decription. The
"a=cs-correlation" line contains an enumeration
of the correlation mechanisms supported by the Offerer, in
the format of subfields.
</t>
<t>
The current list of subfields
include "callerid", "uuie" and "dtmf" and they refer to the
correlation mechanisms defined in <xref
target="sec-corr-caller-id"/>, <xref target="sec-corr-uuie"/>, and
<xref target="sec-corr-dtmf"/>, respectively.
</t>
<t>
If the Offerer supports any of the correlation mechanisms
defined in this memo, and is willing to become the
active party, the Offerer MUST add the "callerid",
"uuie", and/or "dtmf" subfields and MUST specify
values for those subfields.
<list style="symbols">
<t>the international E.164 number as the value in the
"callerid" subfield,</t>
<t>the contents of the User-User information element as
the value of the "uuie" subfield, and/or</t>
<t>the DTMF tone string as the value of the "dtmf"
subfield</t>
</list>
</t>
<t>
If the Offerer is only able to become the passive party in
the circuit-switched bearer setup, it MUST add the
"callerid", "uuie" and/or "dtmf" subfields, but MUST NOT
specify values for those subfields.
</t>
<t>
For example, if the Offerer is willing to use the
User-User Information element and DTMF digit sending
mechanisms, but can only become the passive party, it
includes the following lines to the SDP:
</t>
<t>
<list>
<t>a=cs-correlation:uuie dtmf</t>
<t>a=setup:passive</t>
</list>
</t>
<t>
If, on the other hand, the Offerer is willing to use the
User-User Information element and the DTMF correlation
mechanisms, and is able to become the active or passive
side, it includes to following lines to the SDP:
</t>
<t>
<list>
<t>a=cs-correlation:uuie:56A390F3D2B7310023 dtmf:14D*3</t>
<t>a=setup:actpass</t>
</list>
</t>
<t>
The negotiation of the value of the 'setup' attribute
takes place as defined in Section 4.1 of <xref
target="RFC4145">TCP-Based Media Transport in the
SDP</xref>.
</t>
<t>
The Offerer states which role or roles it is willing to
perform; and the Answerer, taking the Offerer's
willingness into consideration, chooses which roles both
endpoints will actually perform during the
circuit-switched bearer setup.
</t>
<t>
By 'active' endpoint, we refer to an endpoint that will
establish the circuit-switched bearer; and by
'passive' endpoint, we refer to an endpoint that will
receive a circuit-switched bearer.
</t>
<t>
If an Offerer does not know its international E.164
number, it MUST set the 'a=setup' attribute to the value
'active'. If the Offerer knows its international E.164
number, it SHOULD set the value to either 'actpass' or
'passive'.
</t>
<t>
Also 'holdconn' is a permissible value in the 'a=setup'
attribute. It indicates that the connection is not
established for the time being.
</t>
<t>
The Offerer uses the "a=connection" attribute to decide
whether a new circuit-switched bearer is to be established
or not. For the initial Offer, the Offerer MUST use
value 'new'.
</t>
</section>
<section title="Generating the Answer"
anchor="sec-generating-the-answer">
<t>
If the Offer contained a circuit-switched audio or video
stream, the Answerer first determines whether it is able
to accept and use such streams. If the Answerer is not
willing to use circuit-switched media for the session, it
MUST construct an Answer where the port number for such
media stream(s) is set to zero, according to Section 6 of
<xref target="RFC3264">An Offer/Answer Model with the
Session Description Protocol (SDP)</xref>. If the Answerer
is willing to use circuit-switched media for the session,
it MUST ignore the received port number (unless the port
number is set to zero).
</t>
<t>
If the Offer included a "-" as the payload type number, it
indicates that the Offerer is not willing or able to
define any specific payload type. Most often, a "-" is
expected to be used instead of the payload type when the
endpoint is not aware of or not willing to define the
codecs which will eventually be used on the
circuit-switched bearer. The circuit-switched signaling
protocols have their own means of negotiating or
indicating the codecs, therefore an Answerer SHOULD accept
such Offers, and SHOULD set the payload type to "-" also
in the Answer.
</t>
<t>
If the Answerer explicitly wants to specify a codec for
the circuit-switched media, it MAY set the respective
payload numbers in the <fmt> subfield in the
answer. This behavior, however, is NOT RECOMMENDED.
</t>
<t>
When receiving the Offer, the Answerer MUST
determine whether it becomes the active or passive
party.
</t>
<t>
If the SDP in the Offer indicates that the Offerer is
only able to become the active party, the Answerer needs
to determine whether it is able to become the passive
party. If this is not possible e.g. due to the Answerer
not knowing its international E.164 number, the Answerer
MUST reject the circuit-switched media by setting the port
number to zero on the Answer. If the Answerer is aware of
its international E.164 number, it MUST include the
"a=setup" attribute in the Answer and set it to value
"passive" or "holdconn". The Answerer MUST also include
its E.164 number of the "c=" line.
</t>
<t>
If the SDP in the Offer indicates that the Offerer is only
able to become the passive party, the Answerer MUST verify
that the Offerer's E.164 number is included in the "c="
line of the Offer. If the number is included, the Answerer
MUST include the "a=setup" attribute in the Answer and set
it to value "active" or "holdconn". If the number is not
included, call establishment is not possible, and the
Answerer MUST reject the circuit-switched media by setting
the port number to zero in the Answer.
</t>
<t>
If the SDP in the Offer indicates that the Offerer is able
to become either the active or passive party, the Answerer
needs to determine which role it would
like to take. If the Offer includes an international E.164
number in the "c=" line, the Answerer SHOULD become the
active party. If the Offer does not include an E.164
number, and if the Answerer is aware of its international
E.164 number, it MUST become the passive party. If the
Offer does not include an E.164 number in the "c=" line
and the Answerer is not aware of its E.164 number, it MUST
reject the circuit-switched media by setting the port
number to zero in the Answer.
</t>
<t>
The Answerer MUST select those correlation mechanisms
from the Offer it supports, and include an
"a=cs-correlation" attribute line in the Answer containing
those mechanisms it supports and is willing to use. The
Answerer MUST NOT add any mechanisms which were not
included in the offer. If there are more than one
"cs-correlation" attributes per media description in the
Offer, the Answerer MUST discard all but the first for any
media description. Also, the Answerer MUST discard all
unknown "cs-correlation" attribute values.
</t>
<t>
If the Answerer becomes the active party, it MUST
add any of the "callerid", "uuie" or "dtmf"
subfield values.
</t>
<t>
If the Answerer becomes the passive party, it MUST NOT add
values to the "callerid", "uuie" and/or "dtmf" subfields.
</t>
<t>
After generating and sending the Answer, if the Answerer
became the active party, it
<list style="symbols">
<t>MUST extract the E.164 number from the "c=" line
of the Offer and MUST establish a circuit-switched
bearer to that address.</t>
<t>if the SDP Answer contained a value for the
"callerid" subfield, MUST set the Calling Party Number
Information Element to that number,</t>
<t>if the SDP Answer contained a value for the "uuie"
subfield, MUST send the User-User Information element
according to the rules defined for the circuit-switched
technology used, and set the value of the Information
Element to that received in the SDP Offer,</t>
<t>if the SDP Answer contained a value for the "dtmf"
subfield, MUST send those DTMF digits according to
the circuit-switched technology used.</t>
</list>
</t>
<t>
If, on the other hand, the Answerer became the passive
party, it
<list style="symbols">
<t>MUST be prepared to receive a circuit-switched
bearer,</t>
<t>if the Offer contained a value for the "callerid"
subfield, MUST compare that value to the
Calling Party Number Information Element of the
circuit-switched bearer,</t>
<t>if the Offer contained a value for the "dtmf"
subfield, MUST be prepared to receive and collect DTMF digits
once the circuit-switched bearer is set up. The Answerer
MUST compare the received DTMF digits to the value of
the "dtmf" subfield. If the received DTMF digits match
the value of the "dtmf" subfield in the
"cs-correlation" attribute, the call SHOULD be treated
as correlated to the ongoing session.</t>
<t>if the Offer contained a value for the "uuie"
subfield, MUST be prepared to receive a User-User Information
element once the circuit-switched bearer is set up. The
Answerer MUST compare the received UUI to the value of
the "uuie" subfield. If the value of the received UUI
matches the value of the "uuie" subfield, the call
SHOULD be treated as correlated to the ongoing
session.</t>
</list>
</t>
<t>
If the Answerer becomes the active party, generates an SDP
answer, and then it finds out that the circuit-switched
call cannot be established, then such endpoint MUST create
a new SDP offer where circuit-switched stream is removed
from the session (actually, by setting the corresponding
port in the m= line to zero) and send it to its counter
part. This is to synchronize both parties (and potential
intermediaries) on the state of the session.
</t>
</section>
<section title="Offerer processing the Answer">
<t>
When receiving the Answer, if the SDP does
not contain "a=cs-correlation" attribute line, the Offerer
should take that as an indication that the other party
does not support or is not willing to use the procedures
defined in the document for this session, and MUST revert
to normal processing of SDP.
</t>
<t>
When receiving the Answer, the Offerer MUST first
determine whether it becomes the active or passive
party, as described in Section <xref
target="sec-connection-direction"/>.
</t>
<t>
If the Offerer becomes the active party, it
<list style="symbols">
<t>MUST extract the E.164 number from the "c=" line
and MUST establish a circuit-switched bearer to that
address. </t>
<t>if the SDP Answer contained a value for the "uuie"
subfield, MUST send the User-User Information element
according to the rules defined for the circuit-switched
technology used, and set the value of the Information
Element to that received in the SDP Answer,</t>
<t>if the SDP Answer contained a value for the "dtmf"
subfield, MUST send those DTMF digits according to the
circuit-switched technology used.</t>
</list>
</t>
<t>
If the Offerer becomes the passive party, it
<list style="symbols">
<t>MUST be prepared to receive a circuit-switched
bearer,</t>
<t>Note that it if deliver of the Answer is
delayed for some reason, the circuit-switched call may
arrive at the Offerer before the Answer has been
processed. In this case, since the correlation
mechanisms are negotiated as part of the Offer/Answer
exchange, the Answerer cannot know whether the incoming
call attempt is correlated with the session being
negotiated, the Offerer SHOULD accept the call only
after it has received and processed the Answer.</t>
<t>if the Answer contained a value for the "dtmf"
subfield, MUST be prepared to receive and collect DTMF digits
once the circuit-switched bearer is set up. The Offerer
SHOULD compare the received DTMF digits to the value of
the "dtmf" subfield. If the received DTMF digits match
the value of the "dtmf" subfield in the
"cs-correlation" attribute, the call SHOULD be treated
as correlated to the ongoing session.</t>
<t>if the Answer contained a value for the "uuie"
subfield, MUST be prepared to receive a User-User Information
element once the circuit-switched bearer is set up. The
Offerer SHOULD compare the received UUI to the value of
the "uuie" subfield. If the value of the received UUI
matches the value of the "uuie" subfield, the call
SHOULD be treated as correlated to the ongoing
session.</t>
</list>
</t>
</section>
<section title="Modifying the session">
<t>
If, at a later time, one of the parties wishes to modify
the session, e.g., by adding new media stream, or by
changing properties used on an existing stream, it may do
so via the mechanisms defined for <xref
target="RFC3264">An Offer/Answer Model with SDP</xref>.
</t>
<t>
If there is an existing circuit-switched bearer between
the endpoints, and the Offerer wants to reuse that the
Offerer MUST set the value of the "a=connection" attribute
to 'existing'.
</t>
<t>
If either party removes the circuit-switched media from
the session (by setting the port number to zero), it MUST
terminate the circuit-switched bearer using whatever
mechanism is appropriate for the technology in question.
</t>
<t>
If either party wishes to drop and reestablish an existing
call, that party MUST first remove the circuit-switched
media from the session by setting the port number to zero,
and then use another Offer/Answer exchange where it MUST
set the "a=connection" attribute to 'new'". If the media
types are different (for example, a different codec will
be used for the circuit-switched bearer), the media
descriptions for terminating the existing bearer and the
new bearer can be in the same Offer.
</t>
</section>
</section>
<section title="Formal Syntax" anchor="sec-syntax">
<t>
The following is the formal <xref target="RFC5234">
Augmented Backus-Naur Form (ABNF) </xref> syntax that
supports the extensions defined in this specification. The
syntax is built above the <xref target="RFC4566"> SDP
</xref> and the <xref target="RFC3966">tel URI </xref>
grammars. Implementations according to this specification
MUST be compliant with this syntax.
</t>
<t>
<xref target="fig-sdp-syntax"/> shows the formal syntax of the
extensions defined in this memo.
</t>
<figure anchor="fig-sdp-syntax" title="Syntax of the SDP
extensions"><artwork type="abfn"><![CDATA[
; extension to the connection field originally specified
; in RFC 4566
connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF]
;nettype and addrtype are defined in RFC 4566
connection-address /= global-number / "-"
; global-number specified in RFC 3966
;subrules for correlation attribute
attribute /= cs-correlation-attr
; attribute defined in RFC 4566
cs-correlation-attr= "cs-correlation:" corr-mechanisms
corr-mechanisms = corr-mech *(SP corr-mech)
corr-mech = caller-id-mech / uuie-mech /
dtmf-mech / ext-mech
caller-id-mech = "callerid" [":" caller-id-value]
caller-id-value = "+" 1*15DIGIT
uuie-mech = "uuie" [":" uuie-value]
uuie-value = 1*65(HEXDIG HEXDIG)
;This represents up to 130 HEXDIG (65 octets)
;HEXDIG defined in RFC5234
;HEXDIG defined as 0-9, A-F
dtmf-mech = "dtmf" [":" dtmf-value]
dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A )
;0-9, A-D, '#' and '*'
ext-mech = ext-mech-name[":" ext-mech-value]
ext-mech-name = token
ext-mech-value = token
; token is specified in RFC4566
]]></artwork></figure>
</section>
</section>
<section title="Examples" anchor="sec-sdp-examples">
<t>
In the examples below, where an SDP line is too long to be
displayed as a single line, a breaking character "\" indicates
continuation in the following line. Note that this
character is included for display purposes
only. Implementation MUST write a single line without breaks.
</t>
<section title="Single PSTN audio stream"
anchor="sec-sdp-simple-exsample">
<figure anchor="fig-example-basic-flow" title="Basic flow" align="center">
<artwork><![CDATA[
Alice Bob
| |
| (1) SDP Offer (PSTN audio) |
|--------------------------------->|
| |
| (2) SDP Answer (PSTN audio) |
|<---------------------------------|
| |
| PSTN call setup |
|<---------------------------------|
| |
|<==== media over PSTN bearer ====>|
| |
]]></artwork>
</figure>
<t>
<xref target="fig-example-basic-flow"/> shows a basic
example that describes a single audio media stream over a
circuit-switched bearer. Alice generates a SDP Offer which
is shown in <xref
target="fig-example-basic-flow-offer-1"/>. The Offer
describes a PSTN circuit-switched bearer in the "m=" and
"c=" line where it also
indicates its international E.164 number
format. Additionally, Alice expresses that
she can initiate the circuit-switched
bearer or be the recipient of it in the "a=setup"
attribute line. The SDP Offer also includes
correlation identifiers that this endpoint will
insert in the Calling Party Number and/or User-User
Information Element of the PSTN call setup if eventually
this endpoint initiates the PSTN call.
</t>
<figure title="SDP offer (1)" anchor="fig-example-basic-flow-offer-1"><artwork><![CDATA[
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +35891234567
a=setup:actpass
a=connection:new
a=cs-correlation:callerid:+15551234 \
uuie:56A390F3D2B7310023
]]></artwork></figure>
<t>
Bob generates a SDP Answer (<xref
target="fig-example-basic-flow-answer-1"/>), describing a
PSTN audio media on
port 9 without information on the media sub-type on the "m="
line. The "c=" line contains Bob's international E.164
number. In the "a=setup" line Bob indicates
that he is willing to become the active endpoint when
establishing the PSTN call, and he also includes the
"a=cs-correlation" attribute line containing the values he is
going to include in the Calling Party Number and User-User
IE of the PSTN call establishment.
</t>
<figure title="SDP Answer with circuit-switched media"
anchor="fig-example-basic-flow-answer-1"><artwork><![CDATA[
v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7
s=
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +35897654321
a=setup:active
a=connection:new
a=cs-correlation:callerid:+15554321 \
uuie:56A390F3D2B7310023
]]></artwork></figure>
<t>
When Alice receives the Answer, she examines that Bob is
willing to become the active endpoint when setting up the PSTN
call. Alice temporarily stores Bob's E.164 number and the
User-User IE value of the "cs-correlation" attribute, and
waits for a circuit-switched bearer establishment.
</t>
<t>
Bob initiates a circuit-switched bearer using whatever
circuit-switched technology is available for him. The called
party number is set to Alice's number, and calling party
number is set to Bob's own number. Bob also sets the User-User
Information Element value to the one contained in the SDP Answer.
</t>
<t>
When Alice receives the circuit-switched bearer establishment,
she examines the UUIE and the calling party number, and by
comparing those received during O/A exchange determines that
the call is related to the SDP session.
</t>
<t>
It may also be that neither the UUIE nor the calling party
number is received by the called party, or the format of the
calling party number is changed by the PSTN. Implementations
may still accept such call establishment attempts as being
related to the session that was established in the IP
network. As it cannot be guaranteed that the values used for
correlation are always passed intact through the network, they
should be treated as additional hints that the
circuit-switched bearer is actually related to the session.
</t>
</section>
<section title="Advanced SDP example: Circuit-Switched Audio
and Video Streams" anchor="sec-example-audio-and-video">
<figure anchor="fig-example-cs-audio-video-flow" title="Circuit-Switched
Audio and
Video streams" align="center">
<artwork><![CDATA[
Alice Bob
| |
| (1) SDP Offer (PSTN audio and video) |
|------------------------------------------->|
| |
| (2) SDP Answer (PSTN audio) |
|<-------------------------------------------|
| |
| PSTN call setup |
|<-------------------------------------------|
| |
|<======== media over PSTN bearer ==========>|
| |
]]></artwork></figure>
<t>
<xref target="fig-example-cs-audio-video-flow"/> shows an
example of negotiating audio and video media streams over
circuit-switched bearers.
</t>
<figure title="SDP offer with circuit-switched audio and video (1)"
anchor="fig-example-cs-audio-video-offer-1"><artwork><![CDATA[
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
a=setup:actpass
a=connection:new
a=cs-correlation:dtmf:112233
c=PSTN E164 +35891234567
m=audio 9 PSTN -
m=video 9 PSTN 34
a=rtpmap:34 H263/90000
]]></artwork></figure>
<t>
Upon receiving the SDP offer descibed in <xref
target="fig-example-cs-audio-video-offer-1"/>, Bob rejects the
video stream as his device does not currently support video,
but accepts the circuit-switched audio stream. As Alice
indicated that she is able to become either the active, or
passive party, Bob gets to select which role he would like to
take. Since the Offer contained the international E.164 number
of Alice, Bob decides that he becomes the active party in
setting up the circuit-switched bearer. Bob includes a new
value in the "dtmf" subfield of the "cs-correlation"
attribute, which he is going send as DTMF tones once the
bearer setup is complete. The Answer is described in <xref
target="fig-example-cs-audio-video-answer-2"/>
</t>
<figure title="SDP answer with circuit-switched audio and video (2)"
anchor="fig-example-cs-audio-video-answer-2"><artwork><![CDATA[
v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7
s=
t=0 0
a=setup:active
a=connection:new
a=cs-correlation:dtmf:332211
c=PSTN E164 +35897654321
m=audio 9 PSTN -
m=video 0 PSTN 34
]]></artwork></figure>
</section>
<!--
<section title="Advanced SDP example: Alternative and IP Circuit-Switched Audio
and Video Streams" anchor="sec-example-alternatives">
<figure anchor="fig-example-alternative-flow" title="Alternative media" align="center">
<artwork><![CDATA[
Alice Bob
(1) SDP Offer (IP and PSTN audio and video)
>
(2) SDP Answer (PSTN audio and video)
<
PSTN call setup
>
<======== media over PSTN bearer ==========>
]]></artwork></figure>
<t>
<xref target="fig-example-alternative-flow"/> shows an
example of negotiating audio and video media streams over IP or
circuit-switched bearers. Using the mechanisms described in
<xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
Capability Negotiation Framework</xref> and extensions
thereof (<xref target="I-D.ietf-mmusic-sdp-media-capabilities">SDP media capabilities
Negotiation</xref> and <xref target="I-D.garcia-mmusic-sdp-misc-cap">SDP Miscellaneous
Capabilities</xref>) it is possible to construct an SDP
offer where audio and video media can be offered
alternatively over IP or circuit-switched bearer.
</t>
old example <figure title="SDP offer with alternative media (1)"
anchor="fig-example-alternative-flow-offer-1"><artwork><![CDATA[
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
m=audio 49170 RTP/AVP 0 8 3
c=IN IP4 192.0.2.5
a=creq:med-v0,ccap-v0
a=mcap:1 PCMU/8000/1
a=mcap:2 PCMA/8000/1
a=mcap:3 GSM/8000/1
a=mcap:4 -
a=tcap:1 RTP/AVP PSTN
a=ccap:1 IN IP4 192.0.2.1
a=ccap:2 PSTN E164 +15551234
a=acap:1 cs-correlation:uuie:56A390F3D2B7310023
a=acap:2 setup:actpass
a=acap:3 connection:new
a=pcfg:1 t=1 m=1,2,3 c=1
a=pcfg:2 t=2 m=4 c=2 a=1,2,3
]]></artwork></figure>
<figure title="SDP offer with alternative media (1)"
anchor="fig-example-alternative-flow-offer-1"><artwork><![CDATA[
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
c=IN IP4 192.0.2.5
a=sescap:1 1,3
a=sescap:2 2,4
a=creq:med-v0,ccap-v0
a=acap:1 cs-correlation:uuie:56A390F3D2B7310023
a=acap:2 setup:actpass
a=acap:3 connection:new
a=tcap:1 PSTN
m=audio 49170 RTP/AVP 0 8 3
a=mcap:1 -
a=ccap:1 PSTN E164 +15551234 9
a=pcfg:1
a=pcfg:2 m=1 t=1 c=1 a=1,2,3
m=video 49174 RTP/AVP 34
a=mcap:2 -
a=ccap:2 PSTN E164 +15551234 9
a=pcfg:3
a=pcfg:4 m=2 t=1 c=2 a=1,2,3
]]></artwork></figure>
<t>
Upon receiving the SDP offer descibed in <xref
target="fig-example-alternative-flow-offer-1"/>, Bob decided
to select the circuit-switched bearer and generates the answer
described in <xref target="fig-example-alternative-flow-answer-2"/>
</t>
old example <figure title="SDP answer with circuit-switched media (2)"
anchor="fig-example-alternative-flow-answer-2"><artwork><![CDATA[
v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7
s=
t=0 0
m=audio - PSTN -
c=PSTN - -
a=acfg:2
a=setup:active
a=connection:new
a=cs-correlation:uuie:56A390F3D2B7310023
]]></artwork></figure>
<figure title="SDP answer with circuit-switched media (2)"
anchor="fig-example-alternative-flow-answer-2"><artwork><![CDATA[
v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7
s=
t=0 0
a=setup:active
a=connection:new
a=cs-correlation:uuie:56A390F3D2B7310023
m=audio 9 PSTN -
c= PSTN E164 +1551234
m=video 9 PSTN -
c=PSTN E164 +1551234
a=acfg:2
]]></artwork></figure>
</section>
-->
</section>
<section title="Security Considerations" anchor="sec-security">
<t>
This document provides an extension on top of <xref
target="RFC4566">RFC 4566 </xref>, and <xref target="RFC3264">RFC
3264 </xref>. As such, the security considerations of those
documents apply.
</t>
<t>
This memo provides mechanisms to agree on a correlation
identifier or identifiers that are used to evaluate whether an
incoming circuit-switched bearer is related to an ongoing
session in the IP domain. If an attacker replicates the
correlation identifer and establishes a call within the time
window the receiving endpoint is expecting a call, the
attacker may be able to hijack the circuit-switched
bearer. These types of attacks are not specific to the
mechanisms presented in this memo. For example, caller ID
spoofing is a well known attack in the PSTN. Users are advised
to use the same caution before revealing sensitive information
as they would on any other phone call. Furthermore, users
are advised that mechanisms that may be in use in the IP
domain for securing the media, like Secure RTP (SRTP) <xref
target="RFC3711"/>, are not available in the CS domain.
</t>
<t>
For the purposes of establishing a circuit-switched bearer,
the active endpoint needs to know the passive endpoint's phone
number. Phone numbers are sensitive information, and some
people may choose not to reveal their phone numbers when
calling using supplementary services like Calling Line
Identification Restriction (CLIR) in GSM. Implementations
should take the caller's preferences regarding calling line
identification into account if possible, by restricting the
inclusion of the phone number in SDP "c=" line if the caller
has chosen to use CLIR. If this is not possible,
implementations may present a prompt informing the user
that their phone number may be transmitted to the other
party.
</t>
<t>
Similarly as with IP addresses, if there is a desire the
protect the SDP containing phone numbers carried in SIP,
implementers are adviced to follow the security mechanisms
defined in <xref target="RFC3261"/>.
</t>
<t>
It is possible that an attacker creates a circuit-switched
session whereby the attacked endpoint should dial a
circuit-switched number, perhaps even a premium-rate telephone
number. To mitigate the consequences of this attack, endpoints
MUST authenticate and trust remote endpoints users who try to
remain passive in the circuit-switched connection
establishment. It is RECOMMENDED that endpoints have local
policies precluding the active establishment of circuit
switched connections to certain numbers (e.g., international,
premium, long distance). Additionally, it is strongly
RECOMMENDED that the end user is asked for consent prior to
the endpoint initiating a circuit-switched connection which
might incur in charges.
</t>
</section>
<section title="IANA Considerations" anchor="sec-iana">
<t>
This document instructs IANA to register a number of SDP
tokens according to the following data.
</t>
<section title="Registration of new cs-correlation SDP attribute">
<t>
<list>
<t>Contact: Miguel Garcia <miguel.a.garcia@ericsson.com></t>
<t>Attribute name: cs-correlation</t>
<t>Long-form attribute name: PSTN Correlation Identifier</t>
<t>Type of attribute: media level only</t>
<t>This attribute is subject to the charset attribute</t>
<t>Description: This attribute provides the Correlation
Identifier used in PSTN signaling</t>
<t>Specification: RFC XXXX</t>
</list>
</t>
<t>
The IANA is requested to create a subregistry for
'cs-correlation' attribute under the Session Description
Protocol (SDP) Parameters registry. The initial values for
the subregistry are presented in the following, and IANA is
requested to add them into its database:
</t>
<t>
Value of 'cs-correlation' attribute Reference Description
----------------------------------- --------- -----------
callerid RFC XXXX Caller ID
uuie RFC XXXX User-User Information Element
dtmf RFC XXXX Dual-tone Multifrequency
</t>
<t>
Note for the RFC Editor: 'RFC XXXX' above should be replaced
by a reference to the RFC number of this draft.
</t>
<t>
As per the terminology in <xref target="RFC5226"/>, the
registration policy for new values of 'cs-correlation'
parameter is 'Specification Required'.
</t>
</section>
<section title="Registration of a new "nettype" value"
anchor="sec-iana-nettype">
<t>
This memo provides instructions to IANA to register a new
"nettype" in the <eref
target="http://www.iana.org/assignments/sdp-parameters">Session
Description Protocol Parameters registry </eref>. The
registration data, according to <xref target="RFC4566">RFC
4566</xref> follows.
</t>
<figure><artwork>
Type SDP Name Reference
---- ------------------ ---------
nettype PSTN [RFCxxxx]
</artwork></figure>
</section>
<section title="Registration of new "addrtype" values"
anchor="sec-iana-addrtype">
<t>
This memo provides instructions to IANA to register a new
"addrtype" in the <eref
target="http://www.iana.org/assignments/sdp-parameters">Session
Description Protocol Parameters registry </eref>. The
registration data, according to <xref target="RFC4566">RFC
4566</xref> follows.
</t>
<figure><artwork>
Type SDP Name Reference
---- ------------------ ---------
addrtype E164 [RFCxxxx]
- [RFCxxxx]
</artwork></figure>
<t>
Note: RFC XXXX uses the "E164" and "-" addrtypes in
conjunction with the "PSTN" nettype. Please refer to the
relevant RFC for a description of that representation.
</t>
</section>
<section title="Registration of a new "proto" value"
anchor="sec-iana-proto">
<t>
This memo provides instructions to IANA to register a new
"proto" in the <eref
target="http://www.iana.org/assignments/sdp-parameters">Session
Description Protocol Parameters registry </eref>. The
registration data, according to <xref target="RFC4566">RFC
4566</xref> follows.
</t>
<figure><artwork>
Type SDP Name Reference
-------------- --------------------------- ---------
proto PSTN [RFCxxxx]
</artwork></figure>
<t>
The related "fmt" namespace re-uses the conventions and
payload type number defined for RTP/AVP. In this document,
the RTP audio and video media types, when applied to PSTN
circuit-switched bearers, represent merely on audio or video
codec.
</t>
</section>
</section>
<section title="Acknowledgments" anchor="sec-acks">
<t>
The authors want to thank Paul Kyzivat, Flemming Andreasen,
Thomas Belling, John Elwell, Jari Mutikainen, Miikka
Poikselka, Jonathan Rosenberg, Ingemar Johansson, Christer
Holmberg, and Alf Heidermark for providing their insight and
comments on this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2434" ?>
<?rfc include="reference.RFC.3108" ?>
<?rfc include="reference.RFC.3264" ?>
<?rfc include="reference.RFC.3966" ?>
<?rfc include="reference.RFC.4145" ?>
<?rfc include="reference.RFC.4566" ?>
<?rfc include="reference.RFC.5226" ?>
<?rfc include="reference.RFC.5234" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3550" ?>
<?rfc include="reference.RFC.3551" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.3725" ?>
<?rfc include="reference.RFC.4975" ?>
<?rfc include="reference.RFC.3711" ?>
<?rfc include="reference.ITU.E164.1991" ?>
<?rfc include="reference.ITU.Q931.1998" ?>
<?rfc include="reference.I-D.ietf-cuss-sip-uui" ?>
<reference anchor="TS.24.008">
<front>
<title>
Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3
</title>
<author>
<organization>
3GPP
</organization>
</author>
<date day="15" month="December" year="2005"/>
</front>
<seriesInfo name="3GPP TS" value="24.008 3.20.0"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:22:21 |