idnits 2.17.1 draft-ietf-mmusic-sdp-cs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2009) is 5539 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 968, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-01) exists of draft-garcia-mmusic-sdp-misc-cap-00 == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-09 == Outdated reference: A later version (-17) exists of draft-ietf-mmusic-sdp-media-capabilities-06 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC WG M. Garcia-Martin 3 Internet-Draft Ericsson 4 Intended status: Standards Track S. Veikkolainen 5 Expires: August 29, 2009 Nokia 6 February 25, 2009 8 Session Description Protocol (SDP) Extension For Setting Up Audio Media 9 Streams Over Circuit-Switched Bearers In The Public Switched Telephone 10 Network (PSTN) 11 draft-ietf-mmusic-sdp-cs-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 29, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 This memo describes use cases, requirements, and protocol extensions 51 for using the Session Description Protocol (SDP) Offer/Answer model 52 for establishing audio media stream over circuit-switched bearers in 53 the Public Switched Telephone Network (PSTN). 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 59 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 6 62 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 8 64 5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 8 65 5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 8 66 5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 9 67 5.2.3. Correlating the PSTN Circuit-Switched Bearer with 68 SDP . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.2.3.1. The "correlation" attribute . . . . . . . . . . . 11 70 5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 11 71 5.2.3.3. User-User Information Element Correlation 72 Mechanism . . . . . . . . . . . . . . . . . . . . 12 73 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 13 74 5.2.3.5. Negotiating the used correlation mechanisms . . . 15 75 5.3. Considerations for Usage of Existing SDP . . . . . . . . . 16 76 5.3.1. Originator of the Session . . . . . . . . . . . . . . 16 77 5.3.2. Contact information . . . . . . . . . . . . . . . . . 17 78 5.3.3. Determining the Direction of the Circuit-Switched 79 Connection Setup . . . . . . . . . . . . . . . . . . . 17 80 5.4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 18 81 6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 6.1. Basic SDP example: Single Circuit-Switched Audio Stream . 19 83 6.2. Advanced SDP example: Alternative and IP 84 Circuit-Switched Audio Streams . . . . . . . . . . . . . . 20 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 86 7.1. Registration of new correlation SDP attribute . . . . . . 22 87 7.2. Registration of a new "nettype" value . . . . . . . . . . 22 88 7.3. Registration of new "addrtype" values . . . . . . . . . . 22 89 7.4. Registration of a new "proto" value . . . . . . . . . . . 22 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 98 1. Introduction 100 The Session Description Protocol (SDP) [RFC4566] is intended for 101 describing multimedia sessions for the purposes of session 102 announcement, session invitation, and other forms of multimedia 103 session initiation. SDP is most commonly used for describing media 104 streams that are transported over the Real-Time Transport Protocol 105 (RTP) [RFC3550], using the profiles for audio and video media defined 106 in RTP Profile for Audio and Video Conferences with Minimal Control 107 [RFC3551]. 109 However, SDP can be used to describe other transport protocols than 110 RTP. Previous work includes SDP conventions for describing ATM 111 bearer connections [RFC3108] and the Message Session Relay Protocol 112 [RFC4975]. 114 SDP is commonly carried in Session Initiation Protocol (SIP) 115 [RFC3261] messages in order to agree on a common media description 116 among the endpoints. An Offer/Answer Model with Session Description 117 Protocol (SDP) [RFC3264] defines a framework by which two endpoints 118 can exchange SDP media descriptions and come to an agreement as to 119 which media streams should be used, along with the media related 120 parameters. 122 In some scenarios it might be desirable to establish the media stream 123 over a circuit-switched bearer connection even if the signaling for 124 the session is carried over an IP bearer. An example of such a 125 scenario is illustrated with two mobile devices capable of both 126 circuit-switched and packet-switched communication over a low- 127 bandwidth radio bearer. The radio bearer may not be suitable for 128 carrying real-time audio media, and using a circuit-switched bearer 129 would offer, however, a better perceived quality of service. So, 130 according to this scenario, SDP and its higher layer session control 131 protocol (e.g., the Session Initiation Protocol (SIP) [RFC3261]) are 132 used over regular IP connectivity, while the audio is received 133 through the classical circuit-switched bearer. 135 Setting up a signaling relationship in the IP domain instead of just 136 setting up a circuit-switched call offers also the possibility of 137 negotiating in the same session other IP based media that is not 138 sensitive to jitter and delay, for example, text messaging or 139 presence information. 141 At a later point in time the mobile device might move to an area 142 where a high-bandwidth packet-switched bearer, for example a Wireless 143 Local Area Network (WLAN) connection, is available. At this point 144 the mobile device may perform a handover and move the audio media 145 streams over to the high-speed bearer. This implies a new exchange 146 of SDP offer/answer that lead to a re-negotiation of the media 147 streams. 149 Other use cases exists. For example, and endpoint might have at its 150 disposal circuit-switch and packet-switched connectivity, but the 151 audio codecs are not the same in both access networks. Consider that 152 the circuit-switched audio stream supports narrow-bandwidth codecs, 153 while the packet-switched access allows any other audio codec 154 implemented in the endpoint. In this case, it might be beneficial 155 for the endpoint to describe different codecs for each access type 156 and get an agreement on the bearer together with the remote endpoint. 158 There are additional use cases related to third party call control 159 where the session setup time is improved when the circuit-switched 160 bearer in the PSTN is described together with one or more codecs. 162 The rest of the document is structured as follows: Section 2 provides 163 the document conventions, Section 3 introduces the requirements, 164 Section 4 presents an overview of the proposed solutions, and 165 Section 5 contains the protocol description. Section 6 provides a 166 few examples of descriptions of circuit-switched audio streams in 167 SDP. Section 7 and Section 8 contain the IANA and Security 168 considerations, respectively. 170 2. Conventions Used in This Document 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in BCP 14, RFC 2119 175 [RFC2119] and indicate requirement levels for compliant 176 implementations. 178 3. Requirements 180 This section presents the general requirements that are specific for 181 the audio media stream over circuit-switched bearers. 183 REQ-1: A mechanism for endpoints to negotiate and agree on an audio 184 media stream established over a circuit-switched bearer MUST 185 be available. 187 REQ-2: The mechanism MUST allow the endpoints to combine circuit- 188 switched audio media streams with other complementary media 189 streams, for example, text messaging. 191 REQ-3: The mechanism MUST allow the endpoint to negotiate the 192 direction of the circuit-switched connection, i.e., which 193 endpoint is active when initiating the circuit-switched 194 connection. 196 REQ-4: The mechanism MUST be independent of the type of the circuit- 197 switched access (e.g., Integrated Services Digital Network 198 (ISDN), Global System for Mobile Communication (GSM), etc.) 200 REQ-5: There MUST be a mechanism that helps an endpoint to correlate 201 an incoming circuit-switched bearer with the one negotiated 202 in SDP, as opposed to another incoming call that is not 203 related to that. 205 REQ-6: It must be possible for endpoints to advertise different list 206 of audio codecs in the circuit-switched audio stream from 207 those used in a packet-switched audio stream. 209 REQ-7: It must be possible for endpoints to not advertise the list 210 of available codecs for circuit-switched audio streams. 212 4. Overview of Operation 214 The mechanism defined in this memo extends SDP and allows describing 215 an audio media stream established over a circuit-switched bearer. 216 New tokens are registered in the "c=" and "m=" lines to be able to 217 describe an audio media stream over a circuit-switched bearer. These 218 SDP extensions are described in Section 5.2. Since circuit-switched 219 bearers are a sort of connection-oriented media streams, the 220 mechanism re-uses the connection-oriented extensions defined in RFC 221 4145 [RFC4145] to negotiate the active and passive sides of a 222 connection setup. This is further described in Section 5.3.3. 224 4.1. Example Call Flow 226 Consider the example presented in Figure 1. In this example, Alice 227 is located in an environment where she has access to both IP and 228 circuit-switched bearers for communicating with other endpoints. 229 Alice decides that the circuit-switched bearer offers a better 230 perceived quality of service for voice, and issues an SDP Offer 231 containing the description of an audio media stream over circuit- 232 switched bearer. 234 Alice Bob 235 | (1) SDP Offer (PSTN audio) | 236 |----------------------------------->| 237 | | 238 | (2) SDP Answer (PSTN audio) | 239 |<-----------------------------------| 240 | | 241 | PSTN call setup | 242 |<-----------------------------------| 243 | | 244 | | 245 |<===== media over PSTN bearer =====>| 246 | | 248 Figure 1: Example Flow 250 Bob receives the SDP offer and determines that he is located in an 251 environment where the IP based bearer is not suitable for real-time 252 audio media. However he also has PSTN circuit-switched bearer 253 available for audio. Bob generates an SDP answer containing a 254 description of the audio media stream over a circuit-switched bearer. 256 During the offer-answer exchange Alice and Bob also agree the 257 direction in which the circuit-switched connection should be 258 established. The exchange also contains identifiers or references 259 that can be used on the circuit-switched network for addressing the 260 other endpoint, as well as identifying that the incoming circuit- 261 switched bearer establishment is related to the ongoing session 262 between Alice and Bob. 264 Bob establishes a circuit-switched bearer towards Alice using 265 whatever mechanisms are defined for the network type in question. 266 When receiving the incoming circuit-switched connection attempt, 267 Alice is able to determine that the attempt is related to the session 268 she is just establishing with Bob. 270 Alice accepts the circuit-switched connection; the circuit-switched 271 bearer setup is completed. Bob and Alice can now use the circuit- 272 switched connection for two-way audio media. 274 If, for some reason, Bob would like to reject the offered stream, he 275 would set the port number of the specific stream to zero, as 276 specified in RFC3264 [RFC3264]. Also, if Bob does not understand 277 some of the SDP attributes specified in this document, he would 278 ignore them, as specified in RFC4566 [RFC4566]. 280 5. Protocol Description 282 5.1. Level of Compliance 284 Implementations according to this specification MUST implement the 285 SDP extensions described in Section 5.2, and MUST implement the 286 considerations discussed in Section 5.3. 288 5.2. Extensions to SDP 290 This section provides the syntax and semantics of the extensions 291 required for providing a description of audio media streams over 292 circuit-switched bearers in SDP. 294 5.2.1. Connection Data 296 According to SDP [RFC4566], the connection data line in SDP has the 297 following syntax: 299 c= 301 where indicates the network type, indicates the 302 address type, and the is the connection address, 303 which is dependent on the address type. 305 At the moment, the only network type defined is "IN", which indicates 306 Internet network type. The address types "IP4" and "IP6" indicate 307 the type of IP addresses. 309 This memo defines a new network type for describing a circuit- 310 switched bearer network type in the PSTN. The mnemonic "PSTN" is 311 used for this network type. 313 For the address type, we initially consider the possibility of 314 describing E.164 telephone numbers. We define a new "E164" address 315 type. When used, the "E164" address type indicates that the 316 connection address contains a telephone number represented according 317 to the ITU-T E.164 [ITU.E164.1991] recommendation. 319 There are cases, though, when the endpoint is merely aware of a 320 circuit-switched bearer, without having further information about the 321 address type or the E.164 number allocated to it. In these cases a 322 dash "-" is used to indicate an unknown address type or connection 323 address. This makes the connection data line be according to the SDP 324 syntax. 326 Note that and/or should not be 327 omitted without being set to a "-" since this would violate basic 328 syntax of SDP [RFC4566]. 330 The following are examples of the extension to the connection data 331 line: 333 c=PSTN E164 +15551234 335 c=PSTN - - 337 5.2.2. Media Descriptions 339 According to SDP [RFC4566], the media descriptions line in SDP has 340 the following syntax: 342 m= ... 344 The sub-field carries the media type. Since this document 345 deals with establishing an audio bearer, the existing "audio" media 346 type is used. 348 The sub-field is the transport port to which the media stream 349 is sent. Circuit-switched access lacks the concept of a port number, 350 and therefore the sub-field is set to the discard port "9". 352 According to RFC 3264 [RFC3264], a port number of zero in the offer 353 of a unicast stream indicates that the stream is offered but must not 354 be used. If a port number of zero is present in the answer of a 355 unicast stream, it indicates that the stream is rejected. These 356 rules are still valid when the media line in SDP represents a 357 circuit-switched bearer. 359 The sub-field is the transport protocol. The circuit- 360 switched bearer uses whatever transport protocol it has available. 361 This subfield SHOULD be set to the mnemonic "PSTN" to be 362 syntactically correct with SDP [RFC4566] and to indicate the usage of 363 circuit-switched protocols in the PSTN. 365 The sub-field is the media format description. In the 366 classical usage of SDP to describe RTP-based media streams, when the 367 sub-field is set to "RTP/AVP" or "RTP/SAVP", the sub- 368 field contains the payload types as defined in the RTP audio profile 369 [RFC3551]. 371 In the case of circuit-switched descriptions, RTP is not really used. 372 Rather than specifying the RTP audio profile payload type, we use the 373 sub-field to indicate the list of available media types over 374 the circuit-switched bearer. Therefore, the sub-field MAY 375 indicate one or more available audio codecs for a circuit-switched 376 audio stream. We use the classical RTP audio media types, even when 377 applied to PSTN circuit-switched bearers, the media type merely 378 represents an audio codec. 380 However, in some cases, the endpoint is not able to determine the 381 list of available codecs for circuit-switched audio streams. In this 382 case, in order to be syntactically compliant with SDP [RFC4566], the 383 endpoint MUST include a single dash "-" in the sub-field. 385 As per RFC 4566 [RFC4566], the media format descriptions are listed 386 in priority order. 388 Example of a media description for circuit-switched audio streams is: 390 m=audio 9 PSTN 3 0 8 392 m=audio 9 PSTN - 394 5.2.3. Correlating the PSTN Circuit-Switched Bearer with SDP 396 The endpoints should be able to correlate the circuit-switched bearer 397 with the session negotiated with SDP to avoid ringing for an incoming 398 circuit-switched bearer that is related to the session controlled 399 with SDP (and SIP). 401 Several alternatives exist for performing this correlation. This 402 memo provides three mutually non-exclusive correlation mechanisms. 403 Other correlation mechanisms might exist as well, and their usage 404 will be specified when need arises. All mechanisms share the same 405 principles: some unique information is sent in the SDP and in the 406 circuit-switched signaling protocol. If these pieces of information 407 match, then the circuit-switched bearer is part of the session 408 described in the SDP exchange. Otherwise, there is no guarantee that 409 the circuit-switched bearer is related to such session. 411 The first mechanism is based on the exchange of PSTN caller-ID 412 between the endpoints. The caller-ID is also available as the 413 Calling Party ID in the circuit-switched signaling. 415 The second mechanism is based on the inclusion in SDP of a value that 416 is also sent in the User-to-User Information Element that is part of 417 the bearer setup signaling in the PSTN. 419 The third mechanism is based on sending in SDP a string that 420 represents Dual Tone MultiFrequency (DTMF) digits that will be later 421 sent right after the circuit-switched bearer is established. 423 Implementations MAY use any of these mechanisms and MAY use two or 424 more mechanisms simultaneously. 426 5.2.3.1. The "correlation" attribute 428 In order to provide support for the correlation mechanisms, we define 429 a new SDP attribute called "correlation". This "correlation" 430 attribute can include any of the "callerid", "uuie", or "dtmf" 431 parameters, which specify additional information required by the 432 Caller-ID, User to User Information, or DTMF correlation mechanisms, 433 respectively. 435 The following sections provide more detailed information of these 436 parameters. The "correlation" attribute has the following format: 438 "a=correlation: "callerid:" | 439 "uuie:" | 440 "dtmf:" 442 The values "callerid", "uuie" and "dtmf" refer to the correlation 443 mechanisms defined in Section 5.2.3.2, Section 5.2.3.3, and 444 Section 5.2.3.4, respectively. The formal Augmented Backus-Naur 445 Format (ABNF) syntax of the "correlation" attribute is presented in 446 Section 5.4. 448 5.2.3.2. Caller-ID Correlation Mechanism 450 The Caller-ID correlation mechanisms consists of an exchange of the 451 calling party number in E.164 format in SDP, followed by the 452 availability of the Calling Party Number information element in the 453 call setup signaling of the circuit switched connection. If both 454 pieces of information match, the circuit-switched bearer is 455 correlated to the session described in SDP. 457 An endpoint that is feasible to become the active party for setting 458 up the circuit-switched bearer and is willing to send the Calling 459 Party Number in the PSTN signaling SHOULD add a "callerid" parameter 460 in the "correlation" attribute of the SDP offer or answer, and SHOULD 461 include as the value the E.164 number that will be presented in the 462 Calling Party Number in the PSTN signaling. 464 An endpoint that acts as the passive party for setting up the 465 circuit-switch bearer SHOULD add a "callerid" parameter in the 466 "correlation" attribute of the SDP if it supports the mechanism, and 467 MAY include the E.164 number that will be presented in the circuit- 468 switched bearer in the same corresponding lines, although these are 469 not used for correlation. 471 Example of inclusion of E.164 number in the "correlation" attribute 472 is: 474 a=correlation:callerid:+15551234 476 Please note that there are no warranties that this correlation 477 mechanism works or is even available, due a number of problems: 479 o The endpoint might not be aware of its own E.164 number, in which 480 case it cannot populate the SDP appropriately. 482 o The Calling Party Number information element in the circuit- 483 switched signaling might not be available, e.g., due to policy 484 restrictions of the network operator or caller restriction due to 485 privacy. 487 o The Calling Party Number information element in the circuit- 488 switched signaling might be available, but the digit 489 representation of the E.164 number might differ from the one 490 expressed in the SDP. For example, one can be represented in 491 international format and the other might only contain the 492 significant national digits. To mitigate this problem 493 implementations should consider only some of the rightmost digits 494 from the E.164 number for correlation. For example, the numbers 495 +358-1-555-12345 and 01-555-12345 could be considered as the same 496 number. This is also the behavior of some cellular phones, which 497 correlate the incoming calling party with a number stored in the 498 phone book, for the purpose of displaying the caller's name. 500 5.2.3.3. User-User Information Element Correlation Mechanism 502 A second correlation mechanism is based on indicating in SDP a string 503 that represents the User-User Information Element that is part of the 504 call setup signaling of the circuit-switched bearer. The User-User 505 Information Element is specified in ITU-T Q.931 [ITU.Q931.1998] and 506 3GPP TS 24.008 [3GPP.24.008], among others. The User-User 507 Information Element has a maximum size of 35 or 131 octets, depending 508 on the actual message of the PSTN protocol where it is included. 510 The mechanism works as follows: An endpoint creates a User-User 511 Information Element, according to the requirement of the call setup 512 signaling protocol. The same value is included in the SDP offer or 513 SDP answer, in a correlation:uuie attribute. When the SDP offer/ 514 answer exchange is completed, each endpoint has become aware of the 515 value that will be used in the User-User Information Element of the 516 call setup message of the PSTN protocol. The endpoint that initiates 517 the call setup attempt includes this value in the User-User 518 Information Element. The recipient of the call setup attempt can 519 extract the User-User Information Element and correlate it with the 520 value previously received in the SDP. If both values match, then the 521 call setup attempt corresponds to that indicated in the SDP. 523 Note that, for correlation purposes, the value of the User-User 524 Information Element is considered as a opaque string and only used 525 for correlation purposes. Typically call signaling protocols impose 526 requirements on the creation of User-User Information Element for 527 end-user protocol exchange. The details regarding the generation of 528 the User-User Information Element are outside the scope of this 529 specification. 531 An endpoint that is feasible to become the active party for setting 532 up the PSTN call and is willing to send the User-User Information 533 Element in the PSTN signaling SHOULD add a "uuie" parameter in the 534 "correlation" attribute of the SDP offer or answer. This "uuie" 535 parameter SHOULD include the value of the User-User Information 536 Element that will be used in the call setup attempt. 538 An endpoint that takes the role of the passive party for setting up 539 the circuit-switched bearer SHOULD include include a "uuie" parameter 540 in the "correlation" attribute in the SDP, if it supports the UUI 541 mechanism. It MAY also add a value for the "uuie" parameter although 542 it is not used for correlation purposes. 544 Please note that there are no warranties that this correlation 545 mechanism works. On one side, policy restrictions might not make the 546 User-User information available end to end in the PSTN. On the other 547 hand, the generation of the User-User Information Element is 548 controlled by the PSTN circuit-switched call protocol, which might 549 not offer enough freedom for generating different values from one 550 endpoint to another one, or from one call to another in the same 551 endpoint. This might result in the same value of the User-User 552 Information Element for all calls. 554 5.2.3.4. DTMF Correlation Mechanism 556 We introduce a third mechanism for correlating the circuit-switched 557 bearer with the session controlled with SDP. This is based in 558 agreeing on a sequence of digits that are negotiated in the SDP 559 Offer/Answer exchange and sent as Dual Tone Multifrequency 560 (DTMF)tones over the circuit-switched bearer once this bearer is 561 established. If the DTMF digit sequence received through the 562 circuit-switched bearer matches the digit string negotiated in the 563 SDP, the circuit-switched bearer is correlated with the session 564 described in the SDP. The mechanism is similar to many voice 565 conferencing systems which require the user to enter a PIN code using 566 DTMF tones in order to be accepted in a voice conference. 568 The mechanism works as follows: An endpoint selects a DTMF digit 569 sequence. The same sequence is included in the SDP offer or SDP 570 answer, in a "correlation:dtmf" attribute. When the SDP offer/answer 571 exchange is completed, each endpoint has become aware of the DTMF 572 sequence that will be sent right after the circuit-switched bearer is 573 set up. The endpoint that initiates the call setup attempt sends the 574 DTMF digits as per the procedures defined for the circuit-switched 575 bearer technology used. The recipient (passive side of the bearer 576 setup) of the call setup attempt collects the digits and correlates 577 them with the value previously received in the SDP. If the digits 578 match, then the call setup attempt corresponds to that indicated in 579 the SDP. 581 An endpoint that is feasible to become the active party for setting 582 up the PSTN call and is willing to send the DTMF digits after 583 circuit-switched bearer cut-through SHOULD include a "dtmf" parameter 584 in the "correlation" attribute of the SDP offer or answer. The value 585 of the "dtmf" parameter SHOULD contain up to 32 randomly selected 586 DTMF digits (numbers 0-9, characters A-D, "#" and "*"). 588 Implementations are advised to select a number of DTMF digits that 589 provide enough assurance that the call is related, but on the 590 other hand do not prolong the bearer setup time unnecessarily. 592 As an example, an endpoint willing to send DTMF tone sequence "14D*3" 593 would include a "correlation" attribute line as follows: 595 a=correlation:dtmf:14D*3 597 An endpoint that takes the role of the passive party for setting up 598 the circuit-switched bearer SHOULD include include a "dtmf" parameter 599 in the "correlation" attribute in the SDP, if it supports the 600 mechanism. It MAY also add a value for the "dtmf" parameter although 601 it is not used for correlation purposes. 603 Once the circuit-switched bearer is successfully set up, the active 604 side MUST send DTMF digits according to the circuit-switched bearer 605 technology used. The values and number of the DTMF digits MUST match 606 those that were agreed during SDP negotiation. 608 The passive side of the circuit-switched connection setup MUST be 609 prepared to receive and collect DTMF digits once the circuit-switched 610 bearer is set up. The received DTMF digits are compared to the value 611 of the "dtmf" parameter of the "correlation" attribute that the the 612 active side sent during SDP offer/answer exchange. If the received 613 DTMF digits match the value of the "dtmf" parameter in the 614 "correlation" attribute, the call SHOULD be treated as correlated to 615 the ongoing session. 617 If the offerer and answerer successfully agree on the usage of the 618 DTMF digit correlation mechanism, but the passive side does not 619 receive any DTMF digits after successful circuit-switched bearer 620 setup, or receives a set of DTMF digits that do not match the value 621 of the "dtmf" attribute (including receving too many digits), the 622 passive side SHOULD treat the circuit-switched bearer as not 623 correlated to the ongoing session. 625 DTMF digits can only be sent once the circuit-switched bearer is 626 set up. In order to suppress alerting for an incoming circuit- 627 switched call, implementations may choose various mechanisms. For 628 example, alerting may be suppressed for a certain time period for 629 incoming call attempts that originate from the number that was 630 observed during the offer/answer negotiation. 632 5.2.3.5. Negotiating the used correlation mechanisms 634 The three correlation mechanisms presented above (based on called 635 party number, User-User Information Element and DTMF digit sending) 636 are non-exclusive, and can be used independently of each other. 638 In order to agree which correlation mechanisms are supported by each 639 endpoint, we define a negotiation mechanism similar to the one 640 defined for codec negotiation. 642 In some cases an endpoint may support the correlation mechanism, but 643 it is not willing to become the active party in the circuit-switched 644 bearer establishment. 646 If the offerer supports any of the correlation mechanisms defined in 647 this memo, it SHOULD include an attribute line "a=correlation" in the 648 SDP offer. The "a=correlation" line contains an enumeration of the 649 correlation mechanisms supported by the offerer, in the format of 650 parameters. The current list of parameters include "callerid", 651 "uuie" and "dtmf" and they refer to the correlation mechanisms 652 defined in Section 5.2.3.2, Section 5.2.3.3, and Section 5.2.3.4, 653 respectively. For example, if an endpoint is willing to use the 654 User-User Information element and DTMF digit sending mechanisms, it 655 includes the following line to the SDP: 657 a=correlation:uuie dtmf 659 The answerer, when generating the answer, SHOULD select those 660 correlation mechanisms it supports, and include an "a=correlation" 661 attribute line in the answer containing those mechanisms it supports. 662 The answerer MUST NOT add any mechanism which was not included in the 663 offer. 665 If the answer does not contain an "a=correlation" attribute line, the 666 offerer MUST interpret this as an indication that the anwerer does 667 not support any of the correlation mechanisms for this session. 669 If, in addition to supporting any of the correlation mechanisms, an 670 endpoint is willing to assume the role of the active party in 671 establishing the circuit-switched bearer, it MUST add a parameter 672 value to the supported mechanisms. For example, if the endpoint 673 supports and is willing to send the User-User Information element and 674 DTMF digits, it includes the following line to the SDP offer: 676 a=correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3 678 The answerer SHOULD select those correlation mechanisms it supports 679 and is willing to use, and include respective parameter values. If 680 the answerer supports but is not willing to use some of the 681 mechanisms (for example, due to not being able to become the active 682 endpoint when setting up the circuit-switched bearer), it SHOULD 683 include the respective parameter, but MUST NOT add a value to the 684 parameter. 686 Note that, as stated above, it cannot be guaranteed that any given 687 correlation mechanism will succeed even if the usage of those was 688 agreed beforehand. This is due to the fact that the correlation 689 mechanisms require support from the circuit-switched bearer 690 technology used. 692 Therefore, even a single positive indication using any of these 693 mechanisms SHOULD be interpreted by the passive endpoint so that the 694 circuit-switched bearer establishment is related to the ongoing 695 session, even if the other correlation mechanisms fail. 697 5.3. Considerations for Usage of Existing SDP 699 5.3.1. Originator of the Session 701 According to SDP [RFC4566], the origin line in SDP has the following 702 syntax: 704 o= 705 707 Of interest here are the and fields, which 708 indicate the type of network and type of address, respectively. 709 Typically, this field carries the IP address of the originator of the 710 session. Even if the SDP was used to negotiate an audio media stream 711 transported over a circuit-switched bearer, the originator is using 712 SDP over an IP bearer. Therefore, and fields in 713 the "o=" line should be populated with the IP address identifying the 714 source of the signaling. 716 5.3.2. Contact information 718 SDP [RFC4566] defines the "p=" line which may include the phone 719 number of the person reponsible for the conference. Even though this 720 line can carry a phone number, it is not suited for the purpose of 721 defining a connection address for the media. Therefore, we have 722 selected to define the PSTN specific connection addresses in the "c=" 723 line. 725 5.3.3. Determining the Direction of the Circuit-Switched Connection 726 Setup 728 Either endpoint can initiate the establishment of the circuit- 729 switched bearer. In order to avoid a situation where both endpoints 730 attempt to initiate a connection simultaneously, the direction in 731 which the circuit-switched bearer is set up should be negotiated 732 during the Offer/Answer exchange. 734 The framework defined in RFC 4145 [RFC4145] allows the endpoints to 735 agree which endpoint acts as the active endpoint when initiating a 736 TCP connection. While RFC 4145 [RFC4145] was originally designed for 737 establishing TCP connections, it is easily extrapolated to the 738 connection establishment of circuit-switched bearers. This 739 specification uses the concepts specified in RFC 4145 [RFC4145] for 740 agreeing on the direction of establishment of a circuit-switched 741 bearer. 743 RFC 4145 [RFC4145] defines two new attributes in SDP: "setup" and 744 "connection". The "setup" attribute indicates which of the endpoints 745 should initiate the connection establishment of the PSTN circuit- 746 switched bearer. Four values are defined in Section 4 of RFC 4145 747 [RFC4145]: "active", "passive", "actpass", "holdconn". Please refer 748 to Section 4 of RFC 4145 [RFC4145] for a detailed description of this 749 attribute. 751 The "connection" attribute indicates whether a new connection is 752 needed or an existing connection is reused. The attribute can take 753 the values "new" or "existing". Please refer to Section 5 of RFC 754 4145 [RFC4145] for a detailed description of this attribute. 756 Implementations according to this specification MUST support the 757 "setup" and "connection" attributes specified in RFC 4145 [RFC4145], 758 but applied to circuit-switched bearers in the PSTN. 760 In order to establish a circuit-switched connection in the PSTN, the 761 initiating endpoint needs to know the address (E.164 number) of the 762 other endpoint. Therefore, if an endpoint wants to be able to 763 receive incoming circuit-switched calls, it must know its E.164 764 number and must indicate it in SDP. As a consequence, an endpoint 765 that is not aware of its own E.164 number cannot take the role of the 766 passive side with respect the establishment of the circuit-switched 767 connection. 769 5.4. Formal Syntax 771 The following is the formal Augmented Backus-Naur Form (ABNF) 772 [RFC5234] syntax that supports the extensions defined in this 773 specification. The syntax is built above the SDP [RFC4566] grammar. 774 Implementations according to this specification MUST be compliant 775 with this syntax. 777 Figure 2 shows the formal syntax of the extensions defined in this 778 memo. 780 ; extension to the connection field originally specified 781 ; in RFC 4566 783 connection-field = [%x63 "=" nettype SP addrtype SP 784 connection-address CRLF] 785 ;nettype and addrtype are defined in RFC 4566 787 connection-address /= e164-address / "-" 788 e164-address = ["+"] 1*15DIGIT 789 ; DIGIT is specified in RFC 5234 791 ;subrules for correlation attribute 792 attribute /= correlation-attr 793 ; attribute defined in RFC 4566 794 correlation-attr = "correlation:" corr-mechanisms 795 corr-mechanisms = corr-mech *(SP corr-mech) 796 corr-mech = caller-id-mech / uuie-mech / dtmf-mech 797 caller-id-mech = "callerid" [":" caller-id-value] 798 caller-id-value = ["+"] 1*DIGIT 799 uuie-mech = "uuie" [":" uuie-value] 800 uuie-value = 1*32(ALPHA/DIGIT) 801 dtmf-mech = "dtmf" [":" dtmf-value] 802 dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A ) 803 ;0-9, A-D, '#' and '*' 805 Figure 2: Syntax of the SDP extensions 807 6. SDP Examples 809 6.1. Basic SDP example: Single Circuit-Switched Audio Stream 811 Alice Bob 812 | | 813 | (1) SDP Offer (PSTN audio) | 814 |--------------------------------->| 815 | | 816 | (2) SDP Answer (PSTN audio) | 817 |<---------------------------------| 818 | | 819 | PSTN call setup | 820 |<---------------------------------| 821 | | 822 |<==== media over PSTN bearer ====>| 823 | | 825 Figure 3: Basic flow 827 Figure 3 shows a basic example that describes a single audio media 828 stream over a circuit-switched bearer. The SDP offer is show in 829 Figure 4. The endpoint describes a PSTN circuit-switched bearer in 830 the "m=" and "c=" line where it also indicates its E.164 number. 831 Additionally, it expresses that it can initiate the circuit-switched 832 connection or be the recipient of it. The SDP offer also includes a 833 correlation identifier that this endpoint will be inserting the User- 834 User Information Element of the PSTN call setup if eventually this 835 endpoint initiates the PSTN call. 837 v=0 838 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 839 s= 840 t=0 0 841 m=audio 9 PSTN - 842 c=PSTN E164 +15551234 843 a=setup:actpass 844 a=connection:new 845 a=correlation:uuie:2890W284hAT452612908awudfjang908 847 Figure 4: SDP offer (1) 849 6.2. Advanced SDP example: Alternative and IP Circuit-Switched Audio 850 Streams 852 Alice Bob 853 | | 854 | (1) SDP Offer (IP and PSTN audio)| 855 |--------------------------------->| 856 | | 857 | (2) SDP Answer (PSTN audio) | 858 |<---------------------------------| 859 | | 860 | PSTN call setup | 861 |<---------------------------------| 862 | | 863 |<==== media over PSTN bearer ====>| 864 | | 866 Figure 5: Alternative media 868 Figure 5 shows an example of negotiating audio media streams over IP 869 or circuit-switched bearers. Using the mechanisms described in SDP 870 Capability Negotiation Framework 871 [I-D.ietf-mmusic-sdp-capability-negotiation] and extensions thereof 872 (SDP media capabilities Negotiation 873 [I-D.ietf-mmusic-sdp-media-capabilities] and SDP Miscellaneous 874 Capabilities [I-D.garcia-mmusic-sdp-misc-cap]) it is possible to 875 construct an SDP offer where audio media can be offered alternatively 876 over IP or circuit-switched bearer. 878 v=0 879 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 880 s= 881 t=0 0 882 m=audio 49170 RTP/AVP 0 8 3 883 c=IN IP4 192.0.2.5 884 a=creq:med-v0,ccap-v0 885 a=mcap:1 PCMU/8000/1 886 a=mcap:2 PCMA/8000/1 887 a=mcap:3 GSM/8000/1 888 a=mcap:4 - 889 a=tcap:1 RTP/AVP PSTN 890 a=ccap:1 IN IP4 192.0.2.1 891 a=ccap:2 PSTN E164 +15551234 892 a=acap:1 correlation:uuie:2890W284hAT452612908awudfjang908 893 a=acap:2 setup:actpass 894 a=acap:3 connection:new 895 a=pcfg:1 t=1 m=1,2,3 c=1 896 a=pcfg:2 t=2 m=4 c=2 a=1,2,3 898 Figure 6: SDP offer with alternative media (1) 900 Upon receiving the SDP offer descibed in Figure 6, Bob decided to 901 select the circuit-switched bearer and generates the answer described 902 in Figure 7 904 v=0 905 o=- 2890973824 2890987289 IN IP4 192.0.2.7 906 s= 907 t=0 0 908 m=audio - PSTN - 909 c=PSTN - - 910 a=acfg:2 911 a=setup:active 912 a=connection:new 913 a=correlation:uuie:2890W284hAT452612908awudfjang908 915 Figure 7: SDP answer with circuit-switched media (2) 917 7. IANA Considerations 919 This document instructs IANA to register a number of SDP tokens 920 according to the following data. 922 7.1. Registration of new correlation SDP attribute 924 Contact: Miguel Garcia 926 Attribute name: correlation 928 Long-form attribute name: PSTN Correlation Identifier 930 Type of attribute: media level only 932 This attribute is subject to the charset attribute 934 Description: This attribute provides the Correlation Identifier 935 used in PSTN signaling 937 Specification: RFC XXXX 939 7.2. Registration of a new "nettype" value 941 This memo provides instructions to IANA to register a new "nettype" 942 in the Session Description Protocol Parameters registry [1]. The 943 registration data, according to RFC 4566 [RFC4566] follows. 945 Type SDP Name Reference 946 ---- ------------------ --------- 947 nettype PSTN [RFCxxxx] 949 7.3. Registration of new "addrtype" values 951 This memo provides instructions to IANA to register a new "addrtype" 952 in the Session Description Protocol Parameters registry [1]. The 953 registration data, according to RFC 4566 [RFC4566] follows. 955 Type SDP Name Reference 956 ---- ------------------ --------- 957 addrtype E164 [RFCxxxx] 958 - [RFCxxxx] 960 7.4. Registration of a new "proto" value 962 This memo provides instructions to IANA to register a new "proto" in 963 the Session Description Protocol Parameters registry [1]. The 964 registration data, according to RFC 4566 [RFC4566] follows. 966 Type SDP Name Reference 967 -------------- --------------------------- --------- 968 proto PSTN [RFCxxxx] 970 8. Security Considerations 972 This document provides an extension on top of RFC 4566 [RFC4566], and 973 RFC 3264 [RFC3264]. As such, the security considerations of those 974 documents apply. 976 9. Acknowledgments 978 The authors want to thank Flemming Andreasen, Thomas Belling, Jari 979 Mutikainen, Miikka Poikselka, Jonathan Rosenberg, Ingemar Johansson, 980 Christer Holmberg, and Alf Heidermark for providing their insight and 981 comments on this document. 983 10. References 985 10.1. Normative References 987 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 988 Requirement Levels", BCP 14, RFC 2119, March 1997. 990 [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the 991 Session Description Protocol (SDP) for ATM Bearer 992 Connections", RFC 3108, May 2001. 994 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 995 with Session Description Protocol (SDP)", RFC 3264, 996 June 2002. 998 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 999 the Session Description Protocol (SDP)", RFC 4145, 1000 September 2005. 1002 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1003 Description Protocol", RFC 4566, July 2006. 1005 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1006 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1008 10.2. Informative References 1010 [3GPP.24.008] 1011 3GPP, "Mobile radio interface Layer 3 specification; Core 1012 network protocols; Stage 3", 3GPP TS 24.008 3.20.0, 1013 December 2005. 1015 [I-D.garcia-mmusic-sdp-misc-cap] 1016 Garcia, M., Veikkolainen, S., and R. Gilman, 1017 "Miscellaneous Capabilities Negotiation in the Session 1018 Description Protocol (SDP)", 1019 draft-garcia-mmusic-sdp-misc-cap-00 (work in progress), 1020 October 2008. 1022 [I-D.ietf-mmusic-sdp-capability-negotiation] 1023 Andreasen, F., "SDP Capability Negotiation", 1024 draft-ietf-mmusic-sdp-capability-negotiation-09 (work in 1025 progress), July 2008. 1027 [I-D.ietf-mmusic-sdp-media-capabilities] 1028 Gilman, R., Even, R., and F. Andreasen, "SDP media 1029 capabilities Negotiation", 1030 draft-ietf-mmusic-sdp-media-capabilities-06 (work in 1031 progress), January 2009. 1033 [ITU.E164.1991] 1034 International Telecommunications Union, "The International 1035 Public Telecommunication Numbering Plan", ITU- 1036 T Recommendation E.164, 1991. 1038 [ITU.Q931.1998] 1039 "Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN 1040 User - Network Interface Layer 3 Specification for Basic 1041 Call Control", ISO Standard 9594-1, May 1998. 1043 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1044 A., Peterson, J., Sparks, R., Handley, M., and E. 1045 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1046 June 2002. 1048 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1049 Jacobson, "RTP: A Transport Protocol for Real-Time 1050 Applications", STD 64, RFC 3550, July 2003. 1052 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1053 Video Conferences with Minimal Control", STD 65, RFC 3551, 1054 July 2003. 1056 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1057 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1059 URIs 1061 [1] 1063 Authors' Addresses 1065 Miguel A. Garcia-Martin 1066 Ericsson 1067 Calle Via de los Poblados 13 1068 Madrid, ES 28033 1069 Spain 1071 Email: miguel.a.garcia@ericsson.com 1073 Simo Veikkolainen 1074 Nokia 1075 P.O. Box 407 1076 NOKIA GROUP, FI 00045 1077 Finland 1079 Phone: +358 50 486 4463 1080 Email: simo.veikkolainen@nokia.com