draft-ietf-mmusic-sdp-cs-07.txt   draft-ietf-mmusic-sdp-cs-08.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: February 23, 2012 Nokia Expires: April 15, 2012 Nokia
August 22, 2011 October 13, 2011
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 Video Media Streams Over Circuit-Switched Bearers In The Public Switched
Switched Telephone Network (PSTN) Telephone Network (PSTN)
draft-ietf-mmusic-sdp-cs-07 draft-ietf-mmusic-sdp-cs-08
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 February 23, 2012. This Internet-Draft will expire on April 15, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 9 5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 9
5.2.3. Correlating the PSTN Circuit-Switched Bearer with 5.2.3. Correlating the PSTN Circuit-Switched Bearer with
SDP . . . . . . . . . . . . . . . . . . . . . . . . . 10 SDP . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 11 5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 11
5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 11 5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 11
5.2.3.3. User-User Information Element Correlation 5.2.3.3. User-User Information Element Correlation
Mechanism . . . . . . . . . . . . . . . . . . . . 12 Mechanism . . . . . . . . . . . . . . . . . . . . 12
5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 13 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 13
5.3. Negotiating the correlation mechanisms . . . . . . . . . . 14 5.3. Negotiating the correlation mechanisms . . . . . . . . . . 14
5.3.1. Determining the Direction of the Circuit-Switched 5.3.1. Determining the Direction of the Circuit-Switched
Connection Setup . . . . . . . . . . . . . . . . . . . 14 Bearer Setup . . . . . . . . . . . . . . . . . . . . . 14
5.3.2. Offerer behaviour . . . . . . . . . . . . . . . . . . 16 5.3.2. Populating the cs-correlation attribute . . . . . . . 15
5.3.3. Answerer behaviour . . . . . . . . . . . . . . . . . . 17 5.3.3. Considerations on successful correlation . . . . . . . 16
5.3.4. Considerations on successful correlation . . . . . . . 19 5.4. Considerations for Usage of Existing SDP . . . . . . . . . 16
5.4. Considerations for Usage of Existing SDP . . . . . . . . . 19 5.4.1. Originator of the Session . . . . . . . . . . . . . . 16
5.4.1. Originator of the Session . . . . . . . . . . . . . . 19 5.4.2. Contact information . . . . . . . . . . . . . . . . . 17
5.4.2. Contact information . . . . . . . . . . . . . . . . . 20 5.5. Offer/Answer mode extensions . . . . . . . . . . . . . . . 17
5.5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 20 5.5.1. Generating the Initial Offer . . . . . . . . . . . . . 17
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.5.2. Generating the Answer . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5.5.3. Offerer processing the Answer . . . . . . . . . . . . 22
7.1. Registration of new correlation SDP attribute . . . . . . 22 5.5.4. Modifying the session . . . . . . . . . . . . . . . . 23
7.2. Registration of a new "nettype" value . . . . . . . . . . 23 5.6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 23
7.3. Registration of new "addrtype" values . . . . . . . . . . 23 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.4. Registration of a new "proto" value . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Registration of new cs-correlation SDP attribute . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.2. Registration of a new "nettype" value . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8.3. Registration of new "addrtype" values . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 8.4. Registration of a new "proto" value . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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 26 skipping to change at page 5, line 26
There are additional use cases related to third party call control There are additional use cases related to third party call control
where the session setup time is improved when the circuit-switched where the session setup time is improved when the circuit-switched
bearer in the PSTN is described together with one or more codecs. bearer in the PSTN is described together with one or more codecs.
The rest of the document is structured as follows: Section 2 provides The rest of the document is structured as follows: Section 2 provides
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 7 and Section 8 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant [RFC2119] and indicate requirement levels for compliant
implementations. implementations.
skipping to change at page 6, line 6 skipping to change at page 6, line 6
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.
REQ-2: The mechanism MUST allow the endpoints to combine circuit- REQ-2: The mechanism MUST allow the endpoints to combine circuit-
switched audio or video media streams with other switched audio or video media streams with other
complementary media streams, for example, text messaging. complementary media streams, for example, text messaging.
REQ-3: The mechanism MUST allow the endpoint to negotiate the REQ-3: The mechanism MUST allow the endpoint to negotiate the
direction of the circuit-switched connection, i.e., which direction of the circuit-switched bearer, i.e., which
endpoint is active when initiating the circuit-switched endpoint is active when initiating the circuit-switched
connection. bearer.
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.
skipping to change at page 7, line 28 skipping to change at page 7, line 28
Figure 1: Example Flow Figure 1: Example Flow
Bob receives the SDP offer and determines that he is located in an Bob receives the SDP offer and determines that he is located in an
environment where the IP based bearer is not suitable for real-time environment where the IP based bearer is not suitable for real-time
audio media. However he also has PSTN circuit-switched bearer audio media. However he also has PSTN circuit-switched bearer
available for audio. Bob generates an SDP answer containing a available for audio. Bob generates an SDP answer containing a
description of the audio media stream over a circuit-switched bearer. description of the audio media stream over a circuit-switched bearer.
During the offer-answer exchange Alice and Bob also agree the During the offer-answer exchange Alice and Bob also agree the
direction in which the circuit-switched connection should be direction in which the circuit-switched bearer should be established.
established. In this example, Bob becomes the active party, in other In this example, Bob becomes the active party, in other words, he
words, he establishes the circuit-switched call to the other establishes the circuit-switched call to the other endpoint. The
endpoint. The Offer/Answer exchange contains identifiers or Offer/Answer exchange contains identifiers or references that can be
references that can be used on the circuit-switched network for used on the circuit-switched network for addressing the other
addressing the other endpoint, as well as information that is used to endpoint, as well as information that is used to determine that the
determine that the incoming circuit-switched bearer establishment is incoming circuit-switched bearer establishment is related to the
related to the ongoing session between Alice and Bob. ongoing session between Alice and Bob.
Bob establishes a circuit-switched bearer towards Alice using Bob establishes a circuit-switched bearer towards Alice using
whatever mechanisms are defined for the network type in question. whatever mechanisms are defined for the network type in question.
When receiving the incoming circuit-switched connection attempt, When receiving the incoming circuit-switched connection attempt,
Alice is able to determine that the attempt is related to the session Alice is able to determine that the attempt is related to the session
she is just establishing with Bob. she is just establishing with Bob.
Alice accepts the circuit-switched connection; the circuit-switched Alice accepts the circuit-switched connection; the circuit-switched
bearer setup is completed. Bob and Alice can now use the circuit- bearer setup is completed. Bob and Alice can now use the circuit-
switched connection for two-way audio media. switched connection for two-way audio media.
skipping to change at page 8, line 11 skipping to change at page 8, 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 and Section 5.4. considerations discussed in Section 5.3, Section 5.4 and Section 5.5.
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 11, line 31 skipping to change at page 11, line 31
Caller-ID, User to User Information, or DTMF correlation mechanisms, Caller-ID, User to User Information, or DTMF correlation mechanisms,
respectively. The list of correlation mechanisms may be extended by respectively. The list of correlation mechanisms may be extended by
other specifications. other specifications.
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: callerid:<callerid-value> | a=cs-correlation: callerid:<callerid-value> |
uuie:<uuie-value> | uuie:<uuie-value> |
dtmf:<dtmf-value> | dtmf:<dtmf-value> |
[extension-name:<extension-value>] *[extension-name:<extension-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.5. in Section 5.6.
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 in E.164 format in SDP, followed by the calling party number in E.164 format in SDP, followed by the
availability of the Calling Party Number information element in the availability of the Calling Party Number information element in the
call setup signaling of the circuit switched connection. If both call setup signaling of the circuit switched connection. If both
pieces of information match, the circuit-switched bearer is pieces of information match, the circuit-switched bearer is
correlated to the session described in SDP. correlated to the session described in SDP.
Example of inclusion of E.164 number in the "cs-correlation" Example of inclusion of E.164 number in the "cs-correlation"
attribute is: attribute is:
a=cs-correlation:callerid:+15551234 a=cs-correlation:callerid:+15551234
The presence of the "callerid" sub-field indicates that the endpoint The presence of the "callerid" sub-field 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" sub- PSTN call with the session being negotiated. The "callerid" sub-
field MAY be accompanied by the E.164 number of the party inserting field MAY be accompanied by the E.164 number of the party inserting
the parameter. For details on negotiating the correlation the parameter.
mechanisms, see Section 5.3.
Note that there are no warranties that this correlation mechanism Note that there are no warranties that this correlation mechanism
works or is even available, due a number of problems: works or is even available, due a number of problems:
* The endpoint might not be aware of its own E.164 number, in o The endpoint might not be aware of its own E.164 number, in which
which case it cannot populate the SDP appropriately. case it cannot populate the SDP appropriately.
* 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 restrictions of the network operator or caller restriction due to
to privacy. privacy.
* 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. For example, one can be represented in expressed in the SDP. For example, one can be represented in
international format and the other might only contain the international format and the other might only contain the
significant national digits. To mitigate this problem significant national digits. To mitigate this problem
implementations should consider only some of the rightmost implementations should consider only some of the rightmost digits
digits from the E.164 number for correlation. For example, the from the E.164 number for correlation. For example, the numbers
numbers +358-1-555-12345 and 01-555-12345 could be considered +358-1-555-12345 and 01-555-12345 could be considered as the same
as the same number. This is also the behavior of some cellular number. This is also the behavior of some cellular phones, which
phones, which correlate the incoming calling party with a correlate the incoming calling party with a number stored in the
number stored in the phone book, for the purpose of displaying phone book, for the purpose of displaying the caller's name.
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
3GPP TS 24.008 [3GPP.24.008], among others. The User-User 3GPP TS 24.008 [TS.24.008], among others. The User-User Information
Information Element has a maximum size of 35 or 131 octets, depending Element has a maximum size of 35 or 131 octets, depending on the
on the actual message of the PSTN protocol where it is included. actual message of the PSTN protocol where it is included.
The mechanism works as follows: An endpoint creates a User-User The mechanism works as follows: An endpoint creates a User-User
Information Element, according to the requirements of the call setup Information Element, according to the requirements of the call setup
signaling protocol. The same value is included in the SDP offer or signaling protocol. The same value is included in the SDP offer or
SDP answer, in a "cs-correlation:uuie" attribute. When the SDP SDP answer, in a "cs-correlation:uuie" attribute. When the SDP
Offer/Answer exchange is completed, each endpoint has become aware of Offer/Answer exchange is completed, each endpoint has become aware of
the value that will be used in the User-User Information Element of the value that will be used in the User-User Information Element of
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
skipping to change at page 14, line 25 skipping to change at page 14, line 21
As an example, an endpoint willing to send DTMF tone sequence "14D*3" As an example, an endpoint willing to send DTMF tone sequence "14D*3"
would include a "cs-correlation" attribute line as follows: would include a "cs-correlation" attribute line as follows:
a=cs-correlation:dtmf:14D*3 a=cs-correlation:dtmf:14D*3
If the endpoints successfully agree on the usage of the DTMF digit If the endpoints successfully agree on the usage of the DTMF digit
correlation mechanism, but the passive side does not receive any DTMF correlation mechanism, but the passive side does not receive any DTMF
digits after successful circuit-switched bearer setup, or receives a digits after successful circuit-switched bearer setup, or receives a
set of DTMF digits that do not match the value of the "dtmf" set of DTMF digits that do not match the value of the "dtmf"
attribute (including receving too many digits), the passive side attribute (including receiving too many digits), the passive side
SHOULD treat the circuit-switched bearer as not correlated to the SHOULD treat the circuit-switched bearer as not correlated to the
ongoing session. ongoing session.
DTMF digits can only be sent once the circuit-switched bearer is DTMF digits can only be sent once the circuit-switched bearer is
set up. In order to suppress alerting for an incoming circuit- set up. In order to suppress alerting for an incoming circuit-
switched call, implementations may choose various mechanisms. For switched call, implementations may choose various mechanisms. For
example, alerting may be suppressed for a certain time period for example, alerting may be suppressed for a certain time period for
incoming call attempts that originate from the number that was incoming call attempts that originate from the number that was
observed during the offer/answer negotiation. observed during the 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. are non-exclusive, and can be used independently of each other. In
order to know how to populate the "a=cs-correlation" attribute, the
In order to agree which correlation mechanisms are supported and used endpoints need to agree which endpoint will become the active party,
by each endpoint, we define a negotiation mechanism similar to the i.e. the one that will set up the circuit-switched bearer.
one defined for codec negotiation. The sections below describe
active/passive party determination and Offerer and Answerer behaviour
for negotiating the correlation mechanisms.
5.3.1. Determining the Direction of the Circuit-Switched Connection 5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup
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 should be negotiated during the circuit-switched bearer is set up should 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
TCP connection. While RFC 4145 [RFC4145] was originally designed for TCP connection. While RFC 4145 [RFC4145] was originally designed for
establishing TCP connections, it can be easily extrapolated to the establishing TCP connections, it can be easily extrapolated to the
skipping to change at page 15, line 35 skipping to change at page 15, line 27
The "connection" attribute indicates whether a new connection is The "connection" attribute indicates whether a new connection is
needed or an existing connection is reused. The attribute can take needed or an existing connection is reused. The attribute can take
the values "new" or "existing". Please refer to Section 5 of RFC the values "new" or "existing". Please refer to Section 5 of RFC
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 call 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 call. 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 below. Offer/Answer exchange using the procedures described in Section 5.5.
In order to establish a circuit-switched connection in the PSTN, the 5.3.2. Populating the cs-correlation attribute
initiating endpoint needs to know the address (E.164 number) of the
other endpoint. Therefore, if an endpoint wants to be able to
receive incoming circuit-switched calls (i.e., become the passive
party), it must know its E.164 number and must indicate it in SDP.
As a consequence, an endpoint that is not aware of its own E.164
number cannot take the role of the passive side with respect the
establishment of the circuit-switched connection.
5.3.2. Offerer behaviour By defining values for the sub-fields in the "a=cs-correlation"
attribute, the endpoint indicates that it is willing to become the
active party, and that it can use those values in the Calling party
number, User-User Information Element, or as DTMF tones during the
circuit-switched bearer setup.
When generating the Offer, If the Offerer supports any of the Thus, the following rules apply:
correlation mechanisms defined in this memo, it SHOULD include an
An endpoint that can only become the active party in the circuit-
switched bearer setup MUST include all correlation mechanisms it
supports in the "a=cs-correlation" attribute, and MUST also
specify values for the sub-fields.
An endpoint that can only become the passive party in the circuit-
switched bearer setup MUST include all correlation mechanisms it
supports in the "a=cs-correlation" attribute, but MUST NOT specify
values for the sub-fields.
An endpoint that is willing to become either the active or passive
party (by including the "a=setup:actpass" attribute in the Offer),
MUST include all correlation mechanisms it supports in the "a=cs-
correlation" attribute, and MUST also specify values for the sub-
fields.
5.3.3. Considerations on successful correlation
Note that, as stated above, it cannot be guaranteed that any given
correlation mechanism will succeed even if the usage of those was
agreed beforehand. This is due to the fact that the correlation
mechanisms require support from the circuit-switched bearer
technology used.
Therefore, even a single positive indication using any of these
mechanisms SHOULD be interpreted by the passive endpoint so that the
circuit-switched bearer establishment is related to the ongoing
session, even if the other correlation mechanisms fail.
If, after negotiating one or more correlation mechanisms in the SDP
offer/answer exchange, an endpoint receives a circuit-switched bearer
with no correlation information present, the endpoint has two
choices: it can either treat the call as unrelated, or treat the call
as related to the ongoing session in the IP domain.
An endpoint may for example specify a time window after SDP offer/
answer exchange during which received calls are treated as correlated
even if the signaling in the circuit-switched domain does not carry
any correlation information. In this case, there is a chance that
the call is erroneously treated as related to the ongoing session.
An endpoint may also choose to always treat an incoming call as
unrelated if the signaling in the circuit-switched domain does not
carry any correlation information. In this case, there is a chance
that the call is erroneously treated as unrelated.
Since, in these cases, no correlation information can be deduced from
the signaling, it is up to the implementation to decide how to
behave. One option is also to let the user decide whether to accept
the call as related, or to treat the call as unrelated.
5.4. Considerations for Usage of Existing SDP
5.4.1. Originator of the Session
According to SDP [RFC4566], the origin line in SDP has the following
syntax:
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
Of interest here are the <nettype> and <addrtype> fields, which
indicate the type of network and type of address, respectively.
Typically, this field carries the IP address of the originator of the
session. Even if the SDP was used to negotiate an audio or video
media stream transported over a circuit-switched bearer, the
originator is using SDP over an IP bearer. Therefore, <nettype> and
<addrtype> fields in the "o=" line should be populated with the IP
address identifying the source of the signaling.
5.4.2. Contact information
SDP [RFC4566] defines the "p=" line which may include the phone
number of the person responsible for the conference. Even though
this line can carry a phone number, it is not suited for the purpose
of defining a connection address for the media. Therefore, we have
selected to define the PSTN specific connection addresses in the "c="
line.
5.5. Offer/Answer mode extensions
In this section, we define extensions to the Offer/Answer model
defined in The Offer/Answer Model in SDP [RFC3264] and extended in
the SDP Capability Negotiation [RFC5939] to allow for PSTN addresses
to be used with the Offer/Answer model.
5.5.1. Generating the Initial Offer
The Offerer, wishing to use PSTN audio or video stream, MUST populate
the "c=" and "m=" lines as follows.
The endpoint MUST set the <nettype> in the "c=" line to "PSTN", and
the <addrtype> to "E164". Furthermore, the endpoint SHOULD set the
<connection-address> field to its own E.164 number in the
international format (beginning with a "+"). If the endpoint is not
aware of its own E.164 number, it MUST set the <connection-address>
to "-".
In the "m=" line, the endpoint MUST set the <media> subfield to
"audio" or "video", depending on the media type, the <port> to "9"
(the discard port), and the <proto> sub-field to "PSTN".
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
codecs that the endpoint wishes to use. For example, if the endpoint
wishes to use the GSM codec, it would add payload type number 3 in
the list of codecs.
For dynamic payload types, the endpoint MUST define the set of valid
encoding names and related parameters using the "a=rtpmap" attribute
line. See Section 6 of SDP [RFC4566] for details.
When generating the Offer, if the Offerer supports any of the
correlation mechanisms defined in this memo, it MUST include an
attribute line "a=cs-correlation" in the SDP offer. The "a=cs- attribute line "a=cs-correlation" in the SDP offer. The "a=cs-
correlation" line contains an enumeration of the correlation correlation" line contains an enumeration of the correlation
mechanisms supported by the Offerer, in the format of sub-fields. mechanisms supported by the Offerer, in the format of sub-fields.
The current list of sub-fields include "callerid", "uuie" and "dtmf" The current list of sub-fields include "callerid", "uuie" and "dtmf"
and they refer to the correlation mechanisms defined in and they refer to the correlation mechanisms defined in
Section 5.2.3.2, Section 5.2.3.3, and Section 5.2.3.4, respectively. Section 5.2.3.2, Section 5.2.3.3, and Section 5.2.3.4, respectively.
If the Offerer is only able to become the active party (for example If the Offerer supports any of the correlation mechanisms defined in
because it doesn't know its E.164 address), the Offerer SHOULD add this memo, and is willing to become the active party, the Offerer
the "callerid", "uuie", and/or "dtmf" sub-fields but MUST NOT specify MUST add the "callerid", "uuie", and/or "dtmf" sub-fields and MUST
a value for those sub-fields. specify values for those sub-fields.
If the Offerer is able to become the passive party in the circuit-
switched call setup, it SHOULD add values to all correlation
mechanisms it supports:
o the E.164 number as the value in the "callerid" sub-field, o the E.164 number as the value in the "callerid" sub-field,
o the contents of the User-User information element as the value of o the contents of the User-User information element as the value of
the "uuie" sub-field, and the "uuie" sub-field, and/or
o the DTMF tone string as the value of the "dtmf" sub-field o the DTMF tone string as the value of the "dtmf" sub-field
If the Offerer is only able to become the passive party in the
circuit-switched bearer setup, it MUST add the "callerid", "uuie"
and/or "dtmf" sub-fields, but MUST NOT specify values for those sub-
fields.
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 active party, it includes the following line to the SDP: become the passive party, it includes the following lines to the SDP:
a=cs-correlation:uuie dtmf a=cs-correlation:uuie dtmf
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 passive side, it includes to following line to the SDP: to become the active or passive side, it includes to following lines
to the SDP:
a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3 a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3
When receiving the Answer, if the SDP does not contain "a=cs- a=setup:actpass
correlation" attribute line, the Offerer should take that as an
indication that the other party does not support or is not willing to
use the procedures defined in the document for this session, and MUST
revert to normal processing of SDP.
When receiving the Answer, the Offerer MUST first determine whether The negotiation of the value of the 'setup' attribute takes place as
it becomes the active or passive party, as described in Section defined in Section 4.1 of TCP-Based Media Transport in the SDP
Section 5.3.1. [RFC4145].
If the Offerer becomes the active party, it The Offerer states which role or roles it is willing to perform; and
the Answerer, taking the Offerer's willingness into consideration,
chooses which roles both endpoints will actually perform during the
circuit-switched bearer setup.
o SHOULD extract the E.164 address from the "c=" line and SHOULD By 'active' endpoint, we refer to an endpoint that will establish the
establish a circuit-switched call to that address. circuit-switched bearer; and by 'passive' endpoint, we refer to an
endpoint that will receive a circuit-switched bearer.
o if the SDP Answer contained a value for the "uuie" sub-field, If an Offerer does not know its E.164 address, it MUST set the
SHOULD send the User-User Information element according to the 'a=setup' attribute to the value 'active'. If the Offerer knows its
rules defined for the circuit-switched technology used, and set E.164 address, it MUST set the value to either 'actpass' or
the value of the Information Element to that received in the SDP 'passive'.
Answer,
o if the SDP Answer contained a value for the "dtmf" sub-field, Also 'holdconn' is a permissible value in the 'a=setup' attribute.
SHOULD send those DTMF digits according to the circuit-switched It indicates that the connection is not established for the time
technology used. being.
If the Offerer becomes the passive party, it The Offerer uses the "a=connection" attribute to decide whether a new
circuit-switched bearer is to be established or not. If there is no
circuit-switched bearer established between the endpoints, the
Offerer MUST use a value of 'new' in the "a=connection" attribute.
If there is an existing circuit-switched bearer between the
endpoints, and the Offerer wants to reuse that (for example, in the
case of an updated Offer), the Offerer MUST set the value of the
"a=connection" attribute to "existing".
o MUST be prepared to receive a circuit-switched call, 5.5.2. Generating the Answer
o MUST be prepared to receive and collect DTMF digits once the If the Offer contained a circuit-switched audio or video stream, the
circuit-switched bearer is set up. The Offerer SHOULD compare the Answerer first determines whether it is able to accept and use such
received DTMF digits to the value of the "dtmf" sub-field. If the streams. If the Answerer is not willing to use circuit-switched
received DTMF digits match the value of the "dtmf" sub-field in media for the session, it MUST construct an Answer where the port
the "cs-correlation" attribute, the call SHOULD be treated as number for such media stream(s) is set to zero, according to Section
correlated to the ongoing session. 6 of An Offer/Answer Model with the Session Description Protocol
(SDP) [RFC3264].
o MUST be prepared to receive a User-User Information element once If the Offer included a "-" as the payload type number, it indicates
the circuit-switched bearer is set up. The Offerer SHOULD compare that the Offerer is not willing or able to define any specific
the received UUI to the value of the "uuie" sub-field. If the payload type. Most often, a "-" is expected to be used instead of
value of the received UUI matches the value of the "uuie" sub- the payload type when the endpoint is not aware of or not willing to
field, the call SHOULD be treated as correlated to the ongoing define the codecs which will eventually be used on the circuit-
session. switched bearer. The circuit-switched signaling protocols have their
own means of negotiating or indicating the codecs, therefore an
Answerer SHOULD accept such Offers, and SHOULD set the payload type
to "-" also in the Answer.
5.3.3. Answerer behaviour If the Answerer explicitly wants to specify a codec for the circuit-
switched media, it MAY set the respective payload numbers in the
<fmt> sub-field in the answer. This behavior, however, is NOT
RECOMMENDED.
When receiving the Offer, the Answerer MUST first determine whether When receiving the Offer, the Answerer MUST determine whether it
it becomes the active or passive party, as described in Section becomes the active or passive party.
Section 5.3.1.
If the SDP in the Offer indicates that the Offerer is only able to If the SDP in the Offer indicates that the Offerer is only able to
become the active party ("a=setup" line is set to "active", the become the active party, the Answerer needs to determine whether it
Answerer needs to determine whether it is able to become the passive is able to become the passive party. If this is not possible e.g.
party. If this is not possible e.g. due to the Answerer not knowing due to the Answerer not knowing its E.164 address, the Answerer MUST
its E.164 address, the Answerer MUST NOT include "a=setup", reject the circuit-switched media by setting the port number to zero
"a=connection" or "a=cs-correlation" attributes in the Answer. on the Answer. If the Answerer is aware of its E.164 number, it MUST
include the "a=setup" attribute in the Answer and set it to value
"passive" or "holdconn".
When generating the answer, the Answerer SHOULD select those If the SDP in the Offer indicates that the Offerer is only able to
correlation mechanisms from the Offer it supports, and include an become the passive party, the Answerer MUST verify that the Offerer's
"a=cs-correlation" attribute line in the answer containing those E.164 number is included in the "c=" line of the Offer. If the
mechanisms it supports. The Answerer MUST NOT add any mechanisms number is included, the Answerer MUST include the "a=setup" attribute
which were not included in the offer. in the Answer and set it to value "active" or "holdconn". If the
number is not included, call establishment is not possible, and the
Answerer MUST reject the circuit-switched media by setting the port
number to zero in the Answer.
If the Answerer becomes the active party, it MUST NOT add parameter If the SDP in the Offer indicates that the Offerer is able to become
either the active or passive party, the Answerer needs to determine
which role it would like to take. If the Offer includes an E.164
address in the "c=" line, the Answerer SHOULD become the active
party. If the Offer does not include an E.164 number, and if the
Answerer is aware of its E.164 number, it MUST become the passive
party. If the Offer does not include an E.164 number in the "c="
line and the Answerer is not aware of its E.164 number, it MUST
reject the circuit-switched media by setting the port number to zero
in the Answer.
The Answerer MUST select those correlation mechanisms from the Offer
it supports, and include an "a=cs-correlation" attribute line in the
Answer containing those mechanisms it supports. The Answerer MUST
NOT add any mechanisms which were not included in the offer.
If the Answerer becomes the active party, it MUST add parameter
values to the "callerid", "uuie" or "dtmf" sub-fields. values to the "callerid", "uuie" or "dtmf" sub-fields.
If the Answerer becomes the passive party, it MUST add values to the If the Answerer becomes the passive party, it MUST NOT add values to
"callerid", "uuie" and/or "dtmf" sub-fields. the "callerid", "uuie" and/or "dtmf" sub-fields.
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
o SHOULD extract the E.164 address from the "c=" line of the Offer o MUST extract the E.164 address from the "c=" line of the Offer and
and SHOULD establish a circuit-switched call to that address. MUST establish a circuit-switched bearer to that address.
o if the SDP Offer contained a value for the "uuie" sub-field, o if the SDP Answer contained a value for the "callerid" sub-field,
SHOULD send the User-User Information element according to the must set the Calling Party Number Information Element to that
rules defined for the circuit-switched technology used, and set number,
the value of the Information Element to that received in the SDP
o if the SDP Answer contained a value for the "uuie" sub-field, MUST
send the User-User Information element according to the rules
defined for the circuit-switched technology used, and set the
value of the Information Element to that received in the SDP
Offer, Offer,
o if the SDP Offer contained a value for the "dtmf" sub-field, o if the SDP Answer contained a value for the "dtmf" sub-field, MUST
SHOULD send those DTMF digits according to the circuit-switched send those DTMF digits according to the circuit-switched
technology used technology used.
If, on the other hand, the Answerer became the passive party, it If, on the other hand, the Answerer became the passive party, it
MUST be prepared to receive a circuit-switched call, o MUST be prepared to receive a circuit-switched bearer,
MUST be prepared to receive and collect DTMF digits once the o if the Offer contained a value for the "callerid" sub-field, MUST
circuit-switched bearer is set up. The Answerer SHOULD compare compare that value to the Calling Party Number Information Element
the received DTMF digits to the value of the "dtmf" sub-field. If of the circuit-switched bearer,
the received DTMF digits match the value of the "dtmf" sub-field
in the "cs-correlation" attribute, the call SHOULD be treated as
correlated to the ongoing session.
MUST be prepared to receive a User-User Information element once o if the Offer contained a value for the "dtmf" sub-field, MUST be
the circuit-switched bearer is set up. The Answerer SHOULD prepared to receive and collect DTMF digits once the circuit-
compare the received UUI to the value of the "uuie" sub-field. If switched bearer is set up. The Answerer MUST compare the received
the value of the received UUI matches the value of the "uuie" sub- DTMF digits to the value of the "dtmf" sub-field. If the received
field, the call SHOULD be treated as correlated to the ongoing DTMF digits match the value of the "dtmf" sub-field in the "cs-
session. correlation" attribute, the call SHOULD be treated as correlated
to the ongoing session.
5.3.4. Considerations on successful correlation o if the Offer contained a value for the "uuie" sub-field, MUST be
prepared to receive a User-User Information element once the
circuit-switched bearer is set up. The Answerer MUST compare the
received UUI to the value of the "uuie" sub-field. If the value
of the received UUI matches the value of the "uuie" sub-field, the
call SHOULD be treated as correlated to the ongoing session.
Note that, as stated above, it cannot be guaranteed that any given 5.5.3. Offerer processing the Answer
correlation mechanism will succeed even if the usage of those was
agreed beforehand. This is due to the fact that the correlation
mechanisms require support from the circuit-switched bearer
technology used.
Therefore, even a single positive indication using any of these When receiving the Answer, if the SDP does not contain "a=cs-
mechanisms SHOULD be interpreted by the passive endpoint so that the correlation" attribute line, the Offerer should take that as an
circuit-switched bearer establishment is related to the ongoing indication that the other party does not support or is not willing to
session, even if the other correlation mechanisms fail. use the procedures defined in the document for this session, and MUST
revert to normal processing of SDP.
If, after negotiating one or more correlation mechanisms in the SDP When receiving the Answer, the Offerer MUST first determine whether
offer/answer exchange, an endpoint receives a circuit-switched call it becomes the active or passive party, as described in Section
with no correlation information present, the endpoint has two Section 5.3.1.
choices: it can either treat the call as unrelated, or treat the call
as related to the ongoing session in the IP domain.
An endpoint may for example specify a time window after SDP offer/ If the Offerer becomes the active party, it
answer exchange during which received calls are treated as correlated
even if the signaling in the circuit-switched domain does not carry
any correlation information. In this case, there is a chance that
the call is erroneously treated as related to the ongoing session.
An endpoint may also choose to always treat an incoming call as o MUST extract the E.164 address from the "c=" line and MUST
unrelated if the signaling in the circuit-switched domain does not establish a circuit-switched bearer to that address.
carry any correlation information. In this case, there is a chance
that the call is erroneously treated as unrelated.
Since, in these cases, no correlation information can be deduced from o if the SDP Answer contained a value for the "uuie" sub-field, MUST
the signaling, it is up to the implementation to decide how to send the User-User Information element according to the rules
behave. One option is also to let the user decide whether to accept defined for the circuit-switched technology used, and set the
the call as related, or to treat the call as unrelated. value of the Information Element to that received in the SDP
Answer,
5.4. Considerations for Usage of Existing SDP o if the SDP Answer contained a value for the "dtmf" sub-field, MUST
send those DTMF digits according to the circuit-switched
technology used.
5.4.1. Originator of the Session If the Offerer becomes the passive party, it
According to SDP [RFC4566], the origin line in SDP has the following o MUST be prepared to receive a circuit-switched bearer,
syntax:
o=<username> <sess-id> <sess-version> <nettype> <addrtype> o if the Answer contained a value for the "dtmf" sub-field, MUST be
<unicast-address> prepared to receive and collect DTMF digits once the circuit-
switched bearer is set up. The Offerer SHOULD compare the
received DTMF digits to the value of the "dtmf" sub-field. If the
received DTMF digits match the value of the "dtmf" sub-field in
the "cs-correlation" attribute, the call SHOULD be treated as
correlated to the ongoing session.
Of interest here are the <nettype> and <addrtype> fields, which o if the Answer contained a value for the "uuie" sub-field, MUST be
indicate the type of network and type of address, respectively. prepared to receive a User-User Information element once the
Typically, this field carries the IP address of the originator of the circuit-switched bearer is set up. The Offerer SHOULD compare the
session. Even if the SDP was used to negotiate an audio or video received UUI to the value of the "uuie" sub-field. If the value
media stream transported over a circuit-switched bearer, the of the received UUI matches the value of the "uuie" sub-field, the
originator is using SDP over an IP bearer. Therefore, <nettype> and call SHOULD be treated as correlated to the ongoing session.
<addrtype> fields in the "o=" line should be populated with the IP
address identifying the source of the signaling.
5.4.2. Contact information 5.5.4. Modifying the session
SDP [RFC4566] defines the "p=" line which may include the phone If, at a later time, one of the parties wishes to modify the session,
number of the person reponsible for the conference. Even though this e.g., by adding new media stream, or by changing properties used on
line can carry a phone number, it is not suited for the purpose of an existing stream, it may do so via the mechanisms defined for An
defining a connection address for the media. Therefore, we have Offer/Answer Model with SDP [RFC3264].
selected to define the PSTN specific connection addresses in the "c="
line.
5.5. Formal Syntax If either party removes the circuit-switched media from the session
(by setting the port number to zero), it MUST terminate the circuit-
switched bearer using whatever mechanism is appropriate for the
technology in question.
5.6. 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.
skipping to change at page 21, line 38 skipping to change at page 24, line 38
;0-9, A-D, '#' and '*' ;0-9, A-D, '#' and '*'
ext-mech = ext-mech-name[":" ext-mech-value] ext-mech = ext-mech-name[":" ext-mech-value]
ext-mech-name = token ext-mech-name = token
ext-mech-value = token ext-mech-value = token
; token is specified in RFC4566 ; token is specified in RFC4566
Figure 2: Syntax of the SDP extensions Figure 2: Syntax of the SDP extensions
6. Example 6. Example
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 |
|<---------------------------------| |<---------------------------------|
| | | |
|<==== media over PSTN bearer ====>| |<==== media over PSTN bearer ====>|
| | | |
Figure 3: Basic flow Figure 3: Basic flow
Figure 3 shows a basic example that describes a single audio media Figure 3 shows a basic example that describes a single audio media
stream over a circuit-switched bearer. The SDP offer is show in stream over a circuit-switched bearer. Alice generates a SDP Offer
Figure 4. The endpoint describes a PSTN circuit-switched bearer in which is show in Figure 4. The Offer describes a PSTN circuit-
the "m=" and "c=" line where it also indicates its E.164 number. switched bearer in the "m=" and "c=" line where it also indicates its
Additionally, it expresses that it can initiate the circuit-switched E.164 number in the international format. Additionally, Alice
connection or be the recipient of it. The SDP offer also includes a expresses that she can initiate the circuit-switched bearer or be the
correlation identifier that this endpoint will be inserting the User- recipient of it in the "a=setup" attribute line. The SDP Offer also
User Information Element of the PSTN call setup if eventually this includes a correlation identifiers that this endpoint will be
endpoint initiates the PSTN call. inserting the Calling Party Number and/or User-User Information
Element of 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 +15551234 c=PSTN E164 +15551234
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 a=cs-correlation:callerid:+15551234 uuie:2890W284hAT452612908awudfjang908
Figure 4: SDP offer (1) Figure 4: SDP offer (1)
7. IANA Considerations 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.
The "c=" line contains Bob's E.164 number in international format.
In the "a=setup" line Bob indicates that he is willing to become the
active endpoint when establishing the PSTN call, and he also includes
the "a=cs-correlation" attribute line containing the values he is
going to include in the Calling Party Number and User-User IE of the
PSTN call establishment.
v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7
s=
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +15554321
a=setup:active
a=connection:new
a=cs-correlation:callerid:+15554321 uuie:2127W49uThi455916adjfhtow9619361
Figure 5: SDP Answer with circuit-switched media
When Alice receives the Answer, she examines that Bob is willing to
become the active endpoint when setting up the PSTN call. Alice
temporarily stores Bob's E.164 number and the User-User IE value of
the "cs-correlation" attribute, and waits for a circuit-switched
bearer establishment.
Bob initiates a circuit-switched bearer using whatever circuit-
switched technology is available for him. The called party number is
set to Alice's number, and calling party number is set to Bob's own
number. Bob also sets the User-User Information Element value to the
on contained in the SDP Answer.
When Alice receives the circuit-switched bearer establishment, she
examines the UUIE and the calling party number, and by comparing
those received during O/A exchange determines that the call is
related to the SDP session.
It may also be that neither the UUIE nor the calling party number is
received by the called party, or the format of the calling party
number is changed by the PSTN. Implementations may still accept such
call establishment attempts as being related to the session that was
established in the IP network. As it cannot be guaranteed that the
values used for correlation are always passed intact through the
network, they should be treated as additional hints that the circuit-
switched bearer is actually related to the session.
7. Security Considerations
This document provides an extension on top of RFC 4566 [RFC4566], and
RFC 3264 [RFC3264]. As such, the security considerations of those
documents apply.
This memo provides mechanisms to agree on a correlation identifier or
identifiers that are used to evaluate whether an incoming circuit-
switched bearer is related to an ongoing session in the IP domain.
If an attacker replicates the correlation identifer and establishes a
call within the time window the receiving endpoint is expecting a
call, the attacker may be able to hijack the circuit-switched bearer.
These types of attacks are not specific to the mechanisms presented
in this memo. For example, caller ID spoofing is a well known attack
in the PSTN. Users are advised to use the same caution before
revealing sensitive information as they would on any other phone
call. Furthermore, users are advised that mechanisms that may be in
use in the IP domain for securing the media, like Secure RTP (SRTP)
[RFC3711], are not available in the CS domain.
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.
7.1. Registration of new 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 This attribute is subject to the charset attribute
Description: This attribute provides the Correlation Identifier Description: This attribute provides the Correlation Identifier
used in PSTN signaling used in PSTN signaling
Specification: RFC XXXX Specification: RFC XXXX
7.2. Registration of a new "nettype" value The IANA is requested the create a subregistry for 'cs-correlation'
attribute under the Session Description Protocol (SDP) Parameters
registry. The initial values for the subregistry are presented in
the following, and IANA is requested to add them into its database:
Value of 'cs-correlation' attribute Reference Description
----------------------------------- --------- ----------- callerid
RFC XXXX Caller ID uuie RFC XXXX User-User Information Element dtmf
RFC XXXX Dual-tone Multifrequency
Note for the RFC Editor: 'RFC XXXX' above should be replaced by a
reference to the RFC number of this draft.
As per the terminology in [RFC2434], the registration policy for new
values of 'cs-correlation' parameter is 'Specification Required'.
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]
7.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 a new "addrtype"
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
---- ------------------ --------- ---- ------------------ ---------
addrtype E164 [RFCxxxx] addrtype E164 [RFCxxxx]
- [RFCxxxx] - [RFCxxxx]
7.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]
8. Security Considerations
This document provides an extension on top of RFC 4566 [RFC4566], and
RFC 3264 [RFC3264]. As such, the security considerations of those
documents apply.
This memo provides mechanisms to agree on a correlation identifier or
identifiers that are used to evaluate whether an incoming circuit-
switched call is related to an ongoing session in the IP domain. If
an attacker replicates the correlation identifer and establishes a
call within the time window the receiving endpoint is expecting a
call, the attacker may be able to hijack the circuit-switched call.
These types of attacks are not specific to the mechanisms presented
in this memo. For example, caller ID spoofing is a well known attack
in the PSTN. Users are advised to use the same caution before
revealing sensitive information as they would on any other phone
call. Furthermore, users are advised that mechanisms that may be in
use in the IP domain for securing the media, like Secure RTP (SRTP)
[RFC3711], are not available in the CS domain.
9. Acknowledgments 9. Acknowledgments
The authors want to thank Flemming Andreasen, Thomas Belling, John The authors want to thank Flemming Andreasen, Thomas Belling, John
Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan Rosenberg, Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan Rosenberg,
Ingemar Johansson, Christer Holmberg, and Alf Heidermark for Ingemar Johansson, Christer Holmberg, and Alf Heidermark for
providing their insight and comments on this document. providing 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 [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer Session Description Protocol (SDP) for ATM Bearer
Connections", RFC 3108, May 2001. 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.
[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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References [RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 2010.
[3GPP.24.008] 10.2. Informative References
3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", 3GPP TS 24.008 3.20.0,
December 2005.
[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.
skipping to change at page 25, line 31 skipping to change at page 29, line 50
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.
[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]
3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", 3GPP TS 24.008 3.20.0,
December 2005.
URIs URIs
[1] <http://www.iana.org/assignments/sdp-parameters> [1] <http://www.iana.org/assignments/sdp-parameters>
Authors' Addresses Authors' Addresses
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Ericsson Ericsson
Calle Via de los Poblados 13 Calle Via de los Poblados 13
Madrid, ES 28033 Madrid, ES 28033
 End of changes. 80 change blocks. 
269 lines changed or deleted 491 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/