idnits 2.17.1 draft-garcia-mmusic-sdp-cs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 910. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 923. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 30, 2008) is 5657 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 771, 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-05 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: May 3, 2009 Nokia 6 October 30, 2008 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-garcia-mmusic-sdp-cs-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 3, 2009. 38 Abstract 40 This memo describes use cases, requirements, and protocol extensions 41 for using the Session Description Protocol (SDP) Offer/Answer model 42 for establishing audio media streams over circuit-switched bearers in 43 the Public Switched Telephone Network (PSTN). 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 49 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 51 4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5 52 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 53 5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 7 54 5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 7 55 5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 7 56 5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 8 57 5.2.3. Correlating the PSTN Circuit-Switched Bearer with 58 SDP . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5.2.3.1. Caller-ID Correlation Mechanism . . . . . . . . . 9 60 5.2.3.2. User-User Information Element Correlation 61 Mechanism . . . . . . . . . . . . . . . . . . . . 10 62 5.3. Considerations for Usage of Existing SDP . . . . . . . . . 12 63 5.3.1. Originator of the Session . . . . . . . . . . . . . . 12 64 5.3.2. Contact Information . . . . . . . . . . . . . . . . . 12 65 5.3.3. Determining the Direction for Setting Up the 66 Circuit-Switched Bearer . . . . . . . . . . . . . . . 12 67 5.4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 13 68 6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 6.1. Basic SDP Example: Single Circuit-Switched Audio Stream . 14 70 6.2. Advanced SDP Example: Alternative IP and 71 Circuit-Switched Audio Streams . . . . . . . . . . . . . . 15 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 7.1. Registration of a New 'corr-id' SDP Attribute . . . . . . 17 74 7.2. Registration of a New "nettype" value . . . . . . . . . . 17 75 7.3. Registration of New "addrtype" values . . . . . . . . . . 17 76 7.4. Registration of a New "proto" value . . . . . . . . . . . 17 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 83 Intellectual Property and Copyright Statements . . . . . . . . . . 21 85 1. Introduction 87 The Session Description Protocol (SDP) [RFC4566] is intended for 88 describing multimedia sessions for the purposes of session 89 announcement, session invitation, and other forms of multimedia 90 session initiation. SDP is most commonly used for describing media 91 streams that are transported over the Real-Time Transport Protocol 92 (RTP) [RFC3550], using the profiles for audio and video media defined 93 in RTP Profile for Audio and Video Conferences with Minimal Control 94 [RFC3551]. 96 However, SDP can be used to describe other transport protocols than 97 RTP. Previous work includes SDP conventions for describing ATM 98 bearer connections [RFC3108] and the Message Session Relay Protocol 99 [RFC4975]. 101 SDP is commonly carried in Session Initiation Protocol (SIP) 102 [RFC3261] messages in order to agree on a common media description 103 among the endpoints. An Offer/Answer Model with Session Description 104 Protocol (SDP) [RFC3264] defines a framework by which two endpoints 105 can exchange SDP media descriptions and come to an agreement as to 106 which media streams should be used, along with the media related 107 parameters. 109 In some scenarios it might be desirable to establish the media stream 110 over a circuit-switched bearer connection even if the signaling for 111 the session is carried over an IP bearer. An example of such a 112 scenario is illustrated with two mobile devices capable of both 113 circuit-switched and packet-switched communication over a low- 114 bandwidth radio bearer. The radio bearer may not be suitable for 115 carrying real-time audio media, and using a circuit-switched bearer 116 would offer, however, a better perceived quality of service. So, 117 according to this scenario, SDP and its higher layer session control 118 protocol (e.g., the Session Initiation Protocol (SIP) [RFC3261]) are 119 used over regular IP connectivity, while the audio is received 120 through the classical circuit-switched bearer. 122 Setting up a signaling relationship in the IP domain instead of just 123 setting up a circuit-switched call offers also the possibility of 124 negotiating in the same session other IP based media that is not 125 sensitive to jitter and delay, for example, text messaging or 126 presence information. 128 At a later point in time the mobile device might move to an area 129 where a high-bandwidth packet-switched bearer, for example a Wireless 130 Local Area Network (WLAN) connection, is available. At this point 131 the mobile device may perform a handover and move the audio media 132 streams over to the high-speed bearer. This implies a new exchange 133 of SDP offer/answer that lead to a re-negotiation of the media 134 streams. 136 Other use cases exists. For example, and endpoint might have at its 137 disposal circuit-switch and packet-switched connectivity, but the 138 audio codecs are not the same in both access networks. Consider that 139 the circuit-switched audio stream supports narrow-bandwidth codecs, 140 while the packet-switched access allows any other audio codec 141 implemented in the endpoint. In this case, it might be beneficial 142 for the endpoint to describe different codecs for each access type 143 and get an agreement on the bearer together with the remote endpoint. 145 There are additional use cases related to third party call control 146 where the session setup time is improved when the circuit-switched 147 bearer in the PSTN is described together with one or more codecs. 149 The rest of the document is structured as follows: Section 2 provides 150 the document conventions, Section 3 introduces the requirements, 151 Section 4 presents an overview of the proposed solutions, and 152 Section 5 contains the protocol description. Section 6 provides a 153 few examples of descriptions of circuit-switched audio streams in 154 SDP. Section 7 and Section 8 contain the IANA and Security 155 considerations, respectively. 157 2. Conventions Used in This Document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in BCP 14, RFC 2119 162 [RFC2119] and indicate requirement levels for compliant 163 implementations. 165 3. Requirements 167 This section presents the general requirements that are specific for 168 the audio media stream over circuit-switched bearers. 170 REQ-1: A mechanism for endpoints to negotiate and agree on an audio 171 media stream established over a circuit-switched bearer MUST 172 be available. 174 REQ-2: The mechanism MUST allow the endpoints to combine circuit- 175 switched audio media streams with other complementary media 176 streams, for example, text messaging. 178 REQ-3: The mechanism MUST allow the endpoint to negotiate the 179 direction of the circuit-switched connection, i.e., which 180 endpoint is active when initiating the circuit-switched 181 connection. 183 REQ-4: The mechanism MUST be independent of the type of the circuit- 184 switched access (e.g., Integrated Services Digital Network 185 (ISDN), Global System for Mobile Communication (GSM), etc.) 187 REQ-5: There MUST be a mechanism that helps an endpoint to correlate 188 an incoming circuit-switched call with the one negotiated in 189 SDP, as opposed to another incoming call that is not related 190 to that. 192 REQ-6: It must be possible for endpoints to advertise different list 193 of audio codecs in the circuit-switched audio stream from 194 those used in a packet-switched audio stream. 196 REQ-7: It must be possible for endpoints to not advertise the list 197 of available codecs for circuit-switched audio streams. 199 4. Overview of Operation 201 The mechanism defined in this memo extends SDP and allows describing 202 an audio media stream established over a circuit-switched bearer. 203 New tokens are registered in the "c=" and "m=" lines to be able to 204 describe an audio media stream over a circuit-switched bearer. These 205 SDP extensions are described in Section 5.2. Since circuit-switched 206 bearers are a sort of connection-oriented media streams, the 207 mechanism re-uses the connection-oriented extensions defined in RFC 208 4145 [RFC4145] to negotiate the active and passive sides of a 209 connection setup. This is further described in Section 5.3.3. 211 4.1. Example Call Flow 213 Consider the example presented in Figure 1. In this example, Alice 214 is located in an environment where she has access to both IP and 215 circuit-switched bearers for communicating with other endpoints. 216 Alice decides that the circuit-switched bearer offers a better 217 perceived quality of service for voice, and issues an SDP Offer 218 containing the description of an audio media stream over circuit- 219 switched bearer. 221 Alice Bob 222 | (1) SDP Offer (PSTN audio) | 223 |----------------------------------->| 224 | | 225 | (2) SDP Answer (PSTN audio) | 226 |<-----------------------------------| 227 | | 228 | PSTN call setup | 229 |<-----------------------------------| 230 | | 231 | | 232 |<===== media over PSTN bearer =====>| 233 | | 235 Figure 1: Example Flow 237 Bob receives the SDP offer and determines that he is located in an 238 environment where the IP based bearer is not suitable for real-time 239 audio media. However he also has PSTN circuit-switched bearer 240 available for audio. Bob generates an SDP answer containing a 241 description of the audio media stream over a circuit-switched bearer. 243 During the offer-answer exchange Alice and Bob also agree the 244 direction in which the circuit-switched connection should be 245 established. The exchange also contains identifiers or references 246 that can be used on the circuit-switched network for addressing the 247 other endpoint, as well as identifying that the incoming circuit- 248 switched bearer establishment is related to the ongoing session 249 between Alice and Bob. 251 Bob establishes a circuit-switched bearer towards Alice using 252 whatever mechanisms are defined for the network type in question. 253 When receiving the incoming circuit-switched connection attempt, 254 Alice is able to determine that the attempt is related to the session 255 she is just establishing with Bob. 257 Alice accepts the circuit-switched connection; the circuit-switched 258 bearer setup is completed. Bob and Alice can now use the circuit- 259 switched connection for two-way audio media. 261 If, for some reason, Bob would like to reject the offered stream, he 262 would set the port number of the specific stream to zero, as 263 specified in RFC3264 [RFC3264]. Also, if Bob does not understand 264 some of the SDP attributes specified in this document, he would 265 ignore them, as specified in RFC4566 [RFC4566]. 267 5. Protocol Description 269 5.1. Level of Compliance 271 Implementations according to this specification MUST implement the 272 SDP extensions described in Section 5.2, and MUST implement the 273 considerations discussed in Section 5.3. 275 5.2. Extensions to SDP 277 This section provides the syntax and semantics of the extensions 278 required for providing a description of audio media streams over 279 circuit-switched bearers in SDP. 281 5.2.1. Connection Data 283 According to SDP [RFC4566], the connection data line in SDP has the 284 following syntax: 286 c= 288 where indicates the network type, indicates the 289 address type, and the is the connection address, 290 which is dependent on the address type. 292 At the moment, the only network type defined is "IN", which indicates 293 Internet network type. The address types "IP4" and "IP6" indicate 294 the type of IP addresses. 296 This memo defines a new network type for describing a circuit- 297 switched bearer network type in the PSTN. The mnemonic "PSTN" is 298 used for this network type. 300 For the address type, we initially consider the possibility of 301 describing E.164 telephone numbers. We define a new "E164" address 302 type. When used, the "E164" address type indicates that the 303 connection address contains a telephone number represented according 304 to the ITU-T E.164 [ITU.E164.1991] recommendation. 306 There are cases, though, when the endpoint is merely aware of a 307 circuit-switched bearer, without having further information about the 308 address type or the E.164 number allocated to it. In these cases a 309 dash "-"is used to indicate an unknown address type or connection 310 address. This makes the connection data line be according to the SDP 311 syntax. 313 Note that and/or should not be 314 omitted without being set to a "-" since this would violate basic 315 syntax of SDP [RFC4566]. 317 The following are examples of the extension to the connection data 318 line: 320 c=PSTN E164 +15551234 322 c=PSTN - - 324 5.2.2. Media Descriptions 326 According to SDP [RFC4566], the media descriptions line in SDP has 327 the following syntax: 329 m= ... 331 The sub-field carries the media type. Since this document 332 deals with establishing an audio bearer, the existing "audio" media 333 type is used. 335 The sub-field is the transport port to which the media stream 336 is sent. Circuit-switched access lacks the concept of a port number, 337 and therefore the sub-field is set to the discard port "9". 339 According to RFC 3264 [RFC3264], a port number of zero in the offer 340 of a unicast stream indicates that the stream is offered but must not 341 be used. If a port number of zero is present in the answer of a 342 unicast stream, it indicates that the stream is rejected. These 343 rules are still valid when the media line in SDP represents a 344 circuit-switched bearer. 346 The sub-field is the transport protocol. The circuit- 347 switched bearer uses whatever transport protocol it has available. 348 This subfield SHOULD be set to the mnemonic "PSTN" to be 349 syntactically correct with SDP [RFC4566] and to indicate the usage of 350 circuit-switched protocols in the PSTN. 352 The sub-field is the media format description. In the 353 classical usage of SDP to describe RTP-based media streams, when the 354 sub-field is set to "RTP/AVP" or "RTP/SAVP", the sub- 355 field contains the payload types as defined in the RTP audio profile 356 [RFC3551]. 358 In the case of circuit-switched descriptions, RTP is not really used. 359 Rather than specifying the RTP audio profile payload type, we use the 360 sub-field to indicate the list of available media types over 361 the circuit-switched bearer. Therefore, the sub-field MAY 362 indicate one or more available audio codecs for a circuit-switched 363 audio stream. We use the classical RTP audio media types, even when 364 applied to PSTN circuit-switched bearers, the media type merely 365 represents an audio codec. 367 However, in some cases, the endpoint is not able to determine the 368 list of available codecs for circuit-switched audio streams. In this 369 case, in order to be syntactically compliant with SDP [RFC4566], the 370 endpoint MUST include a single dash "-" in the sub-field. 372 As per RFC 4566 [RFC4566], the media format descriptions are listed 373 in priority order. 375 Example of a media description for circuit-switched audio streams is: 377 m=audio 9 PSTN 3 0 8 379 m=audio 9 PSTN - 381 5.2.3. Correlating the PSTN Circuit-Switched Bearer with SDP 383 The endpoints should be able to correlate the circuit-switched bearer 384 with the session negotiated with SDP to avoid ringing for an incoming 385 circuit-switched call that is related to the session controlled with 386 SDP (and SIP). 388 Several alternatives exist for performing this correlation. This 389 memo provides two mutually non-exclusive correlation mechanisms. 390 Other correlation mechanisms might exist as well, and their usage 391 will be specified when need arises. The first mechanism is based on 392 the exchange of PSTN caller-ID between the endpoints, which is also 393 made available as the Calling Party ID in the circuit-switched 394 signaling. The second mechanism is based on the inclusion in SDP of 395 the value of the User-to-User Information Element that is part of the 396 call setup signaling in the PSTN. Implementations MAY use any of 397 these mechanisms and MAY use both mechanisms simultaneously. 399 5.2.3.1. Caller-ID Correlation Mechanism 401 The caller-ID correlation mechanisms consists of an exchange of the 402 calling party number in E.164 format in SDP, followed by the 403 availability of the Calling Party Number information element in the 404 call setup signaling of the circuit switched connection. 406 An endpoint that is feasible to become the active party for setting 407 up the circuit-switched bearer SHOULD include its E.164 number in the 408 field of the "c=" line. An endpoint that acts 409 as the passive party for setting up the circuit-switch bearer MAY 410 include its E.164 number in the same corresponding lines, although 411 these are not used for correlation. 413 Example of inclusion of E.164 number in the "c=" line is: 415 c=PSTN E164 +15551234 417 Please note that there are no warranties that this correlation 418 mechanism works or is even available, due a number of problems: 420 o The endpoint might not be aware of its own E.164 number, in which 421 case it cannot populate the SDP appropriately. 423 o The Calling Party Number information element in the circuit- 424 switched signaling might not be available, e.g., due to policy 425 restrictions of the network operator or caller restriction due to 426 privacy. 428 o The Calling Party Number information element in the circuit- 429 switched signaling might be available, but the digit 430 representation of the E.164 number might differ from the one 431 expressed in the SDP. For example, one can be represented in 432 international format and the other might only contain the 433 significant national digits. Therefore, an implementation may 434 consider only some of the rightmost digits from the E.164 number 435 for correlation. For example, the numbers +358-1-555-12345 and 436 01-555-12345 could be considered as the same number. This is also 437 the behavior of some cellular phones, which correlate the incoming 438 calling party with a number stored in the phone book, for the 439 purpose of displaying the caller's name. 441 5.2.3.2. User-User Information Element Correlation Mechanism 443 A second correlation mechanism is based on indicating in SDP the 444 User-User Information Element that is part of the call setup 445 signaling of the circuit-switched bearer. The User-User Information 446 Element is specified in ITU-T Q.931 [ITU.Q931.1998] and 3GPP TS 447 24.008 [3GPP.24.008], among others. The User-User Information 448 Element has a maximum size of 35 or 131 octets, depending on the 449 actual message of the PSTN protocol where it is included. 451 The mechanism works as follows: An endpoint creates a User-User 452 Information Element, according to the requirement of the call setup 453 signaling protocol. The same value is included in the SDP offer or 454 SDP answer, in a new attribute called 'corr-id', defined below. When 455 the SDP offer/answer exchange is completed, each endpoint has become 456 aware of the value that will be used in the User-User Information 457 Element of the call establishment message of the PSTN protocol. The 458 endpoint that initiates the call setup attempt includes this value in 459 the User-User Information Element. The recipient of the call setup 460 attempt can extract the User-User Information Element and correlate 461 it with the value previously received in the SDP. If both values 462 match, then the call attempt corresponds to that indicated in the 463 SDP. 465 Note that, for correlation purposes, the value of the User-User 466 Information Element is considered as a opaque string and only used 467 for correlation purposes. Typically call signaling protocols impose 468 requirements on the creation of User-User Information Element for 469 end-user protocol exchange. The details regarding the generation of 470 the User-User Information Element are outside the scope of this 471 specification. 473 This specification defines a new SDP attribute, called 'corr-id', 474 whose purpose is to include the User-User Information Element that 475 the endpoint will include in the call setup attempt. The 'corr-id' 476 attribute has the following format: 478 a=corr-id:corr-token 480 An endpoint that is feasible to become the active party for setting 481 up the PSTN call SHOULD include in the 'corr-id' attribute the value 482 of the User-User Information Element that will be used in the PSTN 483 call setup attempt. If both the SDP offerer and the SDP answerer are 484 able to become the active party, each one SHOULD include a 485 correlation value. Then the party that becomes active in setting up 486 the PSTN circuit-switched call includes this value in the User-User 487 information element of the call signaling setup. The passive party 488 is able to inspect the received value of User-User Information 489 Element and correlate it with that received in the SDP in the 490 'corr-id' attribute. An endpoint that takes the role of the passive 491 party for setting up the circuit-switched bearer MAY include a 492 'corr-id' attribute in the SDP, although it is not used for 493 correlation purposes. 495 Please note that there are no warranties that this correlation 496 mechanism works. On one side, policy restrictions might not make the 497 User-User information available end to end in the PSTN. On the other 498 hand, the generation of the User-User Information Element is 499 controlled by the PSTN circuit-switched call protocol, which might 500 not offer enough freedom for generating different values from one 501 endpoint to another one, or from one call to another in the same 502 endpoint. This might result in the same value of the User-User 503 Information Element for all calls. 505 5.3. Considerations for Usage of Existing SDP 507 5.3.1. Originator of the Session 509 According to SDP [RFC4566], the origin line in SDP has the following 510 syntax: 512 o= 513 515 Of interest here are the and fields, which 516 indicate the type of network and type of address, respectively. 517 Typically, this field carries the IP address of the originator of the 518 session. Even if the SDP was used to negotiate an audio media stream 519 transported over a circuit-switched bearer, the originator is using 520 SDP over an IP bearer. Therefore, and fields in 521 the "o=" line should be populated with the IP address identifying the 522 source of the signaling. 524 5.3.2. Contact Information 526 SDP [RFC4566] defines the "p=" line which may include the phone 527 number of the person reponsible for the conference. Even though this 528 line can carry a phone number, it is not suited for the purpose of 529 defining a connection address for the media. Therefore, we have 530 selected to define the PSTN specific connection addresses in the "c=" 531 line. 533 5.3.3. Determining the Direction for Setting Up the Circuit-Switched 534 Bearer 536 Either endpoint can initiate the establishment of the circuit- 537 switched bearer. In order to avoid a situation where both endpoints 538 attempt to initiate a connection simultaneously, the direction in 539 which the circuit-switched bearer is set up should be negotiated 540 during the Offer/Answer exchange. 542 The framework defined in RFC 4145 [RFC4145] allows the endpoints to 543 agree which endpoint acts as the active endpoint when initiating a 544 TCP connection. While RFC 4145 [RFC4145] was originally designed for 545 establishing TCP connections, it is easily extrapolated to the 546 connection establishment of circuit-switched bearers. This 547 specification uses the concepts specified in RFC 4145 [RFC4145] for 548 agreeing on the direction of establishment of a circuit-switched 549 bearer. 551 RFC 4145 [RFC4145] defines two new attributes in SDP: 'setup' and 552 'connection'. The 'setup' attribute indicates which of the endpoints 553 should initiate the connection establishment of the PSTN circuit- 554 switched bearer. Four values are defined in Section 4 of RFC 4145 555 [RFC4145]: "active", "passive", "actpass", "holdconn". Please refer 556 to Section 4 of RFC 4145 [RFC4145] for a detailed description of this 557 attribute. 559 The 'connection' attribute indicates whether a new connection is 560 needed or an existing connection is reused. The attribute can take 561 the values "new" or "existing". Please refer to Section 5 of RFC 562 4145 [RFC4145] for a detailed description of this attribute. 564 Implementations according to this specification MUST support the 565 'setup' and 'connection' attributes specified in RFC 4145 [RFC4145], 566 but applied to circuit-switched bearers in the PSTN. 568 In order to establish a circuit-switched connection in the PSTN, the 569 initiating endpoint needs to know the address (E.164 number) of the 570 other endpoint. Therefore, if an endpoint wants to be able to 571 receive incoming circuit-switched calls, it must know its E.164 572 number and must indicate it in SDP. As a consequence, an endpoint 573 that is not aware of its own E.164 number cannot take the role of the 574 passive side with respect the establishment of the circuit-switched 575 connection. 577 5.4. Formal Syntax 579 The following is the formal Augmented Backus-Naur Form (ABNF) 580 [RFC5234] syntax that supports the extensions defined in this 581 specification. The syntax is built above the SDP [RFC4566] grammar. 582 Implementations according to this specification MUST be compliant 583 with this syntax. 585 Figure 2 shows the formal syntax of the extensions defined in this 586 memo. 588 ;extension to the connection field originally specified in RFC 4566 589 connection-field = [%x63 "=" nettype SP addrtype SP 590 connection-address CRLF] 591 ;nettype and addrtype are defined in RFC 4566 593 connection-address = multicast-address / unicast-address / 594 e164-address / "-" 595 ; multicast-address and unicast-address are 596 ; defined in RFC 4566 598 e164-address = ["+"] 1*15DIGIT 599 ; DIGIT is specified in RFC 5234 601 ;subrules for corr-id attribute 602 attribute = corr-id-attr 603 ; attribute defined in RFC 4566 605 corr-id-attr = "corr-id:" corr-id-value 606 corr-id-value = 1*32(ALPHA/DIGIT) 608 Figure 2: Syntax of the SDP extensions 610 6. SDP Examples 612 6.1. Basic SDP Example: Single Circuit-Switched Audio Stream 614 Alice Bob 615 | | 616 | (1) SDP Offer (PSTN audio) | 617 |--------------------------------->| 618 | | 619 | (2) SDP Answer (PSTN audio) | 620 |<---------------------------------| 621 | | 622 | PSTN call setup | 623 |<---------------------------------| 624 | | 625 |<==== media over PSTN bearer ====>| 626 | | 628 Figure 3: Basic flow 630 Figure 3 shows a basic example that describes a single audio media 631 stream over a circuit-switched bearer. The SDP offer is show in 632 Figure 4. The endpoint describes a PSTN circuit-switched bearer in 633 the "m=" and "c=" line where it also indicates its E.164 number. 634 Additionally, it expresses that it can initiate the circuit-switched 635 connection or be the recipient of it. The SDP offer also includes a 636 correlation identifier that this endpoint will be inserting the User- 637 User Information Element of the PSTN call setup if eventually this 638 endpoint initiates the PSTN call. 640 v=0 641 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 642 s= 643 t=0 0 644 m=audio 9 PSTN - 645 c=PSTN E164 +15551234 646 a=setup:actpass 647 a=connection:new 648 a=corr-id:2890W284hAT452612908awudfjang908 650 Figure 4: SDP offer (1) 652 6.2. Advanced SDP Example: Alternative IP and Circuit-Switched Audio 653 Streams 655 Alice Bob 656 | | 657 | (1) SDP Offer (IP and PSTN audio)| 658 |--------------------------------->| 659 | | 660 | (2) SDP Answer (PSTN audio) | 661 |<---------------------------------| 662 | | 663 | PSTN call setup | 664 |<---------------------------------| 665 | | 666 |<==== media over PSTN bearer ====>| 667 | | 669 Figure 5: Alternative media 671 Figure 5 shows an example of negotiating audio media streams over IP 672 or circuit-switched bearers. Using the mechanisms described in SDP 673 Capability Negotiation Framework 674 [I-D.ietf-mmusic-sdp-capability-negotiation] and extensions thereof 675 (SDP media capabilities Negotiation 676 [I-D.ietf-mmusic-sdp-media-capabilities] and SDP Miscellaneous 677 Capabilities [I-D.garcia-mmusic-sdp-misc-cap]) it is possible to 678 construct an SDP offer where audio media can be offered alternatively 679 over IP or circuit-switched bearer. 681 v=0 682 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 683 s= 684 t=0 0 685 m=audio 49170 RTP/AVP 0 8 3 686 c=IN IP4 192.0.2.5 687 a=creq:med-v0,ccap-v0 688 a=mcap:1 PCMU/8000/1 689 a=mcap:2 PCMA/8000/1 690 a=mcap:3 GSM/8000/1 691 a=mcap:4 - 692 a=tcap:1 RTP/AVP PSTN 693 a=ccap:1 IN IP4 192.0.2.1 694 a=ccap:2 PSTN E164 +15551234 695 a=acap:1 corr-id:2890W284hAT452612908awudfjang908 696 a=acap:2 setup:actpass 697 a=acap:3 connection:new 698 a=pcfg:1 t=1 m=1,2,3 c=1 699 a=pcfg:2 t=2 m=4 c=2 a=1,2,3 701 Figure 6: SDP offer with alternative media (1) 703 Upon receiving the SDP offer descibed in Figure 6, Bob decided to 704 select the circuit-switched bearer and generates the answer described 705 in Figure 7 707 v=0 708 o=- 2890973824 2890987289 IN IP4 192.0.2.7 709 s= 710 t=0 0 711 m=audio - PSTN - 712 c=PSTN - - 713 a=acfg:2 714 a=setup:active 715 a=connection:new 716 a=corr-id:2890W284hAT452612908awudfjang908 718 Figure 7: SDP answer with circuit-switched media (2) 720 7. IANA Considerations 722 This document instructs IANA to register a number of SDP tokens 723 according to the following data. 725 7.1. Registration of a New 'corr-id' SDP Attribute 727 Contact: Miguel Garcia 729 Attribute name: corr-id 731 Long-form attribute name: PSTN Correlation Identifier 733 Type of attribute: media level only 735 This attribute is subject to the charset attribute 737 Description: This attribute provides the Correlation Identifier 738 used in PSTN signaling 740 Specification: RFC XXXX 742 7.2. Registration of a New "nettype" value 744 This memo provides instructions to IANA to register a new "nettype" 745 in the Session Description Protocol Parameters registry [1]. The 746 registration data, according to RFC 4566 [RFC4566] follows. 748 Type SDP Name Reference 749 ---- ------------------ --------- 750 nettype PSTN [RFCxxxx] 752 7.3. Registration of New "addrtype" values 754 This memo provides instructions to IANA to register a new "addrtype" 755 in the Session Description Protocol Parameters registry [1]. The 756 registration data, according to RFC 4566 [RFC4566] follows. 758 Type SDP Name Reference 759 ---- ------------------ --------- 760 addrtype E164 [RFCxxxx] 761 - [RFCxxxx] 763 7.4. Registration of a New "proto" value 765 This memo provides instructions to IANA to register a new "proto" in 766 the Session Description Protocol Parameters registry [1]. The 767 registration data, according to RFC 4566 [RFC4566] follows. 769 Type SDP Name Reference 770 -------------- --------------------------- --------- 771 proto PSTN [RFCxxxx] 773 8. Security Considerations 775 This document provides an extension on top of RFC 4566 [RFC4566], and 776 RFC 3264 [RFC3264]. As such, the security considerations of those 777 documents apply. 779 9. Acknowledgments 781 The authors want to thank Flemming Andreasen, Thomas Belling, Jari 782 Mutikainen, Miikka Poikselka, Jonathan Rosenberg, Ingemar Johansson, 783 Christer Holmberg, and Alf Heidermark for providing their insight and 784 comments on this document. 786 10. References 788 10.1. Normative References 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, March 1997. 793 [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the 794 Session Description Protocol (SDP) for ATM Bearer 795 Connections", RFC 3108, May 2001. 797 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 798 with Session Description Protocol (SDP)", RFC 3264, 799 June 2002. 801 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 802 the Session Description Protocol (SDP)", RFC 4145, 803 September 2005. 805 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 806 Description Protocol", RFC 4566, July 2006. 808 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 809 Specifications: ABNF", STD 68, RFC 5234, January 2008. 811 10.2. Informative References 813 [3GPP.24.008] 814 3GPP, "Mobile radio interface Layer 3 specification; Core 815 network protocols; Stage 3", 3GPP TS 24.008 3.20.0, 816 December 2005. 818 [I-D.garcia-mmusic-sdp-misc-cap] 819 Garcia, M., Veikkolainen, S., and R. Gilman, 820 "Miscellaneous Capabilities Negotiation in the Session 821 Description Protocol (SDP)", 822 draft-garcia-mmusic-sdp-misc-cap-00 (work in progress), 823 October 2008. 825 [I-D.ietf-mmusic-sdp-capability-negotiation] 826 Andreasen, F., "SDP Capability Negotiation", 827 draft-ietf-mmusic-sdp-capability-negotiation-09 (work in 828 progress), July 2008. 830 [I-D.ietf-mmusic-sdp-media-capabilities] 831 Gilman, R., Even, R., and F. Andreasen, "SDP media 832 capabilities Negotiation", 833 draft-ietf-mmusic-sdp-media-capabilities-05 (work in 834 progress), July 2008. 836 [ITU.E164.1991] 837 International Telecommunications Union, "The International 838 Public Telecommunication Numbering Plan", ITU- 839 T Recommendation E.164, 1991. 841 [ITU.Q931.1998] 842 "Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN 843 User - Network Interface Layer 3 Specification for Basic 844 Call Control", ISO Standard 9594-1, May 1998. 846 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 847 A., Peterson, J., Sparks, R., Handley, M., and E. 848 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 849 June 2002. 851 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 852 Jacobson, "RTP: A Transport Protocol for Real-Time 853 Applications", STD 64, RFC 3550, July 2003. 855 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 856 Video Conferences with Minimal Control", STD 65, RFC 3551, 857 July 2003. 859 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 860 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 862 URIs 864 [1] 866 Authors' Addresses 868 Miguel A. Garcia-Martin 869 Ericsson 870 Calle Via de los Poblados 13 871 Madrid, ES 28033 872 Spain 874 Email: miguel.a.garcia@ericsson.com 876 Simo Veikkolainen 877 Nokia 878 P.O. Box 407 879 NOKIA GROUP, FI 00045 880 Finland 882 Phone: +358 50 486 4463 883 Email: simo.veikkolainen@nokia.com 885 Full Copyright Statement 887 Copyright (C) The IETF Trust (2008). 889 This document is subject to the rights, licenses and restrictions 890 contained in BCP 78, and except as set forth therein, the authors 891 retain all their rights. 893 This document and the information contained herein are provided on an 894 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 895 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 896 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 897 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 898 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 899 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 901 Intellectual Property 903 The IETF takes no position regarding the validity or scope of any 904 Intellectual Property Rights or other rights that might be claimed to 905 pertain to the implementation or use of the technology described in 906 this document or the extent to which any license under such rights 907 might or might not be available; nor does it represent that it has 908 made any independent effort to identify any such rights. Information 909 on the procedures with respect to rights in RFC documents can be 910 found in BCP 78 and BCP 79. 912 Copies of IPR disclosures made to the IETF Secretariat and any 913 assurances of licenses to be made available, or the result of an 914 attempt made to obtain a general license or permission for the use of 915 such proprietary rights by implementers or users of this 916 specification can be obtained from the IETF on-line IPR repository at 917 http://www.ietf.org/ipr. 919 The IETF invites any interested party to bring to its attention any 920 copyrights, patents or patent applications, or other proprietary 921 rights that may cover technology that may be required to implement 922 this standard. Please address the information to the IETF at 923 ietf-ipr@ietf.org.