--- 1/draft-ietf-mmusic-sdp-cs-19.txt 2013-06-06 13:14:23.518585133 +0100 +++ 2/draft-ietf-mmusic-sdp-cs-20.txt 2013-06-06 13:14:23.590586909 +0100 @@ -1,21 +1,21 @@ MMUSIC WG M. Garcia-Martin Internet-Draft Ericsson Intended status: Standards Track S. Veikkolainen -Expires: December 05, 2013 Nokia - June 03, 2013 +Expires: December 08, 2013 Nokia + June 06, 2013 Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) - draft-ietf-mmusic-sdp-cs-19 + draft-ietf-mmusic-sdp-cs-20 Abstract This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). Status of This Memo @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -70,21 +70,21 @@ 5.2.3.5. Extensions to correlation mechanisms . . . . . . 15 5.3. Negotiating the correlation mechanisms . . . . . . . . . 15 5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup . . . . . . . . . . . . . . . . . . . . 15 5.3.2. Populating the cs-correlation attribute . . . . . . . 16 5.3.3. Considerations on correlations . . . . . . . . . . . 17 5.4. Considerations for Usage of Existing SDP . . . . . . . . 18 5.4.1. Originator of the Session . . . . . . . . . . . . . . 18 5.4.2. Contact information . . . . . . . . . . . . . . . . . 18 5.5. Considerations for Usage of Third Party Call Control - (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . 18 + (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . 19 5.6.1. Generating the Initial Offer . . . . . . . . . . . . 19 5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 21 5.6.3. Offerer processing the Answer . . . . . . . . . . . . 24 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 26 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 27 6.2. Advanced SDP example: Circuit-Switched Audio and Video Streams . . . . . . . . . . . . . . . . . . . . . . 29 @@ -471,22 +471,23 @@ between the endpoints. The caller-ID is also available as the Calling Party ID in the circuit-switched signaling. 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 the bearer setup signaling in the PSTN. The third mechanism is based on sending in SDP a string that represents Dual Tone MultiFrequency (DTMF) digits that will be later sent right after the circuit-switched bearer is established. - Implementations MAY use any of these mechanisms and MAY use two or - more mechanisms simultaneously. + Implementations MUST support the three correlation mechanisms + 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 In order to provide support for the correlation mechanisms, we define a new media-level SDP attribute called "cs-correlation". This "cs- correlation" attribute can include any of the "callerid", "uuie", or "dtmf" subfields, which specify additional information required by the Caller-ID, User to User Information, or DTMF correlation mechanisms, respectively. The list of correlation mechanisms may be extended by other specifications, see Section 5.2.3.5 for more @@ -762,20 +763,31 @@ 5.3.3. Considerations on correlations Passive endpoints should expect an incoming CS call for setting up the audio bearer. Passive endpoints MAY suppress the incoming CS alert during a certain time periods. Additional restrictions can be applied, such as the passive endpoint not alerting incoming calls originated from the number that was observed during the offer/answer 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 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. @@ -882,29 +894,29 @@ 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 the PSTN bearer. In case the endpoint is not aware of the codecs available for the circuit-switched media streams, it MUST include a dash ("-") in the subfield. The mapping table of static payload types numbers to payload types is initally specified in [RFC3551] and maintained by IANA. 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. + See Section 6 of RFC 4566 [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 Offerer MUST - NOT include more than one "cs-correlation" attribute per media - decription. The "a=cs-correlation" line contains an enumeration of - the correlation mechanisms supported by the Offerer, in the format of - subfields. + When generating the Offer, the Offerer MUST include an attribute line + "a=cs-correlation" in the SDP offer. The Offerer MUST NOT include + more than one "cs-correlation" attribute per media decription. The + "a=cs-correlation" line SHOULD contain an enumeration of all the + correlation mechanisms supported by the Offerer, in the format of + subfields. See Section 5.3.3 for more information on usage of the + correlation mechanisms. The current list of subfields include "callerid", "uuie" and "dtmf" 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. If the Offerer supports any of the correlation mechanisms defined in this memo, and is willing to become the active party, the Offerer MUST add the "callerid", "uuie", and/or "dtmf" subfields and MUST specify values for those subfields. @@ -928,25 +940,25 @@ a=cs-correlation:uuie dtmf a=setup:passive If, on the other hand, the Offerer is willing to use the User-User Information element and the DTMF correlation mechanisms, and is able to become the active or passive side, it includes the following lines in the SDP: a=cs-correlation:uuie:56A390F3D2B7310023 dtmf:14D*3 + a=setup:actpass 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 - [RFC4145]. + defined in Section 4.1 of RFC4145 [RFC4145]. 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. By 'active' endpoint, we refer to an endpoint that will establish the circuit-switched bearer; and by 'passive' endpoint, we refer to an endpoint that will receive a circuit-switched bearer. @@ -963,22 +975,21 @@ circuit-switched bearer is to be established or not. For the initial Offer, the Offerer MUST use value 'new'. 5.6.2. Generating the Answer If the Offer contained a circuit-switched audio or video stream, the 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 circuit-switched media for the session, it MUST construct an Answer where the port number for such media stream(s) is set to zero, - according to Section 6 of An Offer/Answer Model with the Session - Description Protocol (SDP) [RFC3264]. If the Answerer is willing to + according to Section 6 of [RFC3264]. If the Answerer is willing to use circuit-switched media for the session, it MUST ignore the received port number (unless the port number is set to zero). If the Offer included a "-" as the payload type number, it indicates that the Offerer is not willing or able to define any specific 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 define the codecs which will eventually be used on the circuit- switched bearer. The circuit-switched signaling protocols have their own means of negotiating or indicating the codecs, therefore an