idnits 2.17.1 draft-ejzak-sipping-p-em-auth-04.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 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 647. 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 == Line 448 has weird spacing: '... where pro...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 11, 2007) is 6164 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4234 (ref. '5') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4566 (ref. '7') (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group Richard Ejzak 3 INTERNET-DRAFT Alcatel-Lucent 4 Intended status: Informational June 11, 2007 5 Expires: December 12, 2007 7 Private Header (P-Header) Extension to the Session Initiation 8 Protocol (SIP) for Authorization of Early Media 9 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 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference 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/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document describes a private Session Initiation Protocol (SIP) 37 header field (P-header) to be used by the European 38 Telecommunications Standards Institute (ETSI) Telecommunications and 39 Internet converged Services and Protocols for Advanced Networks 40 (TISPAN) for the purpose of authorizing early media flows in Third 41 Generation Partnership Project (3GPP) IP Multimedia Subsystems 42 (IMS). This header field is useful in any SIP network that is 43 interconnected with other SIP networks and needs to control the flow 44 of media in the early dialog state. 46 Table of Contents 48 1. Introduction ................................................. 2 49 2. Applicability Statement....................................... 3 50 3. Conventions and Acronyms...................................... 3 51 4. Background on early media authorization....................... 4 52 4.1. Backward early media ..................................... 5 53 4.2. Forward early media....................................... 6 54 5. Applicability of RFC 3959 and RFC 3960........................ 6 55 6. Overview of Operation......................................... 7 56 7. Limitations of the P-Early-Media header field................. 8 57 8. The P-Early-Media header field................................ 8 58 8.1. Procedures at the User Agent Client.......................10 59 8.2. Procedures at the User Agent Server.......................11 60 8.3. Procedures at the proxy...................................11 61 9. Formal syntax.................................................11 62 10. Security Considerations......................................12 63 11. IANA Considerations..........................................12 64 11.1. Registration of the "P-Early-Media" SIP header field.....12 65 12. Acknowledgements.............................................13 66 13. References...................................................13 67 13.1. Normative References.....................................13 68 13.2. Informative References...................................14 69 14. Authors' Addresses ..........................................14 70 15. IPR Notice...................................................14 71 16. Copyright Notice.............................................15 73 1. Introduction 75 This document defines the use of the P-Early-Media header field for 76 use within SIP [1] messages in certain SIP networks to authorize the 77 cut-through of backward and/or forward early media when permitted by 78 the early media policies of the networks involved. The P-Early-Media 79 header field is intended for use in a SIP network, such as a 3GPP 80 IMS [13][14], that has the following characteristics: its early 81 media policy prohibits the exchange of early media between end 82 users; it is interconnected with other SIP networks that have 83 unknown, untrusted or different policies regarding early media; and 84 it has the capability to "gate" (enable/disable) the flow of early 85 media to/from user equipment. 87 Within an isolated SIP network it is possible to gate early media 88 associated with all endpoints within the network to enforce a 89 desired early media policy among network endpoints. However, when a 90 SIP network is interconnected with other SIP networks, only the 91 boundary node connected to the external network can determine which 92 early media policy to apply to a session established between 93 endpoints on different sides of the boundary. The P-Early-Media 94 header field provides a means for this boundary node to communicate 95 this early media policy decision to other nodes within the network. 97 2. Applicability Statement 99 The use of this extension is only applicable inside a 'Trust Domain' 100 as defined in RFC 3325 [6]. Nodes in such a Trust Domain are 101 explicitly trusted by its users and end-systems to authorize early 102 media requests only when allowed by early media policy within the 103 Trust Domain. 105 This document does NOT offer a general early media authorization 106 model suitable for inter-domain use or use in the Internet at large. 107 Furthermore, since the early media requests are not 108 cryptographically certified, they are subject to forgery, replay, 109 and falsification in any architecture that does not meet the 110 requirements of the Trust Domain. 112 An early media request also lacks an indication of who specifically 113 is making or modifying the request, and so it must be assumed that 114 the Trust Domain is making the request. Therefore, the information 115 is only meaningful when securely received from a node known to be a 116 member of the Trust Domain. 118 Although this extension can be used with parallel forking, it does 119 not improve on the known problems with early media and parallel 120 forking, as described in RFC 3960 [4]. 122 Despite these limitations, there are sufficiently useful specialized 123 deployments that meet the assumptions described above, and can 124 accept the limitations that result, to warrant publication of this 125 mechanism. An example deployment would be a closed network that 126 emulates a traditional circuit switched telephone network. 128 3. Conventions and Acronyms 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC2119 [2]. 134 The following acronyms are used in this document: 136 3GPP - the Third Generation Partnership Project 137 ABNF - Augmented Backus-Naur Form [5] 138 DTMF - Dual Tone Multi-Frequency 139 ETSI - European Telecommunications Standards Institute 140 IMS - Internet Protocol Multimedia Subsystem [13][14] 141 MIME - Multipurpose Internet Mail Extensions 142 NAT - Network Address Translation 143 PSTN - Public Switched Telephone Network 144 SDP - Session Description Protocol [7] 145 SIP - Session Initiation Protocol [1] 146 TISPAN - Telecommunications and Internet converged Services and 147 Protocols for Advanced Networks 148 UA - User Agent [1] 149 UAC - User Agent Client [1] 150 UAS - User Agent Server [1] 152 4. Background on early media authorization 154 PSTN networks typically provide call progress information as 155 backward early media from the terminating switch towards the calling 156 party. PSTN networks also use forward early media from the calling 157 party towards the terminating switch under some circumstances for 158 applications such as digit collection for secondary dialing. PSTN 159 networks typically allow backward and/or forward early media since 160 they are used for the purpose of progressing the call to the answer 161 state and do not involve the exchange of data between endpoints. 163 In a SIP network, backward early media flows from the User Agent 164 Server (UAS) towards the User Agent Client (UAC). Forward early 165 media flows from the UAC towards the UAS. SIP networks by default 166 allow both forms of early media, which may carry user data, once the 167 media path is established. Early media is typically desirable with 168 a PSTN gateway as UAS, but not with SIP user equipment as UAS. 170 To prevent the exchange of user data within early media while 171 allowing early media via PSTN gateways, a SIP network may have a 172 policy to prohibit backward early media from SIP user equipment and 173 to prohibit forward media towards SIP user equipment, either of 174 which may contain user data. A SIP network containing both PSTN 175 gateways and SIP end devices, for example, can maintain such an 176 early media policy by gating "off" any early media with a SIP end 177 device acting as UAS, gating "on" early media with a SIP end device 178 acting as UAC, and gating "on" early media at each PSTN gateway. 180 Unfortunately, a SIP network interconnected with another SIP network 181 may have no means of assuring that the interconnected network is 182 implementing a compatible early media policy, thus allowing the 183 exchange of user data within early media under some circumstances. 184 For example, if a network "A" allows all early media with user 185 equipment as UAC and an interconnected network "B" allows all early 186 media with user equipment as UAS, any session established between 187 user equipment as UAC in "A" and user equipment as UAS in "B" will 188 allow bidirectional user data exchange as early media. Other 189 combinations of early media policies may also produce similar 190 undesirable results. 192 The purpose of the extension is to allow a SIP network 193 interconnected to other SIP networks with different early media 194 policies to correctly identify and enable authorized early media 195 according to its policies. 197 4.1. Backward early media 199 Backward early media in the PSTN typically comprises call progress 200 information such as ringing feedback ("ringback"), or announcements 201 regarding special handling such as forwarding. It may also include 202 requests for further information, such as a credit card number to be 203 entered as forward early media in the form of Dual Tone Multi- 204 Frequency (DTMF) tones or speech. Backward early media of this type 205 provides information to the calling party strictly for the purpose 206 of progressing the call and involves no exchange of data between end 207 users. The usual PSTN charging policy assumes that no data is 208 exchanged between users until the call has been answered. 210 A terminating SIP User Agent (UA) outside of the SIP network, on the 211 other hand, may provide any user data in a backward early media 212 stream. Thus if the network implements the usual early media 213 policy, the network equipment gating the backward early media flow 214 for the originating UA must distinguish between authorized early 215 media from a terminating SIP endpoint and unauthorized early media 216 from another SIP device outside of the network. Given the 217 assumption of a transitive trust relationship between SIP servers in 218 the network, this can be accomplished by including some information 219 in a backward SIP message that identifies the presence of authorized 220 backward early media. Since it is necessary to verify that this 221 indication comes from a trusted source, it is necessary for each 222 server on the path back to the originating UA to be able to verify 223 the trust relationship with the previous server and to remove such 224 an indication when it cannot do so. A server on the boundary to an 225 untrusted SIP network can assure that no indication of authorized 226 backward early media passes from an external UAS to a UAC within the 227 network. Thus the use of a private header field that can be 228 modified by SIP proxies is to be preferred over the use of a 229 Multipurpose Internet Mail Extensions (MIME) attachment that cannot 230 be modified in this way. 232 4.2. Forward early media 234 Forward early media is less common than backward early media in the 235 PSTN. It is typically used to collect secondary dialed digits, to 236 collect credit card numbers, or to collect other DTMF or speech 237 responses for the purpose of further directing the call. Forward 238 early media in the PSTN is always directed toward a network server 239 for the purpose of progressing a call and involves no exchange of 240 data between end users. 242 A terminating SIP UA outside of the SIP network, on the other hand, 243 may receive any user data in a forward early media stream, thus if 244 the network implements the usual early media policy, the network 245 equipment gating the forward early media flow for the originating UA 246 must distinguish between a terminating endpoint that is authorized 247 to receive forward early media, and another SIP device outside of 248 the network that is not authorized to receive forward early media 249 containing user data. This authorization can be accomplished in the 250 same manner as for backward early media by including some 251 information in a backward SIP message that identifies that the 252 terminating side is authorized to receive forward early media. 254 5. Applicability of RFC 3959 and RFC 3960 256 The private header extension defined in this document is applicable 257 to the gateway model defined in RFC 3960 [4], since the PSTN gateway 258 is the primary requestor of early media in an IMS. For the same 259 reason, neither the application server model of RFC 3960, nor the 260 early-session disposition type defined in RFC 3959 [3] is 261 applicable. 263 The gateway model of RFC 3960 [4] allows for individual networks to 264 create local policy with respect to the handling of early media, but 265 does not address the case where a network is interconnected with 266 other networks with unknown, untrusted or different early media 267 policies. Without the kind of information in the P-Early-Media 268 header field, it is not possible for the network to determine 269 whether cut-through of early media could lead to the transfer of 270 data between end-users during session establishment. 272 Thus the private header extension in this document is a natural 273 extension of the gateway model of RFC 3960 [4] that is applicable 274 within a transitive trust domain. 276 6. Overview of Operation 278 This document defines a new P-Early-Media header field for the 279 purpose of requesting and authorizing requests for backward and/or 280 forward early media. A UAC capable of recognizing the P-Early-Media 281 header field may include the header field in an INVITE request. The 282 P-Early-Media header field in an INVITE request contains the 283 "supported" parameter. 285 As members of the Trust Domain, each proxy receiving an INVITE 286 request must decide whether to insert or delete the P-Early-Media 287 header field before forwarding. 289 A UAS receiving an INVITE request can use the presence of the P- 290 Early-Media header field in the request to decide whether to request 291 early media authorization in subsequent messages towards the UAC. 292 After receiving an incoming INVITE request, the UAS requesting 293 backward and/or forward early media will include the P-Early-Media 294 header field in a message towards the UAC within the dialog, 295 including direction parameter(s) that identify for each media line 296 in the session whether the early media request is for backward 297 media, forward media, both or neither. The UAS can change its 298 request for early media by including a modified P-Early-Media header 299 field in a subsequent message towards the UAC within the dialog. 301 Each proxy in the network receiving the P-Early-Media header field 302 in a message towards the UAC has the responsibility for assuring 303 that the early media request comes from an authorized source. If a 304 P-Early-Media header field arrives from either an untrusted source, 305 a source not allowed to send backward early media, or a source not 306 allowed to receive forward early media, then the proxy may remove 307 the P-Early-Media header field or alter the direction parameter(s) 308 of the P-Early-Media header field before forwarding the message, 309 based on local policy. 311 A proxy in the network not receiving the P-Early-Media header field 312 in a message towards the UAC may insert one based on local policy. 314 If the proxy also performs gating of early media, then it uses the 315 parameter(s) of the P-Early-Media header field to decide whether to 316 open or close the gates for backward and forward early media flow(s) 317 between the UAs. The proxy performing gating of early media may 318 also add a "gated" parameter to the P-Early-Media header field 319 before forwarding the message so that other gating proxies in the 320 path can choose to leave open their gates. 322 If the UAC is a trusted server within the network (e.g., a PSTN 323 gateway), then the UAC may use the parameter(s) of the P-Early-Media 324 header field in messages received from the UAS to decide whether to 325 perform early media gating or cut-through and to decide whether or 326 not to render backward early media in preference to generating 327 ringback based on the receipt of a 180 Ringing response. 329 If the UAC is associated with user equipment, then the network will 330 have assigned a proxy the task of performing early media gating, so 331 that the parameter(s) of the P-Early-Media header field received at 332 such a UAC do not require that the UAC police the early media 333 flow(s), but they do provide additional information that the UAC may 334 use to render media. 336 The UAC and proxies in the network may also insert, delete or modify 337 the P-Early-Media header field in messages towards the UAS within 338 the dialog according to local policy, but the interpretation of the 339 header field when used in this way is a matter of local policy and 340 not defined herein. The use of direction parameter(s) in this 341 header field could be used to inform the UAS of the final early 342 media authorization status. 344 7. Limitations of the P-Early-Media header field 346 The P-Early-Media header field does not apply to any SDP with 347 Content-Disposition: early-session [3]. 349 When parallel forking occurs, there is no reliable way to correlate 350 early media authorization in a dialog with the media from the 351 corresponding endpoint, since the SDP messages do not identify the 352 RTP source address of any media stream. When a UAC or proxy 353 receives multiple early dialogs and cannot accurately identify the 354 source of each media stream, it SHOULD use the most restrictive 355 early media authorization it receives on any of the dialogs to 356 decide the policy to apply towards all received media. When early 357 media usage is desired for any reason it is advisable to disable 358 parallel forking using callerprefs [9]. 360 Although the implementation of media gating is outside the scope of 361 this extension, note that media gating must be implemented carefully 362 in the presence of NATs and protocols that aid in NAT traversal. 363 Media gating may also introduce a potential for media clipping that 364 is similar to that created during parallel forking or any other 365 feature that may disable early media, such as custom ringback. 367 8. The P-Early-Media header field 369 The P-Early-Media header field with the "supported" parameter MAY be 370 included in an INVITE request to indicate that the UAC or a proxy on 371 the path recognizes the header field. 373 A network entity MAY request the authorization of early media or 374 change a request for authorization of early media by including the 375 P-Early-Media header field in any message allowed by Table 1 within 376 the dialog towards the sender of the INVITE request. The P-Early- 377 Media header field includes one or more direction parameters where 378 each has one of the values: "sendrecv", "sendonly", "recvonly", or 379 "inactive", following the convention used for Session Description 380 Protocol (SDP) [7][8] stream directionality. Each parameter 381 applies, in order, to the media lines in the corresponding SDP 382 messages establishing session media. Unrecognized parameters SHALL 383 be silently discarded. Non-direction parameters are ignored for 384 purposes of early media authorization. If there are more direction 385 parameters than media lines, the excess SHALL be silently discarded. 386 If there are fewer direction parameters than media lines, the value 387 of the last direction parameter SHALL apply to all remaining media 388 lines. A message directed towards the UAC containing a P-Early- 389 Media header field with no recognized direction parameters SHALL NOT 390 be interpreted as an early media authorization request. 392 The parameter value "sendrecv" indicates a request for authorization 393 of early media associated with the corresponding media line, both 394 from the UAS towards the UAC and from the UAC towards the UAS (both 395 backward and forward early media). The value "sendonly" indicates a 396 request for authorization of early media from the UAS towards the 397 UAC (backward early media), and not in the other direction. The 398 value "recvonly" indicates a request for authorization of early 399 media from the UAC towards the UAS (forward early media), and not in 400 the other direction. The value "inactive" indicates either a 401 request that no early media associated with the corresponding media 402 line be authorized, or a request for revocation of authorization of 403 previously authorized early media. 405 The P-Early-Media header field in any message within a dialog 406 towards the sender of the INVITE request MAY also include the non- 407 direction parameter "gated" to indicate that a network entity on the 408 path towards the UAS is already gating the early media according to 409 the direction parameter(s). When included in the P-Early-Media 410 header field, the "gated" parameter SHALL come after all direction 411 parameters in the parameter list. 413 When receiving a message directed toward the UAC without the P- 414 Early-Media header field and no previous early media authorization 415 request has been received within the dialog, the default early media 416 authorization depends on local policy and may depend on whether the 417 header field was included in the INVITE request. After an early 418 media authorization request has been received within a dialog and a 419 subsequent message is received without the P-Early-Media header 420 field, the previous early media authorization remains unchanged. 422 The P-Early-Media header field in any message within a dialog 423 towards the UAS MAY be ignored or interpreted according to local 424 policy. 426 The P-Early-Media header field does not interact with SDP 427 offer/answer procedures in any way. Early media authorization is 428 not influenced by the state of the SDP offer/answer procedures 429 (including preconditions and directionality) and does not influence 430 the state of the SDP offer/answer procedures. The P-Early-Media 431 header field may or may not be present in messages containing SDP. 432 The most recently received early media authorization applies to the 433 corresponding media line in the session established for the dialog 434 until receipt of the 200 OK response to the INVITE request, at which 435 point all media lines in the session are implicitly authorized. 436 Early media flow in a particular direction requires that early media 437 in that direction is authorized, that media flow in that direction 438 is enabled by the SDP direction attribute for the stream, and that 439 any applicable preconditions [11] are met. Early media 440 authorization does not override the SDP direction attribute or 441 preconditions state, and the SDP direction attribute does not 442 override early media authorization. 444 Table 1 is an extension of Tables 2 and 3 in RFC 3261 [1] for the P- 445 Early-Media header field. The column "PRA" is for the PRACK method 446 [12]. The column "UPD" is for the UPDATE method [10]. 448 Header field where proxy ACK BYE CAN INV OPT REG PRA UPD 449 ________________________________________________________________ 450 P-Early-Media R amr - - - o - - o o 451 P-Early-Media 18x amr - - - o - - - - 452 P-Early-Media 2xx amr - - - - - - o o 454 Table 1: P-Early-Media Header Field 456 8.1. Procedures at the User Agent Client 458 A User Agent Client MAY include the P-Early-Media header field with 459 the "supported" parameter in an INVITE request to indicate that it 460 recognizes the header field. 462 A User Agent Client receiving a P-Early-Media header field MAY use 463 the parameter(s) of the header field to gate or cut-through early 464 media, and to decide whether to render early media from the UAS to 465 the UAC in preference to any locally generated ringback triggered by 466 a 180 Ringing response. If a proxy is providing the early media 467 gating function for the User Agent Client, then the gateway model of 468 RFC 3960 [4] for rendering of early media is applicable. A User 469 Agent Client without a proxy in the network performing early media 470 gating that receives a P-Early-Media header field SHOULD perform 471 gating or cut-through of early media according to the parameter(s) 472 of the header field. 474 8.2. Procedures at the User Agent Server 476 A User Agent Server that is requesting authorization to send or 477 receive early media MAY insert a P-Early-Media header field with 478 appropriate parameters(s) in any message allowed in table 1 towards 479 the UAC within the dialog. A User Agent Server MAY request changes 480 in early media authorization by inserting a P-Early-Media header 481 field with appropriate parameter(s) in any subsequent message 482 allowed in table 1 towards the UAC within the dialog. 484 If the P-Early-Media header field is not present in the INVITE 485 request, the User Agent Server MAY choose to suppress early media 486 authorization requests and MAY choose to execute alternate early 487 media procedures. 489 8.3. Procedures at the proxy 491 When forwarding an INVITE request, a proxy MAY add, retain or delete 492 the P-Early-Media header field, depending on local policy and the 493 trust relationship with the sender and/or receiver of the request. 495 When forwarding a message allowed in table 1 towards the UAC, a 496 proxy MAY add, modify or delete a P-Early-Media header field, 497 depending on local policy and the trust relationship with the sender 498 and/or receiver of the message. In addition, if the proxy controls 499 the gating of early media for the User Agent Client, it SHOULD use 500 the contents of the P-Early-Media header field to gate the early 501 media according to the definitions of the header field parameters 502 defined in clause 8. 504 9. Formal syntax 506 The syntax of the P-Early-Media header field is described below in 507 ABNF according to RFC 4234 [5], as an extension to the ABNF for SIP 508 in RFC 3261 [1]. Note that not all combinations of em-param 509 elements are semantically valid. 511 P-Early-Media = "P-Early-Media" HCOLON 512 [ em-param *(COMMA em-param) ] 513 em-param = "sendrecv" / "sendonly" / "recvonly" 514 / "inactive" / "gated" / "supported" / token 516 10. Security Considerations 518 The use of this extension is only applicable inside a 'Trust Domain' 519 as defined in RFC 3325 [6]. This document does NOT offer a general 520 early media authorization model suitable for inter-domain use or use 521 in the Internet at large. 523 There are no confidentiality concerns associated with the P-Early- 524 Media header field. It is desirable to maintain the integrity of 525 the direction parameters in the header field across each hop between 526 servers to avoid the potential for unauthorized use of early media. 527 It is assumed that the P-Early-Media header field is used within the 528 context of the 3GPP IMS trust domain or a similar trust domain, 529 consisting of a collection of SIP servers maintaining pair wise 530 security associations. 532 Within the trust domain of a network it is only necessary to police 533 the use of the P-Early-Media header field at the boundary to user 534 equipment served by the network and at the boundary to peer 535 networks. It is assumed that boundary servers in the trust domain 536 of a network will have local policy for the treatment of the P- 537 Early-Media header field as it is sent to or received from any 538 possible server external to the network. Since boundary servers are 539 free to modify or remove any P-Early-Media header field in SIP 540 messages forwarded across the boundary, the integrity of the P- 541 Early-Media header field can be verified to the extent that the 542 connections to external servers are secured. The authenticity of 543 the P-Early-Media header field can only be assured to the extent 544 that the external servers are trusted to police the authenticity of 545 the header field. 547 11. IANA Considerations 549 11.1. Registration of the "P-Early-Media" SIP header field 551 Name of Header field: P-Early-Media 553 Short form: none 555 Registrant: Richard Ejzak 556 ejzak@alcatel-lucent.com 558 Normative description: Section 8 of this document 559 12. Acknowledgements 561 The author would like to thank Miguel Garcia-Martin, Jan Holm, 562 Sebastien Garcin, Akira Kurokawa, Erick Sasaki, James Calme, Greg 563 Tevonian, Aki Niemi, Paul Kyzivat, Gonzalo Camarillo, Brett Tate, 564 Jon Peterson, Alfred Hoenes, and David Black for their significant 565 contributions made throughout the writing and reviewing of this 566 document. 568 13. References 570 13.1. Normative References 572 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 573 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 574 Session Initiation Protocol", RFC 3261, June 2002. 575 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 576 Levels", BCP 14, RFC 2119, March 1997. 577 [3] Camarillo, G., "The Early Session Disposition Type for the 578 Session Initiation Protocol (SIP)", RFC 3959, December 2004. 579 [4] Camarillo, G., "Early Media and Ringing Tone Generation in the 580 Session Initiation Protocol (SIP)", RFC 3960, December 2004. 581 [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax 582 Specifications: ABNF", RFC 4234, October 2005. 583 [6] Jennings, C., Peterson, J. and Watson, M., "Private Extensions 584 to the Session Initiation Protocol (SIP) for Asserted Identity 585 within Trusted Network", RFC 3325, November 2002. 586 [7] Handley, M., Jacobson, V. and Perkins, C., "SDP: Session 587 Description Protocol", RFC 4566, July 2006. 588 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 589 Session Description Protocol (SDP)", RFC 3264, June 2002. 590 [9] Rosenberg, J., Schulzrinne, H. and Kyzivat, P., "Caller 591 Preferences for the Session Initiation Protocol (SIP)", RFC 592 3841, August 2004. 593 [10] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 594 Method", RFC 3311, September 2002. 595 [11] Camarillo, G., Marshall, W. and Rosenberg, J., "Integration of 596 Resource Management and Session Initiation Protocol (SIP)", RFC 597 3312, October 2002. 598 [12] Rosenberg, J. and Schulzrinne, H., "Reliability of Provisional 599 Responses in the Session Initiation Protocol (SIP)", RFC 3262, 600 June 2002. 602 13.2. Informative References 604 [13] 3GPP "TS 23.228: IP Multimedia Subsystem (IMS); Stage 2 605 (Release 7)", 3GPP 23.228, March 2007, 606 ftp://ftp.3gpp.org/specs/archive/23_series/23.228/. 607 [14] 3GPP "TS 24.229: IP Multimedia Call Control Protocol based on 608 SIP and SDP; Stage 3 (Release 7)", 3GPP 24.229, March 2007, 609 ftp://ftp.3gpp.org/specs/archive/24_series/24.229/. 611 ETSI documents can be downloaded from the ETSI web server, 612 http://www.etsi.org/". Any 3GPP document can be downloaded from the 613 3GPP webserver, "http://www.3gpp.org/", see specifications. 615 14. Authors' Addresses 617 Richard Ejzak 618 Alcatel-Lucent 619 1960 Lucent Lane 620 Naperville, IL 60566, USA 622 Phone: +1 630 979 7036 623 EMail: ejzak@alcatel-lucent.com 625 15. IPR Notice 627 The IETF takes no position regarding the validity or scope of any 628 Intellectual Property Rights or other rights that might be claimed 629 to pertain to the implementation or use of the technology described 630 in this document or the extent to which any license under such 631 rights might or might not be available; nor does it represent that 632 it has made any independent effort to identify any such rights. 633 Information on the procedures with respect to rights in RFC 634 documents can be found in BCP 78 and BCP 79. 636 Copies of IPR disclosures made to the IETF Secretariat and any 637 assurances of licenses to be made available, or the result of an 638 attempt made to obtain a general license or permission for the use 639 of such proprietary rights by implementers or users of this 640 specification can be obtained from the IETF on-line IPR repository 641 at http://www.ietf.org/ipr. 643 The IETF invites any interested party to bring to its attention any 644 copyrights, patents or patent applications, or other proprietary 645 rights that may cover technology that may be required to implement 646 this standard. Please address the information to the IETF at 647 ietf-ipr@ietf.org. 649 16. Copyright Notice 651 Copyright (C) The IETF Trust (2007). 653 This document is subject to the rights, licenses and restrictions 654 contained in BCP 78, and except as set forth therein, the authors 655 retain all their rights. 657 This document and the information contained herein are provided on 658 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 659 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 660 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 661 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 662 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 663 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 664 FOR A PARTICULAR PURPOSE. 666 This Internet-Draft expires December 12, 2007.