--- 1/draft-ietf-mmusic-sdp-cs-22.txt 2014-02-11 12:14:35.709594130 -0800 +++ 2/draft-ietf-mmusic-sdp-cs-23.txt 2014-02-11 12:14:35.789596079 -0800 @@ -1,21 +1,21 @@ MMUSIC WG M. Garcia-Martin Internet-Draft Ericsson Intended status: Standards Track S. Veikkolainen -Expires: August 4, 2014 Nokia - January 31, 2014 +Expires: August 15, 2014 Nokia + February 11, 2014 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-22 + draft-ietf-mmusic-sdp-cs-23 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 August 4, 2014. + This Internet-Draft will expire on August 15, 2014. Copyright Notice Copyright (c) 2014 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 @@ -64,50 +64,50 @@ 5.2.3. Correlating the PSTN Circuit-Switched Bearer with SDP 10 5.2.3.1. The "cs-correlation" attribute . . . . . . . . . 11 5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 12 5.2.3.3. User-User Information Element Correlation Mechanism . . . . . . . . . . . . . . . . . . . . 13 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . 14 5.2.3.5. The external correlation mechanism . . . . . . . 15 5.2.3.6. Extensions to correlation mechanisms . . . . . . 16 5.3. Negotiating the correlation mechanisms . . . . . . . . . 16 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.3. Considerations on correlations . . . . . . . . . . . 18 - 5.4. Considerations for Usage of Existing SDP . . . . . . . . 18 - 5.4.1. Originator of the Session . . . . . . . . . . . . . . 18 + 5.4. Considerations for Usage of Existing SDP . . . . . . . . 19 + 5.4.1. Originator of the Session . . . . . . . . . . . . . . 19 5.4.2. Contact information . . . . . . . . . . . . . . . . . 19 5.5. Considerations for Usage of Third Party Call Control - (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . 19 + (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . 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.4. Modifying the session . . . . . . . . . . . . . . . . 27 - 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 27 - 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 29 + 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 28 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 30 6.2. Advanced SDP example: Circuit-Switched Audio and - Video Streams . . . . . . . . . . . . . . . . . . . . . . 31 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 8.1. Registration of new cs-correlation SDP attribute . . . . 33 - 8.2. Registration of a new "nettype" value . . . . . . . . . . 34 - 8.3. Registration of new "addrtype" value . . . . . . . . . . 34 - 8.4. Registration of a new "proto" value . . . . . . . . . . . 34 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 - 10.2. Informative References . . . . . . . . . . . . . . . . . 36 - 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 + Video Streams . . . . . . . . . . . . . . . . . . . . . . 32 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 + 8.1. Registration of new cs-correlation SDP attribute . . . . 34 + 8.2. Registration of a new "nettype" value . . . . . . . . . . 35 + 8.3. Registration of new "addrtype" value . . . . . . . . . . 35 + 8.4. Registration of a new "proto" value . . . . . . . . . . . 35 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 + 10.2. Informative References . . . . . . . . . . . . . . . . . 37 + 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction The Session Description Protocol (SDP) [RFC4566] is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP is most commonly used for describing media streams that are transported over the Real-Time Transport Protocol (RTP) [RFC3550], using the profiles for audio and video media defined in RTP Profile for Audio and Video Conferences with Minimal Control @@ -345,22 +345,25 @@ necessary for routing of the call in the PSTN network. There are cases, though, when the endpoint is merely aware of a circuit-switched bearer, without having further information about the E.164 number allocated to it. In these cases a dash ("-") is used to indicate an unknown connection address. This makes the connection data line be according to the SDP syntax. Please note that the "E164" address type defined in this memo is exclusively defined to be used in conjunction with the "PSTN" network - type in accordance with [RFC4566]. Usage of "E164" address type in - conjunction with other network types may be defined elsewhere. + type in accordance with regular Offer/Answer procedures [RFC4566]. + + 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 "PSTN". This memo exclusively uses the international representation of E.164 numbers, i.e., those including a country code and, as described above prepended with a '+' sign. Implementations conforming to this specification and using the "E164" address type together with the "PSTN" network type MUST use the 'global-number-digits' construction specified in RFC 3966 [RFC3966] for representing international E.164 numbers. This representation requires the presence of the '+' sign, and additionally allows for the presence of one or more 'visual- separator' constructions for easier human readability (see @@ -481,29 +484,29 @@ The first mechanism is based on the exchange of PSTN caller-ID 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 + represents Dual-Tone Multi-Frequency (DTMF) digits that will be later sent right after the circuit-switched bearer is established. The fourth correlation mechanism declares support for cases where correlation is done by external means. Typically this means that the decision is left for the human user. This is the way how some current conferencing systems operate: after logging on to the 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 for this mechanism endpoints can use it only when such possibility exist. Endpoints may opt to implement any combination of the correlation 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 implementing none at all. 5.2.3.1. The "cs-correlation" attribute @@ -555,28 +558,28 @@ case it cannot populate the SDP appropriately. o The Calling Party Number information element in the circuit- switched signaling might not be available, e.g., due to policy restrictions of the network operator or caller restriction due to privacy. o The Calling Party Number information element in the circuit- switched signaling might be available, but the digit 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 the rightmost digits from the E.164 number for correlation. For 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 cellular phones, which correlate the incoming calling party with a 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 to consider. 5.2.3.3. User-User Information Element Correlation Mechanism A second correlation mechanism is based on including in SDP a string that represents the User-User Information Element that is part of the call setup signaling of the circuit-switched bearer. The User-User 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 @@ -651,21 +654,21 @@ not offer enough freedom for generating different values from one 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 Information Element for all calls. 5.2.3.4. DTMF Correlation Mechanism We introduce a third mechanism for correlating the circuit-switched bearer with the session described with SDP. This is based on 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 bearer once this bearer is established. If the DTMF digit sequence received through the circuit-switched bearer matches the digit string negotiated in the SDP, the circuit-switched bearer is correlated with the session described in the SDP. The mechanism is similar to many voice conferencing systems which require the user to enter a PIN code using DTMF tones in order to be accepted in a voice conference. The mechanism works as follows: An endpoint selects a DTMF digit sequence. The same sequence is included in the SDP offer or SDP @@ -703,32 +706,49 @@ The fourth correlation mechanism relies on external means for correlating the incoming call to the session. Since endpoints can select which correlation mechanisms they support, it may happen that no other common correlation mechanism is found, or that the selected correlation mechanism does not succeed due to the required feature not being supported by the underlying PSTN network. In these cases, the human user can do the decision of accepting or rejecting the incoming call, thus "correlating" the call with the session. Since not all endpoints are operated by a human user, or if there is no 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. Endpoints wishing to use this external correlation mechanism would use a subfield "external" in the "a=cs-correlation" attribute. - - Unlike the three other correlation mechansism, the "external" - subfield does not accept a value. An example of a "a=cs-correlation" + Unlike the three other correlation mechanism, the "external" subfield + does not accept a value. An example of a "a=cs-correlation" attribute line would look like this: 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 New values for the "cs-correlation" attribute may be specified. The registration policy for new values is "Specification Required", see Section 8. Any such specification MUST include a description of how SDP Offer/Answer mechanism is used to negotiate the use of the new values, taking into account how endpoints determine which side will become active or passive (see Section 5.3 for more details). If, during the Offer/Answer negotiation, either endpoint encounters @@ -844,22 +864,22 @@ session, even if the other correlation mechanisms fail. If, after successfully negotiating any of the "callerid", "uuie" or "dtmf" correlation mechanisms in the SDP offer/answer exchange, an endpoint receives an incoming establishment of a circuit-switched bearer with no correlation information present, the endpoint first checks whether the offer/answer exchange was used to successfully negotiate also the "external" correlation mechanism. If it was, the endpoint should leave the decision to be made by this external means, typically the human user. If the "external" correlation mechanism - was not succesfully negotiated, the endpoint should treat the call as - unrelated to the ongoing session in the IP domain. + was not successfully negotiated, the endpoint should treat the call + as unrelated to the ongoing session in the IP domain. 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= @@ -934,28 +954,28 @@ 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 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 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 + initially 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 RFC 4566 [RFC4566] for details. 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 + more than one "cs-correlation" attribute per media description. 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", "dtmf", and "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.5 respectively. @@ -1257,20 +1278,46 @@ If either party wishes to drop and reestablish an existing call, that party MUST first remove the circuit-switched media from the session by setting the port number to zero, and then use another Offer/Answer exchange where it MUST set the "a=connection" attribute to 'new'". If the media types are different (for example, a different codec will be used for the circuit-switched bearer), the media descriptions for terminating the existing bearer and the new bearer can be in the same 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 The following is the formal Augmented Backus-Naur Form (ABNF) [RFC5234] syntax that supports the extensions defined in this specification. The syntax is built above the SDP [RFC4566] and the tel URI [RFC3966] grammars. Implementations according to this specification MUST be compliant with this syntax. Figure 2 shows the formal syntax of the extensions defined in this memo. @@ -1385,22 +1432,22 @@ t=0 0 m=audio 9 PSTN - c=PSTN E164 +441134960124 a=setup:active a=connection:new a=cs-correlation:callerid:+441134960124 \ uuie:74B9027A869D7966A2 external Figure 5: SDP Answer with circuit-switched media - When Endoint A receives the Answer, it examines that B is willing to - become the active endpoint when setting up the PSTN call. Endoint A + When Endpoint A receives the Answer, it examines that B is willing to + 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 "cs-correlation" attribute, and waits for a circuit-switched bearer establishment. Endpoint B initiates a circuit-switched bearer using whatever 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 own number. Endpoint B also sets the User-User Information Element value to the one contained in the SDP Answer. @@ -1449,21 +1496,21 @@ m=audio 9 PSTN - a=cs-correlation:dtmf:1234536 m=video 9 PSTN 34 a=rtpmap:34 H263/90000 a=cs-correlation:callerid:+441134960123 Figure 7: SDP offer with circuit-switched audio and video (1) Upon receiving the SDP offer described in Figure 7, Endpoint B 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 party, Endpoint B gets to select which role it would like to take. Since the Offer contained the international E.164 number of Endpoint 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" subfield of the "cs-correlation" attribute, which it is going to send as DTMF tones once the bearer setup is complete. The Answer is described in Figure 8 v=0 o=- 2890973824 2890987289 IN IP4 192.0.2.7 @@ -1485,21 +1532,21 @@ 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 identifier 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 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. For the purposes of establishing a circuit-switched bearer, the active endpoint needs to know the passive endpoint's phone number. Phone numbers are sensitive information, and some people may choose not to reveal their phone numbers when calling using supplementary @@ -1555,21 +1602,21 @@ 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 + Multi-Frequency external RFC XXXX External 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 [RFC5226], the registration policy for new values of 'cs-correlation' parameter is 'Specification Required'. 8.2. Registration of a new "nettype" value @@ -1658,22 +1705,22 @@ May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 10.2. Informative References [I-D.ietf-cuss-sip-uui] Johnston, A. and J. Rafferty, "A Mechanism for Transporting User to User Call Control Information in - SIP", draft-ietf-cuss-sip-uui-11 (work in progress), - October 2013. + SIP", draft-ietf-cuss-sip-uui-12 (work in progress), + January 2014. [ITU.E164.1991] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, 1991. [ITU.Q23.1988] International Telecommunications Union, "Technical features of push-button telephone sets", ITU-T Technical Recommendation Q.23, 1988.