draft-ietf-mmusic-sdp-cs-09.txt   draft-ietf-mmusic-sdp-cs-10.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: May 3, 2012 Nokia Expires: September 7, 2012 Nokia
October 31, 2011 March 6, 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-09 draft-ietf-mmusic-sdp-cs-10
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 May 3, 2012. This Internet-Draft will expire on September 7, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 6
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 6 4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 8 5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 9
5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 8 5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 8 5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 9
5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 9 5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 10
5.2.3. Correlating the PSTN Circuit-Switched Bearer with 5.2.3. Correlating the PSTN Circuit-Switched Bearer with
SDP . . . . . . . . . . . . . . . . . . . . . . . . . 10 SDP . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 11 5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 12
5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . 13 Mechanism . . . . . . . . . . . . . . . . . . . . 14
5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 14 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 15
5.3. Negotiating the correlation mechanisms . . . . . . . . . . 15 5.3. Negotiating the correlation mechanisms . . . . . . . . . . 16
5.3.1. Determining the Direction of the Circuit-Switched 5.3.1. Determining the Direction of the Circuit-Switched
Bearer Setup . . . . . . . . . . . . . . . . . . . . . 15 Bearer Setup . . . . . . . . . . . . . . . . . . . . . 16
5.3.2. Populating the cs-correlation attribute . . . . . . . 16 5.3.2. Populating the cs-correlation attribute . . . . . . . 17
5.3.3. Considerations on successful correlation . . . . . . . 16 5.3.3. Considerations on successful correlation . . . . . . . 17
5.4. Considerations for Usage of Existing SDP . . . . . . . . . 17 5.4. Considerations for Usage of Existing SDP . . . . . . . . . 18
5.4.1. Originator of the Session . . . . . . . . . . . . . . 17 5.4.1. Originator of the Session . . . . . . . . . . . . . . 18
5.4.2. Contact information . . . . . . . . . . . . . . . . . 17 5.4.2. Contact information . . . . . . . . . . . . . . . . . 19
5.5. Offer/Answer mode extensions . . . . . . . . . . . . . . . 18 5.5. Considerations for Usage of Third Party Call Control
5.5.1. Generating the Initial Offer . . . . . . . . . . . . . 18 (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.5.2. Generating the Answer . . . . . . . . . . . . . . . . 20 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 19
5.5.3. Offerer processing the Answer . . . . . . . . . . . . 22 5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 19
5.5.4. Modifying the session . . . . . . . . . . . . . . . . 23 5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 21
5.6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 24 5.6.3. Offerer processing the Answer . . . . . . . . . . . . 24
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Registration of new cs-correlation SDP attribute . . . . . 27 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . . 27
8.2. Registration of a new "nettype" value . . . . . . . . . . 28 6.2. Advanced SDP example: Circuit-Switched Audio and Video
8.3. Registration of new "addrtype" values . . . . . . . . . . 28 Streams . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.4. Registration of a new "proto" value . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Registration of new cs-correlation SDP attribute . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 8.2. Registration of a new "nettype" value . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . . 29 8.3. Registration of new "addrtype" values . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 8.4. Registration of a new "proto" value . . . . . . . . . . . 32
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [RFC4566] is intended for The Session Description Protocol (SDP) [RFC4566] is intended for
describing multimedia sessions for the purposes of session describing multimedia sessions for the purposes of session
announcement, session invitation, and other forms of multimedia announcement, session invitation, and other forms of multimedia
session initiation. SDP is most commonly used for describing media session initiation. SDP is most commonly used for describing media
streams that are transported over the Real-Time Transport Protocol streams that are transported over the Real-Time Transport Protocol
(RTP) [RFC3550], using the profiles for audio and video media defined (RTP) [RFC3550], using the profiles for audio and video media defined
in RTP Profile for Audio and Video Conferences with Minimal Control in RTP Profile for Audio and Video Conferences with Minimal Control
skipping to change at page 5, line 32 skipping to change at page 6, line 32
the document conventions, Section 3 introduces the requirements, the document conventions, Section 3 introduces the requirements,
Section 4 presents an overview of the proposed solutions, and Section 4 presents an overview of the proposed solutions, and
Section 5 contains the protocol description. Section 6 provides an Section 5 contains the protocol description. Section 6 provides an
example of descriptions of circuit-switched audio or video streams in example of descriptions of circuit-switched audio or video streams in
SDP. Section 8 and Section 7 contain the IANA and Security SDP. Section 8 and Section 7 contain the IANA and Security
considerations, respectively. considerations, respectively.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14, RFC 2119 "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119] and indicate requirement levels for compliant 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant
implementations. implementations.
3. Requirements 3. Requirements
This section presents the general requirements that are specific for This section presents the general requirements that are specific for
the audio or video media streams over circuit-switched bearers. the audio or video media streams over circuit-switched bearers.
REQ-1: A mechanism for endpoints to negotiate and agree on an audio REQ-1: A mechanism for endpoints to negotiate and agree on an audio
or video media stream established over a circuit-switched or video media stream established over a circuit-switched
bearer MUST be available. bearer MUST be available.
skipping to change at page 8, line 11 skipping to change at page 9, line 11
specified in RFC3264 [RFC3264]. Also, if Bob does not understand specified in RFC3264 [RFC3264]. Also, if Bob does not understand
some of the SDP attributes specified in this document, he would some of the SDP attributes specified in this document, he would
ignore them, as specified in RFC4566 [RFC4566]. ignore them, as specified in RFC4566 [RFC4566].
5. Protocol Description 5. Protocol Description
5.1. Level of Compliance 5.1. Level of Compliance
Implementations according to this specification MUST implement the Implementations according to this specification MUST implement the
SDP extensions described in Section 5.2, and MUST implement the SDP extensions described in Section 5.2, and MUST implement the
considerations discussed in Section 5.3, Section 5.4 and Section 5.5. considerations discussed in Section 5.3, Section 5.4 and Section 5.6.
5.2. Extensions to SDP 5.2. Extensions to SDP
This section provides the syntax and semantics of the extensions This section provides the syntax and semantics of the extensions
required for providing a description of audio or video media streams required for providing a description of audio or video media streams
over circuit-switched bearers in SDP. over circuit-switched bearers in SDP.
5.2.1. Connection Data 5.2.1. Connection Data
According to SDP [RFC4566], the connection data line in SDP has the According to SDP [RFC4566], the connection data line in SDP has the
skipping to change at page 9, line 43 skipping to change at page 10, line 43
the following syntax: the following syntax:
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
The <media> sub-field carries the media type. For establishing an The <media> sub-field 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> sub-field is the transport port to which the media stream The <port> sub-field 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> sub-field is set to the discard port "9". and therefore the <port> sub-field does not carry any meaningful
value. In order to be compliant with SDP syntax, implementations
SHOULD set the <port> sub-field to the discard port value "9" and
MUST ignore it on reception.
According to RFC 3264 [RFC3264], a port number of zero in the offer According to RFC 3264 [RFC3264], a port number of zero in the offer
of a unicast stream indicates that the stream is offered but must not 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 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 unicast stream, it indicates that the stream is rejected. These
rules are still valid when the media line in SDP represents a rules are still valid when the media line in SDP represents a
circuit-switched bearer. circuit-switched bearer.
The <proto> sub-field is the transport protocol. The circuit- The <proto> sub-field is the transport protocol. The circuit-
switched bearer uses whatever transport protocol it has available. switched bearer uses whatever transport protocol it has available.
skipping to change at page 12, line 7 skipping to change at page 13, line 18
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]
dtmf-mech = "dtmf" [":" dtmf-value] dtmf-mech = "dtmf" [":" dtmf-value]
ext-mech = <ext-mech-name>[":"<ext-mech-value>] ext-mech = <ext-mech-name>[":"<ext-mech-value>]
The values "callerid", "uuie" and "dtmf" refer to the correlation The values "callerid", "uuie" and "dtmf" refer to the correlation
mechanisms defined in Section 5.2.3.2, Section 5.2.3.3, and mechanisms defined in Section 5.2.3.2, Section 5.2.3.3, and
Section 5.2.3.4, respectively. The formal Augmented Backus-Naur Section 5.2.3.4, respectively. The formal Augmented Backus-Naur
Format (ABNF) syntax of the "cs-correlation" attribute is presented Format (ABNF) syntax of the "cs-correlation" attribute is presented
in Section 5.6. in Section 5.7.
5.2.3.2. Caller-ID Correlation Mechanism 5.2.3.2. Caller-ID Correlation Mechanism
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.
skipping to change at page 13, line 31 skipping to change at page 14, line 39
the call setup message of the PSTN protocol. The endpoint that the call setup message of the PSTN protocol. The endpoint that
initiates the call setup attempt includes this value in the User-User initiates the call setup attempt includes this value in the User-User
Information Element. The recipient of the call setup attempt can Information Element. The recipient of the call setup attempt can
extract the User-User Information Element and correlate it with the extract the User-User Information Element and correlate it with the
value previously received in the SDP. If both values match, then the value previously received in the SDP. If both values match, then the
call setup attempt corresponds to that indicated in the SDP. call setup attempt corresponds to that indicated in the SDP.
The first three octets of the User-User Information Element specified The first three octets of the User-User Information Element specified
in ITU-T Q.931 [ITU.Q931.1998] are the UUIE identifier, lenght of the in ITU-T Q.931 [ITU.Q931.1998] are the UUIE identifier, lenght of the
user-user contents, and a protocol discriminator, followed by the user-user contents, and a protocol discriminator, followed by the
actual User information. The first three octets of the UUIE MUST NOT actual User information. The first two octets of the UUIE MUST NOT
be used for correlation, only the octets carrying the User be used for correlation, only the octets carrying the Protocol
information value are compared the value of the "cs-correlation:uuie" Discriminator and the User information value are compared the value
attribute. of the "cs-correlation:uuie" attribute. The value of the Protocol
Discriminator octet is not specified in this document; it is expected
OPEN ISSUE: Need to confirm whether this is acceptable. that organizations using this technology will allocate a suitable
value for the Protocol Discriminator.
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 a opaque string and only used Information Element is considered as a 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 warranties that this correlation
skipping to change at page 16, line 9 skipping to change at page 17, line 19
4145 [RFC4145] for a detailed description of this attribute. 4145 [RFC4145] for a detailed description of this attribute.
Implementations according to this specification MUST support the Implementations according to this specification MUST support the
"setup" and "connection" attributes specified in RFC 4145 [RFC4145], "setup" and "connection" attributes specified in RFC 4145 [RFC4145],
but applied to circuit-switched bearers in the PSTN. but applied to circuit-switched bearers in the PSTN.
We define the active party as the one that initiates the circuit- We define the active party as the one that initiates the circuit-
switched bearer after the Offer/Answer process. The passive party is switched bearer after the Offer/Answer process. The passive party is
the one receiving the circuit-switched bearer. Either party may the one receiving the circuit-switched bearer. Either party may
indicate its desire to become the active or passive party during the indicate its desire to become the active or passive party during the
Offer/Answer exchange using the procedures described in Section 5.5. Offer/Answer exchange using the procedures described in Section 5.6.
5.3.2. Populating the cs-correlation attribute 5.3.2. Populating the cs-correlation attribute
By defining values for the sub-fields in the "a=cs-correlation" By defining values for the sub-fields in the "a=cs-correlation"
attribute, the endpoint indicates that it is willing to become the attribute, the endpoint indicates that it is willing to become the
active party, and that it can use those values in the Calling party active party, and that it can use those values in the Calling party
number, User-User Information Element, or as DTMF tones during the number, User-User Information Element, or as DTMF tones during the
circuit-switched bearer setup. circuit-switched bearer setup.
Thus, the following rules apply: Thus, the following rules apply:
skipping to change at page 18, line 5 skipping to change at page 19, line 14
5.4.2. Contact information 5.4.2. Contact information
SDP [RFC4566] defines the "p=" line which may include the phone SDP [RFC4566] defines the "p=" line which may include the phone
number of the person responsible for the conference. Even though number of the person responsible for the conference. Even though
this line can carry a phone number, it is not suited for the purpose 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 of defining a connection address for the media. Therefore, we have
selected to define the PSTN specific connection addresses in the "c=" selected to define the PSTN specific connection addresses in the "c="
line. line.
5.5. Offer/Answer mode extensions 5.5. Considerations for Usage of Third Party Call Control (3PCC)
Best Current Practices for Third Party Call Control (3pcc) in the
Session Initiation Protocol (SIP) [RFC3725] outlines several flows
which are possible in third party call control scenarios and
recommends some flows for specific situations.
One of the assumptions in [RFC3725] is that an SDP Offer may include
a "black hole" connection address, which has the property that
packets sent to it will never leave the host which sent them. For
IPv4, this "black hole" connection address is 0.0.0.0, or a domain
name within the .invalid DNS top level domain.
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 in
rejecting the Offer if the recipient of the Offer is not aware of
its own E.164 number, and thus concluding that it will not be
possible to establish a circuit-switched bearer since neither
party is aware of their E.164 number.
5.6. Offer/Answer mode extensions
In this section, we define extensions to the Offer/Answer model In this section, we define extensions to the Offer/Answer model
defined in The Offer/Answer Model in SDP [RFC3264] and extended in defined in The Offer/Answer Model in SDP [RFC3264] and extended in
the SDP Capability Negotiation [RFC5939] to allow for PSTN addresses the SDP Capability Negotiation [RFC5939] to allow for PSTN addresses
to be used with the Offer/Answer model. to be used with the Offer/Answer model.
5.5.1. Generating the Initial Offer 5.6.1. Generating the Initial Offer
The Offerer, wishing to use PSTN audio or video stream, MUST populate The Offerer, wishing to use PSTN audio or video stream, MUST populate
the "c=" and "m=" lines as follows. the "c=" and "m=" lines as follows.
The endpoint MUST set the <nettype> in the "c=" line to "PSTN", and The endpoint MUST set the <nettype> in the "c=" line to "PSTN", and
the <addrtype> to "E164". Furthermore, the endpoint SHOULD set the the <addrtype> to "E164". Furthermore, the endpoint SHOULD set the
<connection-address> field to its own international E.164 number <connection-address> field to its own international E.164 number
(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, the <port> to "9" "audio" or "video", depending on the media type, and the <proto> sub-
(the discard port), and the <proto> sub-field to "PSTN". field to "PSTN". The <port> sub-field SHOULD be set to "9" (the
discard port).
The <fmt> sub-field carries the payload type number(s) the endpoint The <fmt> sub-field carries the payload type number(s) the endpoint
is wishing to use. Payload type numbers in this case refer to the is wishing to use. Payload type numbers in this case refer to the
codecs that the endpoint wishes to use. For example, if the endpoint codecs that the endpoint wishes to use. For example, if the endpoint
wishes to use the GSM codec, it would add payload type number 3 in wishes to use the GSM codec, it would add payload type number 3 in
the list of codecs. the list of codecs.
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.
skipping to change at page 20, line 13 skipping to change at page 21, line 45
'actpass' or 'passive'. 'actpass' or 'passive'.
Also 'holdconn' is a permissible value in the 'a=setup' attribute. Also 'holdconn' is a permissible value in the 'a=setup' attribute.
It indicates that the connection is not established for the time It indicates that the connection is not established for the time
being. being.
The Offerer uses the "a=connection" attribute to decide whether a new The Offerer uses the "a=connection" attribute to decide whether a new
circuit-switched bearer is to be established or not. For the initial circuit-switched bearer is to be established or not. For the initial
Offer, the Offerer MUST use value 'new'. Offer, the Offerer MUST use value 'new'.
5.5.2. Generating the Answer 5.6.2. Generating the Answer
If the Offer contained a circuit-switched audio or video stream, the If the Offer contained a circuit-switched audio or video stream, the
Answerer first determines whether it is able to accept and use such Answerer first determines whether it is able to accept and use such
streams. If the Answerer is not willing to use circuit-switched streams. If the Answerer is not willing to use circuit-switched
media for the session, it MUST construct an Answer where the port 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 number for such media stream(s) is set to zero, according to Section
6 of An Offer/Answer Model with the Session Description Protocol 6 of An Offer/Answer Model with the Session Description Protocol
(SDP) [RFC3264]. (SDP) [RFC3264]. 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 If the Offer included a "-" as the payload type number, it indicates
that the Offerer is not willing or able to define any specific that the Offerer is not willing or able to define any specific
payload type. Most often, a "-" is expected to be used instead of 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 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- define the codecs which will eventually be used on the circuit-
switched bearer. The circuit-switched signaling protocols have their switched bearer. The circuit-switched signaling protocols have their
own means of negotiating or indicating the codecs, therefore an own means of negotiating or indicating the codecs, therefore an
Answerer SHOULD accept such Offers, and SHOULD set the payload type Answerer SHOULD accept such Offers, and SHOULD set the payload type
to "-" also in the Answer. to "-" also in the Answer.
skipping to change at page 22, line 28 skipping to change at page 24, line 14
correlation" attribute, the call SHOULD be treated as correlated correlation" attribute, the call SHOULD be treated as correlated
to the ongoing session. to the ongoing session.
o if the Offer contained a value for the "uuie" sub-field, MUST be o if the Offer contained a value for the "uuie" sub-field, MUST be
prepared to receive a User-User Information element once the prepared to receive a User-User Information element once the
circuit-switched bearer is set up. The Answerer MUST compare the circuit-switched bearer is set up. The Answerer MUST compare the
received UUI to the value of the "uuie" sub-field. If the value received UUI to the value of the "uuie" sub-field. If the value
of the received UUI matches the value of the "uuie" sub-field, the of the received UUI matches the value of the "uuie" sub-field, the
call SHOULD be treated as correlated to the ongoing session. call SHOULD be treated as correlated to the ongoing session.
5.5.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
Section 5.3.1. Section 5.3.1.
skipping to change at page 23, line 25 skipping to change at page 25, line 12
the "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" sub-field, MUST be o if the Answer contained a value for the "uuie" sub-field, MUST be
prepared to receive a User-User Information element once the prepared to receive a User-User Information element once the
circuit-switched bearer is set up. The Offerer SHOULD compare the circuit-switched bearer is set up. The Offerer SHOULD compare the
received UUI to the value of the "uuie" sub-field. If the value received UUI to the value of the "uuie" sub-field. If the value
of the received UUI matches the value of the "uuie" sub-field, the of the received UUI matches the value of the "uuie" sub-field, the
call SHOULD be treated as correlated to the ongoing session. call SHOULD be treated as correlated to the ongoing session.
5.5.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'.
skipping to change at page 24, line 5 skipping to change at page 25, line 37
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
exchange where it MUST set the "a=connection" attribute to 'new'". exchange where it MUST set the "a=connection" attribute to 'new'".
If the media types are different (for example, a different codec will If the media types are different (for example, a different codec will
be used for the circuit-switched bearer), the media descriptions for be used for the circuit-switched bearer), the media descriptions for
terminating the existing bearer and the new bearer can be in the same terminating the existing bearer and the new bearer can be in the same
Offer. Offer.
5.6. Formal Syntax 5.7. Formal Syntax
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] grammar. specification. The syntax is built above the SDP [RFC4566] grammar.
Implementations according to this specification MUST be compliant Implementations according to this specification MUST be compliant
with this syntax. 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 /= e164-address / "-" connection-address /= e164-address / "-"
e164-address = "+" 1*15DIGIT e164-address = "+" 1*15DIGIT
; DIGIT is specified in RFC 5234 ; DIGIT is specified in RFC 5234
;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 / dtmf-mech / ext-mech corr-mech = caller-id-mech / uuie-mech /
caller-id-mech = "callerid" [":" caller-id-value] dtmf-mech / ext-mech
caller-id-value = "+" 1*15DIGIT caller-id-mech = "callerid" [":" caller-id-value]
uuie-mech = "uuie" [":" uuie-value] caller-id-value = "+" 1*15DIGIT
uuie-value = 1*32(ALPHA/DIGIT) uuie-mech = "uuie" [":" uuie-value]
dtmf-mech = "dtmf" [":" dtmf-value] uuie-value = 1*32(ALPHA/DIGIT)
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. Example 6. Examples
In the examples below, where an SDP line is too long to be displayed
as a single line, a braking character "\" indicates continuation in
the following line. Note that this is character is included for
displaying purposes. Implementation MUST write a single line without
brakes.
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) |
|<---------------------------------| |<---------------------------------|
| | | |
| PSTN call setup | | PSTN call setup |
skipping to change at page 25, line 34 skipping to change at page 27, line 34
stream over a circuit-switched bearer. Alice generates a SDP Offer stream over a circuit-switched bearer. Alice generates a SDP Offer
which is show in Figure 4. The Offer describes a PSTN circuit- which is show in Figure 4. The Offer describes a PSTN circuit-
switched bearer in the "m=" and "c=" line where it also indicates its switched bearer in the "m=" and "c=" line where it also indicates its
international E.164 number format. Additionally, Alice expresses international E.164 number format. Additionally, Alice expresses
that she can initiate the circuit-switched bearer or be the recipient 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 a of it in the "a=setup" attribute line. The SDP Offer also includes a
correlation identifiers that this endpoint will be inserting the correlation identifiers that this endpoint will be inserting the
Calling Party Number and/or User-User Information Element of the PSTN Calling Party Number and/or User-User Information Element of the PSTN
call setup if eventually this endpoint initiates the PSTN call. 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 +35891234567
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=cs-correlation:callerid:+15551234 uuie:2890W284hAT452612908awudfjang908 a=cs-correlation:callerid:+15551234 \
uuie:2890W284hAT452612908awudfjang908
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 +35897654321
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cs-correlation:callerid:+15554321 uuie:2127W49uThi455916adjfhtow9619361 a=cs-correlation:callerid:+15554321 \
uuie:2127W49uThi455916adjfhtow9619361
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.
Bob initiates a circuit-switched bearer using whatever circuit- Bob initiates a circuit-switched bearer using whatever circuit-
skipping to change at page 26, line 44 skipping to change at page 29, line 5
It may also be that neither the UUIE nor the calling party number is 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 received by the called party, or the format of the calling party
number is changed by the PSTN. Implementations may still accept such number is changed by the PSTN. Implementations may still accept such
call establishment attempts as being related to the session that was call establishment attempts as being related to the session that was
established in the IP network. As it cannot be guaranteed that the established in the IP network. As it cannot be guaranteed that the
values used for correlation are always passed intact through the values used for correlation are always passed intact through the
network, they should be treated as additional hints that the circuit- network, they should be treated as additional hints that the circuit-
switched bearer is actually related to the session. switched bearer is actually related to the session.
6.2. Advanced SDP example: Circuit-Switched Audio and Video Streams
Alice Bob
| |
| (1) SDP Offer (PSTN audio and video) |
|------------------------------------------->|
| |
| (2) SDP Answer (PSTN audio) |
|<-------------------------------------------|
| |
| PSTN call setup |
|<-------------------------------------------|
| |
|<======== media over PSTN bearer ==========>|
| |
Figure 6: Circuit-Switched Audio and Video streams
Figure 6 shows an example of negotiating audio and video media
streams over circuit-switched bearers.
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
a=setup:actpass
a=connection:new
a=cs-correlation:dtmf:112233
c=PSTN E164 +35891234567
m=audio 9 PSTN -
m=video 9 PSTN 34
a=rtpmap:34 H263/90000
Figure 7: SDP offer with circuit-switched audio and video (1)
Upon receiving the SDP offer descibed in Figure 7, 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 cs-correlation:dtmf sub-
field, which he is going send as DTMF tones once the bearer setup is
complete. The Answer is described in Figure 8
v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7
s=
t=0 0
a=setup:active
a=connection:new
a=cs-correlation:dtmf:332211
c=PSTN E164 +35897654321
m=audio 9 PSTN -
m=video 0 PSTN 34
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
identifiers that are used to evaluate whether an incoming circuit- identifiers that are used to evaluate whether an incoming circuit-
switched bearer is related to an ongoing session in the IP domain. switched bearer is related to an ongoing session in the IP domain.
If an attacker replicates the correlation identifer and establishes a If an attacker replicates the correlation identifer and establishes a
call within the time window the receiving endpoint is expecting a call within the time window the receiving endpoint is expecting a
call, the attacker may be able to hijack the circuit-switched bearer. call, the attacker may be able to hijack the circuit-switched bearer.
These types of attacks are not specific to the mechanisms presented These types of attacks are not specific to the mechanisms presented
in this memo. For example, caller ID spoofing is a well known attack in this memo. For example, caller ID spoofing is a well known attack
in the PSTN. Users are advised to use the same caution before in the PSTN. Users are advised to use the same caution before
revealing sensitive information as they would on any other phone revealing sensitive information as they would on any other phone
call. Furthermore, users are advised that mechanisms that may be in call. Furthermore, users are advised that mechanisms that may be in
use in the IP domain for securing the media, like Secure RTP (SRTP) use in the IP domain for securing the media, like Secure RTP (SRTP)
[RFC3711], are not available in the CS domain. [RFC3711], 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 the protect the
SDP containing phone numbers carried in SIP, implementers are adviced
to follow the security mechanisms defined in [RFC3261].
8. IANA Considerations 8. IANA Considerations
This document instructs IANA to register a number of SDP tokens This document instructs IANA to register a number of SDP tokens
according to the following data. according to the following data.
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
skipping to change at page 30, line 16 skipping to change at page 33, line 51
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
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[TS.24.008] [TS.24.008]
3GPP, "Mobile radio interface Layer 3 specification; Core 3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", 3GPP TS 24.008 3.20.0, network protocols; Stage 3", 3GPP TS 24.008 3.20.0,
December 2005. December 2005.
URIs URIs
 End of changes. 32 change blocks. 
111 lines changed or deleted 237 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/