idnits 2.17.1 draft-barnes-sip-em-ps-req-sol-00.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, updated by RFC 4748 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 629. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 15, 2007) is 6311 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft M. Lepinski 4 Intended status: Informational BBN Technologies 5 Expires: July 19, 2007 January 15, 2007 7 Early Media in SIP: Problem Statement, Requirements, and Analysis of 8 Solutions 9 draft-barnes-sip-em-ps-req-sol-00 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 July 19, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The Session Initiation Protocol (SIP) enables and permits endpoints 43 in an INVITE transaction to send media packets before an SDP offer/ 44 answer exchange has completed; we refer to such media packets as 45 early media. The use of early media is common in current SIP 46 implementations, and causes several problems, which have been 47 documented elsewhere. This document puts forward the goal of 48 modifying SIP so that compliant implementations will complete an SDP 49 exchange before sending media, and lays out high-level requirements 50 for such a solution. The set of possible solutions is then laid out, 51 and each possibility examined in light of these requirements. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Elmination of Early Media . . . . . . . . . . . . . . . . 5 58 2.2. Additional Messaging . . . . . . . . . . . . . . . . . . . 6 59 2.3. Interoperability with current SIP standards . . . . . . . 6 60 2.4. Interoperability with the PSTN . . . . . . . . . . . . . . 6 61 2.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 6 62 2.6. IPR Constraints . . . . . . . . . . . . . . . . . . . . . 6 63 3. Early Media Solutions . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Minimizing SDP completion time . . . . . . . . . . . . . . 7 65 3.1.1. Fast completion of INVITE transaction . . . . . . . . 7 66 3.1.2. Elimination of offer from INVITE . . . . . . . . . . . 8 67 3.1.3. Provisional Responses . . . . . . . . . . . . . . . . 8 68 3.1.4. Separate INVITE transaction . . . . . . . . . . . . . 9 69 3.1.5. Non-INVITE SIP Mechanisms . . . . . . . . . . . . . . 9 70 3.1.6. Non-SIP mechanisms . . . . . . . . . . . . . . . . . . 10 71 3.2. Handling remaining media . . . . . . . . . . . . . . . . . 11 72 3.2.1. Unreliable SDP answer . . . . . . . . . . . . . . . . 11 73 3.2.2. Backwards-compatibility . . . . . . . . . . . . . . . 11 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 79 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 81 Intellectual Property and Copyright Statements . . . . . . . . . . 14 83 1. Introduction 85 A primary function of the Session Initiation Protocol (SIP, 86 [RFC3261]) is to carry SDP messages that form an SDP offer/answer 87 exchange [RFC3264]. The offer/answer exchange serves to negotiate 88 the parameters necessary for the two end hosts to send multimedia to 89 each other, including transports, port numbers, codecs, and security 90 parameters (e.g., MIKEY [RFC3830]). In the most common SIP INVITE 91 transaction, the calling party (UAC) is the SDP offerer and the 92 called party (UAS) is the SDP answerer; in this scenario, the SDP 93 offer is carried in the SIP INVITE request, and the SDP answer in the 94 200/OK response. 96 Because there is often a substantial delay between the sending of an 97 INVITE and the receipt a 200/OK, this assignment of SDP messages to 98 SIP messages creates a substantial delay between an SDP offer and an 99 SDP answer. Consequently, there is a period of time between the two 100 messages in which the two parties have asymmetric information: The 101 called party has knowledge of both the SDP offered by the calling 102 party and of his own intended response, while the calling party knows 103 only the offer he sent. Given this information, the called party has 104 all the information he needs to begin sending media to the calling 105 party (because this was included in the SDP offer); moreover, he can 106 send these media without sending an SDP answer to the calling party. 107 We define early media as media sent before the completion of an SDP 108 offer/answer exchange. 110 Ours is a different definition than is used in RFC 3960 [RFC3960], 111 which defines early media as "media ... that is exchanged before a 112 particular session is accepted by the called user." The definition 113 in RFC 3960 is consistent with the current usage of SDP within the 114 SIP INVITE transaction, but at the same time conflates two functions 115 of SIP: Negotiation of session-layer parameters (through the SDP 116 offer/answer) and communication of an application-layer request and 117 acceptance of a session (by the INVITE and 200/OK messages). As 118 suggested above, it is this assignment of SDP messages to SIP 119 messages that creates the possibility of early media. 121 Early media is known to create several problems for SIP operation: 123 o Call failure: When endpoints use early media for an extended 124 period of time, timers can fire to close the UAC INVITE 125 transaction before the early media finish and the UAS sends a 126 200/OK. This causes the session proposed in the initial INVITE to 127 be dropped by the UAC, and in some implementations, the flow of 128 media is cut off. 130 o Confidentiality: Techniques such as MIKEY [RFC3830]and Security 131 Descriptions [RFC4568], which use SDP to establish keys for media 132 security protocols, require a full SDP offer/answer exchange to 133 negotiate keys. Such keying techniques are therefore incompatible 134 with early media. 136 o Access Control: In the presence of early media, a UAC must 137 anticipate that media will arrive without any signaling, and thus 138 is obliged to receive (and presumably render) media received from 139 any host on the Internet. 141 o Interaction with forking/retargeting: When an INVITE from a UAC is 142 forked or retarget to UASs that send early media, because these 143 UASs send no signaling, the UAC has no information besides the 144 media itself on which to base a decision as to which media stream 145 to render. 147 o Denial of Service: Early media is the basis of the "voice hammer" 148 attack, described in [draft-ietf-mmusic-ice]. 150 To date, attempts to deal with early media have failed to solve all 151 of the problems caused by early media. Such work typically has 152 started from the assumption that early media is a necessary component 153 of SIP (largely due to RFC 3398 [RFC3398] and RFC 3578 [RFC3578]) and 154 has generally avoided the issue of whether key use-cases (such as 155 PSTN interoperability) can be satisfied without the use of early 156 media. RFC 3960 presents two models for managing early media 157 streams, which mitigate early-media related problems in some cases. 158 However, the document neither specifies the models in sufficient 159 detail nor makes their implementation a mandatory part of SIP. More 160 recently, Stucker has written a draft extending 3960 by detailing a 161 more current set of early media coping mechanisms, and proposing a 162 solution that uses additional SDP attributes to mitigate the problems 163 caused by early media [draft-stucker-sipping-early-media-coping]. 164 Although Stucker's proposed solution addresses several of the above 165 problems, it stops short of requiring an SDP exchange before media 166 transmission. Ejzak has also authored a recent draft regarding early 167 media [draft-ejzak-sipping-p-em-auth]. However, his draft proposes 168 the use of a p-header to prevent fraudulent uses of early media, 169 which are largely orthogonal to the early media problems considered 170 in this draft. 172 In contrast to previous approaches, this draft proposes to address 173 the problems of early media by normatively modifying the SIP protocol 174 to preclude the transmission of early media. In order to remove the 175 possibility of early media, this modification must ensure (to the 176 greatest extent possible) that the SDP offer/answer exchange has 177 completed before any media are sent. At a high level, this goal can 178 be approached from two directions: To complete the SDP exchange as 179 quickly and reliably as possible, and to forbid sending of media 180 before completion. A successful solution will combine these two 181 approaches, since as progress is made on the former, the latter 182 becomes less onerous. 184 The goal of this draft is three-fold: First, in the above, we have 185 provided a consolidated statement of the early media problem, namely 186 that the presence of media before the completion of an SDP offer/ 187 answer exchange is harmful to the functioning of SIP calls. Second, 188 Section 2 specifies requirements for an update to SIP that eliminates 189 early media, in an effort to consolidate the requirements that have 190 been presented to date and enable discussion of solutions. Third, 191 Section 3 lays out the space of possible solutions, enumerating the 192 trade-offs entailed by each so that consensus can be reached on the 193 direction that should be taken by the SIP working group. 195 2. Requirements 197 There have been several informal proposals to date that would 198 mitigate or eliminate early media, but each was disqualified in turn 199 by requirements as perceived by the SIP and SIPPING working groups. 200 In this section, we seek to create a consolidated set of requirements 201 so that a consistent evaluation of solutions can move forward. 202 Below, we use the term "proposed solution" to refer to a protocol 203 that normatively updates the relevant standards (e.g., RFCs 3261, 204 3264, and 3398) in such a way as to eliminate early media, while we 205 use the term "current SIP" to refer to SIP as defined in RFC 3261 and 206 related documents. 208 2.1. Elmination of Early Media 210 The proposed solution must define a normative modification to the SIP 211 protocol (and other relevant protocols) that minimizes or eliminates 212 the possibility of early media in SIP sessions; i.e., it should 213 minimize or eliminate the possibility that a compliant implementation 214 could send media before an SDP offer/answer exchange has completed. 215 Solutions in which receipt of SDP-bearing messages is explicitly 216 acknowledged (e.g., an INVITE/200/ACK or INVITE/180/PRACK exchange) 217 are preferred, since these acknowledgements are the only way to 218 completely eliminate early media (otherwise the answerer cannot know 219 with certainty that the offerer has received his answer). If a 220 proposed solution does not include such acknowledgements, it must 221 define UAS behaviors that minimize the probability of the UAS sending 222 media before the UAC has received the SDP answer. 224 2.2. Additional Messaging 226 In order to minimize the impact of the proposed solution on call- 227 setup times, the proposed solution should minimize the number of 228 signaling messages that are required in addition to those used by 229 current SIP. Proposed solutions should accommodate the fact that 230 messages sent "on the media path" (i.e. directly between the two SIP 231 endpoints) will often be unable to reach their destinations due to 232 current media gating techniques. 234 2.3. Interoperability with current SIP standards 236 The proposed solution must define how entities implementing it will 237 interact with entities that implement the current SIP protocol. The 238 proposed solution should minimize the set of conditions under which a 239 call would fail in such a hybrid scenario, but not in a scenario in 240 which both endpoints use current SIP. 242 2.4. Interoperability with the PSTN 244 The proposed solution must be compatible with the creation of 245 gateways to the PSTN, and may define normative updates as necessary 246 to RFC 3398 and RFC 3578. 248 2.5. Denial of Service 250 The proposed solution must minimize the possibility of new denial of 251 service attacks by minimizing the amount of state that is kept by a 252 UAS prior to the completion of an offer/answer exchange. Ideally, no 253 state in addition to the SIP INVITE state machine will be required 254 (i.e., the initial SDP offer/answer will be conducted statelessly). 256 2.6. IPR Constraints 258 The proposed solution must, to the extent possible, avoid dependence 259 on technologies on which there are known IPR constraints, as this 260 tends to hinder adoption. 262 3. Early Media Solutions 264 The fundamental goal of a system to eliminate early media is to 265 ensure that an SDP offer/answer exchange has completed before media 266 packets are sent. Such a system will combine two approaches: 267 Completing the SDP exchange as quickly and reliably as possible, and 268 providing restrictions on the sending and receiving of media before 269 such completion. A priori, neither approach is at odds with the 270 requirements stated above, so we explore the possible mechanisms for 271 accomplishing each. Many of the solutions below have been suggested 272 on the SIP and SIPPING mailing lists already, sometimes by multiple 273 people independently; we have not made an effort to attribute them. 275 3.1. Minimizing SDP completion time 277 The simplest way to preclude early media is for the SIP endpoints to 278 ensure that an SDP exchange has completed before media packets are 279 generated. In order to convey the SDP messages comprising this 280 exchange, it is necessary to modify the way that SDP messages are 281 carried within SIP session establishment. There are a variety of 282 mechanisms for achieving this goal, including modifications to 283 messages within the INVITE transaction, other non-INVITE SIP 284 mechanisms, and protocols outside of SIP. 286 3.1.1. Fast completion of INVITE transaction 288 Perhaps the most straightforward approach to quickly completing an 289 SDP offer/answer exchange would be to simply complete the SDP 290 exchange already inherent in the SIP INVITE transaction more quickly: 291 To do this, the UAS would send a 200/OK response as soon as an INVITE 292 message is received, rather than awaiting an indication from a higher 293 layer to do so (formally, this moves both the client and server 294 INVITE transactions to the Terminated state as quickly as possible). 295 In essence, this is a change to the semantic meaning of the "200/OK" 296 response; rather than indicating that an application-layer session 297 has begun, it would indicate that an media association had been 298 established, in the sense that all necessary parameters are 299 established for media to flow. A separate message (for instance, an 300 UPDATE [RFC3311]) could be used to indicate that an application-layer 301 user is ready to begin exchanging media. 303 Quickly completing the INVITE transaction has the potential to 304 eliminate early media entirely: Because the 200 response is 305 explicitly acknowledged by the ACK message, both endpoints can be 306 sure that the SDP exchange is complete when the ACK is transmitted. 307 In ISUP terms, a 200/OK response used in this way would correspond to 308 an ACM (rather than to an ANM, as in RFC 3398), and the UPDATE (or 309 similar message) would correspond to the ANM. The failing of this 310 approach is its interaction with SIP forking: Since a 200/OK message 311 moves both endpoints to the Terminated state, the first UAS to 312 respond would automatically cut off all other branches of the call. 313 Although this issue could likely be resolved with a modification to 314 rules for SIP forking, it could inhibit backward compatibility in the 315 interim. 317 3.1.2. Elimination of offer from INVITE 319 One way to ensure that a UAS cannot send media until an SDP exchange 320 has completed would be to forbid a UAC from including an SDP offer in 321 its INVITE message, so that the SDP offer would be sent by the UAS in 322 either a reliable provisional response or the 200/OK message, and the 323 answer in the UAC's PRACK or ACK message. This behavior is allowed 324 by current SIP, but does not eliminate early media because it is not 325 mandatory. At first blush, reusing the existing INVITE transaction 326 in this way seems appealing: Because it is a subset of behaviors 327 allowed by current SIP, it will interact well with current SIP 328 endpoints, and it introduces no additional messaging or state 329 machinery. However, if either endpoint does not support reliable 330 provisional responses [RFC3262], this solution would prevent any 331 media flows before the sending of a 200/OK (distinct from an SDP 332 answer), which would cause many existing SIP applications to fail 333 (including a large number of PSTN applications as they pass through 334 gateways). In addition, the ACK message is not a reliable mechanism 335 for transporting SDP answers, since the UAC (as an SDP answerer) 336 receives no notification that the UAS has received its answer. 338 3.1.3. Provisional Responses 340 Within the INVITE transaction, the only other messages sent from UAS 341 to UAC (besides the INVITE, 200, and ACK messages) that could carry 342 SDP information are provisional (101-199) responses (response type 343 100 is excepted because it is often not retransmitted by proxies). 344 Upon receipt of an INVITE message, a UAS would respond with a 1xx 345 message that would complete the SDP offer/answer. Some have 346 suggested use of the 183 (Call Progress) message for this purpose, as 347 is done in ICE, though another existing or new response type could in 348 principle be used. 350 This approach has the advantage that if the UAS does not support this 351 use of provisional messages, then the call will proceed in the same 352 way as with current SIP. For PSTN gateways, this approach only 353 requires the sending or understanding a single additional message. 354 However, it would be difficult to use provisional responses to 355 eliminate early media, since this would require them to be reliable. 356 Though there exist both SIP (PRACK) and non-SIP (ICE binding request) 357 messages that can acknowledge provisional responses, AT&T holds IPR 358 related to reliable provisional responses. This has limited the 359 deployment of PRACK, and may have the same effect on relevant 360 portions of ICE. 362 3.1.4. Separate INVITE transaction 364 The Application Server model of RFC 3960 provides an SDP exchange for 365 early media by conducting separate INVITE transactions for an "Early" 366 session and for the "Final" session. In a recently proposed 367 realization and extension of this model 368 [draft-stucker-sipping-early-media-indirection], any entity along the 369 signaling path can include an EMIND (Early Media Indirection) header 370 that will prompt the UAC to initiate a separate INVITE transaction 371 with a third entity, e.g., a media server to provide ring-back tones 372 or balance announcements. This transaction establishes an "Early 373 Session," which is terminated when the orignal INVITE transaction is 374 completed and the "Final Session" begun. 376 Using a separate INVITE transaction for early media has several 377 advantages: Since the answer in a 2xx response triggers an ACK in the 378 early INVITE transaction, it can be used to completely prevent early 379 media. Prospects for interoperability with current SIP 380 implementations are good, since no new mechanisms are employed; in 381 particular, the EMIND header will be ignored by implementations that 382 do not support it. And the entire burden of state maintenance is 383 placed on the UAC, which must manage both INVITE transactions. 384 However, using two separate INVITE transactions incurs significant 385 siganling overhead, and it is unclear that this approach, at least as 386 currently specified, can eliminate early media from PSTN gateways 387 that are unable to separate early and regular media. 389 3.1.5. Non-INVITE SIP Mechanisms 391 There are other SIP messages that could be used to carry an SDP 392 answer that would be formally outside of the INVITE transaction, but 393 could be contemporaneous with it. Because these messages would be 394 outside the INVITE transaction, a separate mechanism may be required 395 to associate the transmitted SDP answer with the SDP offer in the 396 INVITE request. 398 3.1.5.1. INFO and UPDATE 400 The SIP INFO method [RFC2976] is currently used to convey additional 401 signaling information in the middle of a session, after the INVITE 402 transaction has terminated. However, it could also be used to convey 403 information relevant to an INVITE transaction, subject to the 404 constraint in RFC 2976 that an INFO request must not change the state 405 of a SIP call. While receipt of an SDP answer in an INFO request 406 would change state at the TU layer (namely, in the UAC core), it 407 would not change the transaction-layer state of the call. INFO 408 messages carrying SDP answers can be associated with the 409 corresponding SDP offer by virtue of the fact that the INFO message 410 carrying the answer will carry the same Call-ID as the INVITE message 411 carrying the offer. The SIP UPDATE method [RFC3311]could be likewise 412 used (in fact, RFC 3311 lists early media as the main motivation for 413 UPDATE, and RFC 3960 uses UPDATE messages as the basis for its 414 gateway model). 416 Current standards require that the UAS in an INFO or UPDATE 417 transaction to send a response to an INFO or UPDATE message, so these 418 messages would provide a reliable transport for SDP answers. Just as 419 with provisional responses, using INFO or UPDATE messages to convey 420 SDP answers is backwards-compatible, and requires minimal 421 modification to PSTN gateways. One potential drawback is that as 422 currently specified, UPDATE and INFO messages cannot be sent before a 423 dialog is established (i.e., a 101-199 response is sent). If not 424 changed or lifted by the proposed solution, this restriction could 425 limit the efficacy of UPDATE (or INFO) for quickly concluding an SDP 426 exchange, since the required 1xx message would introduce additional 427 delay in the transmission of the SDP answer. 429 3.1.5.2. Other Response Codes 431 In current SIP, if a UAS wishes to send early media in response to an 432 INVITE, it will send the media without any SIP response. As an 433 alternative, the UAS wishing to send early media could send a 401 434 response requiring http-auth with null authentication. The UAC would 435 then signal its willingness to receive the media by sending a new 436 INVITE (with the nonce for null authentication). In this model, the 437 UAS's SDP answer would be sent in its 401 response, and the UAC's re- 438 INVITE would confirm receipt of this answer. 440 Although this proposal does provide a reliable transport for SDP 441 answers, it has significant drawbacks: In addition to adding 442 significant messaging overhead, it requires both endpoints to 443 maintain state across INVITE transactions (in addition to the nonce 444 required by null authentication). And the prospects for backward 445 compatibility with this solution are bleak: All calls to current SIP 446 endpoints will fail unless the endpoints support the indicated 447 authentication mechanisms, and forked calls would show unpredictable 448 behavior due to the Heterogeneous Error Response Forking Problem 449 (HERFP). 451 3.1.6. Non-SIP mechanisms 453 There are some proposals to use protocols other than SIP to resolve 454 the problem of early media in SIP. For instance, a lower-level 455 protocol could be defined that could negotiate and SDP session that 456 could then be used by SIP, much as TLS negotiations are conducted 457 before HTTPS data are sent. However, such a protocol would have to 458 duplicate many SIP features, and any such solution would require SIP 459 entities to implement an additional protocol stack, which would have 460 negative consequences for backward-compatability and PSTN 461 interoperability. 463 3.2. Handling remaining media 465 Early media can be completely eliminated only if neither party sends 466 media until it is assured that the SDP offer/answer exchange is 467 completed. Of course, this is only possible when both endpoints 468 support the proposed solution and the SDP answer is carried in a 469 reliable message: In this optimal case, both the offerer and the 470 answerer must not send media until they have received assurance that 471 the SDP exchange has completed. The proposed solution will specify 472 the two remaining cases. 474 3.2.1. Unreliable SDP answer 476 If both endpoints support the solution, but the solution uses an 477 unreliable message to carry the SDP answer, then the offerer can be 478 assured that the SDP exchange has completed (because he has received 479 the answer), but the answerer cannot. In this case, the offerer must 480 not send media until the SDP exchange has completed. The proposed 481 solution should provide an explicit, deterministic criterion for when 482 the answerer may send media: For instance, the answerer may be free 483 to send media after it receives media from the offerer, or after a 484 timer fires that is set when the answer is sent. 486 3.2.2. Backwards-compatibility 488 Depending on the nature of the proposed solution, one party may not 489 be able to know whether the other supports the solution. If a party 490 cannot know, then it must behave as if the other party does support 491 the solution (otherwise, the solution would never be used). If a 492 party can be aware of the other party's support, then the solution 493 should allow a supporting party to knowingly send early media to an 494 non-supporting party, since to do otherwise -- to mandate that a 495 supporting party behave as it would if the other party supported the 496 solution -- is incompatible with existing SIP applications that use 497 early media. Nonetheless, an implementation of the solution should 498 always avoid the use of early media; it should only send early media 499 when it has received early media from a non-supporting endpoint. 501 4. IANA Considerations 503 This document makes no request of IANA. 505 Note to RFC Editor: this section may be removed on publication as an 506 RFC. 508 5. Security Considerations 510 The only new security concern that arises from this draft is the 511 possibility of introducing new denial of service attacks. The 512 requirement addressing this concern is stated in Section 2.5 above. 513 The performance of each candidate solution against this requirement 514 is examined in the section where that solution's is proposed. 516 6. Acknowledgements 518 7. References 520 7.1. Normative References 522 [RFC3261] "SIP: Session Initiation Protocol", June 2002. 524 [RFC3264] "An Offer/Answer Model with the Session Description 525 Protocol (SDP)", June 2002. 527 7.2. Informative References 529 [RFC2976] "The SIP INFO Method", October 2000. 531 [RFC3262] 2, "Reliability of Provisional Responses in the Session 532 Initiation Protocol (SIP)", June 2002. 534 [RFC3311] "The Session Initiation Protocol (SIP) UPDATE Method", 535 September 2002. 537 [RFC3398] "Integrated Services Digital Network (ISDN) User Part 538 (ISUP) to Session Initiation Protocol (SIP) Mapping", 539 December 2002. 541 [RFC3578] "Mapping of Integrated Services Digital Network (ISDN) 542 User Part (ISUP) Overlap Signalling to the Session 543 Initiation Protocol (SIP)", August 2003. 545 [RFC3830] "MIKEY: Multimedia Internet KEYing", August 2004 2004. 547 [RFC3960] "Early Media and Ringing Tone Generation in the Session 548 Initiation Protocol (SIP)", December 2004. 550 [RFC4568] "Session Description Protocol (SDP) Security Descriptions 551 for Media Streams", July 2006. 553 [draft-ejzak-sipping-p-em-auth] 554 "Private Header (P-Header) Extension to the Session 555 Initiation Protocol (SIP) for Authorization of Early 556 Media", January 2007. 558 [draft-ietf-mmusic-ice] 559 "Interactive Connectivity Establishment (ICE): A 560 Methodology for Network Address Translator (NAT) Traversal 561 for Offer/Answer Protocols", October 2006. 563 [draft-stucker-sipping-early-media-coping] 564 "Coping with Early Media in the Session Initiation 565 Protocol (SIP)", October 2006. 567 [draft-stucker-sipping-early-media-indirection] 568 "Early Media INDirection (EMIND) in the Session Initiation 569 Protocol (SIP)", October 2006. 571 Authors' Addresses 573 Richard Barnes 574 BBN Technologies 575 9861 Broken Land Pkwy 576 Columbia, Maryland 21046 577 USA 579 Phone: +1-410-290-6169 580 Email: rbarnes@bbn.com 582 Matt Lepinski 583 BBN Technologies 584 10 Moulton St. 585 Cambridge, Massachusetts 02138 586 USA 588 Phone: +1-617-873-5939 589 Email: mlepinsk@bbn.com 591 Full Copyright Statement 593 Copyright (C) The IETF Trust (2007). 595 This document is subject to the rights, licenses and restrictions 596 contained in BCP 78, and except as set forth therein, the authors 597 retain all their rights. 599 This document and the information contained herein are provided on an 600 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 601 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 602 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 603 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 604 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 605 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 607 Intellectual Property 609 The IETF takes no position regarding the validity or scope of any 610 Intellectual Property Rights or other rights that might be claimed to 611 pertain to the implementation or use of the technology described in 612 this document or the extent to which any license under such rights 613 might or might not be available; nor does it represent that it has 614 made any independent effort to identify any such rights. Information 615 on the procedures with respect to rights in RFC documents can be 616 found in BCP 78 and BCP 79. 618 Copies of IPR disclosures made to the IETF Secretariat and any 619 assurances of licenses to be made available, or the result of an 620 attempt made to obtain a general license or permission for the use of 621 such proprietary rights by implementers or users of this 622 specification can be obtained from the IETF on-line IPR repository at 623 http://www.ietf.org/ipr. 625 The IETF invites any interested party to bring to its attention any 626 copyrights, patents or patent applications, or other proprietary 627 rights that may cover technology that may be required to implement 628 this standard. Please address the information to the IETF at 629 ietf-ipr@ietf.org. 631 Acknowledgment 633 Funding for the RFC Editor function is provided by the IETF 634 Administrative Support Activity (IASA).