draft-ietf-mmusic-sdp-cs-13.txt   draft-ietf-mmusic-sdp-cs-14.txt 
MMUSIC WG M. Garcia-Martin MMUSIC WG M. Garcia-Martin
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track S. Veikkolainen Intended status: Standards Track S. Veikkolainen
Expires: April 24, 2013 Nokia Expires: May 30, 2013 Nokia
October 21, 2012 November 26, 2012
Session Description Protocol (SDP) Extension For Setting Up Audio and Session Description Protocol (SDP) Extension For Setting Up Audio and
Video Media Streams Over Circuit-Switched Bearers In The Public Switched Video Media Streams Over Circuit-Switched Bearers In The Public Switched
Telephone Network (PSTN) Telephone Network (PSTN)
draft-ietf-mmusic-sdp-cs-13 draft-ietf-mmusic-sdp-cs-14
Abstract Abstract
This memo describes use cases, requirements, and protocol extensions This memo describes use cases, requirements, and protocol extensions
for using the Session Description Protocol (SDP) Offer/Answer model for using the Session Description Protocol (SDP) Offer/Answer model
for establishing audio and video media streams over circuit-switched for establishing audio and video media streams over circuit-switched
bearers in the Public Switched Telephone Network (PSTN). bearers in the Public Switched Telephone Network (PSTN).
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2013. This Internet-Draft will expire on May 30, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions Used in This Document . . . . . . . . . . . . . . 6 2. Conventions Used in This Document . . . . . . . . . . . . . . 6
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 7 4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 9 5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 9
5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 9 5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 9 5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 9
5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 10 5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 11
5.2.3. Correlating the PSTN Circuit-Switched Bearer with 5.2.3. Correlating the PSTN Circuit-Switched Bearer with
SDP . . . . . . . . . . . . . . . . . . . . . . . . . 12 SDP . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 13 5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 13
5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 13 5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 13
5.2.3.3. User-User Information Element Correlation 5.2.3.3. User-User Information Element Correlation
Mechanism . . . . . . . . . . . . . . . . . . . . 14 Mechanism . . . . . . . . . . . . . . . . . . . . 14
5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 16 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 16
5.2.3.5. Extensions to correlation mechanisms . . . . . . . 17 5.2.3.5. Extensions to correlation mechanisms . . . . . . . 17
5.3. Negotiating the correlation mechanisms . . . . . . . . . . 17 5.3. Negotiating the correlation mechanisms . . . . . . . . . . 17
5.3.1. Determining the Direction of the Circuit-Switched 5.3.1. Determining the Direction of the Circuit-Switched
Bearer Setup . . . . . . . . . . . . . . . . . . . . . 17 Bearer Setup . . . . . . . . . . . . . . . . . . . . . 18
5.3.2. Populating the cs-correlation attribute . . . . . . . 18 5.3.2. Populating the cs-correlation attribute . . . . . . . 18
5.3.3. Considerations on successful correlation . . . . . . . 19 5.3.3. Considerations on successful correlation . . . . . . . 19
5.4. Considerations for Usage of Existing SDP . . . . . . . . . 19 5.4. Considerations for Usage of Existing SDP . . . . . . . . . 20
5.4.1. Originator of the Session . . . . . . . . . . . . . . 20 5.4.1. Originator of the Session . . . . . . . . . . . . . . 20
5.4.2. Contact information . . . . . . . . . . . . . . . . . 20 5.4.2. Contact information . . . . . . . . . . . . . . . . . 20
5.5. Considerations for Usage of Third Party Call Control 5.5. Considerations for Usage of Third Party Call Control
(3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 20 (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 21 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 21
5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 21 5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 21
5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 23 5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 23
5.6.3. Offerer processing the Answer . . . . . . . . . . . . 25 5.6.3. Offerer processing the Answer . . . . . . . . . . . . 26
5.6.4. Modifying the session . . . . . . . . . . . . . . . . 27 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 27
5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 27 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 27
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . . 29 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . . 29
6.2. Advanced SDP example: Circuit-Switched Audio and Video 6.2. Advanced SDP example: Circuit-Switched Audio and Video
Streams . . . . . . . . . . . . . . . . . . . . . . . . . 31 Streams . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8.1. Registration of new cs-correlation SDP attribute . . . . . 33 8.1. Registration of new cs-correlation SDP attribute . . . . . 33
8.2. Registration of a new "nettype" value . . . . . . . . . . 34 8.2. Registration of a new "nettype" value . . . . . . . . . . 34
skipping to change at page 6, line 4 skipping to change at page 6, line 4
setting up a circuit-switched call offers also the possibility of setting up a circuit-switched call offers also the possibility of
negotiating in the same session other IP based media that is not negotiating in the same session other IP based media that is not
sensitive to jitter and delay, for example, text messaging or sensitive to jitter and delay, for example, text messaging or
presence information. presence information.
At a later point in time the mobile device might move to an area 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 where a high-bandwidth packet-switched bearer, for example a Wireless
Local Area Network (WLAN) connection, is available. At this point Local Area Network (WLAN) connection, is available. At this point
the mobile device may perform a handover and move the audio or video 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 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 exchange of SDP Offer/Answer that leads to a re-negotiation of the
media streams. media streams.
Other use cases exist. For example, and endpoint might have at its Other use cases exist. For example, an endpoint might have at its
disposal circuit-switched and packet-switched connectivity, but the disposal circuit-switched and packet-switched connectivity, but the
same audio or video codecs are not feasible for both access networks. same audio or video codecs are not feasible for both access networks.
For example, the circuit-switched audio or video stream supports For example, the circuit-switched audio or video stream supports
narrow-bandwidth codecs, while the packet-switched access allows any narrow-bandwidth codecs, while the packet-switched access allows any
other audio or video codec implemented in the endpoint. In this other audio or video codec implemented in the endpoint. In this
case, it might be beneficial for the endpoint to describe different case, it might be beneficial for the endpoint to describe different
codecs for each access type and get an agreement on the bearer codecs for each access type and get an agreement on the bearer
together with the remote endpoint. together with the remote endpoint.
There are additional use cases related to third party call control There are additional use cases related to third party call control
skipping to change at page 7, line 19 skipping to change at page 7, line 19
REQ-4: The mechanism MUST be independent of the type of the circuit- REQ-4: The mechanism MUST be independent of the type of the circuit-
switched access (e.g., Integrated Services Digital Network switched access (e.g., Integrated Services Digital Network
(ISDN), Global System for Mobile Communication (GSM), etc.) (ISDN), Global System for Mobile Communication (GSM), etc.)
REQ-5: There MUST be a mechanism that helps an endpoint to correlate REQ-5: There MUST be a mechanism that helps an endpoint to correlate
an incoming circuit-switched bearer with the one negotiated an incoming circuit-switched bearer with the one negotiated
in SDP, as opposed to another incoming call that is not in SDP, as opposed to another incoming call that is not
related to that. related to that.
REQ-6: It MUST be possible for endpoints to advertise different list REQ-6: It MUST be possible for endpoints to advertise different
of audio or video codecs in the circuit-switched audio or lists of audio or video codecs in the circuit-switched audio
video stream from those used in a packet-switched audio or or video stream from those used in a packet-switched audio or
video stream. video stream.
REQ-7: It MUST be possible for endpoints to not advertise the list REQ-7: It MUST be possible for endpoints to not advertise the list
of available codecs for circuit-switched audio or video of available codecs for circuit-switched audio or video
streams. streams.
4. Overview of Operation 4. Overview of Operation
The mechanism defined in this memo extends SDP and allows describing The mechanism defined in this memo extends SDP and allows describing
an audio or video media stream established over a circuit-switched an audio or video media stream established over a circuit-switched
skipping to change at page 10, line 4 skipping to change at page 10, line 4
recommendation. recommendation.
It is a common convention that an international E.164 number contains It is a common convention that an international E.164 number contains
a leading '+' sign. For consistency's sake, we also require the a leading '+' sign. For consistency's sake, we also require the
E.164 telephone is prepended with a '+', even if that is not E.164 telephone is prepended with a '+', even if that is not
necessary for routing of the call in the PSTN network. necessary for routing of the call in the PSTN network.
There are cases, though, when the endpoint is merely aware of a There are cases, though, when the endpoint is merely aware of a
circuit-switched bearer, without having further information about the circuit-switched bearer, without having further information about the
address type or the E.164 number allocated to it. In these cases a 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 dash ("-") is used to indicate an unknown address type or connection
address. This makes the connection data line be according to the SDP address. This makes the connection data line be according to the SDP
syntax. syntax.
Please note that this "E164" and "-" address type defined in this Please note that these "E164" and "-" address types defined in this
memo are exclusively defined to be used in conjunction with the memo are exclusively defined to be used in conjunction with the
"PSTN" network type. Usages of "E164" or "-" address types in "PSTN" network type in accordance with [RFC4566]. Usage of "E164" or
conjunction with other network types may exist elsewhere. "-" address types in conjunction with other network types may be
defined elsewhere.
This memo exclusively uses the international representation of E.164 This memo exclusively uses the international representation of E.164
numbers, i.e., those initiated with a '+' sign. The syntax (see numbers, i.e., those including a country code and, as described above
Section 5.7) refers to the representation of a 'global-number' prepended with a '+' sign. The syntax (see Section 5.7) refers to
construction already specified in RFC 3966 [RFC3966]. This the representation of a 'global-number' construction already
representation requires the presence of the '+' sign. Additionally, specified in RFC 3966 [RFC3966]. This representation requires the
this representation allows for the presence of one or more 'visual- presence of the '+' sign. Additionally, this representation allows
separator' constructions. Implementations confirming to this for the presence of one or more 'visual-separator' constructions.
specification and using the "E164" address type together with the Implementations conforming to this specification and using the "E164"
"PSTN" network type MUST only use international E.164, i.e., those address type together with the "PSTN" network type MUST only use
starting with a '+' sign and SHOULD NOT use visual-separators. international E.164 representation prepended with a '+' sign.
Note that <addrtype> and/or <connection-address> MUST NOT be Note that <addrtype> and/or <connection-address> MUST NOT be
omitted when unknown since this would violate basic syntax of SDP omitted when unknown since this would violate basic syntax of SDP
[RFC4566]. In such cases, they MUST be set to a "-". [RFC4566]. In such cases, they MUST be set to a "-".
The following are examples of the extension to the connection data The following are examples of the extension to the connection data
line: line:
c=PSTN E164 +35891234567 c=PSTN E164 +441134690123
c=PSTN - - c=PSTN - -
When the <addrtype> is PSTN, the connection address is defined as When the <addrtype> is PSTN, the connection address is defined as
follows: follows:
o an international E.164 number o an international E.164 number
When the <addrtype> is "-", the connection address is defined as When the <addrtype> is "-", the connection address is defined as
follows: follows:
o the value "-", signifying that the address is unknown o the value "-", signifying that the address is unknown
o any syntactically valid value, which is to be ignored o any syntactically valid value, which is to be ignored
5.2.2. Media Descriptions 5.2.2. Media Descriptions
According to SDP [RFC4566], the media descriptions line in SDP has According to SDP [RFC4566], the media description line in SDP has the
the following syntax: following syntax:
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
The <media> subfield carries the media type. For establishing an The <media> subfield carries the media type. For establishing an
audio bearer, the existing "audio" media type is used. For audio bearer, the existing "audio" media type is used. For
establishing a video bearer, the existing "video" media type is used. establishing a video bearer, the existing "video" media type is used.
The <port> subfield is the transport port to which the media stream The <port> subfield is the transport port to which the media stream
is sent. Circuit-switched access lacks the concept of a port number, is sent. Circuit-switched access lacks the concept of a port number,
and therefore the <port> subfield does not carry any meaningful and therefore the <port> subfield does not carry any meaningful
skipping to change at page 11, line 43 skipping to change at page 11, line 48
subfield is set to "RTP/AVP" or "RTP/SAVP", the <fmt> subfield subfield is set to "RTP/AVP" or "RTP/SAVP", the <fmt> subfield
contains the payload types as defined in the RTP audio profile contains the payload types as defined in the RTP audio profile
[RFC3551]. [RFC3551].
When "RTP/AVP" is used in the <proto> field, the <fmt> subfield When "RTP/AVP" is used in the <proto> field, the <fmt> subfield
contains the RTP payload type numbers. We use the <fmt> subfield to contains the RTP payload type numbers. We use the <fmt> subfield to
indicate the list of available codecs over the circuit-switched indicate the list of available codecs over the circuit-switched
bearer, by re-using the conventions and payload type numbers defined bearer, by re-using the conventions and payload type numbers defined
for RTP/AVP. The RTP audio and video media types, which, when for RTP/AVP. The RTP audio and video media types, which, when
applied to PSTN circuit-switched bearers, represent merely an audio applied to PSTN circuit-switched bearers, represent merely an audio
or video codec. 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 In some cases, the endpoint is not able to determine the list of
available codecs for circuit-switched media streams. In this case, available codecs for circuit-switched media streams. In this case,
in order to be syntactically compliant with SDP [RFC4566], the in order to be syntactically compliant with SDP [RFC4566], the
endpoint MUST include a single dash "-" in the <fmt> subfield. endpoint MUST include a single dash ("-") in the <fmt> subfield.
As per RFC 4566 [RFC4566], the media format descriptions are listed As per RFC 4566 [RFC4566], the media format descriptions are listed
in priority order. in priority order.
Examples of media descriptions for circuit-switched audio streams Examples of media descriptions for circuit-switched audio streams
are: are:
m=audio 9 PSTN 3 0 8 m=audio 9 PSTN 3 0 8
m=audio 9 PSTN - m=audio 9 PSTN -
skipping to change at page 12, line 47 skipping to change at page 13, line 4
between the endpoints. The caller-ID is also available as the between the endpoints. The caller-ID is also available as the
Calling Party ID in the circuit-switched signaling. Calling Party ID in the circuit-switched signaling.
The second mechanism is based on the inclusion in SDP of a value that 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 is also sent in the User-to-User Information Element that is part of
the bearer setup signaling in the PSTN. the bearer setup signaling in the PSTN.
The third mechanism is based on sending in SDP a string that The third mechanism is based on sending in SDP a string that
represents Dual Tone MultiFrequency (DTMF) digits that will be later represents Dual Tone MultiFrequency (DTMF) digits that will be later
sent right after the circuit-switched bearer is established. sent right after the circuit-switched bearer is established.
Implementations MAY use any of these mechanisms and MAY use two or Implementations MAY use any of these mechanisms and MAY use two or
more mechanisms simultaneously. more mechanisms simultaneously.
5.2.3.1. The "cs-correlation" attribute 5.2.3.1. The "cs-correlation" attribute
In order to provide support for the correlation mechanisms, we define In order to provide support for the correlation mechanisms, we define
a new SDP attribute called "cs-correlation". This "cs-correlation" a new media-level SDP attribute called "cs-correlation". This "cs-
attribute can include any of the "callerid", "uuie", or "dtmf" correlation" attribute can include any of the "callerid", "uuie", or
subfields, which specify additional information required by the "dtmf" subfields, which specify additional information required by
Caller-ID, User to User Information, or DTMF correlation mechanisms, the Caller-ID, User to User Information, or DTMF correlation
respectively. The list of correlation mechanisms may be extended by mechanisms, respectively. The list of correlation mechanisms may be
other specifications, see Section 5.2.3.5 fore more details. There extended by other specifications, see Section 5.2.3.5 for more
MUST be at most one "cs-correlation" attribute per media description. details. There MUST be at most one "cs-correlation" attribute per
media description.
The following sections provide more detailed information of these The following sections provide more detailed information of these
subfields. The "cs-correlation" attribute has the following format: subfields. The "cs-correlation" attribute has the following format:
a=cs-correlation: <correlation-mechanisms> a=cs-correlation: <correlation-mechanisms>
correlation-mechanisms = corr-mech *(SP corr-mech) correlation-mechanisms = corr-mech *(SP corr-mech)
corr-mech = caller-id-mech / uuie-mech / corr-mech = caller-id-mech / uuie-mech /
dfmt-mech / ext-mech dfmt-mech / ext-mech
caller-id-mech = "callerid" [":" caller-id-value] caller-id-mech = "callerid" [":" caller-id-value]
uuie-mech = "uuie" [":" uuie-value] uuie-mech = "uuie" [":" uuie-value]
skipping to change at page 13, line 46 skipping to change at page 14, line 5
The Caller-ID correlation mechanisms consists of an exchange of the The Caller-ID correlation mechanisms consists of an exchange of the
calling party number as an international E.164 number in SDP, calling party number as an international E.164 number in SDP,
followed by the availability of the Calling Party Number information followed by the availability of the Calling Party Number information
element in the call setup signaling of the circuit switched element in the call setup signaling of the circuit switched
connection. If both pieces of information match, the circuit- connection. If both pieces of information match, the circuit-
switched bearer is correlated to the session described in SDP. switched bearer is correlated to the session described in SDP.
Example of inclusion of an international E.164 number in the "cs- Example of inclusion of an international E.164 number in the "cs-
correlation" attribute is: correlation" attribute is:
a=cs-correlation:callerid:+35891234567 a=cs-correlation:callerid:+441134690123
The presence of the "callerid" subfield indicates that the endpoint The presence of the "callerid" subfield indicates that the endpoint
supports use of the calling party number as a means of correlating a supports use of the calling party number as a means of correlating a
PSTN call with the session being negotiated. The "callerid" subfield PSTN call with the session being negotiated. The "callerid" subfield
MAY be accompanied by the international E.164 number of the party MAY be accompanied by the international E.164 number of the party
inserting the parameter. inserting the parameter.
Note that there are no warranties that this correlation mechanism Note that there are no guarantees that this correlation mechanism
works or is even available, due a number of problems: works or is even available, due a number of problems:
o The endpoint might not be aware of its own E.164 number, in which o The endpoint might not be aware of its own E.164 number, in which
case it cannot populate the SDP appropriately. case it cannot populate the SDP appropriately.
o The Calling Party Number information element in the circuit- o The Calling Party Number information element in the circuit-
switched signaling might not be available, e.g., due to policy switched signaling might not be available, e.g., due to policy
restrictions of the network operator or caller restriction due to restrictions of the network operator or caller restriction due to
privacy. privacy.
o The Calling Party Number information element in the circuit- o The Calling Party Number information element in the circuit-
switched signaling might be available, but the digit switched signaling might be available, but the digit
representation of the E.164 number might differ from the one representation of the E.164 number might differ from the one
expressed in the SDP. To mitigate this problem implementations expressed in the SDP. To mitigate this problem implementations
should consider only some of the rightmost digits from the E.164 should consider only some of the rightmost digits from the E.164
number for correlation. For example, the numbers +358-9-123-4567 number for correlation. For example, the numbers +44-113-469-0123
and 09-123-4567 could be considered as the same number. This is and 0113-469-0123 could be considered as the same number. This is
also the behavior of some cellular phones, which correlate the also the behavior of some cellular phones, which correlate the
incoming calling party with a number stored in the phone book, for incoming calling party with a number stored in the phone book, for
the purpose of displaying the caller's name. the purpose of displaying the caller's name.
5.2.3.3. User-User Information Element Correlation Mechanism 5.2.3.3. User-User Information Element Correlation Mechanism
A second correlation mechanism is based on including in SDP a string A second correlation mechanism is based on including in SDP a string
that represents the User-User Information Element that is part of the that represents the User-User Information Element that is part of the
call setup signaling of the circuit-switched bearer. The User-User call setup signaling of the circuit-switched bearer. The User-User
Information Element is specified in ITU-T Q.931 [ITU.Q931.1998] and Information Element is specified in ITU-T Q.931 [ITU.Q931.1998] and
skipping to change at page 15, line 27 skipping to change at page 15, line 34
Protocol Discriminator octet, followed by the User Information Protocol Discriminator octet, followed by the User Information
octets. The value of the Protocol Discriminator octet is not octets. The value of the Protocol Discriminator octet is not
specified in this document; it is expected that organizations using specified in this document; it is expected that organizations using
this technology will allocate a suitable value for the Protocol this technology will allocate a suitable value for the Protocol
Discriminator. Discriminator.
Once the binary value of the "uuie" subfield in the "cs-correlation" Once the binary value of the "uuie" subfield in the "cs-correlation"
attribute is created, it MUST be encoded in hexadecimal before it is 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 inserted in SDP. Each octet of binary data to be represented in the
hexadecimal encoding MUST be mapped to two hexadecimal digits hexadecimal encoding MUST be mapped to two hexadecimal digits
(represented by ASCII characters 0-9 and A-F, each representing four (represented by ASCII characters 0-9 and A-F), each representing four
bits within the octet. The four bits appearing first in the binary bits within the octet. The four bits appearing first in the binary
data MUST be mapped to the first hexadecimal digit and the four data MUST be mapped to the first hexadecimal digit and the four
subsequent bits in the binary data MUST be mapped to the second subsequent bits in the binary data MUST be mapped to the second
hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the
bit appearing first in the binary data SHALL be most significant. bit appearing first in the binary data SHALL be most significant.
Thus, the resulting hexadecimal encoded value needs to have an even Thus, the resulting hexadecimal encoded value needs to have an even
number of hexadecimal digits, and MUST be considered invalid if it number of hexadecimal digits, and MUST be considered invalid if it
has an odd number. has an odd number.
Note that the encoding of the "uuie" subfield of the "cs- Note that the encoding of the "uuie" subfield of the "cs-
correlation" attribute is largely inspired by the encoding of the correlation" attribute is largely inspired by the encoding of the
same value in the User-to-User header field in SIP, according to same value in the User-to-User header field in SIP, according to
the document A Mechanism for Transporting User to User Call the document "A Mechanism for Transporting User to User Call
Control Information in SIP [I-D.ietf-cuss-sip-uui]. Control Information in SIP" [I-D.ietf-cuss-sip-uui].
As an example, an endpoint willing to send a UUIE containing a As an example, an endpoint willing to send a UUIE containing a
protocol discriminator with the hexadecimal value of %x56 and an protocol discriminator with the hexadecimal value of %x56 and an
hexadecimal User Information value of %xA390F3D2B7310023 would hexadecimal User Information value of %xA390F3D2B7310023 would
include a "cs-correlation" attribute line as follows: include a "cs-correlation" attribute line as follows:
a=cs-correlation:uuie:56A390F3D2B7310023 a=cs-correlation:uuie:56A390F3D2B7310023
Note that, for correlation purposes, the value of the User-User Note that, for correlation purposes, the value of the User-User
Information Element is considered as an opaque string and only used Information Element is considered as an opaque string and only used
for correlation purposes. Typically call signaling protocols impose for correlation purposes. Typically call signaling protocols impose
requirements on the creation of User-User Information Element for requirements on the creation of User-User Information Element for
end-user protocol exchange. The details regarding the generation of end-user protocol exchange. The details regarding the generation of
the User-User Information Element are outside the scope of this the User-User Information Element are outside the scope of this
specification. specification.
Please note that there are no warranties that this correlation Please note that there are no guarantees that this correlation
mechanism works. On one side, policy restrictions might not make the mechanism works. On one side, policy restrictions might not make the
User-User information available end to end in the PSTN. On the other User-User information available end to end in the PSTN. On the other
hand, the generation of the User-User Information Element is hand, the generation of the User-User Information Element is
controlled by the PSTN circuit-switched call protocol, which might controlled by the PSTN circuit-switched call protocol, which might
not offer enough freedom for generating different values from one not offer enough freedom for generating different values from one
endpoint to another one, or from one call to another in the same 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 endpoint. This might result in the same value of the User-User
Information Element for all calls. Information Element for all calls.
5.2.3.4. DTMF Correlation Mechanism 5.2.3.4. DTMF Correlation Mechanism
skipping to change at page 17, line 43 skipping to change at page 17, line 50
that mechanism as unsupported, and MUST NOT include that value in that mechanism as unsupported, and MUST NOT include that value in
subsequent Offer/Answer negotiation. subsequent Offer/Answer negotiation.
5.3. Negotiating the correlation mechanisms 5.3. Negotiating the correlation mechanisms
The three correlation mechanisms presented above (based on called The three correlation mechanisms presented above (based on called
party number, User-User Information Element and DTMF digit sending) party number, User-User Information Element and DTMF digit sending)
are non-exclusive, and can be used independently of each other. In are non-exclusive, and can be used independently of each other. In
order to know how to populate the "cs-correlation" attribute, the order to know how to populate the "cs-correlation" attribute, the
endpoints need to agree which endpoint will become the active party, endpoints need to agree which endpoint will become the active party,
i.e. the one that will set up the circuit-switched bearer. i.e., the one that will set up the circuit-switched bearer.
5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup 5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup
In order to avoid a situation where both endpoints attempt to In order to avoid a situation where both endpoints attempt to
initiate a connection simultaneously, the direction in which the initiate a connection simultaneously, the direction in which the
circuit-switched bearer is set up MUST be negotiated during the circuit-switched bearer is set up MUST be negotiated during the
Offer/Answer exchange. Offer/Answer exchange.
The framework defined in RFC 4145 [RFC4145] allows the endpoints to The framework defined in RFC 4145 [RFC4145] allows the endpoints to
agree which endpoint acts as the active endpoint when initiating a agree which endpoint acts as the active endpoint when initiating a
skipping to change at page 21, line 30 skipping to change at page 21, line 35
(with a leading "+"). If the endpoint is not aware of its own E.164 (with a leading "+"). If the endpoint is not aware of its own E.164
number, it MUST set the <connection-address> to "-". number, it MUST set the <connection-address> to "-".
In the "m=" line, the endpoint MUST set the <media> subfield to In the "m=" line, the endpoint MUST set the <media> subfield to
"audio" or "video", depending on the media type, and the <proto> "audio" or "video", depending on the media type, and the <proto>
subfield to "PSTN". The <port> subfield SHOULD be set to "9" (the subfield to "PSTN". The <port> subfield SHOULD be set to "9" (the
discard port). discard port).
The <fmt> subfield carries the payload type number(s) the endpoint is The <fmt> subfield carries the payload type number(s) the endpoint is
wishing to use. Payload type numbers in this case refer to the wishing to use. Payload type numbers in this case refer to the
codecs that the endpoint wishes to use. For example, if the endpoint codecs that the endpoint wishes to use on the PSTN media stream. For
wishes to use the GSM codec, it would add payload type number 3 in example, if the endpoint wishes to use the GSM codec, it would add
the list of codecs. 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 For dynamic payload types, the endpoint MUST define the set of valid
encoding names and related parameters using the "a=rtpmap" attribute encoding names and related parameters using the "a=rtpmap" attribute
line. See Section 6 of SDP [RFC4566] for details. line. See Section 6 of SDP [RFC4566] for details.
When generating the Offer, if the Offerer supports any of the When generating the Offer, if the Offerer supports any of the
correlation mechanisms defined in this memo, it MUST include an correlation mechanisms defined in this memo, it MUST include an
attribute line "a=cs-correlation" in the SDP offer. The Offerer MUST attribute line "a=cs-correlation" in the SDP offer. The Offerer MUST
NOT include more than one "cs-correlation" attribute per media NOT include more than one "cs-correlation" attribute per media
decription. The "a=cs-correlation" line contains an enumeration of decription. The "a=cs-correlation" line contains an enumeration of
skipping to change at page 22, line 22 skipping to change at page 22, line 30
o the DTMF tone string as the value of the "dtmf" subfield o the DTMF tone string as the value of the "dtmf" subfield
If the Offerer is only able to become the passive party in the If the Offerer is only able to become the passive party in the
circuit-switched bearer setup, it MUST add the "callerid", "uuie" circuit-switched bearer setup, it MUST add the "callerid", "uuie"
and/or "dtmf" subfields, but MUST NOT specify values for those and/or "dtmf" subfields, but MUST NOT specify values for those
subfields. subfields.
For example, if the Offerer is willing to use the User-User For example, if the Offerer is willing to use the User-User
Information element and DTMF digit sending mechanisms, but can only Information element and DTMF digit sending mechanisms, but can only
become the passive party, it includes the following lines to the SDP: become the passive party, it includes the following lines in the SDP:
a=cs-correlation:uuie dtmf a=cs-correlation:uuie dtmf
a=setup:passive a=setup:passive
If, on the other hand, the Offerer is willing to use the User-User If, on the other hand, the Offerer is willing to use the User-User
Information element and the DTMF correlation mechanisms, and is able Information element and the DTMF correlation mechanisms, and is able
to become the active or passive side, it includes to following lines to become the active or passive side, it includes the following lines
to the SDP: in the SDP:
a=cs-correlation:uuie:56A390F3D2B7310023 dtmf:14D*3 a=cs-correlation:uuie:56A390F3D2B7310023 dtmf:14D*3
a=setup:actpass a=setup:actpass
The negotiation of the value of the 'setup' attribute takes place as 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 defined in Section 4.1 of TCP-Based Media Transport in the SDP
[RFC4145]. [RFC4145].
The Offerer states which role or roles it is willing to perform; and The Offerer states which role or roles it is willing to perform; and
skipping to change at page 24, line 27 skipping to change at page 24, line 35
either the active or passive party, the Answerer needs to determine either the active or passive party, the Answerer needs to determine
which role it would like to take. If the Offer includes an which role it would like to take. If the Offer includes an
international E.164 number in the "c=" line, the Answerer SHOULD international E.164 number in the "c=" line, the Answerer SHOULD
become the active party. If the Offer does not include an E.164 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, and if the Answerer is aware of its international E.164
number, it MUST become the passive party. If the Offer does not 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 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 aware of its E.164 number, it MUST reject the circuit-switched media
by setting the port number to zero in the Answer. by setting the port number to zero in the Answer.
The Answerer MUST select those correlation mechanisms from the Offer For each media description where the Offer includes a "a=cs-
it supports, and include an "a=cs-correlation" attribute line in the correlation" attribute, the Answerer MUST select from the Offer those
Answer containing those mechanisms it supports and is willing to use. correlation mechanisms it supports, and include in the Answer one
The Answerer MUST NOT add any mechanisms which were not included in "a=cs-correlation" attribute line containing those mechanisms it is
the offer. If there are more than one "cs-correlation" attributes willing to use. The Answerer MUST only add one "a=cs-correlation"
per media description in the Offer, the Answerer MUST discard all but attribute in those media descriptions where also the Offer included a
the first for any media description. Also, the Answerer MUST discard "a=cs-correlation" attribute. The Answerer MUST NOT add any
all unknown "cs-correlation" attribute values. 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 If the Answerer becomes the active party, it MUST add any of the
"callerid", "uuie" or "dtmf" subfield values. "callerid", "uuie" or "dtmf" subfield values.
If the Answerer becomes the passive party, it MUST NOT add values to If the Answerer becomes the passive party, it MUST NOT add values to
the "callerid", "uuie" and/or "dtmf" subfields. the "callerid", "uuie" and/or "dtmf" subfields.
After generating and sending the Answer, if the Answerer became the After generating and sending the Answer, if the Answerer became the
active party, it active party, it
skipping to change at page 26, line 6 skipping to change at page 26, line 16
5.6.3. Offerer processing the Answer 5.6.3. Offerer processing the Answer
When receiving the Answer, if the SDP does not contain "a=cs- When receiving the Answer, if the SDP does not contain "a=cs-
correlation" attribute line, the Offerer should take that as an correlation" attribute line, the Offerer should take that as an
indication that the other party does not support or is not willing to 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 use the procedures defined in the document for this session, and MUST
revert to normal processing of SDP. revert to normal processing of SDP.
When receiving the Answer, the Offerer MUST first determine whether When receiving the Answer, the Offerer MUST first determine whether
it becomes the active or passive party, as described in Section it becomes the active or passive party, as described in
Section 5.3.1. Section 5.3.1.
If the Offerer becomes the active party, it If the Offerer becomes the active party, it
o MUST extract the E.164 number from the "c=" line and MUST o MUST extract the E.164 number from the "c=" line and MUST
establish a circuit-switched bearer to that address. establish a circuit-switched bearer to that address.
o if the SDP Answer contained a value for the "uuie" subfield, MUST o if the SDP Answer contained a value for the "uuie" subfield, MUST
send the User-User Information element according to the rules send the User-User Information element according to the rules
defined for the circuit-switched technology used, and set the defined for the circuit-switched technology used, and set the
skipping to change at page 26, line 28 skipping to change at page 26, line 38
Answer, Answer,
o if the SDP Answer contained a value for the "dtmf" subfield, MUST o if the SDP Answer contained a value for the "dtmf" subfield, MUST
send those DTMF digits according to the circuit-switched send those DTMF digits according to the circuit-switched
technology used. technology used.
If the Offerer becomes the passive party, it If the Offerer becomes the passive party, it
o MUST be prepared to receive a circuit-switched bearer, o MUST be prepared to receive a circuit-switched bearer,
o Note that it if delivery of the Answer is delayed for some reason, o Note that if delivery of the Answer is delayed for some reason,
the circuit-switched call attempt may arrive at the Offerer before the circuit-switched call attempt may arrive at the Offerer before
the Answer has been processed. In this case, since the the Answer has been processed. In this case, since the
correlation mechanisms are negotiated as part of the Offer/Answer correlation mechanisms are negotiated as part of the Offer/Answer
exchange, the Answerer cannot know whether or not the incoming exchange, the Answerer cannot know whether or not the incoming
circuit-switched call attempt is correlated with the session being circuit-switched call attempt is correlated with the session being
negotiated, the Offerer SHOULD answer the circuit-switched call negotiated, the Offerer SHOULD answer the circuit-switched call
attempt only after it has received and processed the Answer. attempt only after it has received and processed the Answer.
o if the Answer contained a value for the "dtmf" subfield, MUST be o If the Answer contained a value for the "dtmf" subfield, the
prepared to receive and collect DTMF digits once the circuit- Offerer MUST be prepared to receive and collect DTMF digits once
switched bearer is set up. The Offerer SHOULD compare the the circuit-switched bearer is set up. The Offerer SHOULD compare
received DTMF digits to the value of the "dtmf" subfield. If the the received DTMF digits to the value of the "dtmf" subfield. If
received DTMF digits match the value of the "dtmf" subfield in the the received DTMF digits match the value of the "dtmf" subfield in
"cs-correlation" attribute, the call SHOULD be treated as the "cs-correlation" attribute, the call SHOULD be treated as
correlated to the ongoing session. correlated to the ongoing session.
o if the Answer contained a value for the "uuie" subfield, MUST be o If the Answer contained a value for the "uuie" subfield, the
prepared to receive a User-User Information element once the Offerer MUST be prepared to receive a User-User Information
circuit-switched bearer is set up. The Offerer SHOULD compare the element once the circuit-switched bearer is set up. The Offerer
received UUI to the value of the "uuie" subfield. If the value of SHOULD compare the received UUI to the value of the "uuie"
the received UUI matches the value of the "uuie" subfield, the subfield. If the value of the received UUI matches the value of
call SHOULD be treated as correlated to the ongoing session. the "uuie" subfield, the call SHOULD be treated as correlated to
the ongoing session.
5.6.4. Modifying the session 5.6.4. Modifying the session
If, at a later time, one of the parties wishes to modify the 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 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 an existing stream, it may do so via the mechanisms defined for An
Offer/Answer Model with SDP [RFC3264]. Offer/Answer Model with SDP [RFC3264].
If there is an existing circuit-switched bearer between the If there is an existing circuit-switched bearer between the
endpoints, and the Offerer wants to reuse that the Offerer MUST set endpoints, and the Offerer wants to reuse that, the Offerer MUST set
the value of the "a=connection" attribute to 'existing'. the value of the "a=connection" attribute to 'existing'.
If either party removes the circuit-switched media from the session If either party removes the circuit-switched media from the session
(by setting the port number to zero), it MUST terminate the circuit- (by setting the port number to zero), it MUST terminate the circuit-
switched bearer using whatever mechanism is appropriate for the switched bearer using whatever mechanism is appropriate for the
technology in question. technology in question.
If either party wishes to drop and reestablish an existing call, that If either party wishes to drop and reestablish an existing call, that
party MUST first remove the circuit-switched media from the session party MUST first remove the circuit-switched media from the session
by setting the port number to zero, and then use another Offer/Answer by setting the port number to zero, and then use another Offer/Answer
skipping to change at page 28, line 5 skipping to change at page 28, line 5
The following is the formal Augmented Backus-Naur Form (ABNF) The following is the formal Augmented Backus-Naur Form (ABNF)
[RFC5234] syntax that supports the extensions defined in this [RFC5234] syntax that supports the extensions defined in this
specification. The syntax is built above the SDP [RFC4566] and the specification. The syntax is built above the SDP [RFC4566] and the
tel URI [RFC3966] grammars. Implementations according to this tel URI [RFC3966] grammars. Implementations according to this
specification MUST be compliant with this syntax. specification MUST be compliant with this syntax.
Figure 2 shows the formal syntax of the extensions defined in this Figure 2 shows the formal syntax of the extensions defined in this
memo. memo.
; extension to the connection field originally specified ; extension to the connection field originally specified
; in RFC 4566 ; in RFC 4566
connection-field = [%x63 "=" nettype SP addrtype SP connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF] connection-address CRLF]
;nettype and addrtype are defined in RFC 4566 ;nettype and addrtype are defined in RFC 4566
connection-address /= global-number / "-" connection-address /= global-number / "-"
; global-number specified in RFC 3966 ; global-number specified in RFC 3966
;subrules for correlation attribute ;subrules for correlation attribute
attribute /= cs-correlation-attr attribute /= cs-correlation-attr
; attribute defined in RFC 4566 ; attribute defined in RFC 4566
cs-correlation-attr= "cs-correlation:" corr-mechanisms cs-correlation-attr = "cs-correlation:" corr-mechanisms
corr-mechanisms = corr-mech *(SP corr-mech) corr-mechanisms = corr-mech *(SP corr-mech)
corr-mech = caller-id-mech / uuie-mech / corr-mech = caller-id-mech / uuie-mech /
dtmf-mech / ext-mech dtmf-mech / ext-mech
caller-id-mech = "callerid" [":" caller-id-value] caller-id-mech = "callerid" [":" caller-id-value]
caller-id-value = "+" 1*15DIGIT caller-id-value = "+" 1*15DIGIT
uuie-mech = "uuie" [":" uuie-value] uuie-mech = "uuie" [":" uuie-value]
uuie-value = 1*65(HEXDIG HEXDIG) uuie-value = 1*65(HEXDIG HEXDIG)
;This represents up to 130 HEXDIG (65 octets) ;This represents up to 130 HEXDIG
;HEXDIG defined in RFC5234 ; (65 octets)
;HEXDIG defined as 0-9, A-F ;HEXDIG defined in RFC5234
dtmf-mech = "dtmf" [":" dtmf-value] ;HEXDIG defined as 0-9, A-F
dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A ) dtmf-mech = "dtmf" [":" dtmf-value]
;0-9, A-D, '#' and '*' dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A )
ext-mech = ext-mech-name[":" ext-mech-value] ;0-9, A-D, '#' and '*'
ext-mech-name = token ext-mech = ext-mech-name [":" ext-mech-value]
ext-mech-value = token ext-mech-name = token
; token is specified in RFC4566 ext-mech-value = token
; token is specified in RFC4566
Figure 2: Syntax of the SDP extensions Figure 2: Syntax of the SDP extensions
6. Examples 6. Examples
In the examples below, where an SDP line is too long to be displayed In the examples below, where an SDP line is too long to be displayed
as a single line, a breaking character "\" indicates continuation in as a single line, a breaking character "\" indicates continuation in
the following line. Note that this character is included for display the following line. Note that this character is included for display
purposes only. Implementation MUST write a single line without purposes only. Implementations MUST write a single line without
breaks. breaks.
6.1. Single PSTN audio stream 6.1. Single PSTN audio stream
Alice Bob Alice Bob
| | | |
| (1) SDP Offer (PSTN audio) | | (1) SDP Offer (PSTN audio) |
|--------------------------------->| |--------------------------------->|
| | | |
| (2) SDP Answer (PSTN audio) | | (2) SDP Answer (PSTN audio) |
skipping to change at page 29, line 39 skipping to change at page 29, line 39
of it in the "a=setup" attribute line. The SDP Offer also includes of it in the "a=setup" attribute line. The SDP Offer also includes
correlation identifiers that this endpoint will insert in the Calling correlation identifiers that this endpoint will insert in the Calling
Party Number and/or User-User Information Element of the PSTN call Party Number and/or User-User Information Element of the PSTN call
setup if eventually this endpoint initiates the PSTN call. setup if eventually this endpoint initiates the PSTN call.
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5
s= s=
t=0 0 t=0 0
m=audio 9 PSTN - m=audio 9 PSTN -
c=PSTN E164 +35891234567 c=PSTN E164 +441134690123
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=cs-correlation:callerid:+15551234 \ a=cs-correlation:callerid:+441134690123 \
uuie:56A390F3D2B7310023 uuie:56A390F3D2B7310023
Figure 4: SDP offer (1) Figure 4: SDP offer (1)
Bob generates a SDP Answer (Figure 5), describing a PSTN audio media Bob generates a SDP Answer (Figure 5), describing a PSTN audio media
on port 9 without information on the media sub-type on the "m=" line. 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 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 "a=setup" line Bob indicates that he is willing to become the active
endpoint when establishing the PSTN call, and he also includes the endpoint when establishing the PSTN call, and he also includes the
"a=cs-correlation" attribute line containing the values he is going "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 to include in the Calling Party Number and User-User IE of the PSTN
call establishment. call establishment.
v=0 v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7 o=- 2890973824 2890987289 IN IP4 192.0.2.7
s= s=
t=0 0 t=0 0
m=audio 9 PSTN - m=audio 9 PSTN -
c=PSTN E164 +35897654321 c=PSTN E164 +441134690124
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cs-correlation:callerid:+15554321 \ a=cs-correlation:callerid:+441134690124 \
uuie:56A390F3D2B7310023 uuie:56A390F3D2B7310023
Figure 5: SDP Answer with circuit-switched media Figure 5: SDP Answer with circuit-switched media
When Alice receives the Answer, she examines that Bob is willing to When Alice receives the Answer, she examines that Bob is willing to
become the active endpoint when setting up the PSTN call. Alice 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 temporarily stores Bob's E.164 number and the User-User IE value of
the "cs-correlation" attribute, and waits for a circuit-switched the "cs-correlation" attribute, and waits for a circuit-switched
bearer establishment. bearer establishment.
skipping to change at page 31, line 32 skipping to change at page 31, line 32
Figure 6 shows an example of negotiating audio and video media Figure 6 shows an example of negotiating audio and video media
streams over circuit-switched bearers. streams over circuit-switched bearers.
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5
s= s=
t=0 0 t=0 0
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=cs-correlation:dtmf:112233 c=PSTN E164 +441134690123
c=PSTN E164 +35891234567
m=audio 9 PSTN - m=audio 9 PSTN -
a=cs-correlation:dtmf:1234536
m=video 9 PSTN 34 m=video 9 PSTN 34
a=rtpmap:34 H263/90000 a=rtpmap:34 H263/90000
a=cs-correlation:callerid:+441134690123
Figure 7: SDP offer with circuit-switched audio and video (1) Figure 7: SDP offer with circuit-switched audio and video (1)
Upon receiving the SDP offer descibed in Figure 7, Bob rejects the Upon receiving the SDP offer descibed in Figure 7, Bob rejects the
video stream as his device does not currently support video, but video stream as his device does not currently support video, but
accepts the circuit-switched audio stream. As Alice indicated that accepts the circuit-switched audio stream. As Alice indicated that
she is able to become either the active, or passive party, Bob gets 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 to select which role he would like to take. Since the Offer
contained the international E.164 number of Alice, Bob decides that contained the international E.164 number of Alice, Bob decides that
he becomes the active party in setting up the circuit-switched he becomes the active party in setting up the circuit-switched
bearer. Bob includes a new value in the "dtmf" subfield of the "cs- 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 correlation" attribute, which he is going to send as DTMF tones once
bearer setup is complete. The Answer is described in Figure 8 the bearer setup is complete. For the video bearer, caller ID based
correlation is used. The Answer is described in Figure 8
v=0 v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7 o=- 2890973824 2890987289 IN IP4 192.0.2.7
s= s=
t=0 0 t=0 0
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cs-correlation:dtmf:332211 c=PSTN E164 +441134690124
c=PSTN E164 +35897654321
m=audio 9 PSTN - m=audio 9 PSTN -
a=cs-correlation:dtmf:654321
m=video 0 PSTN 34 m=video 0 PSTN 34
a=cs-correlation:dtmf:+441134690124
Figure 8: SDP answer with circuit-switched audio and video (2) Figure 8: SDP answer with circuit-switched audio and video (2)
7. Security Considerations 7. Security Considerations
This document provides an extension on top of RFC 4566 [RFC4566], and This document provides an extension on top of RFC 4566 [RFC4566], and
RFC 3264 [RFC3264]. As such, the security considerations of those RFC 3264 [RFC3264]. As such, the security considerations of those
documents apply. documents apply.
This memo provides mechanisms to agree on a correlation identifier or This memo provides mechanisms to agree on a correlation identifier or
skipping to change at page 32, line 49 skipping to change at page 32, line 50
Phone numbers are sensitive information, and some people may choose Phone numbers are sensitive information, and some people may choose
not to reveal their phone numbers when calling using supplementary not to reveal their phone numbers when calling using supplementary
services like Calling Line Identification Restriction (CLIR) in GSM. services like Calling Line Identification Restriction (CLIR) in GSM.
Implementations should take the caller's preferences regarding Implementations should take the caller's preferences regarding
calling line identification into account if possible, by restricting calling line identification into account if possible, by restricting
the inclusion of the phone number in SDP "c=" line if the caller has 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 chosen to use CLIR. If this is not possible, implementations may
present a prompt informing the user that their phone number may be present a prompt informing the user that their phone number may be
transmitted to the other party. transmitted to the other party.
Similarly as with IP addresses, if there is a desire the protect the Similarly as with IP addresses, if there is a desire to protect the
SDP containing phone numbers carried in SIP, implementers are adviced SDP containing phone numbers carried in SIP, implementers are adviced
to follow the security mechanisms defined in [RFC3261]. to follow the security mechanisms defined in [RFC3261].
It is possible that an attacker creates a circuit-switched session It is possible that an attacker creates a circuit-switched session
whereby the attacked endpoint should dial a circuit-switched number, whereby the attacked endpoint should dial a circuit-switched number,
perhaps even a premium-rate telephone number. To mitigate the perhaps even a premium-rate telephone number. To mitigate the
consequences of this attack, endpoints MUST authenticate and trust consequences of this attack, endpoints MUST authenticate and trust
remote endpoints users who try to remain passive in the circuit- remote endpoints users who try to remain passive in the circuit-
switched connection establishment. It is RECOMMENDED that endpoints switched connection establishment. It is RECOMMENDED that endpoints
have local policies precluding the active establishment of circuit have local policies precluding the active establishment of circuit
skipping to change at page 33, line 33 skipping to change at page 33, line 34
8.1. Registration of new cs-correlation SDP attribute 8.1. Registration of new cs-correlation SDP attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Attribute name: cs-correlation Attribute name: cs-correlation
Long-form attribute name: PSTN Correlation Identifier Long-form attribute name: PSTN Correlation Identifier
Type of attribute: media level only Type of attribute: media level only
This attribute is subject to the charset attribute Subject to charset: No
Description: This attribute provides the Correlation Identifier Description: This attribute provides the Correlation Identifier
used in PSTN signaling used in PSTN signaling
Appropriate values:see Section 5.2.3.1
Specification: RFC XXXX Specification: RFC XXXX
The IANA is requested to create a subregistry for 'cs-correlation' The IANA is requested to create a subregistry for 'cs-correlation'
attribute under the Session Description Protocol (SDP) Parameters attribute under the Session Description Protocol (SDP) Parameters
registry. The initial values for the subregistry are presented in registry. The initial values for the subregistry are presented in
the following, and IANA is requested to add them into its database: the following, and IANA is requested to add them into its database:
Value of 'cs-correlation' attribute Reference Description Value of 'cs-correlation' attribute Reference Description
----------------------------------- --------- ----------- callerid ----------------------------------- --------- -----------
RFC XXXX Caller ID uuie RFC XXXX User-User Information Element dtmf callerid RFC XXXX Caller ID
RFC XXXX Dual-tone Multifrequency uuie RFC XXXX User-User
Information Element
dtmf RFC XXXX Dual-tone Multifrequency
Note for the RFC Editor: 'RFC XXXX' above should be replaced by a Note for the RFC Editor: 'RFC XXXX' above should be replaced by a
reference to the RFC number of this draft. reference to the RFC number of this draft.
As per the terminology in [RFC5226], the registration policy for new As per the terminology in [RFC5226], the registration policy for new
values of 'cs-correlation' parameter is 'Specification Required'. values of 'cs-correlation' parameter is 'Specification Required'.
8.2. Registration of a new "nettype" value 8.2. Registration of a new "nettype" value
This memo provides instructions to IANA to register a new "nettype" This memo provides instructions to IANA to register a new "nettype"
in the Session Description Protocol Parameters registry [1]. The in the Session Description Protocol Parameters registry [1]. The
registration data, according to RFC 4566 [RFC4566] follows. registration data, according to RFC 4566 [RFC4566] follows.
Type SDP Name Reference Type SDP Name Reference
---- ------------------ --------- ---- ------------------ ---------
nettype PSTN [RFCxxxx] nettype PSTN [RFCxxxx]
8.3. Registration of new "addrtype" values 8.3. Registration of new "addrtype" values
This memo provides instructions to IANA to register a new "addrtype" This memo provides instructions to IANA to register two new
in the Session Description Protocol Parameters registry [1]. The "addrtype" in the Session Description Protocol Parameters
registration data, according to RFC 4566 [RFC4566] follows. registry [1]. The registration data, according to RFC 4566 [RFC4566]
follows.
Type SDP Name Reference Type SDP Name Reference
---- ------------------ --------- ---- ------------------ ---------
addrtype E164 [RFCxxxx] addrtype E164 [RFCxxxx]
- [RFCxxxx] - [RFCxxxx]
Note: RFC XXXX uses the "E164" and "-" addrtypes in conjunction with Note: RFC XXXX defines the "E164" and "-" addrtypes in conjunction
the "PSTN" nettype. Please refer to the relevant RFC for a with the "PSTN" nettype only. Please refer to the relevant RFC for a
description of that representation. 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.
8.4. Registration of a new "proto" value 8.4. Registration of a new "proto" value
This memo provides instructions to IANA to register a new "proto" in This memo provides instructions to IANA to register a new "proto" in
the Session Description Protocol Parameters registry [1]. The the Session Description Protocol Parameters registry [1]. The
registration data, according to RFC 4566 [RFC4566] follows. registration data, according to RFC 4566 [RFC4566] follows.
Type SDP Name Reference Type SDP Name Reference
-------------- --------------------------- --------- -------------- --------------------------- ---------
proto PSTN [RFCxxxx] proto PSTN [RFCxxxx]
The related "fmt" namespace re-uses the conventions and payload type The related "fmt" namespace re-uses the conventions and payload type
number defined for RTP/AVP. In this document, the RTP audio and number defined for RTP/AVP. In this document, the RTP audio and
video media types, when applied to PSTN circuit-switched bearers, video media types, when applied to PSTN circuit-switched bearers,
represent merely on audio or video codec. 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 lsit of
available codecs for circuit-switched media streams. In this case,
in order to be syntactically compliant with SDP [RFC4566], the
9. Acknowledgments 9. Acknowledgments
The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas
Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan
Rosenberg, Ingemar Johansson, Christer Holmberg, Alf Heidermark, Tom Rosenberg, Ingemar Johansson, Christer Holmberg, Alf Heidermark, Tom
Taylor, Thomas Belling, Keith Drage, and Andrew Allen for providing Taylor, Thomas Belling, Keith Drage, and Andrew Allen for providing
their insight and comments on this document. their insight and comments on this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer
Connections", RFC 3108, May 2001.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
skipping to change at page 36, line 23 skipping to change at page 36, line 28
[ITU.E164.1991] [ITU.E164.1991]
International Telecommunications Union, "The International International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU- Public Telecommunication Numbering Plan", ITU-
T Recommendation E.164, 1991. T Recommendation E.164, 1991.
[ITU.Q931.1998] [ITU.Q931.1998]
"Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN "Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN
User - Network Interface Layer 3 Specification for Basic User - Network Interface Layer 3 Specification for Basic
Call Control", ISO Standard 9594-1, May 1998. Call Control", ISO Standard 9594-1, May 1998.
[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer
Connections", RFC 3108, May 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
 End of changes. 63 change blocks. 
147 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/