idnits 2.17.00 (12 Aug 2021) /tmp/idnits4399/draft-stucker-sipping-early-media-coping-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1037. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1048. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1055. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1061. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (October 18, 2006) is 5694 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 168 == Unused Reference: 'RFC2119' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 964, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) == Outdated reference: A later version (-02) exists of draft-wing-rtpsec-keying-eval-01 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING B. Stucker 3 Internet-Draft Nortel 4 Intended status: Informational October 18, 2006 5 Expires: April 21, 2007 7 Coping with Early Media in the Session Initiation Protocol (SIP) 8 draft-stucker-sipping-early-media-coping-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 21, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Several mechanisms for early media have been proposed in the past, 42 each attacking a different aspect of the problem. A good example of 43 this is RFC-3960 which talks about two models of early media: the 44 gateway model, and the application model. The gateway model uses a 45 series of offer/answer exchanges to control the rendering of early 46 media, but breaks down in the presence of forking (as mentioned in 47 section 3 of RFC-3960). The application model relies on the UAS to 48 know when it is generating early media and use RFC-3959 to keep early 49 media and regular media streams separate to avoid clipping. Even in 50 the presence of the recommendations in RFC-3960 some problems exist 51 within SIP in the area of early media. Although some of these 52 challenges are likely to never be overcome, for example when 53 interworking with a PSTN gateway that does not take into account CPG 54 or ACM messages (in the case of ISUP). However, the potential to 55 improve on what is already there does exist. This document attempts 56 to go into more detail around early media where RFC-3960 left off, 57 what sorts of mechanisms are in use today in existing implementations 58 to deal with the challenges at hand, derives requirements and a 59 possible mechanism to improve upon the current model. In addition, 60 the document goes into other areas that can complicate or be 61 complicated by the presence of early media (especially with forking) 62 such as SRTP keying and media flow authorization. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Types of Early Media . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Pre-routing early media . . . . . . . . . . . . . . . . . 5 70 3.2. Pre-presentation early media . . . . . . . . . . . . . . . 6 71 3.3. Post-presentation early media . . . . . . . . . . . . . . 6 72 3.4. Non-SDP early media . . . . . . . . . . . . . . . . . . . 7 73 4. Current common coping mechanisms for early media . . . . . . . 7 74 4.1. Problems with current coping mechanisms . . . . . . . . . 8 75 4.1.1. Proxy-side coping mechanisms . . . . . . . . . . . . . 8 76 4.1.1.1. Proxy SDP stripping . . . . . . . . . . . . . . . 8 77 4.1.1.2. Proxy SDP weighting . . . . . . . . . . . . . . . 9 78 4.1.2. Client-side coping mechanisms . . . . . . . . . . . . 9 79 4.1.2.1. Client detection of forking . . . . . . . . . . . 9 80 4.1.2.2. Client slow-start INVITE . . . . . . . . . . . . . 10 81 4.1.2.3. Client Usage of Gateway Model . . . . . . . . . . 10 82 4.1.2.4. Client Usage of Application Server Model . . . . . 10 83 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 5.1. Deprecation of forking . . . . . . . . . . . . . . . . . . 11 85 5.2. Deprecation of early media . . . . . . . . . . . . . . . . 11 86 5.3. Originating UA's to render early media . . . . . . . . . . 12 87 5.4. Downstream signaling of acceptance . . . . . . . . . . . . 12 88 5.5. Upstream signaling of importance . . . . . . . . . . . . . 13 89 5.6. Universal backward-compatibility . . . . . . . . . . . . . 13 90 5.7. Recursive forking . . . . . . . . . . . . . . . . . . . . 13 91 5.8. Media Gating . . . . . . . . . . . . . . . . . . . . . . . 14 92 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 14 93 6.1. Early Media Classification and Prioritization . . . . . . 14 94 6.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 14 95 6.1.1.1. Early-Media Classifications . . . . . . . . . . . 15 97 6.2. Early Media Flow Negotiation . . . . . . . . . . . . . . . 16 98 6.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 16 99 6.2.2. SDP parameters . . . . . . . . . . . . . . . . . . . . 16 100 6.2.3. Usage of emflow with offer/answer . . . . . . . . . . 17 101 6.2.3.1. Meaning of a=emflow:none . . . . . . . . . . . . . 17 102 6.2.3.2. Meaning of a=emflow:send . . . . . . . . . . . . . 17 103 6.2.3.3. Meaning of a=emflow:recv . . . . . . . . . . . . . 18 104 6.2.3.4. Meaning of a=emflow:sendrecv . . . . . . . . . . . 18 105 6.2.3.5. Usage of RTP-SSRC-Value . . . . . . . . . . . . . 18 106 6.2.4. Option tag for emflow . . . . . . . . . . . . . . . . 19 107 6.2.5. Example . . . . . . . . . . . . . . . . . . . . . . . 19 108 6.3. Early Media and SRTP . . . . . . . . . . . . . . . . . . . 20 109 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 110 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 111 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 112 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 113 9.2. Informational References . . . . . . . . . . . . . . . . . 22 114 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 115 Intellectual Property and Copyright Statements . . . . . . . . . . 24 117 1. Introduction 119 One of the mechanisms within SIP [RFC3261] that has caused much 120 consternation (and interesting service scenarios) is forking, 121 especially forking of INVITE requests. This is where a SIP INVITE 122 request sent to a SIP proxy is resolved into two or more destinations 123 which are signaled in parallel or sequentially by the proxy. When 124 this occurs, multiple downstream parties will receive similar INVITE 125 requests to initiate a SIP session from a given originating SIP user 126 agent (UA). This creates the possibility of race conditions where 127 the ordering of the provisional and final responses to this request, 128 as observed by the originating SIP UA, may potentially arrive in any 129 order, or not at all. 131 Another mechanism in SIP that looks simple, but causes difficult 132 interactions, was introduced to handle SIP to PSTN interworking. 133 Because the PSTN has a specific set of behaviors which require that 134 only one endpoint in the PSTN network (typically the last PSTN switch 135 reached) may generate media back to the originator of a PSTN call, 136 generation of early media (media produced prior to the intended 137 terminator of a call answering the call) is relatively straight- 138 forward. In SIP, this PSTN interaction with early media was handled 139 by allowing any endpoint that has received an SDP offer as part of 140 setting up a session to be able to immediately generate media back to 141 the to SDP offerer. Further, the SDP offerer was obligated to be 142 prepared to render any media received at the location specified in 143 the SDP offer at any time as long as the session was in a setup or 144 stable state. 146 Each of these mechanisms, taken separately, can create complex 147 signaling flows and difficult service interactions to resolve. 148 Together, however, they compound the effects of one another to create 149 an area of study that has been open within the SIP design community 150 for some time. Several extensions to [RFC3261] have been proposed to 151 handle some of the various effects that early media suffers from, 152 most notably [RFC3959] and [RFC3960]. However, none have fully 153 attacked a few key areas of interest: 154 o Controlling the order and timing of early media stream rendering 155 at the originating SIP UAC. 156 o Knowing under what general conditions early media flows are 157 potentially being sent to the originating SIP UAC. 159 This document seeks to capture the salient requirements for these 160 areas, and propose a mechanism for handling these early media 161 interactions in a more predictable manner. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in BCP 14, RFC 2119 [3]. 169 3. Types of Early Media 171 Not all early media is created equal, some types are more problematic 172 than others. There are four generic types of early media within SIP: 173 1. Pre-routing early media - This is early media that is conveyed 174 via SDP and is presented to the originator by a proxy before 175 routing on the URI is started. 176 2. Pre-presentation early media - This is early media that is 177 presented to the originator, conveyed via SDP, by a proxy after 178 the URI has been routed upon, but before any forwarding of the 179 INVITE request has occurred. 180 3. Post-presentation early media - This is early media that is 181 presented to the originator, conveyed via SDP, by either a 182 forking proxy or any subsequent hop after the INVITE request has 183 been forwarded from the proxy. 184 4. Non-SDP early media - This is early media that may be presented 185 to the originator at any time through means other than SDP, such 186 as the Alert-Info header as defined in [RFC3261] 188 3.1. Pre-routing early media 190 Pre-routing early media is typically generated and characterized by a 191 proxy that has an associated media resource. An example of this type 192 of early media would be a brief 'branding' message that is played to 193 the originator thanking them for using the service provider 194 associated with the originator's local outbound proxy. When the 195 message ends, the media resource signals this to the proxy and 196 routing of the request continues per [RFC3261] 198 This type of early media typically does not pose the originator's 199 local outbound proxy any issues unless the client is using one of the 200 mechanisms defined in Section 4.1.2 or something similar. This is 201 because the proxy is in complete control over the pace at which the 202 terminator will be routed to relative to the media stream being 203 presented. If the proxy attempting to present pre-routing early 204 media to the originator is a subsequent proxy from the originator's 205 local outbound proxy, then the service may not work due to upstream 206 proxies employing one of the mechanisms described in Section 4.1.1 208 3.2. Pre-presentation early media 210 Pre-presentation early media is similar to pre-routing early media 211 except that it may take into account the routes that the proxy is 212 about to route the INVITE request to in its decision of what to play. 213 This may allow the proxy to employ one of the proxy-side early media 214 coping mechanisms defined in Section 4.1.1. Likewise, the proxy may 215 inject its own SDP answer into the signaling to the originator to 216 kick off services like colorful ringback tone (CRBT) where the 217 originator is hearing a recording (typically music) selected by the 218 terminator while the network attempts to reach the terminating party. 220 Pre-presentation early media also differs from non-SDP early media in 221 that the proxy or proxies are manipulating the SDP offer/answer 222 rather than SIP headers such as Alert-Info (as defined in [RFC3261]) 223 to signify what media the originator should be rendering. There are 224 several potential reasons why the Alert-Info header is not used in 225 this case: the service may be interactive, requiring two-way media in 226 order to work (such as digit collection for a credit card number), or 227 may not want to rely on the originator's ability to render the 228 information in the Alert-Info header to the end user (such as a call 229 originating from the PSTN through a SIP gateway). 231 3.3. Post-presentation early media 233 Post-presentation early media is most typically characterized by the 234 ugly interactions that arise between it and forking. Since this is 235 early media that has come about after the proxy has potentially 236 caused multiple endpoints to be contacted, and therefore the 237 possibility that multiple early media streams may have been 238 triggered, it is commonly considered to be the worst-case scenario 239 with early media. 241 To compound the basic issue at play, the presence of forking can 242 confuse the type of early media being presented to the originator. A 243 downstream proxy that has received a forked request may not be aware 244 that the INVITE has forked as a B2BUA may have forked the request. 245 As a result, the proxy may be acting as if it is the only proxy to 246 handle the request from the originator, and operate in a pre-routing, 247 pre-presentation, or non-SDP early media mode despite the fact that 248 the early media reaching the originator is post-presentation. 249 Therefore, unless the proxy is the originator's edge proxy, it cannot 250 necessarily determine what kind of early media it may actually be 251 sending to the originator. 253 3.4. Non-SDP early media 255 Non-SDP early media is typically characterized by the presence of an 256 Alert-Info header [RFC3261]. The Alert-Info header specifies a URI 257 that the originator may go to in order to receive a file or stream 258 that contains information (such as a wave recording) about the 259 ringback tone the terminator wishes the originator to hear. It is 260 somewhat simpler in that it is not part of the offer/answer model, 261 and that it is not trying to create a two-way media stream. The 262 interaction between inband ringback, client generated (local) 263 ringback, and other forms of early media is spelled out in [RFC3960]. 264 It is worth noting that rendering the Alert-Info header contents 265 should only be done when the origin of the header is trusted (per 266 [RFC3261]), so this may limit its usefulness to a considerable 267 degree. The remainder of this document assumes that the UAC and UAS 268 follows the advice in [RFC3960] with respect to interactions with 269 early media. 271 Although non-SDP early media is for future study, it is envisioned 272 that this document would clarify the behavioral interactions between 273 non-SDPearly media and other types of early media. 275 4. Current common coping mechanisms for early media 277 A number of mechanisms exist for coping with early media. They all 278 rely, generally, on 'fixing' the early media problem by 'breaking' 279 the behaviors specified in other RFCs (or at least bending the spirit 280 of them to some extent): 281 1. Proxy SDP stripping - If a proxy detects that it is about to fork 282 an INVITE, it keeps track of this fact in its processing state 283 for the INVITE transaction. Any SDP answers in provisional 284 responses are stripped before being forwarded upstream. The SDP 285 answer may be added into a 200 response upstream from last 286 provisional SDP answer received if SDP is not already present in 287 the message to ensure that the offer/answer exchange is 288 completed. This effectively turns off early media. 289 2. Proxy SDP weighting - If a proxy detects that it had previously 290 forked the INVITE to which it is now receiving a provisional 291 response it may allow a particular provisional response to retain 292 the SDP answer in the message body and strip other SDP answers in 293 provisional responses per the proxy SDP stripping methodology. 294 This mechanism is used to favor SDP that the proxy may have some 295 control over. For instance, if the proxy knows that one forked 296 leg is to a media server streaming CRBT media to the originator, 297 it may allow that SDP answer to flow back, but block all other 298 SDP answers on other legs in the meantime. 300 3. Client detection of forking - Clients may start out playing local 301 ringback to the originator until the first SDP answer is 302 received. When the first SDP answer is received, the client may 303 switch to playing the media for that SDP answer. However, upon 304 detecting that the INVITE forked through subsequent provisionals 305 being received (reception of two or more distinct SDP answers or 306 [RFC3261] 'TO' header tags) the client may irrevocably return to 307 playing local ringback. At this point, the client is likely to 308 continue to playing local ringback until the call is answered, or 309 an error condition arises. 310 4. Client slow-start - Clients may wish to simply not include any 311 SDP in their initial INVITE message in order to accumulate a set 312 of SDP offers from their prospective terminating endpoints. Such 313 INVITEs are known as 'slow-start' INVITEs, because the SDP offer/ 314 answer exchange gets off to a 'slow start'. These may also be 315 used in protocol interworkings (notably H.323 to SIP) with no 316 intent as to managing early media. The client can either use 317 PRACK or UPDATE to respond to offers received in provisional 318 responses at the point in time the originating client wishes to 319 stage early media streams. 321 4.1. Problems with current coping mechanisms 323 4.1.1. Proxy-side coping mechanisms 325 4.1.1.1. Proxy SDP stripping 327 This is a very common mechanism, perhaps second only to the two 328 client mechansims mentioned above. When a proxy employs this 329 mechanism, it remembers when forking has occurred and removes any SDP 330 in provisional responses as a result. This means that if the 331 originator supports reliable provisional responses (100rel) as 332 defined in [RFC3262], that this option tag must be removed by the 333 proxy before forwarding the INVITE to each forked leg. Otherwise it 334 may be forced to potentially handle SDP in negotiation within a PRACK 335 transaction for the originating client with little or no information 336 about the originating client's capabilities. In the case that the 337 originator requires support for PRACK the proxy may have to fail the 338 call setup, handle very complex negotiation signaling in the case 339 that the call forks, or simply not fork the call. 341 Additionally, this mechanism also completely breaks any early media 342 services or announcements, some of which may be critical to proper 343 completion or billing disposition of the call upon answer. For 344 instance, the call may fork to a PSTN gateway that is trying to tell 345 the originator that it is about to bill them $500 to complete the 346 current call. With proxy SDP stripping this announcement would not 347 be heard by the originator. 349 4.1.1.2. Proxy SDP weighting 351 Proxy weighting of SDP can be useful in situations where the proxy 352 knows what is going on with the call routing for each leg. However, 353 lack of information as to why downstream elements are sending SDP in 354 provisional responses can cause proxies to weight the SDP 355 incorrectly. Further, if multiple proxies are traversed, the SDP 356 that is accepted for delivery to the originating UA may not be the 357 SDP selected at any given proxy. There is no indication to 358 downstream network clients as to what has happened with their SDP as 359 it traverses proxys back upstream towards the originator. Likewise, 360 the $500 warning announcement presented in the previous section may 361 or may not be heard. 363 4.1.2. Client-side coping mechanisms 365 4.1.2.1. Client detection of forking 367 This mechanism is where a client may play audible ringback while 368 waiting for an initial provisonal or final response to an INVITE 369 message it originated. When the first provisional response with SDP 370 is received, it may switch from playing audible ringback to rendering 371 the media stream defined in the SDP. If a subsequent provisional 372 response is received from a different endpoint (identifiable by a 373 different to-tag in the 'TO' header as defined in [RFC3261]) it stops 374 rendering any early media media packets it is receiving and typically 375 returns to audible ringback. Upon receiving a non-3xx final 376 response, the UA switches media appropriately to the response. For 377 3xx responses, the client continues to play audible ringback if that 378 was what is currently being rendered, or switches (typically) to 379 ringback again if it was rendering media packets. This mechanism is 380 used by client devices for a number of reasons: 382 o What gets presented to the end user is predictable. 383 o Does not rely on the set of proxies handling any given INVITE 384 request to do anything special. 385 o Is easy to implement. 387 The problem with this approach is that it often causes early media to 388 break altogether. If a leg that the call was forked to is awaiting 389 media from the originating client (such as prompting for digit 390 collection, like a credit card number or extension) that leg's early 391 media may fail due to other provisional responses sent to the 392 originator by other call legs. 394 Network and terminating services that utilize early media are likely 395 to fail or work erratically (due to race conditions between messages) 396 when an originating client behaves in this manner. What's worse, is 397 that there's no indication as to what the originating client is doing 398 to the downstream network elements. 400 Due to the client switching to locally generated playback, and 401 ignoring early media RTP streams prior to receiving a final response 402 to the INVITE, there is the opportunity for clipping to occur is the 403 SIP signaling path latentcy lags the media path latentcy. 405 4.1.2.2. Client slow-start INVITE 407 Slow-start INVITEs circumvent the problem of having to immediately 408 render media packets from an unknown set of terminating endpoints by 409 not giving those endpoints anywhere to send the media to. However, 410 this mechanism has some serious drawbacks, most notably guaranteed 411 clipping (potentially severe if the SDP offer is not received from 412 the other end until a 200 response is received) and the potential for 413 an increased number of messaging round-trips to setup a call. 415 Due to some service designs and protocol interworking slow-start 416 INVITEs will continue to be seen, but due to the clipping problems 417 associated with slow-start INVITEs this coping mechanism is 418 considered to be incomplete. 420 4.1.2.3. Client Usage of Gateway Model 422 Clients typically do not use the [RFC3960] gateway model because of 423 the limitations presented in the RFC around early media and forking 424 with the gateway model in section 3.1. 426 4.1.2.4. Client Usage of Application Server Model 428 The application server model defined in [RFC3960], along with 429 [RFC3959] define an improved mechanism over the gateway model in that 430 early media is negotiated separately from regular media to reduce 431 media clipping issues. However, there still are problems with UASs 432 that generate early media packets upon receiving the SDP offer from 433 the UAC that cannot currently be distinguished from other media in 434 all situations, and the UAC has no feedback from the various UASs 435 that are generating early media as to which ones are of importance or 436 otherwise. UASs typically do adhere to the request in [RFC3960] 437 section 4.1 that they not generate superfluous early media streams to 438 assist the UAC with early media rendering. 440 5. Requirements 442 The following requirements are considered to be the starting point in 443 more formally discussing improvements to SIP for early media 444 interactions: 445 R1: Deprecation of forking within the [RFC3261] is considered to be 446 out-of-scope of the possible solutions (sorry Dean). 447 R2: Deprecation of early media from within [RFC3261] is considered 448 to be out-of-scope of the possible solutions (sorry again, 449 Dean). 450 R3: SIP UAs that are attempting to create a new SIP dialog using the 451 INVITE method should no longer be obligated to blindly render 452 media packets that are delivered to them as a result of an SDP 453 offer sent in the INVITE. 454 R4: A mechanism should exist by which an originating SIP UA can 455 signal to a downstream SIP endpoint that it is now willing to 456 accept media packets. 457 R5: A mechanism should exist by which a terminating SIP UA can 458 signal to an upstream SIP endpoint what type of early media (if 459 known) it wishes to present to the originating UA, if it 460 requires one-way, or two-way media flows, and the relative 461 importance of the early media. 462 R6: Universal backwards-compatability is a secondary goal. Where 463 possible, backwards-compatability with clients that do not 464 implement recommendations in this draft should be preserved. 465 R7: The mechanism must be able to deal with recursive forking 466 scenarios. This is where an INVITE passes two or more proxies 467 that both choose to fork the request to two or more endpoints at 468 each proxy in parallel. 469 R8: The mechanism must not require exchange of packets on the media 470 path to identify or coordinate early media streams as this may 471 not interoperate with common network media gating mechanisms. 473 5.1. Deprecation of forking 475 Deprecation of forking from SIP [RFC3261] is considered to be out of 476 scope. This is due to the heavy deployment of forking in existing 477 implementations for key routing services. Changes of this nature are 478 considered by the author (and others) to be of too large a scope 479 relative to the problem at hand and are subsequently excluded from 480 this draft in favor of searching for less radical solutions. 482 5.2. Deprecation of early media 484 Deprecation of early media from SIP [RFC3261] is considered to be out 485 of scope. Early media is required in order to handle certain PSTN 486 interactions as defined in RFC-3398 [RFC3398] and elsewhere. In 487 addition, the desire to provide announcements and other media prior 488 to the terminating party answering the call is considered desirable 489 and must therefore use some form of "pre-answer" media (currently 490 known as early media). 492 5.3. Originating UA's to render early media 494 Currently, section 5.1 of the offer/answer model [RFC3264] states 495 that the offerer in an SDP offer/answer exchange must be prepared to 496 receive media from media streams described in the offer as being 497 'recvonly' or 'sendrecv'. Further, in section 6.1 of [RFC3264] it 498 states that the answerer in an SDP offer/answer exchange may 499 immediately send media to media streams that are described in the 500 answer as being 'sendrecv' (note: [RFC3264] does not explicitly state 501 as much, but it is assumed that media streams that are 'sendonly' in 502 the SDP answer can also have media immediately sent to them by the 503 SDP offerer). 505 These statements, taken together, create an obligation upon the 506 originating UA to render any early media sent to them by anyone to 507 whom their SDP offer was delivered (unless the media stream was 508 defined to be 'sendonly' or 'inactive'). This is useful in resolving 509 the PSTN interactions in [RFC3398], especially as noted in the 510 example call flows and ACM message processing in section 7 of that 511 document. This obligation on the part of the originating UA has 512 subsequently been used in the absence of actual PSTN interworking to 513 provide services that mimic the PSTN network (such as providing far- 514 end announcements), or provide other services such as colorful 515 ringback tones (CRBT) in which media is streamed to the originator 516 while the terminator is being located/alerted. 518 The argument can, and has, been made that simply because a service 519 exists in the PSTN world, that it does not mean that it must exist 520 within SIP. However, given the prevalence of services that utilize 521 early media, and the number of RFCs that talk about dealing with 522 various aspects of early media, this particular train appears to have 523 long ago left the station. It is not the intent of this document to 524 pass judgement upon these services, but to find a way to cope with 525 them in a more robust manner than currently is available. 527 The obvious downside to this property of [RFC3264] is that while the 528 offerer may have limited control over the delivery of their SDP 529 offer, they have an obligation to render anything sent to them. This 530 severely restricts the policies that the offerer (as the originator) 531 may use to decide to render early media, which needs to be augmented. 533 5.4. Downstream signaling of acceptance 535 An INVITE with SDP should serve two simple purposes: establish the 536 path by which all signaling shall follow to/from the originator and 537 the set of terminating clients, and to let each terminating party 538 know what sort of communications the originator can and will engage 539 in. Currently, SDP offers also imply tacit acceptance of any and all 540 media that might be generated in the reverse path upstream towards 541 the originator. This should not necessarily always be the case, and 542 a mechanism whereby the originator may assert that it is further 543 ready to receive media packets is needed. The originator may wish to 544 imply a combination of early and final media acceptance or denial in 545 order to prevent unruly early media interactions and clipping of 546 final media. 548 5.5. Upstream signaling of importance 550 A provisional response from a terminating party currently implies 551 that the terminating party is listening to the SIP signaling it is 552 receiving, and (if an SDP answer is present) the type of 553 communications that the terminator wishes to engage in (if any). 554 What is missing is a way for the terminating party to tell upstream 555 entities what sort of demands it has upon the originator for 556 rendering of its early media, and the relative importance associated 557 with the media that it generates towards the originator. This helps 558 the originator decide what is important and what is not when choosing 559 which media stream it should render (if it wishes to, see 560 Section 4.1.2.1). 562 5.6. Universal backward-compatibility 564 There are scenarios in which there is no way to cope appropriately 565 with early media streams. An example would be a call that forks to 566 an ISUP PSTN gateway as defined in [RFC3398] that is ignorant of the 567 content of early media it is generating. There is no reliable 568 indication in ISUP CPG or ACM messages as to what the other end might 569 be doing for early media. It is possible that a cause code is 570 present in the CPG in some ISUP to legacy platform interworking 571 scenarios, but these are not present generally in ISUP signaling 572 flows, and therefore cannot be relied upon. Mechansims to deal with 573 these types of devices is currently for future study and not explored 574 further here at this time. 576 5.7. Recursive forking 578 The mechanism should be able to deal with recursive forking 579 scenarios. This would be where two or more independent proxies fork 580 a given INVITE request from an originating client. In this case, the 581 proxies are normally not coordinated in their operations. As a 582 result, the mechanism proposed should be robust enough to allow for 583 both end-to-middle and end-to-end negotiation of early media. 585 5.8. Media Gating 587 In many network environments, it is common for the media flow to be 588 'gated' in some way. Gating refers to a practice whereby an element 589 in the network is examining the signaling (SIP and SDP) being 590 exchanged by UAs and is sending instructions to a middlebox as to 591 when media packets are authorized to flow between UAs. This gating 592 behavior is typically used to prevent theft of service. As a result 593 of this gating behavior, any mechanism used to identify or coordinate 594 early media should not employ media packet exchanges. It is 595 allowable for early media itself to be marked as such in the media 596 packets, however, because gating behavior does not interact 597 negatively with such a mechanism. Operations that require early 598 media packet behavior by the UAC may fail in the presence of gating. 600 6. Recommendations 602 The following sections include recommendations that create a 603 framework that is capable of both identifying/prioritizing the type 604 of early media being presented to the originator, and giving the 605 originating client a means by which it can control the order in which 606 early media flows are presented to it. 608 6.1. Early Media Classification and Prioritization 610 6.1.1. Overview 612 Regardless of the mechanism that is used to control the presentation 613 of early media, if at any point more than one endpoint is attempting 614 to stream early media to the originator a few problems arise: 616 o Nobody upstream of the device attempting to stream early media to 617 the originator is aware of what exactly it is that the early media 618 generator is generating. Is it advertising? Is it an important 619 message? Who knows. This is important not only for the 620 originating client (see Section 4.1.2.1), but proxies as well 621 since they may be employing a weighting mechanism as described in 622 Section 4.1.1.2. 623 o The device generating the early media may have no idea how many 624 other devices that are peer to it or downstream from it are also 625 trying to generate early media. Again, this is important if the 626 client is using the client-side detection of forking mechanism 627 defined in Section 4.1.2.1. 628 o Multiple streams may be included in the offer, not all of which 629 are suitable or intended for early media. For instance, an offer 630 may include video and audio streams. Early media may only be 631 streamed to the audio port during call setup. Another example 632 would be the inclusion of RTP and SRTP streams where only the RTP 633 stream is intended for early media. Therefore, the UAC may not 634 wish to apply early-media coping mechanisms to all streams 635 offered. 637 In order to rectify this situation, proper classification of the 638 possible early media to be sent after completion of the SDP exchange 639 is needed and a specific linkage of that classification to particular 640 streams is highly desirable. This can be handled either by inclusion 641 of SIP headers in the message carrying SDP sent towards the 642 originator or by inclusion in the SDP itself. If the classification 643 is handled in the SDP itself, this limits the ability of 644 intermediaries to use this information to update the SDP as the 645 message body may covered by an integrity protection mechanism or may 646 be otherwise unavailable (for example, the SDP could be encrypted). 647 If the classification is handled in the SIP headers, then it may be 648 unclear as to which SDP stream the classification applies to. If 649 classification is handled via a SIP header (previous revisions of 650 this document referred to an 'Early-Media-Class' header), then it is 651 recommended that the SIP header only apply to SDP covered by an 652 Early-Session content disposition as defined in [RFC3959]. This 653 allows the UAC to clearly understand which streams the classification 654 applies to. In either case, via SIP or SDP, upon answer of the 655 INVITE, all processing of media streams and SDP should revert to 656 [RFC3261]RFC-3261 rules as the call is answered and no media from 657 this point on should be considered 'early'. 659 6.1.1.1. Early-Media Classifications 661 The following list is given to show a possible set of common early- 662 media classifications. Each class is given in increasing order of 663 importance. 665 1. RFC-3264 - The default behaivor defined in RFC-3264 is requested. 666 2. Advertisement - A non-critical advertisement. 667 3. Warning - A non-critical announcement. 668 4. Two-way - The endpoint presenting early media wishes to establish 669 a two-way early media session before completing the call. 670 5. Critical - A critical announcement, such as: "We're about to bill 671 you for $10k". 672 6. Unknown - The nature of the early media being presented to the 673 originator is unknown (such as from a PSTN gateway receiving a 674 generic announcement.) 676 Early media classified as "Unknown" must unfortunately be considered 677 of the highest importance: there's no indication given that qualifies 678 it to be of lower importance. It is recommended that unclassified 679 early media would be treated as RFC-3264. This is to prevent network 680 elements that do not classify their early media from overriding 681 elements that are more forthcoming. An additional q-value, such as 682 that defined in section 20.10 of [RFC3261], can be used to break ties 683 between classifications. 685 6.2. Early Media Flow Negotiation 687 The following sections take the requirements from Section 5 and tries 688 to create a mechanism that can satisfy them. This mechanism is built 689 along similar lines as the SIP preconditions framework [RFC3312]. 691 6.2.1. Overview 693 A simple mechanism is introduced that tells terminators what the 694 originator expects to have happen with respect to early media. This 695 information may also be of use to intermediate nodes that also wish 696 to generate early media. The mechanism differs from the SDP 697 [RFC2327] 'a=recvonly', 'a=sendonly', 'a=sendrecv', and 'a=inactive' 698 attributes in that the final media flow mode can be negotiated and 699 ready upon answer without further messaging, and from the 700 preconditions [RFC3959] SDP attributes in that QoS can be negotiated 701 separately as well. 703 6.2.2. SDP parameters 705 The following media-level parameters are defined: 706 early-media-flow-status = "a=emflow:" direction-tag [ COMMA rtp- 707 ssrc-value ] 708 direction-tag = ("none" | "send" | "recv" | "sendrecv") 709 rtp-ssrc-value = 1 * 8hex 711 The early-media-flow-status 'a=emflow' denotes two things: 713 o The current state of the early media from the perspective of the 714 originating party of the call as specified by the direction-tag. 715 o The RTP SSRC for a given early media stream (as defined in section 716 8 of [RFC3550]) to facilitate correlation of RTP packets with a 717 particular early media session. It is possible for this value to 718 be the same for two different early media stream. The intent of 719 this is to give the UAC a starting point to work from. 720 ISSUE: What should the UAC do if it sees that the RTP SSRC in 721 two or more early media flows collides? 722 ISSUE: How stable are RTP SSRC values during call setup? 724 It is expected that the directionality indicators defined in 725 [RFC2327] as 'a=sendrecv', 'a=sendonly', 'a=recvonly', and 726 'a=inactive' are otherwise unaffected. Likewise, preconditions, as 727 defined in [RFC3312] are likewise unaffected. The emflow values may 728 be changed in subsequent offer/answer exchanges to allow the 729 originator to properly stage multiple early media streams according 730 to the Early-Media-Class header values. For example, an originator 731 may specify 'a=emflow:none' initially to suppress all early media 732 flows, and then send an UPDATE with a new SDP offer to an endpoint 733 the originator received an early media indication from with 734 'a=emflow:recv' to denote that the originator is now willing to 735 receive early media. 737 Regardless of the value of this parameter, both endpoints may 738 immediately begin exchanging media packets upon answer according to 739 [RFC3261], [RFC3264] and [RFC2327].Intermediate proxies should honor 740 this indication, and adjust their behavior accordingly, potentally 741 causing them to divert from their normal early media coping 742 mechanisms. 744 6.2.3. Usage of emflow with offer/answer 746 6.2.3.1. Meaning of a=emflow:none 748 If the emflow value of 'none' is set in an the SDP offer, it 749 indicates that the endpoint generating the offer will not accept 750 early media and that anyone accepting this SDP offer MUST NOT send 751 early media. If the emflow value in the SDP offer was 'none', then 752 the emflow value in the SDP answer MUST be set to 'none' as well. 754 If the emflow value of 'none' is set in an SDP answer, it indicates 755 that the endpoint generating the answer will not generate early 756 media. The SDP offeror can take this indication to mean that they 757 should not expect early media packets from this endpoint per 758 [RFC3264], and that any received prior to answer from this source MAY 759 be discarded. 761 6.2.3.2. Meaning of a=emflow:send 763 If the emflow value of 'send' is set in an the SDP offer, it 764 indicates that the endpoint generating the offer may send early media 765 packets, but will not accept early media. Anyone accepting this SDP 766 offer MUST NOT send early media, but SHOULD process received early 767 media packets if it is appropriate to the device receiving packets to 768 do so. If the emflow value in the SDP offer was 'send', then the 769 emflow value in the SDP answer MUST be set to 'none' or 'recv' 770 depending on whether the application intends to process the early 771 media packets that the offeror may send to it. 773 If the emflow value of 'send' is set in an SDP answer, it indicates 774 that the endpoint generating the answer may generate early media but 775 will not process any sent to it. Any early media sent to it per 777 [RFC3264] MAY be discarded. The SDP offeror can take this indication 778 to mean that they should expect early media packets from this 779 endpoint and behave appropriately. 781 6.2.3.3. Meaning of a=emflow:recv 783 If the emflow value of 'recv' is set in an the SDP offer, it 784 indicates that the endpoint generating the offer may be sent early 785 media packets, but will not generate early media. Anyone accepting 786 this SDP offer MAY send early media, but SHOULD NOT expect to receive 787 early media from the SDP offeror, and that any media packets received 788 prior to answer from this the offeror may safely be discarded. If 789 the emflow value in the SDP offer was 'recv', then the emflow value 790 in the SDP answer MUST be set to 'none' or 'send' depending on 791 whether the application intends to send the early media packets to 792 the offeror or not. 794 If the emflow value of 'recv' is set in an SDP answer, it indicates 795 that the endpoint generating the answer will accept early media but 796 will not generate any.The SDP offeror can take this indication to 797 mean that they should not expect early media packets from this 798 endpoint and may safely discard any received prior to answer. 800 6.2.3.4. Meaning of a=emflow:sendrecv 802 If the emflow value of 'sendrecv' is set in an the SDP offer, it 803 indicates that the endpoint generating the offer may send and receive 804 early media packets. Anyone accepting this SDP offer MAY send early 805 media, and SHOULD process received early media packets if it is 806 appropriate to the device receiving packets to do so. If the emflow 807 value in the SDP offer was 'sendrecv', then the emflow value in the 808 SDP answer MAY be set to any value. The value set in the SDP answer 809 depends on if the endpoint answering the SDP offer intends to send 810 and/or receive early media packets. 812 If the emflow value of 'sendrecv' is set in an SDP answer, it 813 indicates that the endpoint generating the answer may generate and 814 receive early media and behave appropriately. 816 6.2.3.5. Usage of RTP-SSRC-Value 818 The RTP-SSRC value is useful in helping endpoints correlate incoming 819 RTP packets with SDP offer/answer exchanges. The value used in this 820 tag is the SSRC value used in the header portion of an RTP packet as 821 defined in [RFC3550]. The SSRC value in an RTP packet is used to 822 define a means for an endpoint to synchronize RTP packets sent from a 823 particular source. As such, the SSRC value must be unique for a 824 given RTP stream. 826 The worst-case expectation for uniqueness of an SSRC value during the 827 offer/answer SDP phase of RTP resource allocation is given in Section 828 8 of [RFC3550] as 10^(-4) if there are 1000 different RTP streams 829 being offered. As the number of RTP streams typically used in a call 830 setup, even with significant forking involved, is likely to be O(10) 831 or fewer, the likelihood of each RTP stream getting a unique SSRC 832 number early on is good. If a collision is detected, then [RFC3550] 833 defines a mechanism for detecting this and reselecting a unique SSRC 834 value. This re-selection does not require another SDP exchange 835 today, but if necessary, an SDP exchange could be initiated through a 836 target refresh of the INVITE dialog to update the SDP offer and/or 837 answer with the update SSRC value in the emflow parameter. 839 6.2.4. Option tag for emflow 841 The option tag "emflow" is defined for use in the Require and 842 Supported header fields [RFC3261]. An offerer MAY include this tag 843 in a Require header if they wish to ensure that any endpoint reached 844 supports this extension (typically when 'a=emflow:' is not set to 845 'sendrecv'). Then if the party generating an SDP offer or answer 846 supports this extension it MUST include this tag in a Supported 847 header if it is not already in a Require header of any message 848 containing SDP. This allows the other party or parties involved in 849 the signaling flow to know that the other end is processing their 850 emflow values. 852 6.2.5. Example 854 The following figures show a simple offer/answer exchange in which 855 the UAC does not wish to receive early media automatically. The UAS 856 then answers indicating that it has a warning announcement it would 857 like to play as early media. The UAC then updates the emflow value 858 to allow the warning announcement to proceed. 860 v=0 861 o=alice 2890844526 2890844526 IN IP4 uac.anywhere.com 862 s= 863 c=IN IP4 uac.example.com 864 t=0 0 865 m=audio 49170 RTP/AVP 0 866 a=rtpmap:0 PCMU/8000 867 a=emflow: none, 1e4f381 869 Figure 1: An SDP offer with no early media allowed and SSRC 1e4f381. 871 ... 872 Early-Media-Class: Warning; q=1.0 874 v=0 875 o=bob 2890844730 2890844730 IN IP4 uas.example.com 876 s= 877 c=IN IP4 uas.example.com 878 t=0 0 879 m=audio 49920 RTP/AVP 0 880 a=rtpmap:0 PCMU/8000 881 a=emflow: none, 23a73c01 883 Figure 2: A SIP early media answer to the offer with SSRC of 884 23a73c01. 886 v=0 887 o=alice 2890844526 2890844526 IN IP4 uac.anywhere.com 888 s= 889 c=IN IP4 uac.example.com 890 t=0 0 891 m=audio 49170 RTP/AVP 0 892 a=rtpmap:0 PCMU/8000 893 a=emflow: recv, 1e4f381 895 Figure 3: An SDP offer with early media allowed towards the UAC. 897 v=0 898 o=bob 2890844730 2890844730 IN IP4 uas.example.com 899 s= 900 c=IN IP4 uas.example.com 901 t=0 0 902 m=audio 49920 RTP/AVP 0 903 a=rtpmap:0 PCMU/8000 904 a=emflow: send, 23a73c01 906 Figure 4: An SDP answer to the offer acknowledging that early media 907 will be sent using RTP SSRC 23a73c01. 909 6.3. Early Media and SRTP 911 One of the challenges in dealing with SRTP is the initial key 912 exchanges required to support it. The draft 913 [I-D.wing-rtpsec-keying-eval] discusses a number of keying 914 mechanisms, concentrating on their interaction with SIP. Given the 915 amount of effort likely involved to establish a secure media flow, it 916 is undesirable to require that early media be secure. After all, an 917 attacker can likely surmise from a 180 Ringing response to an INVITE 918 that the originator is probably hearing ringback. It is the 919 conversation that typically seeks to be protected, therefore securing 920 early media in many situations is likely wasteful. 922 Additionally, there may be issues where the early media coping 923 mechanisms mentioned in Section 4 are employed that prevents SRTP 924 keying exchanges from taking place in a timely manner. This can 925 cause a number of potentially poor outcomes, especially when SDP is 926 stripped or otherwise manipulated during call setup by a network 927 element. 929 Finally, network elements that wish to generate early media typically 930 serve many endpoints simultaneously. This means that they do not 931 have the computational power available to support key exchange and 932 encryption without an undesirable reduction in the amount of traffic 933 that they can handle. Therefore, it is recommended that if a client 934 is offering an SRTP stream, that they also offer a regular RTP stream 935 as well for purposes of early media. This gives the network a 936 separate playground to work with for purposes of establishing early 937 media to the UAC. If the SDP for the early media stream were 938 separated in the SDP offer (possibly using [RFC3959]) it is 939 conceivable that network elements that employ the mechanisms 940 described in Section 4 would simply leave the SRTP portion of a UAC's 941 offer alone, thereby improving the observed behavior of SRTP and 942 early media by the user and SIP network administrator. 944 ISSUE: The interaction between the mechanisms outlined in this 945 draft and SRTP clearly warrants more investigation. 947 7. Security Considerations 949 This document is a work in progress. Security considerations will be 950 added as various recommendations become more concrete. 952 8. IANA Considerations 954 This document defines the SDP media type of "emflow" and the 955 direction-tag values of "none", "send", "recv", and "sendrecv" which 956 will require IANA registration. 958 9. References 959 9.1. Normative References 961 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 962 Requirement Levels", BCP 14, RFC 2119, March 1997. 964 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 965 Specifications: ABNF", RFC 2234, November 1997. 967 9.2. Informational References 969 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 970 Protocol", RFC 2327, April 1998. 972 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 973 A., Peterson, J., Sparks, R., Handley, M., and E. 974 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 975 June 2002. 977 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 978 Provisional Responses in Session Initiation Protocol 979 (SIP)", RFC 3262, June 2002. 981 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 982 with Session Description Protocol (SDP)", RFC 3264, 983 June 2002. 985 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 986 "Integration of Resource Management and Session Initiation 987 Protocol (SIP)", RFC 3312, October 2002. 989 [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, 990 "Integrated Services Digital Network (ISDN) User Part 991 (ISUP) to Session Initiation Protocol (SIP) Mapping", 992 RFC 3398, December 2002. 994 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 995 Jacobson, "RTP: A Transport Protocol for Real-Time 996 Applications", STD 64, RFC 3550, July 2003. 998 [RFC3959] Camarillo, G., "The Early Session Disposition Type for the 999 Session Initiation Protocol (SIP)", RFC 3959, 1000 December 2004. 1002 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1003 Tone Generation in the Session Initiation Protocol (SIP)", 1004 RFC 3960, December 2004. 1006 [I-D.wing-rtpsec-keying-eval] 1007 Audet, F. and D. Wing, "Evaluation of SRTP Keying with 1008 SIP", draft-wing-rtpsec-keying-eval-01 (work in progress), 1009 June 2006. 1011 Author's Address 1013 Brian Stucker 1014 Nortel 1015 2201 Lakeside 1016 Richardson, TX 75082 1017 US 1019 Phone: +1 972 685 7724 1020 Email: bstucker@nortel.com 1021 URI: http://www.nortel.com/ 1023 Full Copyright Statement 1025 Copyright (C) The Internet Society (2006). 1027 This document is subject to the rights, licenses and restrictions 1028 contained in BCP 78, and except as set forth therein, the authors 1029 retain all their rights. 1031 This document and the information contained herein are provided on an 1032 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1033 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1034 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1035 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1036 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1037 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1039 Intellectual Property 1041 The IETF takes no position regarding the validity or scope of any 1042 Intellectual Property Rights or other rights that might be claimed to 1043 pertain to the implementation or use of the technology described in 1044 this document or the extent to which any license under such rights 1045 might or might not be available; nor does it represent that it has 1046 made any independent effort to identify any such rights. Information 1047 on the procedures with respect to rights in RFC documents can be 1048 found in BCP 78 and BCP 79. 1050 Copies of IPR disclosures made to the IETF Secretariat and any 1051 assurances of licenses to be made available, or the result of an 1052 attempt made to obtain a general license or permission for the use of 1053 such proprietary rights by implementers or users of this 1054 specification can be obtained from the IETF on-line IPR repository at 1055 http://www.ietf.org/ipr. 1057 The IETF invites any interested party to bring to its attention any 1058 copyrights, patents or patent applications, or other proprietary 1059 rights that may cover technology that may be required to implement 1060 this standard. Please address the information to the IETF at 1061 ietf-ipr@ietf.org. 1063 Acknowledgment 1065 Funding for the RFC Editor function is provided by the IETF 1066 Administrative Support Activity (IASA).