draft-ietf-mmusic-sdp-cs-19.txt   draft-ietf-mmusic-sdp-cs-20.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: December 05, 2013 Nokia Expires: December 08, 2013 Nokia
June 03, 2013 June 06, 2013
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-19 draft-ietf-mmusic-sdp-cs-20
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 December 05, 2013. This Internet-Draft will expire on December 08, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 35 skipping to change at page 2, line 35
5.2.3.5. Extensions to correlation mechanisms . . . . . . 15 5.2.3.5. Extensions to correlation mechanisms . . . . . . 15
5.3. Negotiating the correlation mechanisms . . . . . . . . . 15 5.3. Negotiating the correlation mechanisms . . . . . . . . . 15
5.3.1. Determining the Direction of the Circuit-Switched 5.3.1. Determining the Direction of the Circuit-Switched
Bearer Setup . . . . . . . . . . . . . . . . . . . . 15 Bearer Setup . . . . . . . . . . . . . . . . . . . . 15
5.3.2. Populating the cs-correlation attribute . . . . . . . 16 5.3.2. Populating the cs-correlation attribute . . . . . . . 16
5.3.3. Considerations on correlations . . . . . . . . . . . 17 5.3.3. Considerations on correlations . . . . . . . . . . . 17
5.4. Considerations for Usage of Existing SDP . . . . . . . . 18 5.4. Considerations for Usage of Existing SDP . . . . . . . . 18
5.4.1. Originator of the Session . . . . . . . . . . . . . . 18 5.4.1. Originator of the Session . . . . . . . . . . . . . . 18
5.4.2. Contact information . . . . . . . . . . . . . . . . . 18 5.4.2. Contact information . . . . . . . . . . . . . . . . . 18
5.5. Considerations for Usage of Third Party Call Control 5.5. Considerations for Usage of Third Party Call Control
(3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . 18 (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . 19 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . 19
5.6.1. Generating the Initial Offer . . . . . . . . . . . . 19 5.6.1. Generating the Initial Offer . . . . . . . . . . . . 19
5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 21 5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 21
5.6.3. Offerer processing the Answer . . . . . . . . . . . . 24 5.6.3. Offerer processing the Answer . . . . . . . . . . . . 24
5.6.4. Modifying the session . . . . . . . . . . . . . . . . 26 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 26
5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 27 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 27
6.2. Advanced SDP example: Circuit-Switched Audio and 6.2. Advanced SDP example: Circuit-Switched Audio and
Video Streams . . . . . . . . . . . . . . . . . . . . . . 29 Video Streams . . . . . . . . . . . . . . . . . . . . . . 29
skipping to change at page 11, line 8 skipping to change at page 11, line 8
between the endpoints. The caller-ID is also available as the between the endpoints. The caller-ID is also available as the
Calling Party ID in the circuit-switched signaling. Calling Party ID in the circuit-switched signaling.
The second mechanism is based on the inclusion in SDP of a value that The second mechanism is based on the inclusion in SDP of a value that
is also sent in the User-to-User Information Element that is part of is also sent in the User-to-User Information Element that is part of
the bearer setup signaling in the PSTN. the bearer setup signaling in the PSTN.
The third mechanism is based on sending in SDP a string that The third mechanism is based on sending in SDP a string that
represents Dual Tone MultiFrequency (DTMF) digits that will be later represents Dual Tone MultiFrequency (DTMF) digits that will be later
sent right after the circuit-switched bearer is established. sent right after the circuit-switched bearer is established.
Implementations MAY use any of these mechanisms and MAY use two or Implementations MUST support the three correlation mechanisms
more mechanisms simultaneously. specified in Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4,
and SHOULD include all supported mechanisms the initial Offer.
5.2.3.1. The "cs-correlation" attribute 5.2.3.1. The "cs-correlation" attribute
In order to provide support for the correlation mechanisms, we define In order to provide support for the correlation mechanisms, we define
a new media-level SDP attribute called "cs-correlation". This "cs- a new media-level SDP attribute called "cs-correlation". This "cs-
correlation" attribute can include any of the "callerid", "uuie", or correlation" attribute can include any of the "callerid", "uuie", or
"dtmf" subfields, which specify additional information required by "dtmf" subfields, which specify additional information required by
the Caller-ID, User to User Information, or DTMF correlation the Caller-ID, User to User Information, or DTMF correlation
mechanisms, respectively. The list of correlation mechanisms may be mechanisms, respectively. The list of correlation mechanisms may be
extended by other specifications, see Section 5.2.3.5 for more extended by other specifications, see Section 5.2.3.5 for more
skipping to change at page 17, line 30 skipping to change at page 17, line 30
5.3.3. Considerations on correlations 5.3.3. Considerations on correlations
Passive endpoints should expect an incoming CS call for setting up Passive endpoints should expect an incoming CS call for setting up
the audio bearer. Passive endpoints MAY suppress the incoming CS the audio bearer. Passive endpoints MAY suppress the incoming CS
alert during a certain time periods. Additional restrictions can be alert during a certain time periods. Additional restrictions can be
applied, such as the passive endpoint not alerting incoming calls applied, such as the passive endpoint not alerting incoming calls
originated from the number that was observed during the offer/answer originated from the number that was observed during the offer/answer
negotiation. negotiation.
There may be cases when an endpoint is not willing to include all
three correlation mechanisms in the "a=cs-correlation" attribute line
even if it supports all three mechansism. For example, some
correlation mechanism can be omitted if the endpoint is certain that
the PSTN network does not support carrying the correlation
identifier. Also, since using the DTMF based correlation mechanism
requires the call to be accepted before DTMF tones cane be sent, some
endpoints may enforce a policy restricting this due to for example
cost associated with received calls, making the DTMF based mechanism
unusable.
Note that it cannot be guaranteed that any given correlation Note that it cannot be guaranteed that any given correlation
mechanism will succeed even if the usage of those was agreed mechanism will succeed even if the usage of those was agreed
beforehand. This is due to the fact that the correlation mechanisms beforehand. This is due to the fact that the correlation mechanisms
require support from the circuit-switched bearer technology used. require support from the circuit-switched bearer technology used.
Therefore, even a single positive indication using any of these Therefore, even a single positive indication using any of these
mechanisms SHOULD be interpreted by the passive endpoint so that the mechanisms SHOULD be interpreted by the passive endpoint so that the
circuit-switched bearer establishment is related to the ongoing circuit-switched bearer establishment is related to the ongoing
session, even if the other correlation mechanisms fail. session, even if the other correlation mechanisms fail.
skipping to change at page 20, line 6 skipping to change at page 20, line 16
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 initally 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 SDP [RFC4566] for details. See Section 6 of RFC 4566 [RFC4566] for details.
When generating the Offer, if the Offerer supports any of the When generating the Offer, the Offerer MUST include an attribute line
correlation mechanisms defined in this memo, it MUST include an "a=cs-correlation" in the SDP offer. The Offerer MUST NOT include
attribute line "a=cs-correlation" in the SDP offer. The Offerer MUST more than one "cs-correlation" attribute per media decription. The
NOT include more than one "cs-correlation" attribute per media "a=cs-correlation" line SHOULD contain an enumeration of all the
decription. The "a=cs-correlation" line contains an enumeration of correlation mechanisms supported by the Offerer, in the format of
the correlation mechanisms supported by the Offerer, in the format of subfields. See Section 5.3.3 for more information on usage of the
subfields. correlation mechanisms.
The current list of subfields include "callerid", "uuie" and "dtmf" The current list of subfields 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 supports any of the correlation mechanisms defined in If the Offerer supports any of the correlation mechanisms defined in
this memo, and is willing to become the active party, the Offerer this memo, and is willing to become the active party, the Offerer
MUST add the "callerid", "uuie", and/or "dtmf" subfields and MUST MUST add the "callerid", "uuie", and/or "dtmf" subfields and MUST
specify values for those subfields. specify values for those subfields.
skipping to change at page 21, line 4 skipping to change at page 21, line 15
a=cs-correlation:uuie dtmf a=cs-correlation:uuie dtmf
a=setup:passive a=setup:passive
If, on the other hand, the Offerer is willing to use the User-User If, on the other hand, the Offerer is willing to use the User-User
Information element and the DTMF correlation mechanisms, and is able Information element and the DTMF correlation mechanisms, and is able
to become the active or passive side, it includes the following lines to become the active or passive side, it includes the following lines
in the SDP: in the SDP:
a=cs-correlation:uuie:56A390F3D2B7310023 dtmf:14D*3 a=cs-correlation:uuie:56A390F3D2B7310023 dtmf:14D*3
a=setup:actpass a=setup:actpass
The negotiation of the value of the 'setup' attribute takes place as The negotiation of the value of the 'setup' attribute takes place as
defined in Section 4.1 of TCP-Based Media Transport in the SDP defined in Section 4.1 of RFC4145 [RFC4145].
[RFC4145].
The Offerer states which role or roles it is willing to perform; and The Offerer states which role or roles it is willing to perform; and
the Answerer, taking the Offerer's willingness into consideration, the Answerer, taking the Offerer's willingness into consideration,
chooses which roles both endpoints will actually perform during the chooses which roles both endpoints will actually perform during the
circuit-switched bearer setup. circuit-switched bearer setup.
By 'active' endpoint, we refer to an endpoint that will establish the By 'active' endpoint, we refer to an endpoint that will establish the
circuit-switched bearer; and by 'passive' endpoint, we refer to an circuit-switched bearer; and by 'passive' endpoint, we refer to an
endpoint that will receive a circuit-switched bearer. endpoint that will receive a circuit-switched bearer.
skipping to change at page 21, line 39 skipping to change at page 21, line 50
circuit-switched bearer is to be established or not. For the initial circuit-switched bearer is to be established or not. For the initial
Offer, the Offerer MUST use value 'new'. Offer, the Offerer MUST use value 'new'.
5.6.2. Generating the Answer 5.6.2. Generating the Answer
If the Offer contained a circuit-switched audio or video stream, the If the Offer contained a circuit-switched audio or video stream, the
Answerer first determines whether it is able to accept and use such Answerer first determines whether it is able to accept and use such
streams. If the Answerer does not support or is not willing to use streams. If the Answerer does not support or is not willing to use
circuit-switched media for the session, it MUST construct an Answer circuit-switched media for the session, it MUST construct an Answer
where the port number for such media stream(s) is set to zero, where the port number for such media stream(s) is set to zero,
according to Section 6 of An Offer/Answer Model with the Session according to Section 6 of [RFC3264]. If the Answerer is willing to
Description Protocol (SDP) [RFC3264]. If the Answerer is willing to
use circuit-switched media for the session, it MUST ignore the use circuit-switched media for the session, it MUST ignore the
received port number (unless the port number is set to zero). received port number (unless the port number is set to zero).
If the Offer included a "-" as the payload type number, it indicates If the Offer included a "-" as the payload type number, it indicates
that the Offerer is not willing or able to define any specific that the Offerer is not willing or able to define any specific
payload type. Most often, a "-" is expected to be used instead of payload type. Most often, a "-" is expected to be used instead of
the payload type when the endpoint is not aware of or not willing to the payload type when the endpoint is not aware of or not willing to
define the codecs which will eventually be used on the circuit- define the codecs which will eventually be used on the circuit-
switched bearer. The circuit-switched signaling protocols have their switched bearer. The circuit-switched signaling protocols have their
own means of negotiating or indicating the codecs, therefore an own means of negotiating or indicating the codecs, therefore an
 End of changes. 11 change blocks. 
19 lines changed or deleted 30 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/