--- 1/draft-ietf-mmusic-sdp-cs-16.txt 2013-01-14 10:33:20.076124704 +0100 +++ 2/draft-ietf-mmusic-sdp-cs-17.txt 2013-01-14 10:33:20.132126252 +0100 @@ -1,21 +1,21 @@ MMUSIC WG M. Garcia-Martin Internet-Draft Ericsson Intended status: Standards Track S. Veikkolainen -Expires: July 13, 2013 Nokia - January 9, 2013 +Expires: July 18, 2013 Nokia + January 14, 2013 Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) - draft-ietf-mmusic-sdp-cs-16 + draft-ietf-mmusic-sdp-cs-17 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 July 13, 2013. + This Internet-Draft will expire on July 18, 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 @@ -64,25 +64,25 @@ 5.2.3. Correlating the PSTN Circuit-Switched Bearer with SDP . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 13 5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 13 5.2.3.3. User-User Information Element Correlation Mechanism . . . . . . . . . . . . . . . . . . . . 14 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 16 5.2.3.5. Extensions to correlation mechanisms . . . . . . . 17 5.3. Negotiating the correlation mechanisms . . . . . . . . . . 17 5.3.1. Determining the Direction of the Circuit-Switched - Bearer Setup . . . . . . . . . . . . . . . . . . . . . 18 + Bearer Setup . . . . . . . . . . . . . . . . . . . . . 17 5.3.2. Populating the cs-correlation attribute . . . . . . . 18 - 5.3.3. Considerations on successful correlation . . . . . . . 19 - 5.4. Considerations for Usage of Existing SDP . . . . . . . . . 20 - 5.4.1. Originator of the Session . . . . . . . . . . . . . . 20 + 5.3.3. Considerations on correlations . . . . . . . . . . . . 19 + 5.4. Considerations for Usage of Existing SDP . . . . . . . . . 19 + 5.4.1. Originator of the Session . . . . . . . . . . . . . . 19 5.4.2. Contact information . . . . . . . . . . . . . . . . . 20 5.5. Considerations for Usage of Third Party Call Control (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 21 5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 21 5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 23 5.6.3. Offerer processing the Answer . . . . . . . . . . . . 26 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 27 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 27 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 @@ -351,23 +351,23 @@ 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 Section 5.7). - Note that and/or MUST NOT be - omitted when unknown since this would violate basic syntax of SDP - [RFC4566]. In such cases, they MUST be set to a "-". + Note that and/or MUST NOT be omitted + when unknown since this would violate basic syntax of SDP [RFC4566]. + In such cases, they MUST be set to a "-". The following are examples of the extension to the connection data line: c=PSTN E164 +441134960123 c=PSTN - - When the is PSTN, the connection address is defined as follows: @@ -487,30 +487,21 @@ 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 details. There MUST be at most one "cs-correlation" attribute per media description. The following sections provide more detailed information of these - subfields. The "cs-correlation" attribute has the following format: - - a=cs-correlation: - correlation-mechanisms = corr-mech *(SP corr-mech) - corr-mech = caller-id-mech / uuie-mech / - dfmt-mech / ext-mech - caller-id-mech = "callerid" [":" caller-id-value] - uuie-mech = "uuie" [":" uuie-value] - dtmf-mech = "dtmf" [":" dtmf-value] - ext-mech = [":"] + subfields. Section 5.7> defined the formal syntax. The values "callerid", "uuie" and "dtmf" refer to the correlation mechanisms defined in Section 5.2.3.2, Section 5.2.3.3, and Section 5.2.3.4, respectively. The formal Augmented Backus-Naur Format (ABNF) syntax of the "cs-correlation" attribute is presented in Section 5.7. 5.2.3.2. Caller-ID Correlation Mechanism The Caller-ID correlation mechanisms consists of an exchange of the @@ -538,27 +529,30 @@ 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. 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. + expressed in the SDP, due to, e.g., lack of 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 + [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 Element has a maximum size of 35 or 131 octets, depending on the actual message of the PSTN protocol where it is included and the @@ -591,32 +584,25 @@ are input to the creation of the value of the "uuie" subfield in the "cs-correlation" attribute. Therefore, the value of the "uuie" subfield in the "cs-correlation" attribute MUST start with the Protocol Discriminator octet, followed by the User Information octets. The value of the Protocol Discriminator octet is not specified in this document; it is expected that organizations using this technology will allocate a suitable value for the Protocol Discriminator. Once the binary value of the "uuie" subfield in the "cs-correlation" - attribute is created, it MUST be encoded in hexadecimal before it is - inserted in SDP. Each octet of binary data to be represented in the - hexadecimal encoding MUST be mapped to two hexadecimal digits - (represented by ASCII characters 0-9 and A-F), each representing four - bits within the octet. The four bits appearing first in the binary - data MUST be mapped to the first hexadecimal digit and the four - subsequent bits in the binary data MUST be mapped to the second - hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the - bit appearing first in the binary data SHALL be most significant. - Thus, the resulting hexadecimal encoded value needs to have an even - number of hexadecimal digits, and MUST be considered invalid if it - has an odd number. + attribute is created, it MUST be base 16 (also known as "hex") + encoded before it is inserted in SDP. Please refer to RFC 4648 + [RFC4648] for a detailed description of base 16 encoding. The + resulting encoded value needs to have an even number of hexadecimal + digits, and MUST be considered invalid if it has an odd number. Note that the encoding of the "uuie" subfield of the "cs- correlation" attribute is largely inspired by the encoding of the same value in the User-to-User header field in SIP, according to 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 @@ -664,41 +650,35 @@ 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 attempt collects the digits and compares them with the value previously received in the SDP. If the digits match, then the call setup attempt corresponds to that indicated in the SDP. Implementations are advised to select a number of DTMF digits that provide enough assurance that the call is related, but on the - other hand do not prolong the bearer setup time unnecessarily. + other hand do not prolong the bearer setup time unnecessarily. A + number of 5 to 10 digits is a good compromise. As an example, an endpoint willing to send DTMF tone sequence "14D*3" would include a "cs-correlation" attribute line as follows: a=cs-correlation:dtmf:14D*3 If the endpoints successfully agree on the usage of the DTMF digit correlation mechanism, but the passive side does not receive any DTMF digits after successful circuit-switched bearer setup, or receives a set of DTMF digits that do not match the value of the "dtmf" attribute (including receiving too many digits), the passive side - SHOULD treat the circuit-switched bearer as not correlated to the - ongoing session. - - DTMF digits can only be sent once the circuit-switched bearer is - set up. In order to suppress alerting for an incoming circuit- - switched call, implementations may choose various mechanisms. For - example, alerting may be suppressed for a certain time period for - incoming call attempts that originate from the number that was - observed during the offer/answer negotiation. + SHOULD consider that this DTMF mechanism has failed to correlate the + incoming call. 5.2.3.5. 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). @@ -774,27 +754,33 @@ switched bearer setup MUST include all correlation mechanisms it supports in the "a=cs-correlation" attribute, but MUST NOT specify values for the subfields. An endpoint that is willing to become either the active or passive party (by including the "a=setup:actpass" attribute in the Offer), MUST include all correlation mechanisms it supports in the "a=cs- correlation" attribute, and MUST also specify values for the subfields. -5.3.3. Considerations on successful correlation +5.3.3. Considerations on correlations - Note that, as stated above, 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. + 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 uduring the offer/answer + negotiation. + + 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. If, after negotiating one or more correlation mechanisms in the SDP offer/answer exchange, an endpoint receives a circuit-switched bearer with no correlation information present, the endpoint has two choices: it can either treat the call as unrelated, or treat the call @@ -855,25 +841,25 @@ a "black hole" connection address, which has the property that 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 name within the .invalid DNS top level domain. When using an E.164 address scheme in the context of third-party call control, when the User Agent needs to indicate an unknown phone number, it MUST populate the of the SDP "c=" line with a "-" string. - Note that this may result in the recipient of the initial Offer in - rejecting the Offer if the recipient of the Offer is not aware of - its own E.164 number, and thus concluding that it will not be - possible to establish a circuit-switched bearer since neither - party is aware of their E.164 number. + Note that this may result in the recipient of the initial offer + rejecting such offer if the recipient of the offer was not aware + of its own E.164 number. Consequently it will not be possible to + establish a circuit-switched bearer, since neither party is aware + of their E.164 number. 5.6. Offer/Answer mode extensions In this section, we define extensions to the Offer/Answer model defined in The Offer/Answer Model in SDP [RFC3264] to allow for PSTN addresses to be used with the Offer/Answer model. 5.6.1. Generating the Initial Offer The Offerer, wishing to use PSTN audio or video stream, MUST populate @@ -1556,20 +1541,23 @@ [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, October 2006. + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, 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]