Session Description Protocol (SDP) Extension For Setting Up
Audio and Video Media Streams Over Circuit-Switched Bearers In
The Public Switched Telephone Network (PSTN)
EricssonCalle Via de los Poblados 13MadridES28033Spainmiguel.a.garcia@ericsson.comNokiaP.O. Box 226NOKIA GROUPFI00045Finland+358 50 486 4463 simo.veikkolainen@nokia.com
RAI
MMUSIC WGI-DInternet-DraftPSTN
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).
The Session Description Protocol
(SDP) 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 Real-Time
Transport Protocol (RTP), using the profiles for audio
and video media defined in RTP Profile
for Audio and Video Conferences with Minimal Control.
However, SDP can be used to describe other transport protocols
than RTP. Previous work includes SDP
conventions for describing ATM bearer connections and
the Message Session Relay
Protocol.
SDP is commonly carried in Session
Initiation Protocol (SIP) messages in order to agree on
a common media description among the endpoints. An Offer/Answer Model with Session
Description Protocol (SDP) 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.
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 Session Initiation
Protocol (SIP) ) are used over regular IP connectivity,
while the audio or video is received through the classical
circuit-switched bearer.
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.
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 leads to a re-negotiation of the media
streams.
Other use cases exist. For example, an 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.
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.
The rest of the document is structured as follows: provides the document conventions,
introduces the requirements,
presents an overview of the
proposed solutions, and contains the protocol
description. provides an
example of descriptions of circuit-switched audio or
video streams in SDP. and contain the Security and IANA
considerations, respectively.
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, RFC
2119 and indicate requirement levels for compliant
implementations.
This section presents the general requirements that are specific for
the audio or video media streams over circuit-switched bearers.
A mechanism for endpoints to negotiate and agree on an audio
or video media stream established over a circuit-switched
bearer MUST be available.
The mechanism MUST allow the endpoints to combine
circuit-switched audio or video media streams with other
complementary media streams, for example, text messaging.
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.
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.)
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.
It MUST be possible for endpoints to advertise different
lists of audio or video codecs in the circuit-switched audio
or video stream from those used in a packet-switched audio
or video stream.
It MUST be possible for endpoints to not advertise the list
of available codecs for circuit-switched audio or video
streams.
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 . Since
circuit-switched bearers are connection-oriented media
streams, the mechanism re-uses the connection-oriented
extensions defined in RFC 4145
to negotiate the active and passive sides of a connection
setup. This is further described in .
Consider the example presented in . 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.
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.
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.
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.
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.
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 RFC3264. Also, if Bob does not
understand some of the SDP attributes specified in this
document, he would ignore them, as specified in
RFC4566.
Implementations according to this specification MUST
implement the SDP extensions described in
, and MUST implement the
considerations discussed in , and .
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.
According to SDP, the
connection data line in SDP has the following syntax:
c=<nettype> <addrtype> <connection-address>
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.
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.
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.
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
ITU-T E.164
recommendation.
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.
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.
Please note that these "E164" and "-" address types
defined in this memo are exclusively defined to be used in
conjunction with the "PSTN" network type in accordance
with . Usage of "E164"
or "-" address types in conjunction with other network
types may be defined elsewhere.
This memo exclusively uses the international
representation of E.164 numbers, i.e., those including a
country code and, as described above prepended
with a '+' sign. Implementations conforming to this
specification and using the "E164" address type together
with the "PSTN" network type MUST use the
'global-number-digits' construction specified in
RFC 3966 for representing
international E.164 numbers. This
representation requires the presence of the '+'
sign, and additionally allows for the
presence of one or more 'visual-separator' constructions
for easier human readability (see ).
Note that <addrtype> and/or
<connection-address> MUST NOT be omitted when
unknown since this would violate basic syntax of SDP. In such cases, they MUST be
set to a "-".
The following are examples of the extension to the
connection data line:
c=PSTN E164 +441134960123
c=PSTN - -
When the <addrtype> is PSTN, the connection address
is defined as follows:
an international E.164 number
When the <addrtype> is "-", the connection address
is defined as follows:
the value "-", signifying that the address is
unknownany syntactically valid value, which is to be
ignored
According to SDP, the
media description line in SDP has the following syntax:
m=<media> <port> <proto> <fmt> ...
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.
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.
According to RFC 3264 , 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.
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 SDP and to indicate the usage of
circuit-switched protocols in the PSTN.
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 RTP audio profile.
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. The
endpoint SHOULD only use those payload type whose
corresponding codecs is available for PSTN media streams.
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 SDP , the
endpoint MUST include a single dash ("-") in the <fmt>
subfield.
As per RFC 4566, the media
format descriptions are listed in priority order.
Examples of media descriptions for circuit-switched audio
streams are:
m=audio 9 PSTN 3 0 8
m=audio 9 PSTN -
Similarly, an example of a media description for
circuit-switched video stream is:
m=video 9 PSTN 34
m=video 9 PSTN -
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).
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.
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.
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.
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.
In order to provide support for the correlation
mechanisms, we define a new media-level 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
for more details. There MUST be at most one
"cs-correlation" attribute per media description.
The following sections provide more detailed information
of these subfields. > defined
the formal syntax.
The values "callerid", "uuie" and "dtmf" refer to the
correlation mechanisms defined in , , and , respectively. The formal
Augmented Backus-Naur Format (ABNF) syntax of the
"cs-correlation" attribute is presented in .
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.
Example of inclusion of an international E.164 number in
the "cs-correlation" attribute is:
a=cs-correlation:callerid:+441134960123
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.
Note that there are no guarantees that this
correlation mechanism works or is even available, due a
number of problems:
The endpoint might not be aware of its own E.164
number, in which case it cannot populate the SDP
appropriately.
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.
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, due to,
e.g., lack of of country code. To mitigate this
problem implementations should consider only some of
the rightmost digits from the E.164 number for
correlation. For example, the numbers
+44-113-496-0123 and 0113-496-0123 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. Please refer to ITU-T E.164 reccommendation
for consideration of the relevant number of
digits to consider.
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 ITU-T Q.931 and 3GPP TS 24.008, 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.
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.
According to ITU-T
Q.931, 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.
Once the binary value of the "uuie" subfield in the
"cs-correlation" attribute is created, it MUST be base 16
(also known as "hex") encoded before it is inserted in
SDP. Please refer to RFC
4648 for a detailed description of base 16
encoding. The resulting encoded value needs to have an
even number of hexadecimal digits, and MUST be
considered invalid if it has an odd number.
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 "A Mechanism for
Transporting User to User Call Control Information
in SIP".
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:
a=cs-correlation:uuie:56A390F3D2B7310023
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.
Please note that there are no guarantees 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.
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.
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.
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. A
number of 5 to 10 digits is a good compromise.
As an example, an endpoint willing to send DTMF tone
sequence "14D*3" would include a "cs-correlation" attribute
line as follows:
a=cs-correlation:dtmf:14D*3
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 consider that this DTMF
mechanism has failed to correlate the incoming call.
New values for the "cs-correlation" attribute may be
specified. The registration policy for new values
is "Specification Required", see . 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 for more details).
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.
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.
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.
The framework defined in RFC
4145 allows the endpoints to agree which endpoint
acts as the active endpoint when initiating a TCP
connection. While RFC 4145
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 RFC 4145 for agreeing on the
direction of establishment of a circuit-switched bearer.
RFC 4145 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 RFC 4145 : "active", "passive",
"actpass", "holdconn". Please refer to Section 4 of RFC 4145 for a detailed description
of this attribute.
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 RFC 4145 for a detailed description
of this attribute.
Implementations according to this specification MUST support
the "setup" and "connection" attributes specified in RFC 4145 , but applied to
circuit-switched bearers in the PSTN.
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 .
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.
Thus, the following rules apply:
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.
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.
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.
Passive endpoints should expect an incoming CS call for
setting up the audio bearer. Passive endpoints MAY
suppress the incoming CS alert during a certain time
periods. Additional restrictions can be applied, such as
the passive endpoint not alerting incoming calls
originated from the number that was observed uduring the
offer/answer negotiation.
Note that 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.
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.
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.
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.
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.
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.
According to SDP, the
origin line in SDP has the following syntax:
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
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.
SDP 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.
Best Current Practices for Third
Party Call Control (3pcc) in the Session Initiation
Protocol (SIP) outlines several flows which are
possible in third party call control scenarios and
recommends some flows for specific situations.
One of the assumptions in 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.
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.
Note that this may result in the recipient of the
initial offer rejecting such offer if the recipient of
the offer was not aware of its own E.164
number. Consequently it will not be possible to
establish a circuit-switched bearer, since neither
party is aware of their E.164 number.
In this section, we define extensions to the Offer/Answer
model defined in The Offer/Answer
Model in SDP to allow for PSTN addresses to
be used with the Offer/Answer model.
The Offerer, wishing to use PSTN audio or video stream,
MUST populate the "c=" and "m=" lines as follows.
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 "-".
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).
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 on the PSTN media stream. For example, if the
endpoint wishes to use the GSM codec, it would add payload
type number 3 in the list of codecs. The list of payload
types SHOULD only contain those codecs the endpoint is
able to use on the PSTN bearer. In case the endpoint is
not aware of the codecs available for the circuit-switched
media streams, it MUST include a dash ("-") in the
<fmt> subfield.
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 SDP for details.
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.
The current list of subfields
include "callerid", "uuie" and "dtmf" and they refer to the
correlation mechanisms defined in , , and
, respectively.
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.
the international E.164 number as the value in the
"callerid" subfield,the contents of the User-User information element as
the value of the "uuie" subfield, and/orthe DTMF tone string as the value of the "dtmf"
subfield
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.
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 in the SDP:
a=cs-correlation:uuie dtmfa=setup:passive
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 the following lines in the SDP:
a=cs-correlation:uuie:56A390F3D2B7310023 dtmf:14D*3a=setup:actpass
The negotiation of the value of the 'setup' attribute
takes place as defined in Section 4.1 of TCP-Based Media Transport in the
SDP.
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.
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.
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'.
Also 'holdconn' is a permissible value in the 'a=setup'
attribute. It indicates that the connection is not
established for the time being.
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'.
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
An Offer/Answer Model with the
Session Description Protocol (SDP). 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).
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.
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.
When receiving the Offer, the Answerer MUST
determine whether it becomes the active or passive
party.
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 on the "c=" line.
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.
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.
For each media description where the Offer includes a
"a=cs-correlation" attribute, the Answerer MUST select
from the Offer those correlation mechanisms it supports,
and include in the Answer one "a=cs-correlation" attribute
line containing those mechanisms it is willing to use. The
Answerer MUST only add one "a=cs-correlation" attribute in
those media descriptions where also the Offer included a
"a=cs-correlation" attribute. 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.
If the Answerer becomes the active party, it MUST
add any of the "callerid", "uuie" or "dtmf"
subfield values.
If the Answerer becomes the passive party, it MUST NOT add
values to the "callerid", "uuie" and/or "dtmf" subfields.
After generating and sending the Answer, if the Answerer
became the active party, it
MUST extract the E.164 number from the "c=" line
of the Offer and MUST establish a circuit-switched
bearer to that address.if the SDP Answer contained a value for the
"callerid" subfield, MUST set the Calling Party Number
Information Element to that number,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,if the SDP Answer contained a value for the "dtmf"
subfield, MUST send those DTMF digits according to
the circuit-switched technology used.
If, on the other hand, the Answerer became the passive
party, it
MUST be prepared to receive a circuit-switched
bearer,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,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.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.
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 the Answerer 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
counterpart. This is to synchronize both parties (and
potential intermediaries) on the state of the session.
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.
When receiving the Answer, the Offerer MUST first
determine whether it becomes the active or passive
party, as described in .
If the Offerer becomes the active party, it
MUST extract the E.164 number from the "c=" line
and MUST establish a circuit-switched bearer to that
address. 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,if the SDP Answer contained a value for the "dtmf"
subfield, MUST send those DTMF digits according to the
circuit-switched technology used.
If the Offerer becomes the passive party, it
MUST be prepared to receive a circuit-switched
bearer,Note that if delivery of the Answer is delayed for
some reason, the circuit-switched call attempt 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 or not the
incoming circuit-switched call attempt is correlated
with the session being negotiated, the Offerer SHOULD
answer the circuit-switched call attempt only after it
has received and processed the Answer.If the Answer contained a value for the "dtmf"
subfield, the Offerer 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.If the Answer contained a value for the "uuie"
subfield, the Offerer 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.
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 An Offer/Answer Model with SDP.
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'.
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.
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.
The following is the formal
Augmented Backus-Naur Form (ABNF) syntax that
supports the extensions defined in this specification. The
syntax is built above the SDP
and the tel URI
grammars. Implementations according to this specification
MUST be compliant with this syntax.
shows the formal syntax of the
extensions defined in this memo.
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. Implementations MUST write a single line without breaks.
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 . 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.
Bob generates a SDP Answer (), 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.
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.
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.
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.
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.
shows an
example of negotiating audio and video media streams over
circuit-switched bearers.
Upon receiving the SDP offer described in , 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 to send as DTMF tones once the
bearer setup is complete. The Answer is described in
This document provides an extension on top of RFC 4566 , and RFC
3264 . As such, the security considerations of those
documents apply.
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 identifier 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 wellknown 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) , are not available in the CS domain.
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.
Similarly as with IP addresses, if there is a desire to
protect the SDP containing phone numbers carried in SIP,
implementers are advised to follow the security mechanisms
defined in .
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.
This document instructs IANA to register a number of SDP
tokens according to the following data.
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>Attribute name: cs-correlationLong-form attribute name: PSTN Correlation IdentifierType of attribute: media level onlySubject to charset: NoDescription: This attribute provides the Correlation
Identifier used in PSTN signalingAppropriate values:see Specification: RFC XXXX
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:
Note for the RFC Editor: 'RFC XXXX' above should be replaced
by a reference to the RFC number of this draft.
As per the terminology in , the
registration policy for new values of 'cs-correlation'
parameter is 'Specification Required'.
This memo provides instructions to IANA to register a new
"nettype" in the Session
Description Protocol Parameters registry . The
registration data, according to RFC
4566 follows.
This memo provides instructions to IANA to register two new
"addrtype" in the Session
Description Protocol Parameters registry . The
registration data, according to RFC
4566 follows.
Note: RFC XXXX defines the "E164" and "-" addrtypes in
conjunction with the "PSTN" nettype only. Please refer to the
relevant RFC for a description of that representation.
Note to IANA: The current "addrtype" sub-registry structure
does not capture the fact that a given addrtype is defined in
the context of a particular "nettype". The sub-registry
structure should be to correct that as part of this registration.
This memo provides instructions to IANA to register a new
"proto" in the Session
Description Protocol Parameters registry . The
registration data, according to RFC
4566 follows.
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 an audio or video
codec in its native format directly on top of a single PSTN
bearer.
In come 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 SDP
, the endpoint MUST include a single
dash ("-") in the <fmt> subfield.
The authors want to thank Paul Kyzivat, Flemming Andreasen,
Thomas Belling, John Elwell, Jari Mutikainen, Miikka
Poikselka, Jonathan Rosenberg, Ingemar Johansson, Christer
Holmberg, Alf Heidermark, Tom Taylor, Thomas Belling, Keith
Drage, and Andrew Allen for providing their insight and
comments on this document.
Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3
3GPP