idnits 2.17.1 draft-ietf-mmusic-offer-answer-examples-06.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 965. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 28, 2005) is 6869 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) -- Looks like a reference, but probably isn't: 'Offer' on line 847 -- Looks like a reference, but probably isn't: 'Answer' on line 857 -- Looks like a reference, but probably isn't: 'Second-Offer' on line 867 -- Looks like a reference, but probably isn't: 'Second-Answer' on line 877 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '2') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '4') (Obsoleted by RFC 4733, RFC 4734) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group A. Johnston 3 Internet-Draft MCI 4 Expires: December 30, 2005 R. Sparks 5 Estacado Systems 6 June 28, 2005 8 Session Description Protocol Offer/Answer Examples 9 draft-ietf-mmusic-offer-answer-examples-06 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of 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 December 30, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document gives examples of Session Description Protocol (SDP) 43 offer/answer exchanges. Examples include codec negotiation and 44 selection, hold and resume, and addition and deletion of media 45 streams. The examples show multiple media types, bidirectional, 46 unidirectional, inactive streams and dynamic payload types. Common 47 Third Party Call Control (3pcc) examples are also given. 49 Table of Contents 51 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Codec Negotiation and Selection . . . . . . . . . . . . . . . 3 53 2.1 Audio and Video 1 . . . . . . . . . . . . . . . . . . . . 3 54 2.2 Audio and Video 2 . . . . . . . . . . . . . . . . . . . . 4 55 2.3 Audio and Video 3 . . . . . . . . . . . . . . . . . . . . 6 56 2.4 Two Audio Streams . . . . . . . . . . . . . . . . . . . . 6 57 2.5 Audio and Video 4 . . . . . . . . . . . . . . . . . . . . 7 58 2.6 Audio Only 1 . . . . . . . . . . . . . . . . . . . . . . . 9 59 2.7 Audio and Video 5 . . . . . . . . . . . . . . . . . . . . 9 60 2.8 Audio and Video 6 . . . . . . . . . . . . . . . . . . . . 11 61 3. Hold and Resume Scenarios . . . . . . . . . . . . . . . . . . 12 62 3.1 Hold and Unhold 1 . . . . . . . . . . . . . . . . . . . . 12 63 3.2 Hold with Two Streams . . . . . . . . . . . . . . . . . . 13 64 4. Addition and Deletion of Media Streams . . . . . . . . . . . . 15 65 4.1 Second Audio Stream Added . . . . . . . . . . . . . . . . 15 66 4.2 Audio then Video Added . . . . . . . . . . . . . . . . . . 17 67 4.3 Audio and Video, then Video Deleted . . . . . . . . . . . 18 68 5. Third Party Call Control (3pcc) . . . . . . . . . . . . . . . 20 69 5.1 No Media, then Audio Added . . . . . . . . . . . . . . . . 20 70 5.2 Hold and Unhold 2 . . . . . . . . . . . . . . . . . . . . 21 71 5.3 Hold and Unhold 3 . . . . . . . . . . . . . . . . . . . . 22 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 74 8. Informative References . . . . . . . . . . . . . . . . . . . . 23 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 76 Intellectual Property and Copyright Statements . . . . . . . . 25 78 1. Overview 80 This document describes offer/answer examples of Session Description 81 Protocol (SDP) based on RFC 3264 [1]. The SDP in these examples is 82 defined by RFC 2327 [2]. The offers and answers are assumed to be 83 transported using a protocol such as Session Initiation Protocol 84 (SIP) [3]. 86 Examples include codec negotiation and selection, hold and resume, 87 and addition and deletion of media streams. The examples show 88 multiple media types, bidirectional, unidirectional, inactive streams 89 and dynamic payload types. Common Third Party Call Control (3pcc) 90 [5] examples are also given. 92 The following sections contain examples in which two parties, Alice 93 and Bob, exchange SDP offers, answers, and, in some cases, additional 94 offers and answers. Note that the subject line (s=) contains a 95 single space character. 97 2. Codec Negotiation and Selection 99 2.1 Audio and Video 1 101 This common scenario shows a video and audio session in which 102 multiple codecs are offered but only one is accepted. As a result of 103 the exchange shown below, Alice and Bob may send only PCMU audio and 104 MPV video. Note: Dynamic payload type 97 is used for iLBC codec [6]. 106 [Offer] 108 v=0 109 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 110 s= 111 c=IN IP4 host.atlanta.example.com 112 t=0 0 113 m=audio 49170 RTP/AVP 0 8 97 114 a=rtpmap:0 PCMU/8000 115 a=rtpmap:8 PCMA/8000 116 a=rtpmap:97 iLBC/8000 117 m=video 51372 RTP/AVP 31 32 118 a=rtpmap:31 H261/90000 119 a=rtpmap:32 MPV/90000 121 [Answer] 123 v=0 124 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 125 s= 126 c=IN IP4 host.biloxi.example.com 127 t=0 0 128 m=audio 49174 RTP/AVP 0 129 a=rtpmap:0 PCMU/8000 130 m=video 49170 RTP/AVP 32 131 a=rtpmap:32 MPV/90000 133 2.2 Audio and Video 2 135 Alice can support PCMU, PCMA, and iLBC codecs, but not more than one 136 at the same time. Alice offers all three to maximize chances of a 137 successful exchange and Bob accepts two of them. Audio only session 138 is established in initial exchange between Alice and Bob using either 139 PCMU or PCMA codecs (payload type in RTP packet tells which is being 140 used). Since Alice only supports one audio codec at a time, a second 141 offer is made with just that one codec to limit the codec choice to 142 just one. 144 Note: the version number is incremented in both SDP messages in the 145 second exchange. Now only the PCMU codec may be used for media 146 session between Alice and Bob. 148 Note: The declined video stream still present in the second exchange 149 of SDP with ports set to zero. 151 [Offer] 153 v=0 154 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 155 s= 156 c=IN IP4 host.atlanta.example.com 157 t=0 0 158 m=audio 49170 RTP/AVP 0 8 97 159 a=rtpmap:0 PCMU/8000 160 a=rtpmap:8 PCMA/8000 161 a=rtpmap:97 iLBC/8000 162 m=video 51372 RTP/AVP 31 32 163 a=rtpmap:31 H261/90000 164 a=rtpmap:32 MPV/90000 166 [Answer] 168 v=0 169 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 170 s= 171 c=IN IP4 host.biloxi.example.com 172 t=0 0 173 m=audio 49172 RTP/AVP 0 8 174 a=rtpmap:0 PCMU/8000 175 a=rtpmap:8 PCMA/8000 176 m=video 0 RTP/AVP 31 177 a=rtpmap:31 H261/90000 179 [Second-Offer] 181 v=0 182 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 183 s= 184 c=IN IP4 host.atlanta.example.com 185 t=0 0 186 m=audio 51372 RTP/AVP 0 187 a=rtpmap:0 PCMU/8000 188 m=video 0 RTP/AVP 31 189 a=rtpmap:31 H261/90000 191 [Second-Answer] 193 v=0 194 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 195 s= 196 c=IN IP4 host.biloxi.example.com 197 t=0 0 198 m=audio 49172 RTP/AVP 0 199 a=rtpmap:0 PCMU/8000 200 m=video 0 RTP/AVP 31 201 a=rtpmap:31 H261/90000 203 2.3 Audio and Video 3 205 Alice offers three audio and two video codecs, while Bob accepts with 206 a single audio and video codec. As a result of this exchange, Bob 207 and Alice use iLBC for audio and H261 for video. 209 Note: change of dynamic payload type from 97 to 99 between the offer 210 and the answer is OK since it references same codec. 212 [Offer] 214 v=0 215 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 216 s= 217 c=IN IP4 host.atlanta.example.com 218 t=0 0 219 m=audio 49170 RTP/AVP 0 8 97 220 a=rtpmap:0 PCMU/8000 221 a=rtpmap:8 PCMA/8000 222 a=rtpmap:97 iLBC/8000 223 m=video 51372 RTP/AVP 31 32 224 a=rtpmap:31 H261/90000 225 a=rtpmap:32 MPV/90000 227 [Answer] 229 v=0 230 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 231 s= 232 c=IN IP4 host.biloxi.example.com 233 t=0 0 234 m=audio 49172 RTP/AVP 99 235 a=rtpmap:99 iLBC/8000 236 m=video 51374 RTP/AVP 31 237 a=rtpmap:31 H261/90000 239 2.4 Two Audio Streams 241 In this example, Alice wishes to establish separate audio streams, 242 one for normal audio and the other for telephone-events. Alice 243 offers two separate streams, one audio with two codecs and the other 244 with RFC 2833 [4] tones (for DTMF). Bob accepts both audio streams 245 choosing the iLBC codec and telephone-events. 247 [Offer] 249 v=0 250 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 251 s= 252 c=IN IP4 host.atlanta.example.com 253 t=0 0 254 m=audio 49170 RTP/AVP 0 97 255 a=rtpmap:0 PCMU/8000 256 a=rtpmap:97 iLBC/8000 257 m=audio 49172 RTP/AVP 98 258 a=rtpmap:98 telephone-event/8000 259 a=sendonly 261 [Answer] 263 v=0 264 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 265 s= 266 c=IN IP4 host.biloxi.example.com 267 t=0 0 268 m=audio 49172 RTP/AVP 97 269 a=rtpmap:97 iLBC/8000 270 m=audio 49174 RTP/AVP 98 271 a=rtpmap:98 telephone-event/8000 272 a=recvonly 274 2.5 Audio and Video 4 276 Alice and Bob establish an audio and video session with a single 277 audio and video codec. In a second exchange, Bob changes his address 278 for media and Alice accepts with the same SDP as the initial exchange 279 (and as a result does not increment the version number). 281 [Offer] 283 v=0 284 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 285 s= 286 c=IN IP4 host.atlanta.example.com 287 t=0 0 288 m=audio 49170 RTP/AVP 97 289 a=rtpmap:97 iLBC/8000 290 m=video 51372 RTP/AVP 31 291 a=rtpmap:31 H261/90000 293 [Answer] 295 v=0 296 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 297 s= 298 c=IN IP4 host.biloxi.example.com 299 t=0 0 300 m=audio 49174 RTP/AVP 97 301 a=rtpmap:97 iLBC/8000 302 m=video 49170 RTP/AVP 31 303 a=rtpmap:31 H261/90000 305 [Second-Offer] 307 v=0 308 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 309 s= 310 c=IN IP4 newhost.biloxi.example.com 311 t=0 0 312 m=audio 49178 RTP/AVP 97 313 a=rtpmap:97 iLBC/8000 314 m=video 49188 RTP/AVP 31 315 a=rtpmap:31 H261/90000 317 [Second-Answer] 319 v=0 320 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 321 s= 322 c=IN IP4 host.atlanta.example.com 323 t=0 0 324 m=audio 49170 RTP/AVP 97 325 a=rtpmap:97 iLBC/8000 326 m=video 51372 RTP/AVP 31 327 a=rtpmap:31 H261/90000 329 2.6 Audio Only 1 331 Alice wishes to establish an audio session with Bob using either PCMU 332 codec or iLBC codec with RFC2833 tones, but not both at the same 333 time. The offer contains these two media streams. Bob declines the 334 first one and accepts the second one. If both media streams had been 335 accepted, Alice would have sent a second declining one of the 336 streams, as shown in Section 4.3. 338 [Offer] 340 v=0 341 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 342 s= 343 c=IN IP4 host.atlanta.example.com 344 t=0 0 345 m=audio 49170 RTP/AVP 0 346 a=rtpmap:0 PCMU/8000 347 m=audio 51372 RTP/AVP 97 101 348 a=rtpmap:97 iLBC/8000 349 a=rtpmap:101 telephone-event/8000 351 [Answer] 353 v=0 354 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 355 s= 356 c=IN IP4 host.biloxi.example.com 357 t=0 0 358 m=audio 0 RTP/AVP 0 359 a=rtpmap:0 PCMU/8000 360 m=audio 49170 RTP/AVP 97 101 361 a=rtpmap:97 iLBC/8000 362 a=rtpmap:101 telephone-event/8000 364 2.7 Audio and Video 5 366 Alice and Bob establish an audio and video session in the first 367 exchange with a single audio and video codec. In the second 368 exchange, Alice adds a second video codec which Bob accepts which 369 allows Alice and Bob to switch between the two video codecs without 370 another offer/answer exchange. 372 [Offer] 374 v=0 375 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 376 s= 377 c=IN IP4 host.atlanta.example.com 378 t=0 0 379 m=audio 49170 RTP/AVP 99 380 a=rtpmap:99 iLBC/8000 381 m=video 51372 RTP/AVP 31 382 a=rtpmap:31 H261/90000 384 [Answer] 386 v=0 387 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 388 s= 389 c=IN IP4 host.biloxi.example.com 390 t=0 0 391 m=audio 49172 RTP/AVP 99 392 a=rtpmap:99 iLBC/8000 393 m=video 51374 RTP/AVP 31 394 a=rtpmap:31 H261/90000 396 [Second-Offer] 398 v=0 399 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 400 s= 401 c=IN IP4 host.atlanta.example.com 402 t=0 0 403 m=audio 49170 RTP/AVP 99 404 a=rtpmap:99 iLBC/8000 405 m=video 51372 RTP/AVP 31 32 406 a=rtpmap:31 H261/90000 407 a=rtpmap:32 MPV/90000 409 [Second-Answer] 411 v=0 412 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 413 s= 414 c=IN IP4 host.biloxi.example.com 415 t=0 0 416 m=audio 49172 RTP/AVP 99 417 a=rtpmap:99 iLBC/8000 418 m=video 51374 RTP/AVP 31 32 419 a=rtpmap:31 H261/90000 420 a=rtpmap:32 MPV/90000 422 2.8 Audio and Video 6 424 This example shows an audio and video offer that is accepted, but the 425 answerer wants the video sent to a different address than the audio. 426 This is a common scenario in conferencing where the video and audio 427 mixing utilizes different servers. In this example, Alice offers 428 audio and video and Bob accepts. 430 [Offer] 432 v=0 433 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 434 s= 435 c=IN IP4 host.atlanta.example.com 436 t=0 0 437 m=audio 49170 RTP/AVP 0 8 97 438 a=rtpmap:0 PCMU/8000 439 a=rtpmap:8 PCMA/8000 440 a=rtpmap:97 iLBC/8000 441 m=video 51372 RTP/AVP 31 32 442 a=rtpmap:31 H261/90000 443 a=rtpmap:32 MPV/90000 445 [Answer] 447 v=0 448 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 449 s= 450 c=IN IP4 host.biloxi.example.com 451 t=0 0 452 m=audio 49174 RTP/AVP 0 453 a=rtpmap:0 PCMU/8000 454 m=video 49172 RTP/AVP 32 455 c=IN IP4 otherhost.biloxi.example.com 456 a=rtpmap:32 MPV/90000 458 3. Hold and Resume Scenarios 460 3.1 Hold and Unhold 1 462 Alice calls Bob, but Bob answers placing Alice on hold. Bob then 463 takes Alice off hold in the second offer. Alice changes port number 464 in the second exchange. The media session between Alice and Bob is 465 now active after Alice's second answer. Note that a=sendrecv could 466 be present in both second offer and answer exchange. This is a 467 common flow in 3pcc [5] scenarios. 469 [Offer] 471 v=0 472 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 473 s= 474 c=IN IP4 host.atlanta.example.com 475 t=0 0 476 m=audio 49170 RTP/AVP 0 97 477 a=rtpmap:0 PCMU/8000 478 a=rtpmap:97 iLBC/8000 480 [Answer] 482 v=0 483 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 484 s= 485 c=IN IP4 placeholder.biloxi.example.com 486 t=0 0 487 m=audio 49172 RTP/AVP 97 488 a=rtpmap:97 iLBC/8000 489 a=sendonly 491 [Second-Offer] 493 v=0 494 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 495 s= 496 c=IN IP4 host.biloxi.example.com 497 t=0 0 498 m=audio 49170 RTP/AVP 97 499 a=rtpmap:97 iLBC/8000 501 [Second-Answer] 503 v=0 504 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 505 s= 506 c=IN IP4 host.atlanta.example.com 507 t=0 0 508 m=audio 49178 RTP/AVP 97 509 a=rtpmap:97 iLBC/8000 511 3.2 Hold with Two Streams 513 In this example, two audio streams are established in the first 514 offer/answer exchange. In this second offer/answer exchange, one of 515 the audio streams ins placed on hold. Alice offers two media 516 streams, a bidirectional audio stream and a send only telephone event 517 stream. Bob accepts both streams. Bob then puts Alice's audio 518 stream on hold but not the tone stream. Alice responds with 519 identical SDP to the initial offer. 521 [Offer] 523 v=0 524 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 525 s= 526 c=IN IP4 host.atlanta.example.com 527 t=0 0 528 m=audio 49170 RTP/AVP 0 97 529 a=rtpmap:0 PCMU/8000 530 a=rtpmap:97 iLBC/8000 531 m=audio 49172 RTP/AVP 98 532 a=rtpmap:98 telephone-event/8000 533 a=sendonly 535 [Answer] 537 v=0 538 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 539 s= 540 c=IN IP4 host.biloxi.example.com 541 t=0 0 542 m=audio 49172 RTP/AVP 97 543 a=rtpmap:97 iLBC/8000 544 m=audio 49174 RTP/AVP 98 545 a=rtpmap:98 telephone-event/8000 546 a=recvonly 548 [Second-Offer] 550 v=0 551 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 552 s= 553 c=IN IP4 host.biloxi.example.com 554 t=0 0 555 m=audio 49172 RTP/AVP 97 556 a=rtpmap:97 iLBC/8000 557 a=sendonly 558 m=audio 49174 RTP/AVP 98 559 a=rtpmap:98 telephone-event/8000 560 a=recvonly 562 [Second-Answer] 564 v=0 565 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 566 s= 567 c=IN IP4 host.atlanta.example.com 568 t=0 0 569 m=audio 49170 RTP/AVP 0 97 570 a=rtpmap:0 PCMU/8000 571 a=rtpmap:97 iLBC/8000 572 m=audio 49172 RTP/AVP 98 573 a=rtpmap:98 telephone-event/8000 574 a=sendonly 576 4. Addition and Deletion of Media Streams 578 This section shows addition and deletion of media streams. 580 4.1 Second Audio Stream Added 582 In this example, the first offer/answer exchange establishes a single 583 audio stream with a single codec. The second offer/answer exchange 584 adds a second audio stream for telephone events. The second stream 585 is added by Bob's media server (different connection address) to 586 receive RFC 2833 telephone-events (DTMF digits, typically) from 587 Alice. Alice accepts. Even though the 2nd stream is unidirectional, 588 Alice receives RTCP packets on port 49173 from the media server. 590 [Offer] 592 v=0 593 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 594 s= 595 c=IN IP4 host.atlanta.example.com 596 t=0 0 597 m=audio 49170 RTP/AVP 0 97 598 a=rtpmap:0 PCMU/8000 599 a=rtpmap:97 iLBC/8000 601 [Answer] 603 v=0 604 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 605 s= 606 c=IN IP4 host.biloxi.example.com 607 t=0 0 608 m=audio 49170 RTP/AVP 97 609 a=rtpmap:97 iLBC/8000 611 [Second-Offer] 613 v=0 614 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 615 s= 616 c=IN IP4 host.biloxi.example.com 617 t=0 0 618 m=audio 49170 RTP/AVP 97 619 a=rtpmap:97 iLBC/8000 620 m=audio 48282 RTP/AVP 98 621 c=IN IP4 mediaserver.biloxi.example.com 622 a=rtpmap:98 telephone-event/8000 623 a=recvonly 625 [Second-Answer] 627 v=0 628 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 629 s= 630 c=IN IP4 host.atlanta.example.com 631 t=0 0 632 m=audio 49170 RTP/AVP 97 633 a=rtpmap:97 iLBC/8000 634 m=audio 49172 RTP/AVP 98 635 c=IN IP4 host.atlanta.example.com 636 a=rtpmap:98 telephone-event/8000 637 a=sendonly 639 4.2 Audio then Video Added 641 Audio only session is established in initial exchange between Alice 642 and Bob using PCMU codec. Alice adds a video stream which is 643 accepted by Bob. 645 [Offer] 647 v=0 648 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 649 s= 650 c=IN IP4 host.atlanta.example.com 651 t=0 0 652 m=audio 49170 RTP/AVP 0 653 a=rtpmap:0 PCMU/8000 655 [Answer] 657 v=0 658 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 659 s= 660 c=IN IP4 host.biloxi.example.com 661 t=0 0 662 m=audio 49172 RTP/AVP 0 663 a=rtpmap:0 PCMU/8000 665 [Second-Offer] 667 v=0 668 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 669 s= 670 c=IN IP4 host.atlanta.example.com 671 t=0 0 672 m=audio 49170 RTP/AVP 0 673 a=rtpmap:0 PCMU/8000 674 m=video 49172 RTP/AVP 31 675 a=rtpmap:31 H261/90000 677 [Second-Answer] 679 v=0 680 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 681 s= 682 c=IN IP4 host.biloxi.example.com 683 t=0 0 684 m=audio 49172 RTP/AVP 0 685 a=rtpmap:0 PCMU/8000 686 m=video 49168 RTP/AVP 31 687 a=rtpmap:31 H261/90000 689 4.3 Audio and Video, then Video Deleted 691 Alice and Bob establish an audio and video session. In a second 692 exchange, Bob deletes the video session resulting in an audio only 693 session. 695 [Offer] 697 v=0 698 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 699 s= 700 c=IN IP4 host.atlanta.example.com 701 t=0 0 702 m=audio 49170 RTP/AVP 97 703 a=rtpmap:97 iLBC/8000 704 m=video 51372 RTP/AVP 31 705 a=rtpmap:31 H261/90000 707 [Answer] 709 v=0 710 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 711 s= 712 c=IN IP4 host.biloxi.example.com 713 t=0 0 714 m=audio 49174 RTP/AVP 97 715 a=rtpmap:97 iLBC/8000 716 m=video 49170 RTP/AVP 31 717 a=rtpmap:31 H261/90000 719 [Second-Offer] 721 v=0 722 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 723 s= 724 c=IN IP4 host.biloxi.example.com 725 t=0 0 726 m=audio 49174 RTP/AVP 97 727 a=rtpmap:97 iLBC/8000 728 m=video 0 RTP/AVP 31 729 a=rtpmap:31 H261/90000 731 [Second-Answer] 733 v=0 734 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 735 s= 736 c=IN IP4 host.atlanta.example.com 737 t=0 0 738 m=audio 49170 RTP/AVP 97 739 a=rtpmap:97 iLBC/8000 740 m=video 0 RTP/AVP 31 741 a=rtpmap:31 H261/90000 743 5. Third Party Call Control (3pcc) 745 This section shows examples common in Third Party Call Control (3pcc) 746 flows [5]. Call hold and resume flows are also common in 3pcc. 748 5.1 No Media, then Audio Added 750 The first offer from Alice contains no media lines, so Bob accepts 751 with no media lines. In the second exchange, Alice adds an audio 752 stream which Bob accepts. 754 [Offer] 756 v=0 757 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 758 s= 759 c=IN IP4 host.atlanta.example.com 760 t=0 0 762 [Answer] 764 v=0 765 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 766 s= 767 c=IN IP4 host.biloxi.example.com 768 t=0 0 770 [Second-Offer] 772 v=0 773 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 774 s= 775 c=IN IP4 host.atlanta.example.com 776 t=0 0 777 m=audio 49170 RTP/AVP 97 778 a=rtpmap:97 iLBC/8000 780 [Second-Answer] 782 v=0 783 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 784 s= 785 c=IN IP4 host.biloxi.example.com 786 t=0 0 787 m=audio 49172 RTP/AVP 97 788 a=rtpmap:97 iLBC/8000 790 5.2 Hold and Unhold 2 792 The first offer from Alice contains the connection address 0.0.0.0 793 and a random port number, which means that Bob can not send media to 794 Alice (the media stream is "black holed" or "bh"). Bob accepts with 795 normal SDP. In the second exchange, Alice changes the connection 796 address, Bob accepts, and a media session is established. 798 [Offer] 800 v=0 801 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 802 s= 803 c=IN IP4 0.0.0.0 804 t=0 0 805 m=audio 23442 RTP/AVP 97 806 a=rtpmap:97 iLBC/8000 808 [Answer] 810 v=0 811 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 812 s= 813 c=IN IP4 host.biloxi.example.com 814 t=0 0 815 m=audio 49170 RTP/AVP 97 816 a=rtpmap:97 iLBC/8000 818 [Second-Offer] 820 v=0 821 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 822 s= 823 c=IN IP4 host.atlanta.example.com 824 t=0 0 825 m=audio 49170 RTP/AVP 97 826 a=rtpmap:97 iLBC/8000 828 [Second-Answer] 830 v=0 831 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 832 s= 833 c=IN IP4 host.biloxi.example.com 834 t=0 0 835 m=audio 49170 RTP/AVP 97 836 a=rtpmap:97 iLBC/8000 838 5.3 Hold and Unhold 3 840 The first offer from Alice contains an audio stream, but the answer 841 from Bob contains the connection address 0.0.0.0 and a random port 842 number, which means that Alice can not send media to Bob (the media 843 stream is "black holed" or "bh"). In the second exchange, Bob 844 changes the connection address, Alice accepts, and a media session is 845 established. 847 [Offer] 849 v=0 850 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 851 s= 852 c=IN IP4 host.atlanta.example.com 853 t=0 0 854 m=audio 49170 RTP/AVP 97 855 a=rtpmap:97 iLBC/8000 857 [Answer] 859 v=0 860 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 861 s= 862 c=IN IP4 0.0.0.0 863 t=0 0 864 m=audio 9322 RTP/AVP 97 865 a=rtpmap:97 iLBC/8000 867 [Second-Offer] 869 v=0 870 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 871 s= 872 c=IN IP4 host.biloxi.example.com 873 t=0 0 874 m=audio 49172 RTP/AVP 97 875 a=rtpmap:97 iLBC/8000 877 [Second-Answer] 879 v=0 880 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 881 s= 882 c=IN IP4 host.atlanta.example.com 883 t=0 0 884 m=audio 49170 RTP/AVP 97 885 a=rtpmap:97 iLBC/8000 887 6. Security Considerations 889 SDP offer and answer messages can contain private information about 890 addresses and sessions to be established between parties. If this 891 information needs to be kept private, some security mechanism in the 892 protocol used to carry the offers and answers must be used. For SIP, 893 this means using TLS transport and/or S/MIME encryption of the SDP 894 message body. 896 It is important that SDP offer and answer messages be properly 897 authenticated and authorized before using them to establish a media 898 session. Example SIP mechanisms include SIP Digest, certs, or 899 cryptographically verified SIP identity. 901 7. IANA Considerations 903 This document introduces no IANA considerations. 905 8. Informative References 907 [1] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 908 Session Description Protocol (SDP)", RFC 3264, June 2002. 910 [2] Handley, M. and V. Jacobson, "SDP: Session Description 911 Protocol", RFC 2327, April 1998. 913 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 914 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 915 Session Initiation Protocol", RFC 3261, June 2002. 917 [4] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, 918 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 920 [5] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 921 "Best Current Practices for Third Party Call Control (3pcc) in 922 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 923 April 2004. 925 [6] Duric, A. and S. Andersen, "Real-time Transport Protocol (RTP) 926 Payload Format for internet Low Bit Rate Codec (iLBC) Speech", 927 RFC 3952, December 2004. 929 Authors' Addresses 931 Alan Johnston 932 MCI 933 100 South 4th Street 934 St. Louis, MO 63102 936 Email: alan.johnston@mci.com 938 Robert J. Sparks 939 Estacado Systems 941 Email: RjS@estacado.net 943 Intellectual Property Statement 945 The IETF takes no position regarding the validity or scope of any 946 Intellectual Property Rights or other rights that might be claimed to 947 pertain to the implementation or use of the technology described in 948 this document or the extent to which any license under such rights 949 might or might not be available; nor does it represent that it has 950 made any independent effort to identify any such rights. Information 951 on the procedures with respect to rights in RFC documents can be 952 found in BCP 78 and BCP 79. 954 Copies of IPR disclosures made to the IETF Secretariat and any 955 assurances of licenses to be made available, or the result of an 956 attempt made to obtain a general license or permission for the use of 957 such proprietary rights by implementers or users of this 958 specification can be obtained from the IETF on-line IPR repository at 959 http://www.ietf.org/ipr. 961 The IETF invites any interested party to bring to its attention any 962 copyrights, patents or patent applications, or other proprietary 963 rights that may cover technology that may be required to implement 964 this standard. Please address the information to the IETF at 965 ietf-ipr@ietf.org. 967 Disclaimer of Validity 969 This document and the information contained herein are provided on an 970 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 971 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 972 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 973 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 974 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 975 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 977 Copyright Statement 979 Copyright (C) The Internet Society (2005). This document is subject 980 to the rights, licenses and restrictions contained in BCP 78, and 981 except as set forth therein, the authors retain all their rights. 983 Acknowledgment 985 Funding for the RFC Editor function is currently provided by the 986 Internet Society.