idnits 2.17.1 draft-ietf-sip-answermode-07.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 1147. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1165. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1171. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (May 28, 2008) is 5774 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1054, but not defined ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-27) exists of draft-ietf-mmusic-media-loopback-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group D. Willis, Ed. 3 Internet-Draft Softarmor Systems 4 Intended status: Standards Track A. Allen 5 Expires: November 29, 2008 Research in Motion (RIM) 6 May 28, 2008 8 Requesting Answering Modes for the Session Initiation Protocol (SIP) 9 draft-ietf-sip-answermode-07 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 29, 2008. 36 Abstract 38 This document extends SIP with two header fields and associated 39 option tags that can be used in INVITE requests to convey the 40 requester's preference for user-interface handling related to 41 answering of that request. The first header, "Answer-Mode", 42 expresses a preference as to whether the target node's user interface 43 waits for user input before accepting the request or instead accepts 44 the request without waiting on user input. The second header, "Priv- 45 Answer-Mode" is similar to the first, except that it requests 46 administrative-level access and has consequent additional 47 authentication and authorization requirements. These behaviors have 48 applicability to applications such as Push-to-Talk and to diagnostics 49 like loop-back. Usage of each header field in a response to indicate 50 how the request was handled is also defined. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 Table of Contents 60 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Syntax of Header Fields and Option Tags . . . . . . . . . . . 6 64 3. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields . 6 66 4. Usage of the Answer-Mode and Priv-Answer-Mode Header 67 Fields in Requests . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. The Difference Between Answer-Mode and Priv-Answer-Mode . 8 69 4.2. The "require" Modifier . . . . . . . . . . . . . . . . . . 10 70 4.3. Procedures at User Agent Clients (UAC) . . . . . . . . . . 10 71 4.3.1. All Requests . . . . . . . . . . . . . . . . . . . . . 10 72 4.3.2. REGISTER Transactions . . . . . . . . . . . . . . . . 10 73 4.3.3. INVITE Transactions . . . . . . . . . . . . . . . . . 10 74 4.4. Procedures at Intermediate Proxies . . . . . . . . . . . . 12 75 4.4.1. General Proxy Behavior . . . . . . . . . . . . . . . . 12 76 4.4.2. Issues with Automatic Answering and Forking . . . . . 13 77 4.5. Procedures at User Agent Servers (UAS) . . . . . . . . . . 13 78 4.5.1. INVITE Transactions . . . . . . . . . . . . . . . . . 13 80 5. Usage of the Answer-Mode and Priv-Answer-Mode Header 81 Fields in Responses . . . . . . . . . . . . . . . . . . . . . 14 82 5.1. Procedures at the UAS . . . . . . . . . . . . . . . . . . 15 83 5.2. Procedures at the UAC . . . . . . . . . . . . . . . . . . 15 85 6. Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 16 86 6.1. REGISTER Request . . . . . . . . . . . . . . . . . . . . . 16 87 6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . . 16 88 6.3. 200 (OK) Response . . . . . . . . . . . . . . . . . . . . 17 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 91 7.1. Attack Sensitivity Depends on Media Characteristics . . . 18 92 7.2. Application Design Affects Attack Opportunity . . . . . . 20 93 7.3. Applying the Analysis . . . . . . . . . . . . . . . . . . 20 94 7.4. Minimal Policy Requirement . . . . . . . . . . . . . . . . 22 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 97 8.1. Registration of Header Fields . . . . . . . . . . . . . . 23 98 8.2. Registration of Header Field Parameters . . . . . . . . . 23 99 8.3. Registration of SIP Option Tags . . . . . . . . . . . . . 24 101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 104 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 105 10.2. Informative References . . . . . . . . . . . . . . . . . . 25 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 108 Intellectual Property and Copyright Statements . . . . . . . . . . 27 110 1. Background 112 The conventional model for session establishment using the Session 113 Initiation Protocol (SIP, [RFC3261]) involves 1) sending a request 114 for a session (a SIP INVITE), notification of the user receiving the 115 request, 2 ) acceptance of the request and of the session by that 116 user, and 3 ) the sending of a response (SIP 200 OK) back to the 117 requester before the session is established. Some usage scenarios 118 deviate from this model, specifically with respect to the 119 notification and acceptance phase. While it has always been possible 120 for the node receiving the request to skip the notification and 121 acceptance phases, there has been no standard mechanism for the party 122 sending the request to specifically indicate a desire (or 123 requirement) for this sort of treatment. This document defines a SIP 124 extension header field that can be used to request specific treatment 125 related to the notification and acceptance phase. 127 The first usage scenario is the requirement for diagnostic loopback 128 calls. In this sort of scenario, a testing service sends an INVITE 129 to a node being tested. The tested node accepts and a dialog is 130 established. But rather than establishing a two-way media flow, the 131 tested node loops back or "echoes" media received from the testing 132 service back toward the testing service. The testing service can 133 then analyze the media flow for quality and timing characteristics. 134 SDP usage for this sort of flow is described in 135 [I-D.ietf-mmusic-media-loopback]. In this sort of application, it 136 might not be necessary that the human using the node under test 137 interact with the node in any way for the test to be satisfactorily 138 executed. In some cases, it might be appropriate to alert the user 139 to the ongoing test, and in other cases it might not be. 141 The second scenario is that of "Push to Talk" applications being 142 specified by the Open Mobile Alliance. In this sort of environment, 143 SIP is used to establish `a dialog supporting asynchronous delivery 144 of unidirectional media flow, giving a user experience like that of a 145 traditional two-way radio. It is conventional for the INVITES used 146 to be automatically accepted by the called UA (User Agent), and the 147 media is commonly played out on a loudspeaker. The called party's 148 UA's microphone is not engaged until the user presses the local 149 "talk" button to respond. 151 A third scenario is the "PBX attendant". Traditional office PBX 152 systems often include intercom functionality. A typical use for the 153 intercom function is to allow a receptionist to activate a 154 loudspeaker on a desk telephone in order to announce a visitor. Not 155 every caller can access the loudspeaker, only the receptionist or 156 operator, and it is not expected that these callers will always want 157 "intercom" functionality -- they might instead want to make an 158 ordinary call. 160 There are presumably many more use cases for the extensions defined 161 in this specification, but this document was developed to 162 specifically meet the requirements of these scenarios or others with 163 essentially similar properties. 165 These sorts of mechanisms are not required to provide the 166 functionality of an "answering machine" or "voice mail recorder". 167 Such a device knows that it is expected to answer and does not 168 require a SIP extension to support its behavior. 170 Much of the discussion of this topic in working group meetings and on 171 the mailing list dealt with differentiating "answering mode" from 172 "alerting mode". Some early work did not make this distinction. We 173 therefore proceed with the following definitions: 175 o Answering Mode includes behaviors in a SIP UA relating to 176 acceptance or rejection of a request that are contingent on 177 interaction between the UA and the user of that UA after the UA 178 has received the request. We are principally concerned with the 179 user interaction involved in accepting the request and initiating 180 an active session. An example of this might be pressing the "yes" 181 button on a mobile phone. 183 o Alerting Mode includes behaviors in a SIP UA relating to informing 184 the user of the UA that a request to initiate a session has been 185 received. An example of this might be activating the ring tone of 186 a mobile phone. 188 This document deals only with "Answering Mode". Issues relating to 189 "Alerting Mode" are outside its scope. 191 This document defines two SIP extension header fields, "Answer-Mode" 192 and "Priv-Answer-Mode". These two extensions take the same 193 parameters and operate in the same general way. 195 The distinction between Answer-Mode and Priv-Answer-Mode relates to 196 the level of authorization being claimed by the UAC and verified and 197 policed by the UAS. Requests are usually made using Answer-Mode. 198 Requests made using Priv-Answer-Mode request "privileged" treatment 199 from the UAS. This mechanism is discussed in greater detail below 200 under the heading "The Difference Between Answer-Mode and Priv- 201 Answer-Mode". 203 Priv-Answer-Mode is not an assertion of privilege. Instead, it is a 204 request for privileged treatment. This is similar to the UNIX model 205 where a user might run a command normally, or use "sudo" to request 206 administrative privilege for the command. Including the "Priv-" part 207 is equivalent to prefixing a UNIX command with "sudo". In other 208 words, a separate policy table (like "/etc/sudoers") is consulted to 209 determine whether the user may receive the requested treatment. 211 This distinction is discussed in greater detail in Section 4.1. 213 2. Syntax of Header Fields and Option Tags 215 The following syntax uses ABNF as defined in [RFC5234]. Further, it 216 relies on the syntax for SIP defined in . [RFC3261] 218 The syntax for the header fields defined in this document is: 220 Answer-Mode = "Answer-Mode" HCOLON answer-mode-value 221 *(SEMI answer-mode-param) 223 Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode-value 224 *(SEMI answer-mode-param) 226 answer-mode-value = "Manual" / "Auto" / token 228 answer-mode-param= "require" / generic-param 230 The SIP option tag indicating support for this extension is 231 "answermode". 233 For implementors: SIP header field names and values are always 234 compared in a case-insensitive manner. The pretty capitalization 235 is just for readability. 237 This syntax includes extension hooks, "token" for answer-modes 238 values, and "generic-param" for optional parameters, that could be 239 defined in future specifications extending this one. This 240 specification defines only the behavior for the values given 241 explicitly above. In order to provide forward compatibility, 242 implementations MUST ignore unknown values. 244 3. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields 246 This document defines usage of the Answer-Mode and Priv-Answer-Mode 247 header fields in initial (dialog-forming) SIP INVITE requests and in 248 200 (OK) responses to those requests. This document specifically 249 does not define usage in any other sort of request or response, 250 including but not limited to ACK, CANCEL, or any mid-dialog usage. 252 This limitation stems from the intended usage of this extension, 253 which is to affect the way that users interact with communications 254 devices when requesting new communications sessions and when 255 responding to such requests. This sort of interaction occurs only 256 during the formation of a dialog and its initial usage, and not 257 during subsequent operations such as re-INVITE. However, the 258 security aspects of the session initiation must be applied to changes 259 in media description introduced by re-INVITES or similar requests. 260 See Section 7.1 for further discussion of this issue. 262 4. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in 263 Requests 265 The Answer-Mode or Priv-Answer-Mode header field is used by a UAC in 266 an INVITE request to invoke specific handling by the responding UAS 267 related to "automatic answering" functionality for any dialog 268 resulting from that INVITE request. If no Answer-Mode or Priv- 269 Answer-Mode header field is included in the request, answering 270 behavior is at the discretion of the UAS, as it would be in the 271 absence of this specification. The desired handling is indicated by 272 the value of the Answer-Mode or Priv-Answer-Mode header field, as 273 follows: 275 Manual: The UAS is asked to defer accepting the request until the 276 user of the UAS has interacted with the user interface (UI) of the 277 UAS in such a way as to indicate that the user desires the UAS to 278 accept the request. 280 Auto: The UAS is asked to accept the request automatically, without 281 waiting for the user of the UAS to interact with the UI of the UAS 282 in such a way as to indicate that the user desires the UAS to 283 accept the request. 285 Each value of the Answer-Mode or Priv-Answer-Mode header field can 286 include an optional parameter, "require". If present, this parameter 287 indicates that the UAC would prefer that the UAS reject the request 288 if the UAS is unwilling (perhaps due to policy) to answer in the mode 289 requested, rather than answering in another mode. For example, this 290 parameter could be used to make sure that a test "loopback" call 291 doesn't disturb a user who has configured her phone to manually 292 answer even if the caller requests an automatic answer. 294 The UAS is responsible for deciding how to honor this preference. In 295 general, the UAS makes an authorization decision based on the 296 authenticated identity presented in the request using authentication 297 mechanisms such as SIP Digest Authentication [RFC3261], the SIP 298 Identity mechanism [RFC4474], or (within the restricted networks for 299 which it is suitable) the SIP mechanism for asserted identity within 300 trusted networks [RFC3325] and using authorization information or 301 policy available to the UAS. This decision making MUST consider the 302 risk model of the media session corresponding to the request, and the 303 UAS MUST NOT answer without user input in cases where the privacy or 304 security of the user would be compromised as a result. Making this 305 determination is a matter of system or application design, and cannot 306 be in general addressed by having a set of functions that are 307 configurable on or off. Specific discussion of media sessions and 308 appropriate policy is discussed in Section 7. 310 4.1. The Difference Between Answer-Mode and Priv-Answer-Mode 312 The function of both the Answer-Mode and Priv-Answer-Mode header 313 fields is similar; they both ask that the UAS handle the request as 314 specified by the header field's value (automatic or manual). The 315 difference is in the way the requests interact with the UAS's policy. 316 A typical UAS will have different policies for handing the each 317 header field. For example, assume that the user of a UAS has placed 318 that UAS into "meeting mode", indicating that she is engaged in an 319 important activity and does not wish to be spuriously interrupted. 320 The UAS might disallow automatic answering for Answer-Mode requests 321 while in "meeting mode". However, that UAS might allow automatic 322 answering for requests made with Priv-Answer-Mode. There will 323 probably be differences in authorization policy. For example, a UAS 324 might be configured such that callers on the "friends" list are 325 allowed to make requests using Answer-Mode but not Priv-Answer-Mode. 326 That same UAS might be configured to only allow callers on the 327 "administrators" list to use Priv-Answer-Mode. This is different 328 from always basing the behavior on the identity of the calling party. 329 For example, assume caller "Bob" is on both the "friends" list and 330 "administrators" list. If Bob wants his request to be processed 331 according to the regular policy, he uses Answer-Mode. If Bob wants 332 his request to be processed under the more restrictive "privileged" 333 policy, he uses Priv-Answer-Mode. 335 A UAS SHOULD apply a stricter authorization policy to a request with 336 Priv-Answer-Mode than it does to requests with Answer-Mode. The 337 default policy SHOULD be to refuse requests containing "Priv-Answer- 338 Mode" header fields, unless the requester is authenticated and 339 specifically authorized to make Priv-Answer-Mode requests. Failure 340 to enforce such a policy leaves the user potentially vulnerable to 341 abuses as discussed in Section 7. 343 The use case envisioned for Priv-Answer-Mode relates to handling 344 urgent requests from authorized callers. For example, assume Larry 345 is a limousine driver working with a fleet dispatcher. Larry likes 346 to provide a quiet environment for his car, so his communicator is 347 configured for manual answer mode for all non-privileged calls, 348 including push-to-talk (Answer-Mode: Auto) calls. Each time he gets 349 a call, Larry's communicator chimes softly to alert him to the call. 350 If the circumstances permit it, Larry presses the communicator in 351 order to accept the call, the communicator sends a 200 (OK) response, 352 and the calling party's talk burst is played out through the 353 communicator's loudspeaker. This treatment is delivered to incoming 354 requests that have an Answer-Mode header field having values of 355 "Manual" or "Auto" (or no Answer-Mode header field at all) no matter 356 who the caller is. 358 Larry's fleet dispatch operator is familiar with this policy, and 359 needs to inform Larry about a critical matter. The dispatch operator 360 tries several times to push-to-talk call Larry (including Answer- 361 Mode: Auto in the requests), but the calls aren't accepted because 362 Larry has fallen asleep, and therefore isn't pressing his 363 communicator to accept the call. 365 The operator then presses his "urgent" button and calls Larry again. 366 This time, the INVITE request carries a "Priv-Answer-Mode: Auto" 367 header field. Larry's communicator checks the identity of the caller 368 (using a SIP Identity assertion or functionally equivalent 369 mechanism), and matches the operator's identity against the list of 370 users allowed to do Priv-Answer-Mode. Since the operator is listed, 371 the communicator immediately returns a 200 (OK) response accepting 372 the call. The operator speaks, and the resulting talk-burst is 373 summarily played out the loudspeaker on Larry's communicator, waking 374 him up. 376 The effect of requesting Priv-Answer-Mode is different than the 377 effect of simply granting higher privilege to an Answer-Mode request 378 based on the requester's identity and corresponding authorization 379 level. This distinction is what allows the fleet operator to make 380 polite (Answer-Mode: Auto) requests to Larry under normal conditions, 381 and receive different handling (Priv-Answer-Mode: Auto) for a request 382 having greater urgency. 384 In normal operations, only one of "Answer-Mode" and "Priv-Answer- 385 Mode" would be used in an INVITE request. If both are present, the 386 UAS will first test the authorization of the requester for Priv- 387 Answer-Mode, and if authorized, process the request as if only Priv- 388 Answer-Mode had been included. If the requester is not authorized 389 for Priv-Answer-Mode, then the UAS will process the request as if 390 only "Answer-Mode" had been included. 392 4.2. The "require" Modifier 394 Both Answer-Mode and Priv-Answer-Mode allow a modifier of "require". 395 Example: "Priv-Answer-Mode: Auto;require". This modifier does not 396 influence the UAS's policy in choosing whether to answer manually or 397 automatically. The UAS decides whether or not to answer 398 automatically based on other aspects of the request. The "require" 399 modifier is only evaluated after the UAS has selected an answering 400 mode. If the UAS's policy has resulted in an answering mode that is 401 different from that specified in the request, the presence of the 402 "require" modifier asks the UAS to reject the call. In the given 403 example, the UAS is being asked to answer automatically if the caller 404 is authorized for automatic answering under the "privileged" policy, 405 and to reject the call (rather than answering manually) if the caller 406 is not authorized for this mode. This is discussed in more depth in 407 Section 4.5. 409 4.3. Procedures at User Agent Clients (UAC) 411 4.3.1. All Requests 413 A UA supporting the Answer-Mode and Priv-Answer-Mode header fields 414 SHOULD indicate its support by including an option tag of 415 "answermode" in the Supported header field of all requests it sends. 417 4.3.2. REGISTER Transactions 419 To indicate that it supports the answer-mode negotiation feature, a 420 UA MAY include an extensions parameter with a value that includes 421 "answermode". Example: 423 ;extensions="answermode,100rel,gruu" 425 in the Contact: header field of its REGISTER requests. This usage of 426 feature tags is described in [RFC3840]. 428 If a UA is dependent on support for callee capabilities in the 429 registrar, it MAY include a Require header field with the value 430 "pref" in its REGISTER request. This will cause the registrar to 431 reject the request if the registrar does not support callee 432 capabilities and caller preferences. Example: 434 Require: pref 436 4.3.3. INVITE Transactions 438 A UAC supporting this specification MAY include an Answer-Mode or 439 Priv-Answer-Mode header field in an INVITE where it wishes to 440 influence the answering mode of the responding UAS. 442 Note: this is meaningful only in initial or dialog-forming INVITE 443 requests. Answer-Mode and Priv-Answer-Mode header fields 444 appearing in other requests are ignored. In general, if the 445 request would not normally result in a notification to the user 446 and acceptance by that user (for example, "ringing" and 447 "answering"), then these extensions are not applicable. 449 To request that the UAS answer only after having interacted with its 450 user and receiving an affirmative instruction from that user, the UAC 451 includes an Answer-Mode or Priv-Answer-Mode header field having a 452 value of "Manual". Example: 454 Answer-Mode: Manual 456 To request that the UAS answer manually, and ask that it reject the 457 INVITE request if unable or unwilling to answer manually, the UAC 458 includes an Answer-Mode or Priv-Answer-Mode header field having a 459 value of "Manual" and a parameter of "require". Example: 461 Answer-Mode: Manual;require 463 To request that the UAS answer automatically without waiting for 464 input from the user, the UAC includes an Answer-Mode or Priv-Answer- 465 Mode header field having a value of "Auto". Example: 467 Answer-Mode: Auto 469 To request that the UAS answer automatically, and ask that it reject 470 the INVITE request if unable or unwilling to answer automatically, 471 the UAC includes an Answer-Mode or Priv-Answer-Mode header field 472 having a value of "Auto" and a parameter of "require". Example: 474 Answer-Mode: Auto;require 476 To require that the UAS either support this extension or reject the 477 request, the UAC includes a Require: header field having the value 478 "answermode". This does not actually force the UAS to automatically 479 answer, it just requires that the UAS either understand this 480 extension or reject the request. We do not have a SIP negotiation 481 technique to force specific behavior. Rather, the desired behavior 482 is indicated in the SIP extension itself. Example: 484 Require: answermode 486 To request that retargeting proxies in the path preferentially select 487 targets that have indicated support for this extension in their 488 registration, a UAC includes an Accept-Contact header field with an 489 extensions parameter having a value of "answermode". This usage of 490 Accept-Contact is described in [RFC3841]. This would normally be 491 used in conjunction with the "Require: answermode" header field as 492 described above. Example: 494 Require: answermode Accept-Contact: 495 *;extensions="answermode";methods="INVITE" 497 To request that retargeting proxies in the path do not select targets 498 that have indicated non-support for this extension in their 499 registration, a UAC includes an Accept-Contact header field with an 500 extensions parameter having a value of "answermode" and an option 501 field of "require". This usage of Accept-Contact is described in 502 [RFC3841]. This would normally be used in conjunction with the 503 "Require: answermode" header field as described above. Example: 505 Require: answermode Accept-Contact: 506 *;extensions="answermode"; methods="INVITE";require 508 To request that retargeting proxies in the path exclusively select 509 targets that have indicated support for this extension in their 510 registration, a UAC includes an Accept-Contact header field 511 extensions parameter having a value of "answermode"" and options of 512 "require" and "explicit". This usage of Accept-Contact is described 513 in [RFC3841]. This would normally be used in conjunction with the 514 "Require: answermode" header field as described above. Example: 516 Require: answermode Accept-Contact: 517 *;extensions="answermode"; 518 methods="INVITE";require;explicit 520 4.4. Procedures at Intermediate Proxies 522 4.4.1. General Proxy Behavior 524 The general procedure at all intermediate proxies including the UAC's 525 serving proxy or proxies and the UAS's serving proxy or proxies is to 526 ignore the Answer-Mode header field. However, the serving proxies 527 (proxies responsible for resolving an address-of-record (AOR) into a 528 registered contact) MAY exercise control over the requested answer 529 mode, either inserting or deleting an Answer-Mode or Priv-Answer-Mode 530 header field or altering the value of an existing header field in 531 accord with local policy. This could result in behavior that is 532 inconsistent with user expectations (such as having a call that was 533 intended to be a diagnostic loopback answered by a human) and 534 consequently proxies MUST NOT insert, delete, or alter Answer-Mode or 535 Priv-Answer-Mode header fields unless explicitly authorized to do so 536 by an external agreement between the proxy operator and the user of 537 the UA that the proxy is serving. These serving proxies MAY also 538 reject a request according to local policy, and SHOULD use the 539 rejection codes as specified below for the UAS if they do so. 541 4.4.2. Issues with Automatic Answering and Forking 543 One of the well-known issues with forking is the problem of multiple 544 acceptance. If an INVITE request is forked to several UASes, and 545 more than one of those replies with a 200 (OK) response, the 546 conventional approach is to continue the dialog with the first 547 respondent, and tear down the dialog (using BYE requests) with all 548 other respondents. 550 While this problem exists without an auto-answer negotiation 551 capability, it is apparent that widespread adoption of UAs that 552 engage in auto-answer behavior will exacerbate the multiple 553 acceptance problem. Consequently, systems designers need to take 554 this aspect into consideration. In general, auto-answer is NOT 555 RECOMMENDED in environments that include parallel forking. 557 As an alternative, it might be reasonable to use a variation on 558 manual-answer combined with no alerting and early media. In this 559 approach, the initial message or talk-burst is transmitted as early 560 media to all recipients, where it is displayed or played out. Any 561 response utterance (pushing the transmit key and talking) from the 562 user of a UAS following this would serve as an "acceptance", 563 resulting in a 200 (OK) response being transmitted by their UAS. 564 Consequently, the race-condition for acceptance would be limited to 565 the subset of UAs actually responding under user control, rather than 566 the full set of UAs to which the request was forked. 568 Another alternative would be to use dynamic conferencing instead of 569 forking. In this approach, instead of forking the request, a 570 conference would be initiated and all registered UAs invited into 571 that conference. The mixer attached to the conference would then 572 mediate traffic flows appropriately. 574 4.5. Procedures at User Agent Servers (UAS) 576 4.5.1. INVITE Transactions 578 For a request having an Answer-Mode value of "Manual" and not having 579 an Answer-Mode parameter of "require", the UAS SHOULD defer accepting 580 the request until the user of the UAS has confirmed willingness to 581 accept the request. This behavior MAY be altered as needed for 582 unattended UASes or other local characteristics or policy. For 583 example, an auto-attendant or PSTN gateway system that always answers 584 automatically would go ahead and answer, despite the presence of the 585 "Manual" Answer-Mode header field value. 587 For a request having an Answer-Mode value of "Manual" and an Answer- 588 Mode parameter of "require", the UAS MUST defer accepting the request 589 until the user of the UAS has confirmed willingness to accept the 590 request. If the UAS is not capable of answering the request in this 591 "Manual" mode or is unwilling to do so, it MUST reject the request 592 and SHOULD do so with a "403 (Forbidden)" response and MAY include a 593 reason phrase of "manual answer forbidden". 595 For a request having an Answer-Mode value of "Auto", the UAS SHOULD, 596 if the calling party is authenticated and authorized for automatic 597 answering, accept the request without further user input. The UAS 598 MAY, according to local policy or user preferences, treat this 599 request as it would treat a request having an Answer-Mode with a 600 value of "Manual" or having no Answer-Mode header field. If the 601 calling party is not authenticated and authorized for automatic 602 answer, the UAS MAY either handle the request as per "manual", or 603 reject the request. If the UAS rejects the request, it SHOULD do so 604 with a "403 (Forbidden)" response, and MAY include a reason phrase of 605 "automatic answer forbidden". There may be an interaction with 606 [RFC3261] section 23.2, which in some cases requires user validation 607 of certificates used for S/MIME. Since this places the same 608 interrupt burden on the user as would manually answering the request, 609 a UAS experiencing this requirement for user validation of a request 610 that requires automatic answering SHOULD reject the request with a 611 "403 (Forbidden)" response and MAY include a reason phrase of 612 "Certificate validation requires user input not compatible with 613 automatic answer." 615 For a request having an Answer-Mode value of "Auto" and an Answer- 616 Mode parameter of "require", the UAS SHOULD, if the calling party is 617 authenticated and authorized for automatic answering, accept the 618 request. The UAS MUST NOT allow "manual" answer of this request, but 619 MAY reject it. If, for whatever reason, the UAS chooses not to 620 accept the request automatically, the UAS MUST reject the request and 621 SHOULD do so with a "403 (Forbidden)" response, and MAY include a 622 reason phrase of "automatic answer forbidden". 624 Similar behavior applies for Priv-Answer-Mode, except that the policy 625 for authorization may be different (and generally more stringent). 627 5. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in 628 Responses 630 The Answer-Mode header field or Priv-Answer-Mode can be inserted by a 631 UAS into a response in order to indicate how it handled the 632 associated request with respect to automatic answering functionality. 633 The UAC might use this information to inform the user or otherwise 634 adapt the behavior of the user interface. The handling is indicated 635 by the value of the header field, as follows: 637 Manual: The UAS responded after the user of the UAS interacted with 638 the user interface (UI) of the UAS in such a way as to indicate 639 that the user desires the UAS to accept the request. 641 Auto: The UAS responded automatically, without waiting for the user 642 of the UAS to interact with the UI of the UAS in such a way as to 643 indicate that the user desires the UAS to accept the request. 645 The Answer-Mode and Priv-Answer-Mode header fields, when used in 646 responses, are only valid in a 200 (OK) response to an INVITE 647 request. 649 5.1. Procedures at the UAS 651 A UAS supporting this specification inserts an Answer-Mode or Priv- 652 Answer-Mode header field into the 200 (OK) response to an INVITE 653 request when it wishes to inform the UAC as to whether the request 654 was answered manually or automatically. It is reasonable for a UAS 655 to assume that if the UAC included an Answer-Mode header field in the 656 request that it would probably like to see an Answer-Mode header 657 field in the response. The full rationale for including or not 658 including this header field in a response is outside of the scope of 659 this specification, and is sensitive to the privacy concerns of the 660 user of the UAS. For example, informing the calling party that a 661 call was answered manually might reveal the presence of an "actual 662 human" at the responding UAS. While in the general case the ensuing 663 conversation would also reveal this same information, there might be 664 cases where this information might need to be protected. 665 Consequently, UASes supporting this specification SHOULD include 666 appropriately configurable policy mechanisms for making this 667 determination, and the default configuration SHOULD be to exclude 668 this header field from responses. 670 5.2. Procedures at the UAC 672 A UAC MAY use the value of the Answer-Mode or Priv-Answer-Mode header 673 field, if present, to adapt the user interface and/or inform the user 674 about the handling of the request. For example, the user of a push- 675 to-talk system might speak differently if she knows that the called 676 party answered "in person" vs. having the call blare out of an 677 unattended speaker phone. 679 6. Examples of Usage 681 The following examples show Bob registering a contact that supports 682 the negotiation of answering mode. Alice then calls Bob with an 683 INVITE request, asking for automatic answering and explicitly asking 684 that the request not be routed to contacts that have not indicated 685 support for this extension. Further, Alice requires that the request 686 be rejected if Bob's UA does not support negotiation of answering 687 mode. Bob replies with a 200 (OK) response indicating that the call 688 was answered automatically. 690 The Content-Length header field shown in the examples contains a 691 placeholder "..." instead of a valid Content-Length. Furthermore, 692 the SDP bodies that would be expected in the INVITE requests and 693 200 (OK) responses are not shown. 695 6.1. REGISTER Request 697 In the following example, Bob's UA is registering and indicating that 698 it supports the answermode extension. 700 REGISTER sip:example.com SIP/2.0 701 From: Bob 702 To: Bob 703 CallID: hh89as0d-asd88jkk@cell-phone.example.com 704 CSeq: 1 REGISTER 705 Contact: sip:cell-phone.example.com; 706 ;audio 707 ;+sip.extensions="answermode" 708 ;methods="INVITE,BYE,OPTIONS,CANCEL,ACK" 709 ;schemes="sip" 711 6.2. INVITE Request 713 In this example, Alice is calling Bob and asking Bob's UA to answer 714 automatically. However, Alice is willing for Bob to answer manually 715 if Bob's policy is to prefer manual answer, so Alice does not include 716 a ";require" modifier on "Answer-Mode: Auto" 717 INVITE sip:bob@example.com SIP/2.0 718 Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43 719 Max-Forwards: 70 720 From: Alice ;tag=9fxced76sl 721 To: Bob 722 Call-ID:3848276298220188511@client-alice.example.com 723 CSeq: 1 INVITE 724 Contact: 725 Require: answermode 726 Accept-contact:*;require;explicit;extensions="answermode" 727 Answer-Mode: Auto 728 Content-Type: application/sdp Content-Length: ... 730 6.3. 200 (OK) Response 732 Here, Bob has accepted the call and his UA has answered 733 automatically, which it indicates in the 200 (OK) response. 735 SIP/2.0 200 OK 736 Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43 737 From: Alice ;tag=9fxced76sl 738 To: Bob ;tag=8321234356 739 Call-ID: 3848276298220188511@client-alice.example.com 740 CSeq: 1 INVITE 741 Contact: 742 Answer-Mode: Auto 743 Content-Type: application/sdp 744 Content-Length: ... 746 7. Security Considerations 748 This specification adds the ability for a UAC to request potentially 749 risky user interface behavior relating to the acceptance of an INVITE 750 request by the UAS receiving the request. Specifically, the UAC can 751 request that the UAS accept the request without input to the UAS by 752 the user of the UAS (Answer-Mode: Auto). 754 There are several attacks possible here, with the most obvious being 755 the ability to turn a phone into a remote listening device without 756 its user being aware of it. Additional potential attacks include 757 reverse charge fraud, unsolicited "push to talk" communications (spam 758 over push-to-talk or SPTT), playout of obnoxious noises (the "whoopee 759 cushion" attack), battery-rundown denial of service, "forced busy" 760 denial of service, running up the victim's data transport bill, and 761 phishing via session insertion (where an ongoing session is replaced 762 by another without the victim's awareness). 764 Since SIP implementations do not commonly implement end-to-end 765 message protections, this specification is completely dependent on 766 transitive security across SIP proxies. Any misbehaving proxy can 767 insert, delete, and/or alter the contents of the Answer-Mode and 768 Priv-Answer-Mode header fields, and can in general do so without 769 being noticed by either the UAC or UAS. Consequently, it is critical 770 that any proxies in the path be not only trusted, but worthy of that 771 trust. While proxies do not generally intentionally insert, delete, 772 or alter the Answer-Mode and Priv-Answer-Mode header fields, this 773 specification does not a use case for such manipulation by proxies 774 acting on behalf of the user of a UAC or UAS that has limited support 775 for the authentication or policy enforcement needed to securely 776 exercise these extensions. Proxies that perform such extension- 777 sensitive manipulation MUST therefore provide complete policy 778 enforcement, as per the minimal policy discussed in Section 7.4. 780 The existing body of SIP work provides strong capabilities for 781 authentication of requests, prevention of man-in-the-middle attacks, 782 protecting the privacy and integrity of media flows, and so on 783 (although as noted above, these capabilities usually rely on 784 transitive trust across proxies). The behaviors added by the 785 extensions in this document raise additional possibilities for 786 attacks against media flows not completely addressed by existing SIP 787 work, and therefore require analysis in this document. 789 Media attacks can be loosely categorized as: 791 Insertion: Media is inserted into and played out by the victim UA 792 without consent of the UA's user. 794 Interception: The victim UA's media acquisition facility (such as a 795 microphone or camera) is activated, producing a media stream, 796 without the consent of the UA's user. 798 7.1. Attack Sensitivity Depends on Media Characteristics 800 The danger of abuse varies greatly depending on the media 801 characteristics of the session being established. Since the 802 expressive range of media sessions that can be established by SIP is 803 unbounded, we might find it more effective to model loose categories 804 of media modality rather than explicitly describing every possible 805 scenario. Security analysis can then be applied per modality. 807 The media modalities of interest appear to be: 809 UAC-sourced (Inbound) Unidirectional Media Insertion: Sensitive 810 media flows from the UAC and is rendered by the UAS, annoying the 811 user of the UAS or disrupting the function of the UAS. We refer 812 to this as the "whoopee-cushion" attack because of its utility in 813 replicating the rude-noise making joke seat cushion. The danger 814 of this attack is quite literally amplified by a loudspeaker 815 apparatus attached to the victim UAS. Media that has minimal 816 secondary implication (such as sending a move in a chess game to a 817 computer that isn't running a chess game) is related, but of far 818 less significance. This sort of attack can also have other 819 consequences, such as discharging the victim's battery or 820 increasing charges for data transport to be paid by the victim. 822 UAS-sourced (Outbound) Unidirectional Media Interception: Sensitive 823 media flows from the UAS and is rendered by the UAC, violating the 824 privacy of the user of the UAS. We refer to this as the "bug-my- 825 phone" attack because that would appear to be primary attack 826 motivator. 828 Bidirectional Media Insertion or Interception: Bidirectional media 829 is the common case when SIP is used in a voice-over-IP scenario or 830 "traditional phone call". Once a media flow is established, both 831 ends send and receive media without further engagement. The media 832 information is presumed to be sensitive -- that is, if intercepted 833 it damages the victim's privacy, and if inserted, it annoys or 834 interferes with the recipient. Attacks of this sort might produce 835 both of the "whoopee-cushion" or the "bug-my-phone" scenarios, 836 potentially even simultaneously. 838 It seems reasonable to consider the "bug-my-phone" attack as being in 839 a different class (potentially far more severe) than the "whoopee- 840 cushion" attack. This distinction suggests that security policy 841 could be established in different and presumably less restrictive 842 fashion for inbound media flows than for outbound media flows. The 843 set of callers from which a user would be willing to automatically 844 accept inbound media is reasonably much broader than the set of 845 callers to which a user would be willing to automatically grant 846 outbound media access, although this may not be true in all 847 environments, especially those where reception of unwanted media has 848 unwanted financial consequences. 850 For example: Assume a UA is designed such that it can be used to 851 receive push-to-talk calls to a loudspeaker, and it can be used as a 852 "baby monitor" (has an open mic and streams received audio to 853 listeners). The policy for activating the push-to-talk loudspeaker 854 would probably need to be reasonably broad (perhaps "all the user's 855 buddies"), but the policy for the baby monitor would need to be very 856 narrow (perhaps "only the baby's mother") or even completely closed. 857 The minimal policy defined in Section 7.4 explicitly forbids this 858 functionality. 860 7.2. Application Design Affects Attack Opportunity 862 In the most common use cases, the security aspects are somewhat 863 mitigated by design aspects of the application. For example, in 864 traditional telephony, the called party is alerted to the request 865 (the phone rings), no media session is established without the 866 acceptance of the called party (picking up the phone), and the media 867 path is most commonly delivered to a single-user handset. 868 Consequently, this application (although bidirectional) is relatively 869 secure against both media insertion and media interception attacks of 870 the sort enabled by the extensions in this document. The use of 871 policy-free automatic-answering devices (like answering machines) and 872 amplifiers (speakerphones and call-screening devices) weakens this 873 defense. 875 In push-to-talk applications, media can be sent from UAC to UAS 876 without user oversight, but no media is sent from the called UAS 877 without user input (the "push" of "push-to-talk"). Consequently, 878 there is no "bug-my-phone" attack opportunity. Further, screening of 879 the UAC by eliminating UAC identities not on some sort of "white 880 list" (often, a buddy list) reduces the threat of "whoopee cushion" 881 attacks (except from one's buddies, of course). 883 Similar approaches apply to most applications. Insertion can be 884 controlled (but not eliminated) by combining identity mechanisms with 885 simple authorization policy, and interception can be effectively 886 eliminated by combining strong identity mechanisms with aggressive 887 authorization policy and/or user interaction. 889 7.3. Applying the Analysis 891 The extensions described in this document provide mechanisms by which 892 a UAC can request that a UAS not deploy two of the five defensive 893 mechanisms -- user alerting and user acceptance. In order for this 894 not to produce undue risk of insertion attacks or any increased risk 895 of interception attacks, we are therefore forced to rely on the 896 remaining defensive mechanisms. This document defines a minimum 897 threshold for satisfactory security. Certainly more restrictive 898 policies might reasonably be used, but any policy less restrictive 899 than the approach described below is very likely to result in 900 significant security issues. 902 From the previous discussion of risks, attacks and vulnerabilities, 903 we can derive five defensive mechanisms have five defense mechanisms 904 available at the application level: 906 1. Identity -- know who the request came from. 908 2. Alerting -- Let the called user know what's happening. Some 909 applications might use inbound media as an alert. 911 3. Acceptance -- Require called user to make run-time decision. 912 Asking the user to make a run-time decision without alerting the 913 user to the need to make a decision is generally infeasible. 914 This will have implications for possible alerting options that 915 are outside the scope of this document. 917 4. Limit the I/O -- Turn off loudspeakers or microphone. This could 918 be used to convert a bidirectional media session (very risky, 919 possible "bug my phone")into a unidirectional inbound-only (less 920 risky, possible "spam" or "rundown", etc. ) session while waiting 921 for user acceptance. 923 5. Policy -- rules about other factors, such was black and 924 whitelisting based on identity, disallowing acceptance without 925 alerting, etc. 927 Since SIP and related work already provide several mechanisms 928 (including SIP Digest Authentication [RFC3261], the SIP Identity 929 mechanism [RFC4474], and the SIP mechanism for asserted identity 930 within private networks [RFC3325], in networks for which it is 931 suitable) for establishing the identity of the originator of a 932 request, we presume that an appropriately selected mechanism is 933 available for UAs implementing the extensions described in this 934 document. In short, UAs implementing these extensions MUST be 935 equipped with and MUST exercise a request identity mechanism. The 936 analysis below proceeds from an assumption that the identity of the 937 sender of each request is either known or is known to be unknown, and 938 can therefore be considered in related policy considerations. 939 Failure to meet this identity requirement either opens the door to a 940 wide range of attacks, or requires operational policy so tight as to 941 make these extensions useless. 943 We previously established a class distinction between inbound and 944 outbound media flows, and can model bidirectional flows as "worst 945 case" sums of the risks of the other two classes. Given this 946 distinction, it seems reasonable to provide separate directionality 947 policy classes for: 949 1. Inbound media flows. 951 2. Outbound media flows. 953 For each directionality policy class, we can divide the set of 954 request identities into three classes: 956 1. Identities explicitly authorized for the class. 958 2. Identities explicitly denied for the class. 960 3. Identities for which we have no explicit policy and need the user 961 to make a decision. 963 Note that not all combinations of policies possible in this 964 decomposition are generally useful. Specifically, a policy of 965 "inbound media denied, outbound media allowed" equates to a "bug my 966 phone" attack, and is disallowed by the minimal policy of 967 Section 7.4which, as written, excludes all cases of "Outbound media 968 explicitly authorized". 970 7.4. Minimal Policy Requirement 972 User agents implementing this specification SHOULD NOT establish a 973 session providing inbound media without explicit user acceptance 974 where the requesting user is unknown, or is known and has not been 975 granted authorization for such a session. This requirement is 976 intended to prevent "SPAM broadcast" attacks where unexpected and 977 unwanted media is played out at a UAS . 979 User agents implementing this specification MUST NOT establish a 980 session providing outbound or bidirectional media sourced from the 981 user agent without explicit user acceptance. Loopback media used for 982 connectivity testing is not constrained by this requirement. This 983 requirement is intended to assure that this extension can not be used 984 to turn a UAS into a remote-controlled microphone (or "bug") without 985 the knowledge of its user. Since SIP allows for a session to be 986 initially established with inbound-only media and then transitioned 987 (via re-INVITE or UPDATE) to an outbound or bidirectional session, 988 enforcing this policy requires dialog-stateful inspection in the SIP 989 UAS. In other words, if a session was initiated with automatic 990 answering, the UAS MUST NOT transition to a mode that sends outbound 991 media without explicit acceptance by the user of the UAS. 993 8. IANA Considerations 995 8.1. Registration of Header Fields 997 This document defines new SIP header fields named "Answer-Mode" and 998 "Priv-Answer-Mode". 1000 The following rows shall be added to the "Header Fields" section of 1001 the SIP parameter registry: 1003 +------------------+--------------+-----------+ 1004 | Header Name | Compact Form | Reference | 1005 +------------------+--------------+-----------+ 1006 | Answer-Mode | | [RFCXXXX] | 1007 | Priv-Answer-Mode | | [RFCXXXX] | 1008 +------------------+--------------+-----------+ 1010 Editor Note: [RFCXXXX] should be replaced with the designation of 1011 this document. 1013 8.2. Registration of Header Field Parameters 1015 This document defines parameters for the header fields defined in the 1016 preceding section. The header fields "Answer-Mode" and "Priv-Answer- 1017 Mode" can take the values "Manual" or "Auto". 1019 The following rows shall be added to the "Header Field Parameters and 1020 Parameter Values" section of the SIP parameter registry: 1022 +------------------+----------------+-------------------+-----------+ 1023 | Header Field | Parameter Name | Predefined Values | Reference | 1024 +------------------+----------------+-------------------+-----------+ 1025 | Answer-Mode | Manual | No | [RFCXXXX] | 1026 | Answer-Mode | Manual;require | No | [RFCXXXX] | 1027 | Answer-Mode | Auto | No | [RFCXXXX] | 1028 | Answer-Mode | Auto;require | No | [RFCXXXX] | 1029 | Priv-Answer-Mode | Manual | No | [RFCXXXX] | 1030 | Priv-Answer-Mode | Manual;require | No | [RFCXXXX] | 1031 | Priv-Answer-Mode | Auto | No | [RFCXXXX] | 1032 | Priv-Answer-Mode | Auto;require | No | [RFCXXXX] | 1033 +------------------+----------------+-------------------+-----------+ 1035 Editor Note: [RFCXXXX] should be replaced with the designation of 1036 this document. 1038 8.3. Registration of SIP Option Tags 1040 This document defines the SIP option tag "answermode". 1042 The following row shall be added to the "Option Tags" section of the 1043 SIP Parameter Registry: 1045 +------------+------------------------------------------+-----------+ 1046 | Name | Description | Reference | 1047 +------------+------------------------------------------+-----------+ 1048 | answermode | This option tag is for support of the | [RFCXXXX] | 1049 | | Answer-Mode and Priv-Answer-Mode | | 1050 | | extensions used to negotiate automatic | | 1051 | | or manual answering of a request. | | 1052 +------------+------------------------------------------+-----------+ 1054 Editor Note: [RFCXXXX] should be replaced with the designation of 1055 this document. 1057 9. Acknowledgements 1059 This document draws requirements and a large part of its methodology 1060 from the work of the Open Mobile Alliance, and specifically from an 1061 Internet Draft by Andrew Allen, Jan Holm, and Tom Hallin. 1063 The editor would also like to recognize the contributions of David 1064 Oran and others who argued on the SIPPING mailing list and at the OMA 1065 ad-hoc meeting at IETF 62 that the underlying ideas of the above 1066 draft were broadly applicable to the SIP community, and that the 1067 concepts of alerting and answering should be clearly delineated. 1068 Further, the security review provided by Sandy Murphy and gen-art 1069 review by Suresh Krishnan were very helpful in improving the quality 1070 of the document. 1072 10. References 1074 10.1. Normative References 1076 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1077 Requirement Levels", BCP 14, RFC 2119, March 1997. 1079 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1080 A., Peterson, J., Sparks, R., Handley, M., and E. 1081 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1082 June 2002. 1084 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1085 "Indicating User Agent Capabilities in the Session 1086 Initiation Protocol (SIP)", RFC 3840, August 2004. 1088 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1089 Preferences for the Session Initiation Protocol (SIP)", 1090 RFC 3841, August 2004. 1092 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1093 Authenticated Identity Management in the Session 1094 Initiation Protocol (SIP)", RFC 4474, August 2006. 1096 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1097 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1099 10.2. Informative References 1101 [I-D.ietf-mmusic-media-loopback] 1102 Hedayat, K., "An Extension to the Session Description 1103 Protocol (SDP) for Media Loopback", 1104 draft-ietf-mmusic-media-loopback-08 (work in progress), 1105 April 2008. 1107 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1108 Extensions to the Session Initiation Protocol (SIP) for 1109 Asserted Identity within Trusted Networks", RFC 3325, 1110 November 2002. 1112 Authors' Addresses 1114 Dean Willis (editor) 1115 Softarmor Systems 1116 3100 Independence Pkwy #311-164 1117 Plano, Texas 75075 1118 USA 1120 Phone: unlisted 1121 Fax: unlisted 1122 Email: dean.willis@softarmor.com 1123 Andrew Allen 1124 Research in Motion (RIM) 1125 122 West John Carpenter Parkway, Suite 430 1126 Irving, Texas 75039 1127 USA 1129 Phone: unlisted 1130 Fax: unlisted 1131 Email: aallen@rim.com 1133 Full Copyright Statement 1135 Copyright (C) The IETF Trust (2008). 1137 This document is subject to the rights, licenses and restrictions 1138 contained in BCP 78, and except as set forth therein, the authors 1139 retain all their rights. 1141 This document and the information contained herein are provided on an 1142 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1143 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1144 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1145 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1146 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1147 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1149 Intellectual Property 1151 The IETF takes no position regarding the validity or scope of any 1152 Intellectual Property Rights or other rights that might be claimed to 1153 pertain to the implementation or use of the technology described in 1154 this document or the extent to which any license under such rights 1155 might or might not be available; nor does it represent that it has 1156 made any independent effort to identify any such rights. Information 1157 on the procedures with respect to rights in RFC documents can be 1158 found in BCP 78 and BCP 79. 1160 Copies of IPR disclosures made to the IETF Secretariat and any 1161 assurances of licenses to be made available, or the result of an 1162 attempt made to obtain a general license or permission for the use of 1163 such proprietary rights by implementers or users of this 1164 specification can be obtained from the IETF on-line IPR repository at 1165 http://www.ietf.org/ipr. 1167 The IETF invites any interested party to bring to its attention any 1168 copyrights, patents or patent applications, or other proprietary 1169 rights that may cover technology that may be required to implement 1170 this standard. Please address the information to the IETF at 1171 ietf-ipr@ietf.org.