draft-ietf-mmusic-sdp-cs-22.txt   draft-ietf-mmusic-sdp-cs-23.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: August 4, 2014 Nokia Expires: August 15, 2014 Nokia
January 31, 2014 February 11, 2014
Session Description Protocol (SDP) Extension For Setting Audio and Video Session Description Protocol (SDP) Extension For Setting Audio and Video
Media Streams Over Circuit-Switched Bearers In The Public Switched Media Streams Over Circuit-Switched Bearers In The Public Switched
Telephone Network (PSTN) Telephone Network (PSTN)
draft-ietf-mmusic-sdp-cs-22 draft-ietf-mmusic-sdp-cs-23
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 August 4, 2014. This Internet-Draft will expire on August 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 2, line 29 skipping to change at page 2, line 29
5.2.3. Correlating the PSTN Circuit-Switched Bearer with SDP 10 5.2.3. Correlating the PSTN Circuit-Switched Bearer with 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 . . . . . . . . . 12 5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 12
5.2.3.3. User-User Information Element Correlation 5.2.3.3. User-User Information Element Correlation
Mechanism . . . . . . . . . . . . . . . . . . . . 13 Mechanism . . . . . . . . . . . . . . . . . . . . 13
5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . 14 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . 14
5.2.3.5. The external correlation mechanism . . . . . . . 15 5.2.3.5. The external correlation mechanism . . . . . . . 15
5.2.3.6. Extensions to correlation mechanisms . . . . . . 16 5.2.3.6. Extensions to correlation mechanisms . . . . . . 16
5.3. Negotiating the correlation mechanisms . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . 16 Bearer Setup . . . . . . . . . . . . . . . . . . . . 17
5.3.2. Populating the cs-correlation attribute . . . . . . . 17 5.3.2. Populating the cs-correlation attribute . . . . . . . 17
5.3.3. Considerations on correlations . . . . . . . . . . . 18 5.3.3. Considerations on correlations . . . . . . . . . . . 18
5.4. Considerations for Usage of Existing SDP . . . . . . . . 18 5.4. Considerations for Usage of Existing SDP . . . . . . . . 19
5.4.1. Originator of the Session . . . . . . . . . . . . . . 18 5.4.1. Originator of the Session . . . . . . . . . . . . . . 19
5.4.2. Contact information . . . . . . . . . . . . . . . . . 19 5.4.2. Contact information . . . . . . . . . . . . . . . . . 19
5.5. Considerations for Usage of Third Party Call Control 5.5. Considerations for Usage of Third Party Call Control
(3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . 19 (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . 20 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . 20
5.6.1. Generating the Initial Offer . . . . . . . . . . . . 20 5.6.1. Generating the Initial Offer . . . . . . . . . . . . 20
5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 22 5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 23
5.6.3. Offerer processing the Answer . . . . . . . . . . . . 25 5.6.3. Offerer processing the Answer . . . . . . . . . . . . 25
5.6.4. Modifying the session . . . . . . . . . . . . . . . . 27 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 27
5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 27 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 28
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 29 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 30
6.2. Advanced SDP example: Circuit-Switched Audio and 6.2. Advanced SDP example: Circuit-Switched Audio and
Video Streams . . . . . . . . . . . . . . . . . . . . . . 31 Video Streams . . . . . . . . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8.1. Registration of new cs-correlation SDP attribute . . . . 33 8.1. Registration of new cs-correlation SDP attribute . . . . 34
8.2. Registration of a new "nettype" value . . . . . . . . . . 34 8.2. Registration of a new "nettype" value . . . . . . . . . . 35
8.3. Registration of new "addrtype" value . . . . . . . . . . 34 8.3. Registration of new "addrtype" value . . . . . . . . . . 35
8.4. Registration of a new "proto" value . . . . . . . . . . . 34 8.4. Registration of a new "proto" value . . . . . . . . . . . 35
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 36
10.2. Informative References . . . . . . . . . . . . . . . . . 36 10.2. Informative References . . . . . . . . . . . . . . . . . 37
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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 8, line 25 skipping to change at page 8, line 25
necessary for routing of the call in the PSTN network. necessary for routing of the call in the PSTN network.
There are cases, though, when the endpoint is merely aware of a There are cases, though, when the endpoint is merely aware of a
circuit-switched bearer, without having further information about the circuit-switched bearer, without having further information about the
E.164 number allocated to it. In these cases a dash ("-") is used to E.164 number allocated to it. In these cases a dash ("-") is used to
indicate an unknown connection address. This makes the connection indicate an unknown connection address. This makes the connection
data line be according to the SDP syntax. data line be according to the SDP syntax.
Please note that the "E164" address type defined in this memo is Please note that the "E164" address type defined in this memo is
exclusively defined to be used in conjunction with the "PSTN" network exclusively defined to be used in conjunction with the "PSTN" network
type in accordance with [RFC4566]. Usage of "E164" address type in type in accordance with regular Offer/Answer procedures [RFC4566].
conjunction with other network types may be defined elsewhere.
Note: RFC 3108 [RFC3108] also defines address type "E.164". This
definition is distinct from the one defined by this memo and shall
not be used with <nettype> "PSTN".
This memo exclusively uses the international representation of E.164 This memo exclusively uses the international representation of E.164
numbers, i.e., those including a country code and, as described above numbers, i.e., those including a country code and, as described above
prepended with a '+' sign. Implementations conforming to this prepended with a '+' sign. Implementations conforming to this
specification and using the "E164" address type together with the specification and using the "E164" address type together with the
"PSTN" network type MUST use the 'global-number-digits' construction "PSTN" network type MUST use the 'global-number-digits' construction
specified in RFC 3966 [RFC3966] for representing international E.164 specified in RFC 3966 [RFC3966] for representing international E.164
numbers. This representation requires the presence of the '+' sign, numbers. This representation requires the presence of the '+' sign,
and additionally allows for the presence of one or more 'visual- and additionally allows for the presence of one or more 'visual-
separator' constructions for easier human readability (see separator' constructions for easier human readability (see
skipping to change at page 11, line 16 skipping to change at page 11, line 21
The first mechanism is based on the exchange of PSTN caller-ID The first mechanism is based on the exchange of PSTN caller-ID
between the endpoints. The caller-ID is also available as the between the endpoints. The caller-ID is also available as the
Calling Party ID in the circuit-switched signaling. Calling Party ID in the circuit-switched signaling.
The second mechanism is based on the inclusion in SDP of a value that The second mechanism is based on the inclusion in SDP of a value that
is also sent in the User-to-User Information Element that is part of is also sent in the User-to-User Information Element that is part of
the bearer setup signaling in the PSTN. the bearer setup signaling in the PSTN.
The third mechanism is based on sending in SDP a string that The third mechanism is based on sending in SDP a string that
represents Dual Tone MultiFrequency (DTMF) digits that will be later represents Dual-Tone Multi-Frequency (DTMF) digits that will be later
sent right after the circuit-switched bearer is established. sent right after the circuit-switched bearer is established.
The fourth correlation mechanism declares support for cases where The fourth correlation mechanism declares support for cases where
correlation is done by external means. Typically this means that the correlation is done by external means. Typically this means that the
decision is left for the human user. This is the way how some decision is left for the human user. This is the way how some
current conferencing systems operate: after logging on to the current conferencing systems operate: after logging on to the
conference, the system calls back to the user's phone number to conference, the system calls back to the user's phone number to
establish audio communiations, and it is up to the human user to establish audio communications, and it is up to the human user to
accept or reject the incoming call. By declaring explicit support accept or reject the incoming call. By declaring explicit support
for this mechanism endpoints can use it only when such possibility for this mechanism endpoints can use it only when such possibility
exist. exist.
Endpoints may opt to implement any combination of the correlation Endpoints may opt to implement any combination of the correlation
mechanisms specified in Section 5.2.3.2, Section 5.2.3.3, mechanisms specified in Section 5.2.3.2, Section 5.2.3.3,
Section 5.2.3.4, and Section 5.2.3.5, including an option of Section 5.2.3.4, and Section 5.2.3.5, including an option of
implementing none at all. implementing none at all.
5.2.3.1. The "cs-correlation" attribute 5.2.3.1. The "cs-correlation" attribute
skipping to change at page 12, line 42 skipping to change at page 12, line 48
case it cannot populate the SDP appropriately. case it cannot populate the SDP appropriately.
o The Calling Party Number information element in the circuit- o The Calling Party Number information element in the circuit-
switched signaling might not be available, e.g., due to policy switched signaling might not be available, e.g., due to policy
restrictions of the network operator or caller restriction due to restrictions of the network operator or caller restriction due to
privacy. privacy.
o The Calling Party Number information element in the circuit- o The Calling Party Number information element in the circuit-
switched signaling might be available, but the digit switched signaling might be available, but the digit
representation of the E.164 number might differ from the one representation of the E.164 number might differ from the one
expressed in the SDP, due to, e.g., lack of of country code. To expressed in the SDP, due to, e.g., lack of country code. To
mitigate this problem implementations should consider only some of mitigate this problem implementations should consider only some of
the rightmost digits from the E.164 number for correlation. For the rightmost digits from the E.164 number for correlation. For
example, the numbers +44-113-496-0123 and 0113-496-0123 could be example, the numbers +44-113-496-0123 and 0113-496-0123 could be
considered as the same number. This is also the behavior of some considered as the same number. This is also the behavior of some
cellular phones, which correlate the incoming calling party with a cellular phones, which correlate the incoming calling party with a
number stored in the phone book, for the purpose of displaying the number stored in the phone book, for the purpose of displaying the
caller's name. Please refer to ITU-T E.164 reccommendation caller's name. Please refer to ITU-T E.164 recommendation
[ITU.E164.1991] for consideration of the relevant number of digits [ITU.E164.1991] for consideration of the relevant number of digits
to consider. to consider.
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 [TS.24.008], among others. The User-User Information 3GPP TS 24.008 [TS.24.008], among others. The User-User Information
skipping to change at page 14, line 42 skipping to change at page 14, line 47
not offer enough freedom for generating different values from one not offer enough freedom for generating different values from one
endpoint to another one, or from one call to another in the same endpoint to another one, or from one call to another in the same
endpoint. This might result in the same value of the User-User endpoint. This might result in the same value of the User-User
Information Element for all calls. Information Element for all calls.
5.2.3.4. DTMF Correlation Mechanism 5.2.3.4. DTMF Correlation Mechanism
We introduce a third mechanism for correlating the circuit-switched We introduce a third mechanism for correlating the circuit-switched
bearer with the session described with SDP. This is based on bearer with the session described with SDP. This is based on
agreeing on a sequence of digits that are negotiated in the SDP Offer agreeing on a sequence of digits that are negotiated in the SDP Offer
/Answer exchange and sent as Dual Tone Multifrequency (DTMF) ITU-T /Answer exchange and sent as Dual-Tone Multi-Frequency (DTMF) ITU-T
Recommendation Q.23 [ITU.Q23.1988] tones over the circuit-switched Recommendation Q.23 [ITU.Q23.1988] tones over the circuit-switched
bearer once this bearer is established. If the DTMF digit sequence bearer once this bearer is established. If the DTMF digit sequence
received through the circuit-switched bearer matches the digit string received through the circuit-switched bearer matches the digit string
negotiated in the SDP, the circuit-switched bearer is correlated with negotiated in the SDP, the circuit-switched bearer is correlated with
the session described in the SDP. The mechanism is similar to many the session described in the SDP. The mechanism is similar to many
voice conferencing systems which require the user to enter a PIN code voice conferencing systems which require the user to enter a PIN code
using DTMF tones in order to be accepted in a voice conference. using DTMF tones in order to be accepted in a voice conference.
The mechanism works as follows: An endpoint selects a DTMF digit The mechanism works as follows: An endpoint selects a DTMF digit
sequence. The same sequence is included in the SDP offer or SDP sequence. The same sequence is included in the SDP offer or SDP
skipping to change at page 15, line 48 skipping to change at page 15, line 50
The fourth correlation mechanism relies on external means for The fourth correlation mechanism relies on external means for
correlating the incoming call to the session. Since endpoints can correlating the incoming call to the session. Since endpoints can
select which correlation mechanisms they support, it may happen that select which correlation mechanisms they support, it may happen that
no other common correlation mechanism is found, or that the selected no other common correlation mechanism is found, or that the selected
correlation mechanism does not succeed due to the required feature correlation mechanism does not succeed due to the required feature
not being supported by the underlying PSTN network. In these cases, not being supported by the underlying PSTN network. In these cases,
the human user can do the decision of accepting or rejecting the the human user can do the decision of accepting or rejecting the
incoming call, thus "correlating" the call with the session. Since incoming call, thus "correlating" the call with the session. Since
not all endpoints are operated by a human user, or if there is no not all endpoints are operated by a human user, or if there is no
other external means implemented by the endpoint for the correlation other external means implemented by the endpoint for the correlation
funtion, we explicitly define support for such external correlation function, we explicitly define support for such external correlation
mechanism. mechanism.
Endpoints wishing to use this external correlation mechanism would Endpoints wishing to use this external correlation mechanism would
use a subfield "external" in the "a=cs-correlation" attribute. use a subfield "external" in the "a=cs-correlation" attribute.
Unlike the three other correlation mechanism, the "external" subfield
Unlike the three other correlation mechansism, the "external" does not accept a value. An example of a "a=cs-correlation"
subfield does not accept a value. An example of a "a=cs-correlation"
attribute line would look like this: attribute line would look like this:
a=cs-correlation:external a=cs-correlation:external
Endpoints which are willing to only use the three explicit
correlation mechanisms defined in this document ("callerid", "uuie",
and/or "dtmf") would not include the "external" mechanism in the
Offer/Answer exchange.
The external correlation mechanism typically relies on the human user
to do the decision on whether the call is related to the ongoing
session or not. After the user accepts the call, that bearer is
considered as related to the session. There is a small chance that
the user receives at the same time another circuit-switched call
which is not related to the ongoing session. The user may reject
this call if he is able to determine (e.g. based on the calling line
identification) that the call is not related to the session, and
continue waiting for another call attempt. If the user accepts the
incoming circuit-switched call, but it turns out to be not related to
the session, the endpoints need to rely on the human user to take
appropriate action (typically, they would hang up).
5.2.3.6. Extensions to correlation mechanisms 5.2.3.6. Extensions to correlation mechanisms
New values for the "cs-correlation" attribute may be specified. The New values for the "cs-correlation" attribute may be specified. The
registration policy for new values is "Specification Required", see registration policy for new values is "Specification Required", see
Section 8. Any such specification MUST include a description of how Section 8. Any such specification MUST include a description of how
SDP Offer/Answer mechanism is used to negotiate the use of the new SDP Offer/Answer mechanism is used to negotiate the use of the new
values, taking into account how endpoints determine which side will values, taking into account how endpoints determine which side will
become active or passive (see Section 5.3 for more details). become active or passive (see Section 5.3 for more details).
If, during the Offer/Answer negotiation, either endpoint encounters If, during the Offer/Answer negotiation, either endpoint encounters
skipping to change at page 18, line 43 skipping to change at page 19, line 18
session, even if the other correlation mechanisms fail. session, even if the other correlation mechanisms fail.
If, after successfully negotiating any of the "callerid", "uuie" or If, after successfully negotiating any of the "callerid", "uuie" or
"dtmf" correlation mechanisms in the SDP offer/answer exchange, an "dtmf" correlation mechanisms in the SDP offer/answer exchange, an
endpoint receives an incoming establishment of a circuit-switched endpoint receives an incoming establishment of a circuit-switched
bearer with no correlation information present, the endpoint first bearer with no correlation information present, the endpoint first
checks whether the offer/answer exchange was used to successfully checks whether the offer/answer exchange was used to successfully
negotiate also the "external" correlation mechanism. If it was, the negotiate also the "external" correlation mechanism. If it was, the
endpoint should leave the decision to be made by this external means, endpoint should leave the decision to be made by this external means,
typically the human user. If the "external" correlation mechanism typically the human user. If the "external" correlation mechanism
was not succesfully negotiated, the endpoint should treat the call as was not successfully negotiated, the endpoint should treat the call
unrelated to the ongoing session in the IP domain. as unrelated to the ongoing session in the IP domain.
5.4. Considerations for Usage of Existing SDP 5.4. Considerations for Usage of Existing SDP
5.4.1. Originator of the Session 5.4.1. Originator of the Session
According to SDP [RFC4566], the origin line in SDP has the following According to SDP [RFC4566], the origin line in SDP has the following
syntax: syntax:
o=<username> <sess-id> <sess-version> <nettype> <addrtype> o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address> <unicast-address>
skipping to change at page 19, line 29 skipping to change at page 20, line 8
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. Considerations for Usage of Third Party Call Control (3PCC) 5.5. Considerations for Usage of Third Party Call Control (3PCC)
Best Current Practices for Third Party Call Control (3pcc) in the Best Current Practices for Third Party Call Control (3pcc) in the
Session Initiation Protocol (SIP) [RFC3725] outlines several flows Session Initiation Protocol (SIP) [RFC3725] outlines several flows
which are possible in third party call control scenarios and which are possible in third party call control scenarios and
recommends some flows for specific situations. recommends some flows for specific situations.
One of the assumptions in [RFC3725] is that an SDP Offer may include One of the assumptions in [RFC3725] is that an SDP Offer may include
a "black hole" connection address, which has the property that a "black hole" connection address, which has the property that
packets sent to it will never leave the host which sent them. For 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 IPv4, this "black hole" connection address is 0.0.0.0, or a domain
name within the .invalid DNS top level domain. name within the .invalid DNS top level domain.
When using an E.164 address scheme in the context of third-party call When using an E.164 address scheme in the context of third-party call
skipping to change at page 20, line 40 skipping to change at page 21, line 16
wishing to use. Payload type numbers in this case refer to the wishing to use. Payload type numbers in this case refer to the
codecs that the endpoint wishes to use on the PSTN media stream. For codecs that the endpoint wishes to use on the PSTN media stream. For
example, if the endpoint wishes to use the GSM codec, it would add example, if the endpoint wishes to use the GSM codec, it would add
payload type number 3 in the list of codecs. The list of payload payload type number 3 in the list of codecs. The list of payload
types MUST only contain those codecs the endpoint is able to use on types MUST only contain those codecs the endpoint is able to use on
the PSTN bearer. In case the endpoint is not aware of the codecs the PSTN bearer. In case the endpoint is not aware of the codecs
available for the circuit-switched media streams, it MUST include a available for the circuit-switched media streams, it MUST include a
dash ("-") in the <fmt> subfield. dash ("-") in the <fmt> subfield.
The mapping table of static payload types numbers to payload types is The mapping table of static payload types numbers to payload types is
initally specified in [RFC3551] and maintained by IANA. For dynamic initially specified in [RFC3551] and maintained by IANA. For dynamic
payload types, the endpoint MUST define the set of valid encoding payload types, the endpoint MUST define the set of valid encoding
names and related parameters using the "a=rtpmap" attribute line. names and related parameters using the "a=rtpmap" attribute line.
See Section 6 of RFC 4566 [RFC4566] for details. See Section 6 of RFC 4566 [RFC4566] for details.
When generating the Offer, the Offerer MUST include an attribute line When generating the Offer, the Offerer MUST include an attribute line
"a=cs-correlation" in the SDP offer. The Offerer MUST NOT include "a=cs-correlation" in the SDP offer. The Offerer MUST NOT include
more than one "cs-correlation" attribute per media decription. The more than one "cs-correlation" attribute per media description. The
"a=cs-correlation" line SHOULD contain an enumeration of all the "a=cs-correlation" line SHOULD contain an enumeration of all the
correlation mechanisms supported by the Offerer, in the format of correlation mechanisms supported by the Offerer, in the format of
subfields. See Section 5.3.3 for more information on usage of the subfields. See Section 5.3.3 for more information on usage of the
correlation mechanisms. correlation mechanisms.
The current list of subfields include "callerid", "uuie", "dtmf", and The current list of subfields include "callerid", "uuie", "dtmf", and
"extenal", and they refer to the correlation mechanisms defined in "extenal", and they refer to the correlation mechanisms defined in
Section 5.2.3.2, Section 5.2.3.3, Section 5.2.3.4, and Section 5.2.3.2, Section 5.2.3.3, Section 5.2.3.4, and
Section 5.2.3.5 respectively. Section 5.2.3.5 respectively.
skipping to change at page 27, line 30 skipping to change at page 28, line 5
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.
If either party would like to remove existing RTP based media from
the session and replace that with a circuit-switched bearer, it would
create a new Offer to add the circuit-switched media as described in
Section 5.6.1 above, replacing the RTP based media description by the
circuit-switched media description, as specified in RFC 3264
[RFC3264].
Once the Offer/Answer exchange is done, but the circuit-switched
bearer is not yet established, there may be a period of time when no
media is available. Also, it may happen that correlating the
circuit-switched call fails for reasons discussed in Section 5.3.3.
In this case, even if the Offer/Answer exchange was successful,
endpoints are not able to receive or send media. It is up to the
implementation to decide the behavior in this case; if nothing else
is done, the user most likely hangs up after a while if there was no
other media in the session. Note that this may also happen when
switching from RTP media to another RTP media (for example when
firewall blocks the new media stream).
If either party would like to remove existing circuit-switched media
from the session and replace that with RTP based media, it would
modify the media description as per the procedures defined in RFC
3264 [RFC3264]. The endpoint MUST then terminate the circuit-
switched bearer using whatever mechanism is appropriate for the
technology in question.
5.7. 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] and the specification. The syntax is built above the SDP [RFC4566] and the
tel URI [RFC3966] grammars. Implementations according to this tel URI [RFC3966] grammars. Implementations according to this
specification MUST be compliant with this syntax. specification MUST be compliant with this syntax.
Figure 2 shows the formal syntax of the extensions defined in this Figure 2 shows the formal syntax of the extensions defined in this
memo. memo.
skipping to change at page 30, line 25 skipping to change at page 31, line 25
t=0 0 t=0 0
m=audio 9 PSTN - m=audio 9 PSTN -
c=PSTN E164 +441134960124 c=PSTN E164 +441134960124
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cs-correlation:callerid:+441134960124 \ a=cs-correlation:callerid:+441134960124 \
uuie:74B9027A869D7966A2 external uuie:74B9027A869D7966A2 external
Figure 5: SDP Answer with circuit-switched media Figure 5: SDP Answer with circuit-switched media
When Endoint A receives the Answer, it examines that B is willing to When Endpoint A receives the Answer, it examines that B is willing to
become the active endpoint when setting up the PSTN call. Endoint A become the active endpoint when setting up the PSTN call. Endpoint A
temporarily stores B's E.164 number and the User-User IE value of the temporarily stores B's E.164 number and the User-User IE value of the
"cs-correlation" attribute, and waits for a circuit-switched bearer "cs-correlation" attribute, and waits for a circuit-switched bearer
establishment. establishment.
Endpoint B initiates a circuit-switched bearer using whatever Endpoint B initiates a circuit-switched bearer using whatever
circuit-switched technology is available for it. The called party circuit-switched technology is available for it. The called party
number is set to A's number, and calling party number is set to B's number is set to A's number, and calling party number is set to B's
own number. Endpoint B also sets the User-User Information Element own number. Endpoint B also sets the User-User Information Element
value to the one contained in the SDP Answer. value to the one contained in the SDP Answer.
skipping to change at page 31, line 43 skipping to change at page 32, line 43
m=audio 9 PSTN - m=audio 9 PSTN -
a=cs-correlation:dtmf:1234536 a=cs-correlation:dtmf:1234536
m=video 9 PSTN 34 m=video 9 PSTN 34
a=rtpmap:34 H263/90000 a=rtpmap:34 H263/90000
a=cs-correlation:callerid:+441134960123 a=cs-correlation:callerid:+441134960123
Figure 7: SDP offer with circuit-switched audio and video (1) Figure 7: SDP offer with circuit-switched audio and video (1)
Upon receiving the SDP offer described in Figure 7, Endpoint B Upon receiving the SDP offer described in Figure 7, Endpoint B
rejects the video stream as the device does not currently support rejects the video stream as the device does not currently support
video, but accepts the circuit-switched audio stream. As Endoint A video, but accepts the circuit-switched audio stream. As Endpoint A
indicated that it is able to become either the active or passive indicated that it is able to become either the active or passive
party, Endpoint B gets to select which role it would like to take. party, Endpoint B gets to select which role it would like to take.
Since the Offer contained the international E.164 number of Endpoint Since the Offer contained the international E.164 number of Endpoint
A, Endpoint B decides that it becomes the active party in setting up A, Endpoint B decides that it becomes the active party in setting up
the circuit-switched bearer. B includes a new value in the "dtmf" the circuit-switched bearer. B includes a new value in the "dtmf"
subfield of the "cs-correlation" attribute, which it is going to send subfield of the "cs-correlation" attribute, which it is going to send
as DTMF tones once the bearer setup is complete. The Answer is as DTMF tones once the bearer setup is complete. The Answer is
described in Figure 8 described in Figure 8
v=0 v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7 o=- 2890973824 2890987289 IN IP4 192.0.2.7
skipping to change at page 32, line 31 skipping to change at page 33, line 31
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 identifier and establishes If an attacker replicates the correlation identifier and establishes
a call within the time window the receiving endpoint is expecting a 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 For the purposes of establishing a circuit-switched bearer, the
active endpoint needs to know the passive endpoint's phone number. active endpoint needs to know the passive endpoint's phone number.
Phone numbers are sensitive information, and some people may choose Phone numbers are sensitive information, and some people may choose
not to reveal their phone numbers when calling using supplementary not to reveal their phone numbers when calling using supplementary
skipping to change at page 34, line 11 skipping to change at page 35, line 11
attribute under the Session Description Protocol (SDP) Parameters attribute under the Session Description Protocol (SDP) Parameters
registry. The initial values for the subregistry are presented in registry. The initial values for the subregistry are presented in
the following, and IANA is requested to add them into its database: the following, and IANA is requested to add them into its database:
Value of 'cs-correlation' attribute Reference Description Value of 'cs-correlation' attribute Reference Description
----------------------------------- --------- ----------- ----------------------------------- --------- -----------
callerid RFC XXXX Caller ID callerid RFC XXXX Caller ID
uuie RFC XXXX User-User uuie RFC XXXX User-User
Information Element Information Element
dtmf RFC XXXX Dual-tone dtmf RFC XXXX Dual-tone
Multifrequency Multi-Frequency
external RFC XXXX External external RFC XXXX External
Note for the RFC Editor: 'RFC XXXX' above should be replaced by a Note for the RFC Editor: 'RFC XXXX' above should be replaced by a
reference to the RFC number of this draft. reference to the RFC number of this draft.
As per the terminology in [RFC5226], the registration policy for new As per the terminology in [RFC5226], the registration policy for new
values of 'cs-correlation' parameter is 'Specification Required'. values of 'cs-correlation' parameter is 'Specification Required'.
8.2. Registration of a new "nettype" value 8.2. Registration of a new "nettype" value
skipping to change at page 36, line 20 skipping to change at page 37, line 20
May 2008. May 2008.
[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 10.2. Informative References
[I-D.ietf-cuss-sip-uui] [I-D.ietf-cuss-sip-uui]
Johnston, A. and J. Rafferty, "A Mechanism for Johnston, A. and J. Rafferty, "A Mechanism for
Transporting User to User Call Control Information in Transporting User to User Call Control Information in
SIP", draft-ietf-cuss-sip-uui-11 (work in progress), SIP", draft-ietf-cuss-sip-uui-12 (work in progress),
October 2013. January 2014.
[ITU.E164.1991] [ITU.E164.1991]
International Telecommunications Union, "The International International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU-T Public Telecommunication Numbering Plan", ITU-T
Recommendation E.164, 1991. Recommendation E.164, 1991.
[ITU.Q23.1988] [ITU.Q23.1988]
International Telecommunications Union, "Technical International Telecommunications Union, "Technical
features of push-button telephone sets", ITU-T Technical features of push-button telephone sets", ITU-T Technical
Recommendation Q.23, 1988. Recommendation Q.23, 1988.
 End of changes. 28 change blocks. 
48 lines changed or deleted 94 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/