--- 1/draft-ietf-mmusic-sdp-cs-18.txt 2013-06-03 13:14:20.731013514 +0100 +++ 2/draft-ietf-mmusic-sdp-cs-19.txt 2013-06-03 13:14:20.803015349 +0100 @@ -1,21 +1,21 @@ MMUSIC WG M. Garcia-Martin Internet-Draft Ericsson Intended status: Standards Track S. Veikkolainen -Expires: October 27, 2013 Nokia - April 25, 2013 +Expires: December 05, 2013 Nokia + June 03, 2013 - Session Description Protocol (SDP) Extension For Setting Up Audio and -Video Media Streams Over Circuit-Switched Bearers In The Public Switched +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-18 + draft-ietf-mmusic-sdp-cs-19 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 October 27, 2013. + This Internet-Draft will expire on December 05, 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 @@ -75,38 +75,38 @@ 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 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 . . . . . . . . . . . . . . . . 25 + 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 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 - 8.1. Registration of new cs-correlation SDP attribute . . . . 31 - 8.2. Registration of a new "nettype" value . . . . . . . . . . 32 - 8.3. Registration of new "addrtype" values . . . . . . . . . . 32 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 + 8.1. Registration of new cs-correlation SDP attribute . . . . 32 + 8.2. Registration of a new "nettype" value . . . . . . . . . . 33 + 8.3. Registration of new "addrtype" values . . . . . . . . . . 33 8.4. Registration of a new "proto" value . . . . . . . . . . . 33 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 33 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 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 @@ -224,74 +224,75 @@ are defined for the "c=" and "m=" lines to be able to describe a media stream over a circuit-switched bearer. These SDP extensions are described in Section 5.2. Since circuit-switched bearers are connection-oriented media streams, the mechanism re-uses the connection-oriented extensions defined in RFC 4145 [RFC4145] to negotiate the active and passive sides of a connection setup. This is further described in Section 5.3.1. 4.1. Example Call Flow - Consider the example presented in Figure 1. In this example, Alice - is located in an environment where she has access to both IP and - circuit-switched bearers for communicating with other endpoints. - Alice decides that the circuit-switched bearer offers a better - perceived quality of service for voice, and issues an SDP Offer - containing the description of an audio media stream over circuit- - switched bearer. + Consider the example presented in Figure 1. In this example, + Endpoint A is located in an environment where it has access to both + IP and circuit-switched bearers for communicating with other + endpoints. Endpoint A decides that the circuit-switched bearer + offers a better perceived quality of service for voice, and issues an + SDP Offer containing the description of an audio media stream over + circuit-switched bearer. - Alice Bob + Endpoint A Endpoint B | (1) SDP Offer (PSTN audio) | |----------------------------------->| | | | (2) SDP Answer (PSTN audio) | |<-----------------------------------| | | | PSTN call setup | |<-----------------------------------| | | | | |<===== media over PSTN bearer =====>| | | Figure 1: Example Flow - Bob receives the SDP offer and determines that he is located in an - environment where the IP based bearer is not suitable for real-time - audio media. However he also has PSTN circuit-switched bearer - available for audio. Bob generates an SDP answer containing a - description of the audio media stream over a circuit-switched bearer. + Endpoitn B receives the SDP offer and determines that it is located + in an environment where the IP based bearer is not suitable for real- + time audio media. However, Endpoint B also has PSTN circuit-switched + bearer available for audio. Endpoint B generates an SDP answer + containing a description of the audio media stream over a circuit- + switched bearer. - During the offer-answer exchange Alice and Bob also agree the + During the offer-answer exchange Endpoints A and B also agree the direction in which the circuit-switched bearer should be established. - In this example, Bob becomes the active party, in other words, he - establishes the circuit-switched call to the other endpoint. The + In this example, Endpoint B becomes the active party, in other words, + it establishes the circuit-switched call to the other endpoint. The Offer/Answer exchange contains identifiers or references that can be used on the circuit-switched network for addressing the other endpoint, as well as information that is used to determine that the incoming circuit-switched bearer establishment is related to the - ongoing session between Alice and Bob. + ongoing session between the two endpoints. - Bob establishes a circuit-switched bearer towards Alice using - whatever mechanisms are defined for the network type in question. - When receiving the incoming circuit-switched connection attempt, - Alice is able to determine that the attempt is related to the session - she is just establishing with Bob. + Endpoint B establishes a circuit-switched bearer towards Endpoint A + using whatever mechanisms are defined for the network type in + question. When receiving the incoming circuit-switched connection + attempt, Endpoint A is able to determine that the attempt is related + to the session it is just establishing with B. - Alice accepts the circuit-switched connection; the circuit-switched - bearer setup is completed. Bob and Alice can now use the circuit- - switched connection for two-way audio media. + Endpoint A accepts the circuit-switched connection; the circuit- + switched bearer setup is completed. The two endpoints can now use + the circuit-switched connection for two-way audio media. - If, for some reason, Bob would like to reject the offered stream, he - would set the port number of the specific stream to zero, as - specified in RFC3264 [RFC3264]. Also, if Bob does not understand - some of the SDP attributes specified in this document, he would + If, for some reason, Endpoint B would like to reject the offered + stream, it would set the port number of the specific stream to zero, + as specified in RFC3264 [RFC3264]. Also, if B does not understand + some of the SDP attributes specified in this document, it would ignore them, as specified in RFC4566 [RFC4566]. 5. Protocol Description 5.1. Level of Compliance Implementations according to this specification MUST implement the SDP extensions described in Section 5.2, and MUST implement the considerations discussed in Section 5.3, Section 5.4 and Section 5.6. @@ -414,24 +415,24 @@ The subfield is the media format description. In the classical usage of SDP to describe RTP-based media streams, when the subfield is set to "RTP/AVP" or "RTP/SAVP", the subfield contains the payload types as defined in the RTP audio profile [RFC3551]. When "RTP/AVP" is used in the field, the subfield contains the RTP payload type numbers. We use the subfield to indicate the list of available codecs over the circuit-switched bearer, by re-using the conventions and payload type numbers defined - for RTP/AVP. The RTP audio and video media types, which, when - applied to PSTN circuit-switched bearers, represent merely an audio - or video codec. If the endpoint is able to determine the list of - available codecs for circuit-switched media streams, it MUST use the + for RTP/AVP. The RTP audio and video media types, when applied to + PSTN circuit-switched bearers, represent merely an audio or video + codec. If the endpoint is able to determine the list of available + codecs for circuit-switched media streams, it MUST use the corresponding payload type numbers in the subfield. In some cases, the endpoint is not able to determine the list of available codecs for circuit-switched media streams. In this case, in order to be syntactically compliant with SDP [RFC4566], the endpoint MUST include a single dash ("-") in the subfield. As per RFC 4566 [RFC4566], the media format descriptions are listed in priority order. @@ -602,51 +603,50 @@ the document "A Mechanism for Transporting User to User Call Control Information in SIP" [I-D.ietf-cuss-sip-uui]. As an example, an endpoint willing to send a UUIE containing a protocol discriminator with the hexadecimal value of %x56 and an hexadecimal User Information value of %xA390F3D2B7310023 would include a "cs-correlation" attribute line as follows: a=cs-correlation:uuie:56A390F3D2B7310023 - Note that, for correlation purposes, the value of the User-User - Information Element is considered as an opaque string and only used - for correlation purposes. Typically call signaling protocols impose - requirements on the creation of User-User Information Element for - end-user protocol exchange. The details regarding the generation of - the User-User Information Element are outside the scope of this - specification. + Note that the value of the User-User Information Element is + considered as an opaque string and only used for correlation + purposes. Typically call signaling protocols impose requirements on + the creation of User-User Information Element for end-user protocol + exchange. The details regarding the generation of the User-User + Information Element are outside the scope of this specification. Please note that there are no guarantees that this correlation mechanism works. On one side, policy restrictions might not make the User-User information available end to end in the PSTN. On the other hand, the generation of the User-User Information Element is controlled by the PSTN circuit-switched call protocol, which might 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) 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. + /Answer exchange and sent as Dual Tone Multifrequency (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 answer, in a "dtmf" subfield of the "cs-correlation" attribute. When the SDP Offer/Answer exchange is completed, each endpoint has become aware of the DTMF sequence that will be sent right after the circuit- switched bearer is set up. The endpoint that initiates the call setup attempt sends the DTMF digits according to the procedures defined for the circuit-switched bearer technology used. The recipient (passive side of the bearer setup) of the call setup @@ -877,23 +878,25 @@ The subfield carries the payload type number(s) the endpoint is wishing to use. Payload type numbers in this case refer to the codecs that the endpoint wishes to use 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. - 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. + 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. 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. The current list of subfields include "callerid", "uuie" and "dtmf" @@ -946,38 +949,38 @@ 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. If an Offerer does not know its international E.164 number, it MUST set the 'a=setup' attribute to the value 'active'. If the Offerer knows its international E.164 number, it SHOULD set the value to either 'actpass' or 'passive'. Also 'holdconn' is a permissible value in the 'a=setup' attribute. - It indicates that the connection is not established for the time - being. + It indicates that the connection should not be established for the + time being. The Offerer uses the "a=connection" attribute to decide whether a new 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 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 use circuit- - switched media for the session, it MUST ignore the received port - number (unless the port number is set to zero). + 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 + 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 Answerer SHOULD accept such Offers, and SHOULD set the payload type to "-" also in the Answer. @@ -998,34 +1001,35 @@ number to zero on the Answer. If the Answerer is aware of its international E.164 number, it MUST include the "a=setup" attribute in the Answer and set it to value "passive" or "holdconn". The Answerer MUST also include its E.164 number on the "c=" line. If the SDP in the Offer indicates that the Offerer is only able to become the passive party, the Answerer MUST verify that the Offerer's E.164 number is included in the "c=" line of the Offer. If the number is included, the Answerer MUST include the "a=setup" attribute in the Answer and set it to value "active" or "holdconn". If the - number is not included, call establishment is not possible, and the + number is not included, or the recipient of the Offer is not willing + to establish a connection the E.164 based on a priori knowledge of + cost, or other reasons, call establishment is not possible, and the Answerer MUST reject the circuit-switched media by setting the port number to zero in the Answer. If the SDP in the Offer indicates that the Offerer is able to become - either the active or passive party, the Answerer needs to determine - which role it would like to take. If the Offer includes an - international E.164 number in the "c=" line, the Answerer SHOULD - become the active party. If the Offer does not include an E.164 - number, and if the Answerer is aware of its international E.164 - number, it MUST become the passive party. If the Offer does not - include an E.164 number in the "c=" line and the Answerer is not - aware of its E.164 number, it MUST reject the circuit-switched media - by setting the port number to zero in the Answer. + either the active or passive party, the Answerer determines which + role it will take. If the Offer includes an international E.164 + number in the "c=" line, the Answerer SHOULD become the active party. + If the Answerer does not become the active party, and if the Answerer + is aware of its E.164 number, it MUST become the passive party. If + the Answerer does not become the active or the passive party, it MUST + reject the circuit-switched media by setting the port number to zero + in the Answer. For each media description where the Offer includes a "a=cs- correlation" attribute, the Answerer MUST select from the Offer those correlation mechanisms it supports, and include in the Answer one "a =cs-correlation" attribute line containing those mechanisms it is willing to use. The Answerer MUST only add one "a=cs-correlation" attribute in those media descriptions where also the Offer included a "a=cs-correlation" attribute. The Answerer MUST NOT add any mechanisms which were not included in the offer. If there are more than one "cs-correlation" attributes per media description in the @@ -1055,24 +1059,26 @@ value of the Information Element to that received in the SDP Offer, o if the SDP Answer contained a value for the "dtmf" subfield, MUST send those DTMF digits according to the circuit-switched technology used. If, on the other hand, the Answerer became the passive party, it o MUST be prepared to receive a circuit-switched bearer, - o if the Offer contained a value for the "callerid" subfield, MUST compare that value to the Calling Party Number Information Element - of the circuit-switched bearer, + of the circuit-switched bearer. If the received Calling Party + Number Information Element matches the value of the "callerid" + subfield, the call SHOULD be treated as correlated to the ongoing + session. o if the Offer contained a value for the "dtmf" subfield, MUST be prepared to receive and collect DTMF digits once the circuit- switched bearer is set up. The Answerer MUST compare the received DTMF digits to the value of the "dtmf" subfield. If the received DTMF digits match the value of the "dtmf" subfield in the "cs- correlation" attribute, the call SHOULD be treated as correlated to the ongoing session. o if the Offer contained a value for the "uuie" subfield, MUST be @@ -1139,20 +1145,36 @@ correlated to the ongoing session. o If the Answer contained a value for the "uuie" subfield, the Offerer MUST be prepared to receive a User-User Information element once the circuit-switched bearer is set up. The Offerer SHOULD compare the received UUI to the value of the "uuie" subfield. If the value of the received UUI matches the value of the "uuie" subfield, the call SHOULD be treated as correlated to the ongoing session. + According the Offer/Answer Model with SDP [RFC3264], the Offerer + needs to be ready to receive media as soon as the Offer has been + sent. It may happen that the Answerer, if it became the active + party, will initiate a circuit-switched bearer setup which will + arrive at the Offerer before the Answer has arrived. However, the + Offerer needs to receive the Answer and examine the information about + the correlation mechanisms in order to successfully perform + correlation of the circuit-switched call to the session. Therefore, + if the Offerer receives an incoming circuit-switched call, it MUST + NOT accept the call before the Answer has been received. If no + Answer is received during an implementation specific time, the + Offerer MUST either modify the session according to [RFC3264] or + terminate it according to the session signaling procedures in + question (for terminating a SIP session, see Section 15 of + [RFC3261]). + 5.6.4. Modifying the session If, at a later time, one of the parties wishes to modify the session, e.g., by adding new media stream, or by changing properties used on an existing stream, it may do so via the mechanisms defined for An Offer/Answer Model with SDP [RFC3264]. If there is an existing circuit-switched bearer between the endpoints, and the Offerer wants to reuse that, the Offerer MUST set the value of the "a=connection" attribute to 'existing'. @@ -1224,111 +1245,112 @@ 6. Examples In the examples below, where an SDP line is too long to be displayed as a single line, a breaking character "\" indicates continuation in the following line. Note that this character is included for display purposes only. Implementations MUST write a single line without breaks. 6.1. Single PSTN audio stream - Alice Bob + Endpoint A Endpoint B | | | (1) SDP Offer (PSTN audio) | |--------------------------------->| | | | (2) SDP Answer (PSTN audio) | |<---------------------------------| | | | PSTN call setup | |<---------------------------------| | | |<==== media over PSTN bearer ====>| | | Figure 3: Basic flow Figure 3 shows a basic example that describes a single audio media - stream over a circuit-switched bearer. Alice generates a SDP Offer - which is shown in Figure 4. The Offer describes a PSTN circuit- - switched bearer in the "m=" and "c=" line where it also indicates its - international E.164 number format. Additionally, Alice expresses - that she can initiate the circuit-switched bearer or be the recipient - of it in the "a=setup" attribute line. The SDP Offer also includes - correlation identifiers that this endpoint will insert in the Calling - Party Number and/or User-User Information Element of the PSTN call - setup if eventually this endpoint initiates the PSTN call. + stream over a circuit-switched bearer. Endpoint A generates a SDP + Offer which is shown in Figure 4. The Offer describes a PSTN + circuit-switched bearer in the "m=" and "c=" line where it also + indicates its international E.164 number format. Additionally, + Endpoint A expresses that it can initiate the circuit-switched bearer + or be the recipient of it in the "a=setup" attribute line. The SDP + Offer also includes correlation identifiers that this endpoint will + insert in the Calling Party Number and/or User-User Information + Element of the PSTN call setup if eventually this endpoint initiates + the PSTN call. v=0 o=alice 2890844526 2890842807 IN IP4 192.0.2.5 s= t=0 0 m=audio 9 PSTN - c=PSTN E164 +441134960123 a=setup:actpass a=connection:new a=cs-correlation:callerid:+441134960123 \ uuie:56A390F3D2B7310023 Figure 4: SDP offer (1) - Bob generates a SDP Answer (Figure 5), describing a PSTN audio media - on port 9 without information on the media sub-type on the "m=" line. - The "c=" line contains Bob's international E.164 number. In the - "a=setup" line Bob indicates that he is willing to become the active - endpoint when establishing the PSTN call, and he also includes the "a - =cs-correlation" attribute line containing the values he is going to - include in the Calling Party Number and User-User IE of the PSTN call - establishment. + Endpoint B generates a SDP Answer (Figure 5), describing a PSTN audio + media on port 9 without information on the media sub-type on the "m=" + line. The "c=" line contains B's international E.164 number. In the + "a=setup" line Endpoint B indicates that it is willing to become the + active endpoint when establishing the PSTN call, and it also includes + the "a=cs-correlation" attribute line containing the values it is + going to include in the Calling Party Number and User-User IE of the + PSTN call establishment. v=0 o=- 2890973824 2890987289 IN IP4 192.0.2.7 s= t=0 0 m=audio 9 PSTN - c=PSTN E164 +441134960124 a=setup:active a=connection:new a=cs-correlation:callerid:+441134960124 \ - uuie:56A390F3D2B7310023 + uuie:74B9027A869D7966A2 Figure 5: SDP Answer with circuit-switched media - When Alice receives the Answer, she examines that Bob is willing to - become the active endpoint when setting up the PSTN call. Alice - temporarily stores Bob's E.164 number and the User-User IE value of - the "cs-correlation" attribute, and waits for a circuit-switched - bearer establishment. + 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 + 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. - Bob initiates a circuit-switched bearer using whatever circuit- - switched technology is available for him. The called party number is - set to Alice's number, and calling party number is set to Bob's own - number. Bob also sets the User-User Information Element value to the - one contained in the SDP Answer. + 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. - When Alice receives the circuit-switched bearer establishment, she - examines the UUIE and the calling party number, and by comparing + When Endpoint A receives the circuit-switched bearer establishment, + it examines the UUIE and the calling party number, and by comparing those received during O/A exchange determines that the call is related to the SDP session. It may also be that neither the UUIE nor the calling party number is received by the called party, or the format of the calling party number is changed by the PSTN. Implementations may still accept such call establishment attempts as being related to the session that was established in the IP network. As it cannot be guaranteed that the values used for correlation are always passed intact through the network, they should be treated as additional hints that the circuit- switched bearer is actually related to the session. 6.2. Advanced SDP example: Circuit-Switched Audio and Video Streams - Alice Bob + Endpoint A Endpoint B | | | (1) SDP Offer (PSTN audio and video) | |------------------------------------------->| | | | (2) SDP Answer (PSTN audio) | |<-------------------------------------------| | | | PSTN call setup | |<-------------------------------------------| | | @@ -1345,32 +1367,34 @@ s= t=0 0 a=setup:actpass a=connection:new c=PSTN E164 +441134960123 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, Bob rejects the - video stream as his device does not currently support video, but - accepts the circuit-switched audio stream. As Alice indicated that - she is able to become either the active, or passive party, Bob gets - to select which role he would like to take. Since the Offer - contained the international E.164 number of Alice, Bob decides that - he becomes the active party in setting up the circuit-switched - bearer. Bob includes a new value in the "dtmf" subfield of the "cs- - correlation" attribute, which he is going to send as DTMF tones once - the bearer setup is complete. The Answer is described in Figure 8 + 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 + 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 s= t=0 0 a=setup:active a=connection:new c=PSTN E164 +441134960124 m=audio 9 PSTN - a=cs-correlation:dtmf:654321 @@ -1453,21 +1478,22 @@ The IANA is requested to create a subregistry for 'cs-correlation' attribute under the Session Description Protocol (SDP) Parameters registry. The initial values for the subregistry are presented in the following, and IANA is requested to add them into its database: Value of 'cs-correlation' attribute Reference Description ----------------------------------- --------- ----------- callerid RFC XXXX Caller ID uuie RFC XXXX User-User Information Element - dtmf RFC XXXX Dual-tone Multifrequency + dtmf RFC XXXX Dual-tone + Multifrequency Note for the RFC Editor: 'RFC XXXX' above should be replaced by a reference to the RFC number of this draft. As per the terminology in [RFC5226], the registration policy for new values of 'cs-correlation' parameter is 'Specification Required'. 8.2. Registration of a new "nettype" value This memo provides instructions to IANA to register a new "nettype" @@ -1518,20 +1545,25 @@ The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan Rosenberg, Ingemar Johansson, Christer Holmberg, Alf Heidermark, Tom Taylor, Thomas Belling, Keith Drage, and Andrew Allen for providing their insight and comments on this document. 10. References 10.1. Normative References + [ITU.Q931.1998] + , "Digital Subscriber Signalling System No. 1 (DSS 1) - + ISDN User - Network Interface Layer 3 Specification for + Basic Call Control", ISO Standard 9594-1, May 1998. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. @@ -1558,24 +1590,24 @@ Johnston, A. and J. Rafferty, "A Mechanism for Transporting User to User Call Control Information in SIP", draft-ietf-cuss-sip-uui-10 (work in progress), April 2013. [ITU.E164.1991] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, 1991. - [ITU.Q931.1998] - , "Digital Subscriber Signalling System No. 1 (DSS 1) - - ISDN User - Network Interface Layer 3 Specification for - Basic Call Control", ISO Standard 9594-1, May 1998. + [ITU.Q23.1988] + International Telecommunications Union, "Technical + features of push-button telephone sets ", ITU-T Technical + Recommendation Q.23, 1988. [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.