idnits 2.17.1 draft-rosenberg-mmusic-sdp-offer-answer-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 87: '...fer (and answer) MUST be a valid SDP, ...' RFC 2119 keyword, line 88: '... [1]. This means it MUST contain a v line, o line, s line and t line....' RFC 2119 keyword, line 89: '...e line or p line MUST be present. Howe...' RFC 2119 keyword, line 90: '... RECOMMENDED that all implementation...' RFC 2119 keyword, line 92: '... MUST be representable with a 64 bit...' (91 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 26, 2001) is 8216 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 section? '1' on line 617 looks like a reference -- Missing reference section? '2' on line 621 looks like a reference -- Missing reference section? '3' on line 625 looks like a reference -- Missing reference section? '4' on line 629 looks like a reference -- Missing reference section? '5' on line 633 looks like a reference -- Missing reference section? '6' on line 637 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft J.Rosenberg,H.Schulzrinne 4 draft-rosenberg-mmusic-sdp-offer-answer-00.txt dynamicsoft,Columbia U. 5 October 26, 2001 6 Expires: April 2002 8 An Offer/Answer Model with SDP 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines a mechanism by which two entities can make use 34 of SDP arrive at a common view of a multimedia session between them. 35 In the model, one participant offers the other a description of the 36 desired session from their perspective, and the other participant 37 answers with the desired session from their perspective. This 38 offer/answer model is most useful in unicast sessions where 39 information from both participants is needed for the complete view of 40 the session. The offer/answer model is used by protocols like SIP. 42 1 Introduction 44 The Session Description Protocol (SDP) [1] was originally conceived 45 as a way to describe multicast sessions carried on the Mbone. The 46 Session Announcement Protocol (SAP) [2] was devised as a multicast 47 mechanism to carry SDP messages. Although the SDP specification 48 allows for unicast operation, it is not complete. Unlike multicast, 49 where there is a global view of the session that is used by all 50 participants, unicast sessions involve two participants, and a 51 complete view of the session requires information from both 52 participants, and agreement on parameters between them. 54 As an example, a multicast session requires conveying a single 55 multicast address for a particular media stream. However, for a 56 unicast session, two addresses are needed - one for each participant. 57 As another example, a multicast session requires indication of which 58 codecs will be used in the session. However, for unicast, the set of 59 codecs needs to be determined by finding an overlap in the set 60 supported by each participant. 62 As a result, even though SDP has the expressiveness to describe 63 unicast sessions, it is missing the semantics and operational details 64 of how it is actually done. In this draft, we remedy that by defining 65 a simple offer/answer model based on SDP. In this model, one 66 participant in the session generates an SDP that constitutes the 67 offer - the set of media streams and codecs the offerer wishes to 68 use, along with the IP addresses and ports the offer would like to 69 use to receive the media. The offer is conveyed to the other 70 participant, called the answerer. The answerer generates an answer, 71 which is an SDP that responds to offer provided it. The answer has a 72 matching media stream for each one in the offer, indicating whether 73 the stream is accepted or not, along with the codecs that will be 74 used and the IP addresses and ports that the answerer wants to use to 75 receive media. 77 We also define guidelines for how the offer/answer model is used to 78 update a session once it has begun. 80 The means by which the offers and answers are conveyed are outside 81 the scope of this document. The offer/answer model defined here is 82 the mandatory baseline mechanism used by the Session Initiation 83 Protocol (SIP) [3]. 85 2 Generating the initial offer 87 The offer (and answer) MUST be a valid SDP, as defined by RFC 2327 88 [1]. This means it MUST contain a v line, o line, s line and t line. 89 Either an e line or p line MUST be present. However, it is 90 RECOMMENDED that all implementations accept SDP without e, p, or s 91 lines. The numeric value of the session id and version in the o line 92 MUST be representable with a 64 bit signed integer. Although the SDP 93 specification allows for multiple session descriptions to be 94 concatenated together into a large SDP message, an SDP message used 95 in the offer/answer model MUST contain only a single session 96 description. 98 The SDP "s=" line and the SIP Subject header field have different 99 meanings when inviting to a multicast session. The session 100 description line describes the subject of the multicast session, 101 while the SIP Subject header field describes the reason for the 102 invitation. For invitations to two-party sessions, the SDP "s=" line 103 MAY consist of a single space character (0x20). 105 Unfortunately, SDP does not allow to leave the "s=" line 106 empty. 108 Once the offerer has sent the offer, it MUST be prepared to receive 109 media described by that offer. 111 2.1 Unicast 113 The offer MUST contain zero or more media sections. Zero media 114 sessions implies that the offerer wishes to communicate, but that the 115 streams for the session will be added at a later time through re- 116 INVITEs. 118 If a session description from an offerer contains a media stream 119 which is listed as send (receive) only, it means that the offerer is 120 only willing to send (receive) this stream, not receive (send). Media 121 streams are marked as send-only or receive-only media streams using 122 the SDP "a=sendonly" and "a=recvonly" attributes, respectively. If 123 neither attribute is present, the default is both send and receive 124 (which MAY be explicitly indicated with the "a=sendrecv" attribute). 126 For recvonly and sendrecv streams, the port number and address in the 127 session description indicate where the media stream should be sent 128 to. For send-only RTP streams, the address and port number indicate 129 where RTCP reports are to be sent to. Specifically, RTCP reports are 130 sent to the port number one higher than the number indicated. The IP 131 address and port present in the offer indicate nothing about the 132 source IP address and source port of RTP and RTCP packets that will 133 be sent by the offerer. A port number of zero in the offer indicates 134 that the stream is offered but should never be used. This has no 135 useful semantics in an initial INVITE, but is allowed for reasons of 136 completeness, since the response can contain a zero port indicating a 137 rejected stream (Section 3. Furthermore, existing streams can be 138 terminated by setting the port to zero (Section 4. In general, a port 139 number of zero indicates that the media stream is not wanted. 141 The list of payload types for each media stream conveys two pieces of 142 information, namely the set of codecs that the offerer is capable of 143 sending and/or receiving (depending on the direction attributes), and 144 the RTP payload type numbers used to identify those codecs. If 145 multiple codecs are listed, it means that the offerer is capable of 146 making use of any of those codecs during the call. In other words, 147 the answerer MAY change codecs in the middle of the call, without 148 sending a SIP message, to make use of any of those listed. For a 149 send-only stream, the offer SHOULD indicate those codecs the offerer 150 is willing to send for this stream. For a receive-only stream, the 151 offer SHOULD indicate those codecs the offerer is willing to receive 152 for this stream. For a send and receive stream, the offer SHOULD 153 indicate those codecs that the offerer is willing to send and receive 154 with. 156 For receive-only streams, the payload type numbers indicate the value 157 of the payload type field in RTP packets the offerer is expecting to 158 receive for that codec. For send-only streams, the payload type 159 numbers indicate the value of the payload type field in RTP packets 160 the offerer is planning to send for that codec type. For send-and- 161 receive streams, the payload type numbers indicate the value of the 162 payload type field the offerer expects to both send and receive. This 163 means that the payload type for a codec is the same in both 164 directions. 166 All media descriptions SHOULD contain "a=rtpmap" mappings from RTP 167 payload types to encodings. If there is no "a=rtpmap", the static 168 payload type table from RFC 1890 [4] is to be used. 170 This allows easier migration away from static payload 171 types. 173 In all cases, the codecs in the m line are listed in order of 174 preference, with the first codec listed being preferred. In this 175 case, preferred means that the recipient of the offer SHOULD use the 176 codec with the highest preference that is acceptable to it. 178 If the ptime attribute is present for a stream, it indicates the 179 desired packetization interval that the offerer would like to 180 receive. 182 If multiple media streams of different types are present, it means 183 that the offerer wishes to use those streams at the same time. A 184 typical case is an audio and video stream as part of a 185 videoconference. 187 If multiple media streams of the same type are present, it means that 188 the offerer wishes to send (and/or receive), multiple streams at the 189 same time. When sending multiple streams of the same type, the source 190 of the stream (such as the microphone or circuit on a gateway) is 191 sent multiple times, once for each stream. Each stream MAY use 192 different encodings. When receiving multiple streams of the same 193 type, the streams MUST be mixed before playing them out. A typical 194 usage example is a pre-paid calling card application, where the user 195 can enter in a "long pound" at any time during a call to hangup and 196 make a new call on the same card. This requires media from the user 197 to the remote gateway, and to a system that looks for the long pound. 199 There are some codecs, such as the RTP payload format for DTMF tones 200 and digits [5] and comfort noise codecs, which can only encode 201 specific types of media content. When one of these codecs is present 202 in an offered stream that is send-only or send-and-receive, it means 203 that the offerer will send using that codec only when the content of 204 the media stream is of a type that can be encoded with that codec. 205 When the content of the media stream cannot be encoded with that 206 codec, another codec indicated in the m line can be used. If there 207 are no other codecs in the m line, nothing is sent. This is useful 208 for handling the case where a UA would like to send DTMF only, using 209 RFC 2833, to a remote server. This is indicated with a single media 210 line containing only the DTMF codec. 212 2.2 Multicast 214 Construction of a session description for a multicast offer follows 215 the procedures above, with a few exceptions. 217 The address listed in the c line MUST be a multicast address. It 218 indicates the address that the offerer wishes to receive packets on. 220 The interpretation of send-only and receive-only for multicast media 221 sessions differs from that for unicast sessions. For multicast, 222 send-only means that the recipient of the session description (caller 223 or callee) SHOULD only send media streams to the address and port 224 indicated. Receive-only means that the recipient of the session 225 description SHOULD only receive media on the address and port 226 indicated. 228 3 Generating the answer 230 The answer to an offered SDP is based on the offered SDP. If the 231 answer is different in any way (different IP addresses, ports, etc.), 232 the origin line MUST be different in the answer, since the answer is 233 generated by a different entity. In that case, the version number in 234 the o line of the answer is unrelated to the version number in the o 235 line of the offer. 237 For each m line in the offer, there MUST be a corresponding m line in 238 the answer. The answer MUST contain exactly the same number of m 239 lines as the offer. This allows for streams to be matched up based on 240 their order. This implies that if the offer contained zero m lines, 241 the answer MUST contain zero m lines. 243 An offered stream MAY be rejected in the answer, for any reason. The 244 definition of rejected is both neither offerer and answerer MUST NOT 245 generate media (or RTCP packets) for that stream. To reject an 246 offered stream, the port number in the corresponding stream in the 247 answer is set to zero. Any media formats listed are ignored. At least 248 one MUST be present, as specified by SDP. 250 Once the answer has been sent, the answerer MUST be prepared to 251 receive media as described in the answer. 253 3.1 Unicast 255 If a stream is offered with a unicast address, the answer MUST 256 contain a unicast address. 258 If a stream is offered as sendonly, the corresponding stream MUST be 259 marked as recvonly in the answer. Furthermore, the corresponding 260 stream in the answer MUST contain at least one codec the answerer is 261 willing to receive with from amongst those listed in the offer. The 262 stream MAY indicate additional codecs, not listed in the 263 corresponding stream in the offer, that the answerer is willing to 264 receive with. The connection address and port indicate the address 265 where the answerer wishes to receive RTP (RTCP will be received on 266 the port which is one higher). 268 If a media stream is listed as recvonly in the offer, the answer MUST 269 be marked as sendonly. Furthermore, the corresponding stream in the 270 answer MUST contain at least one codec the answerer is willing to 271 send with from amongst those listed in the offer. The IP address and 272 port indicate the address where the answerer wishes to receive RTCP 273 (RTCP will be received on the port number one higher than the one 274 listed in the SDP). 276 If an offered media stream is listed as sendrecv (or contains no 277 direction attribute, in which case it is sendrecv by default), the 278 corresponding stream in the answer MAY be marked as sendonly, 279 recvonly, or sendrecv. The default is sendrecv. If the stream in the 280 answer is marked as sendonly, it MUST contain at least one codec the 281 answerer is willing to send with from amongst those listed in the 282 offer. The IP address and port indicate the address where the 283 answerer wishes to receive RTCP. If the stream in the answer is 284 marked as recvonly, it MUST contain at least one codec the answerer 285 is willing to receive with from amongst those listed in the offer. 287 The stream MAY indicate additional codecs, not listed in the 288 corresponding stream in the offer, that the answerer is willing to 289 receive with. The connection address and port in the answer indicate 290 the address where the answerer wishes to receive RTP and RTCP (RTCP 291 will be received on the port number one higher than the one listed in 292 the SDP). If the stream in the answer is marked as sendrecv, it MUST 293 contain at least one codec the answerer is willing to both send and 294 receive with, from amongst those listed in the offer. The stream MAY 295 indicate additional codecs, not listed in the corresponding stream in 296 the offer, that the answerer is willing to receive with. The 297 connection address and port indicate the address where the answerer 298 wishes to receive RTP (RTCP will be received on the port which is one 299 higher). 301 The payload type numbers for a particular codec within a stream MUST 302 be the same in offer and answer. In other words, a different dynamic 303 payload type number for the same codec cannot be used in each 304 direction. 306 In all cases, the codecs in the m line are listed in order of 307 preference, with the first codec listed being preferred. In this 308 case, preferred means that the recipient of the answer SHOULD use the 309 codec with the highest preference that is acceptable to it. 311 The answerer MAY include a ptime attribute for any media stream; this 312 indicates the packetization interval that the answerer would like to 313 receive. There is no requirement that the packetization interval be 314 the same in each direction for a particular stream. 316 Although the answerer MAY list the codecs in their desired order of 317 preference, it is RECOMMENDED that unless there is a specific reason, 318 the answer list codecs in the same relative order they were present 319 in the offer. In other words, if a stream in the offer lists codecs 320 8, 22 and 48, in that order, and the answerer only supports codecs 8 321 and 48, it is RECOMMENDED that, if the answerer has no reason to 322 change it, the ordering of codecs in the answer be 8, 48, and not 48, 323 8. This helps ensure that the same codec is used in both directions. 325 If the answerer has no media formats in common for a particular 326 offered stream, the answerer MUST reject that media stream. 328 If there are no media formats in common for all streams, the entire 329 offered session is rejected. 331 3.2 Multicast 333 For multicast, receive and send multicast addresses are the same and 334 all parties use the same port numbers to receive media data. If the 335 session description provided by the offerer is acceptable to the 336 answerer, the answerer can choose not to include a session 337 description or MAY echo the description in the response. 339 An answerer MAY return a session description with some of the payload 340 types removed, or port numbers set to zero (but no other value). This 341 indicates to the offerer that the answerer does not support the given 342 stream or media types which were removed. An answerer MUST NOT change 343 whether a given stream is send-only, receive-only, or send-and- 344 receive. 346 If an answerer does not support multicast at all, it SHOULD reject 347 the session description. 349 4 Modifying the session 351 At any point during the call, either participant MAY issue a re- 352 INVITE to modify characteristics of the session. It is fundamental to 353 the operation of SIP that the exact same offer-answer procedure 354 defined above is used for re-INVITE. This means that a re-INVITE MAY 355 contain no SDP, so that the 200 OK to the re-INVITE contains the 356 offer. In this case, the offerer MUST offer the same SDP it provided 357 previously. This is to ensure that the offered SDP in the 2xx will be 358 acceptable to the UAC, as there is no way to reject it. 360 The offer in a re-INVITE MAY be identical to the last SDP provided to 361 the other party (which may have been provided in an offer or an 362 answer), or it MAY be different. We refer to the last SDP provided as 363 the "previous SDP". If the offer is the same, the answer MAY be the 364 same as the previous SDP from the answerer, or it MAY be different. 365 If the offered SDP is different from the previous SDP, some 366 constraints are placed on its construction, discussed below. 368 Nearly all aspects of the session can be modified. New streams can be 369 added, existing streams can be deleted, and parameters of existing 370 streams can change. When issuing an offer that modifies the session, 371 the o line of the new SDP MUST be identical to that in the previous 372 SDP, except that the version in the origin field MUST increment from 373 the previous SDP. If the version in the origin line does not 374 increment, the SDP MUST be identical to the SDP with that version 375 number. The answerer MUST be prepared to receive an offer that 376 contains SDP with a version that has not changed; this is effectively 377 a no-op. However, the answerer MUST generate a valid answer (which 378 MAY be the same as the previous SDP from the answerer, or MAY be 379 different), according to the procedures defined in Section 3. 381 If an SDP is offered which is different from the previous SDP, the 382 new SDP MUST have a matching media section for each media section in 383 the previous SDP. In other words, if the previous SDP had N media 384 lines, the new SDP MUST have at least N media lines. The ith media 385 stream in the previous SDP, counting from the top, matches the ith 386 media stream in the new SDP, counting from the top. This matching is 387 necessary in order for the answerer to determine which stream in the 388 new SDP corresponds to a stream in the previous SDP. Because of these 389 requirements, the number of m lines in a stream never decreases, but 390 only increases. Deleted media streams from a previous SDP MUST NOT be 391 removed from a new SDP. 393 4.1 Adding a media stream 395 New media streams are created by adding additional media descriptions 396 below the existing ones. New media sections MUST appear below any 397 existing media sections. The rules for formatting this media section 398 are identical to those described in Section 2. 400 When the answerer receives an SDP with more media descriptions than 401 the previous SDP from the offerer, the answerer knows that new media 402 streams are being added. These can be rejected or accepted by placing 403 a matching media description in the answer. The procedures for 404 constructing the new media description in the answer are described in 405 Section 3. 407 4.2 Removing a media stream 409 Existing media streams are removed by creating a new SDP with the 410 port number for that stream set to zero. Otherwise, the media 411 description SHOULD be formatted identically to the corresponding 412 stream in the previous SDP. 414 A stream that is offered with a port of zero MUST be marked with port 415 zero in the answer. Otherwise, the media description for the removed 416 stream SHOULD be formatted identically to the corresponding stream in 417 the previous SDP. 419 4.3 Modifying a media stream 421 Nearly all characteristics of a media stream can be modified. 423 The port number for a stream MAY be changed. To do this, the offerer 424 creates a new media description, with the port number in the m line 425 different from the corresponding stream in the previous SDP. If only 426 the port number is to be changed, the rest of the media stream 427 description SHOULD remain unchanged. The offerer MUST be prepared to 428 receive media on both the old and new ports as soon as the offer is 429 sent. The offerer MUST NOT cease listening for media on the old port 430 until media arrives on the new port. At that time, it MAY cease 431 listening for media on the old port. 433 The corresponding media stream in the answer MAY be the same as the 434 stream in the previous SDP from the answerer, or MAY be different. 435 If the updated stream is accepted by the answerer, the answerer 436 SHOULD begin sending traffic for that stream to the new port 437 immediately. If the answerer changes the port from the previous SDP, 438 it MUST be prepared to receive media on both the old and new ports as 439 soon as the answer is sent. The answerer MUST NOT cease listening for 440 media on the old port until media arrives on the new port. At that 441 time, it MAY cease listening for media on the old port. 443 To change the IP address where media is sent to, the same procedure 444 is followed for changing the port number. The only difference is that 445 the connection line is updated, not the port number. 447 The list of codecs used in the session MAY be changed. To do this, 448 the offerer creates a new media description, with the list of media 449 formats in the m line different from the corresponding stream in the 450 previous SDP. This list MAY include new codecs, and MAY remove codecs 451 present from the previous SDP. When a new codec is used with a 452 dynamic payload type number, it MUST NOT reuse a dynamic payload type 453 number used previously in the session. The stream of RTP packets is 454 only loosely synchronized with the SIP/SDP that controls them. So, if 455 a user agent A sends media with dynamic payload type 10, and then 456 performs a re-INVITE that removes codec 10, and then later another 457 re-INVITE that adds a new codec, reusing dynamic payload type 10, an 458 old packet might arrive at the recipient. It would have no way to 459 know whether payload type 10 indicates the old codec or the new. 460 Rather than attempting to synchronize by passing RTP sequence numbers 461 in SDP (which requires additional state), we simply disallow reuse. 463 The corresponding media stream in the answer is formulated as 464 described in Section 3. If the new list of codecs for a stream 465 changes the choice of which codec is used, the new codec SHOULD be 466 used immediately. That means the offerer MUST be prepared to receive 467 media with a new codec as soon as it sends the offer, and the 468 answerer MUST be prepared to receive media with a new codec as soon 469 as it sends the answer. 471 The media type (audio, video, etc.) for a stream MAY be changed. This 472 is particularly useful for changing between voice and fax in a single 473 stream, which are both separate media types. To do this, the offerer 474 creates a new media description, with a new media type, in place of 475 the description in the previous SDP which is to be changed. The IP 476 address and port for the stream MAY change, or MAY remain the same. 477 However, the list of payload type numbers for the new codecs MUST be 478 different than any used previously for this stream. 480 The corresponding media stream in the answer is formulated as 481 described in Section 3. Assuming the stream is acceptable, the 482 answerer SHOULD begin sending with the new media type and codecs as 483 soon as it receives the offer. 485 The transport for a stream MAY be changed. The process for doing this 486 is identical to changing the port, excepting the transport is 487 updated, not the port. 489 Any other attributes in a media description MAY be updated in an 490 offer. 492 4.4 Putting a media stream on hold 494 If a party in a call wants to put the other party "on hold", i.e., 495 request that it temporarily stops sending one or more media streams, 496 a party offers the other an updated SDP. 498 If the stream to be placed on hold was previously a sendrecv media 499 stream, it is placed on hold by marking it as sendonly. If the stream 500 to be placed on hold was previously a recvonly media stream, it is 501 placed on hold by marking it inactive. The inactive direction 502 attribute is specified in RFC 3108 [6]. 504 This means that a stream is placed "on hold" separately in each 505 direction. Each stream is placed "on hold" independently. The 506 recipient of an offer for a stream on-hold SHOULD NOT automatically 507 return an answer with the corresponding stream on hold. An SDP with 508 all streams "on hold" is referred to as held SDP 510 Certain third party call control scenarios do not work when 511 a UA responds to held SDP with held SDP. 513 Typically, when a user "presses" hold, the UA will generate a re- 514 INVITE with all streams in the SDP indicating a direction of 515 sendonly, and it will also locally mute, so that no media is sent to 516 the far end, and no media is played out. 518 RFC2543 specified that placing a user on hold was accomplished by 519 setting the connection address to 0.0.0.0. This has been deprecated, 520 since it doesn't allow for RTCP to be used with held streams, and 521 breaks with connection oriented media. However, a UA MUST be capable 522 of receiving SDP with a connection address of 0.0.0.0, in which case 523 it means that neither RTP nor RTCP should be sent to the peer. 525 5 Example 526 For example, assume that the caller Alice has included the following 527 description in her INVITE request. It includes a bidirectional audio 528 stream and two bidirectional video streams, using H.261 (payload type 529 31) and MPEG (payload type 32). The offered SDP is: 531 v=0 532 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com 533 s=New board design 534 e=alice@foo.org 535 t=0 0 536 c=IN IP4 host.anywhere.com 537 m=audio 49170 RTP/AVP 0 538 a=rtpmap:0 PCMU/8000 539 m=video 51372 RTP/AVP 31 540 a=rtpmap:31 H261/90000 541 m=video 53000 RTP/AVP 32 542 a=rtpmap:32 MPV/90000 544 The callee, Bob, does not want to receive or send the first video 545 stream, so it returns the media description below as the answer: 547 v=0 548 o=bob 2890844730 2890844730 IN IP4 host.example.com 549 s=New board design 550 e=bob@bar.com 551 t=0 0 552 c=IN IP4 host.example.com 553 m=audio 47920 RTP/AVP 0 1 554 a=rtpmap:0 PCMU/8000 555 m=video 0 RTP/AVP 31 556 m=video 53000 RTP/AVP 32 557 a=rtpmap:32 MPV/90000 559 At some point later, Bob decides to change the port where he will 560 receive the audio stream (from 47920 to 6400), and at the same time, 561 add an additional audio stream as receive only, using the RTP payload 562 format for events. Bob offers the following SDP in the INVITE: 564 v=0 565 o=bob 2890844730 2890844731 IN IP4 host.example.com 566 s=New board design 567 e=bob@bar.com 568 t=0 0 569 c=IN IP4 host.example.com 570 m=audio 6400 RTP/AVP 0 1 571 a=rtpmap:0 PCMU/8000 572 m=video 0 RTP/AVP 31 573 m=video 53000 RTP/AVP 32 574 a=rtpmap:32 MPV/90000 575 m=audio 8864 RTP/AVP 110 576 a=rtpmap:110 telephone-events 577 a=recvonly 579 Alice accepts the additional media stream, and so generates the 580 following answer: 582 v=0 583 o=alice 2890844526 2890844527 IN IP4 host.anywhere.com 584 s=New board design 585 e=alice@foo.org 586 t=0 0 587 c=IN IP4 host.anywhere.com 588 m=audio 49170 RTP/AVP 0 589 a=rtpmap:0 PCMU/8000 590 m=video 51372 RTP/AVP 31 591 a=rtpmap:31 H261/90000 592 m=video 53000 RTP/AVP 32 593 a=rtpmap:32 MPV/90000 594 m=audio 4520 RTP/AVP 110 595 a=rtpmap:110 telephone-events 596 a=sendonly 598 6 Author's Addresses 600 Jonathan Rosenberg 601 dynamicsoft 602 72 Eagle Rock Avenue 603 First Floor 604 East Hanover, NJ 07936 605 email: jdrosen@dynamicsoft.com 607 Henning Schulzrinne 608 Dept. of Computer Science 609 Columbia University 610 1214 Amsterdam Avenue 611 New York, NY 10027 612 USA 613 email: schulzrinne@cs.columbia.edu 615 7 Bibliography 617 [1] M. Handley and V. Jacobson, "SDP: session description protocol," 618 Request for Comments 2327, Internet Engineering Task Force, Apr. 619 1998. 621 [2] M. Handley, C. Perkins, and E. Whelan, "Session announcement 622 protocol," Request for Comments 2974, Internet Engineering Task 623 Force, Oct. 2000. 625 [3] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 626 Session initiation protocol," Internet Draft, Internet Engineering 627 Task Force, Nov. 2000. Work in progress. 629 [4] H. Schulzrinne, "RTP profile for audio and video conferences with 630 minimal control," Request for Comments 1890, Internet Engineering 631 Task Force, Jan. 1996. 633 [5] H. Schulzrinne and S. Petrack, "RTP payload for DTMF digits, 634 telephony tones and telephony signals," Request for Comments 2833, 635 Internet Engineering Task Force, May 2000. 637 [6] R. Kumar and M. Mostafa, "Conventions for the use of the session 638 description protocol (SDP) for ATM bearer connections," Request for 639 Comments 3108, Internet Engineering Task Force, May 2001. 641 Table of Contents 643 1 Introduction ........................................ 1 644 2 Generating the initial offer ........................ 2 645 2.1 Unicast ............................................. 3 646 2.2 Multicast ........................................... 5 647 3 Generating the answer ............................... 5 648 3.1 Unicast ............................................. 6 649 3.2 Multicast ........................................... 7 650 4 Modifying the session ............................... 8 651 4.1 Adding a media stream ............................... 9 652 4.2 Removing a media stream ............................. 9 653 4.3 Modifying a media stream ............................ 9 654 4.4 Putting a media stream on hold ...................... 11 655 5 Example ............................................. 11 656 6 Author's Addresses .................................. 13 657 7 Bibliography ........................................ 14