idnits 2.17.1 draft-olson-sipping-refer-extensions-01.txt: -(886): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 36 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 22 characters in excess of 72. ** There are 91 instances of lines with control characters in the document. == There are 16 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 931 has weird spacing: '...riented dialo...' -- 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 (February 16, 2004) is 7375 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) ** Obsolete normative reference: RFC 3265 (ref. '5') (Obsoleted by RFC 6665) == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-03 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-05) exists of draft-mahy-sip-remote-cc-01 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-00 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING S. Olson 3 Internet-Draft O. Levin 4 Expires: August 16, 2004 Microsoft Corporation 5 February 16, 2004 7 Extended-REFER framework and other REFER extensions 8 draft-olson-sipping-refer-extensions-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 16, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document proposes to generalize and extend REFER method for 39 facilitating various advanced functionalities within SIP systems. The 40 new extensions are explicitly signaled by inclusion of new option 41 tags in the Require header of REFER. 43 Table of Contents 45 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 48 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 49 4.1 The Extended REFER Framework . . . . . . . . . . . . . . . . 6 50 4.2 Additional REFER Extensions and Behaviors . . . . . . . . . 7 51 5. Preventing Forking of REFER Requests . . . . . . . . . . . . 8 52 6. Replacing Refer-To URI Syntax with a MIME Body . . . . . . . 9 53 7. Using Arbitrary Event Packages with REFER . . . . . . . . . 11 54 8. Suppressing the REFER Implicit Subscription . . . . . . . . 17 55 9. Applying REFER to SIP Response Codes . . . . . . . . . . . . 19 56 10. Adding callid and tag Parameters to Refer-To Header . . . . 27 57 11. Using of isfocus Feature Parameter with REFER . . . . . . . 28 58 12. REFER with a Referred-By Header with aib . . . . . . . . . . 29 59 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 60 13.1 extended-refer Option Tag Registration . . . . . . . . . . . 30 61 13.2 norefersub Option Tag Registration . . . . . . . . . . . . . 30 62 13.3 refer-response Option Tag Registration . . . . . . . . . . . 30 63 14. Security Considerations . . . . . . . . . . . . . . . . . . 31 64 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 65 References . . . . . . . . . . . . . . . . . . . . . . . . . 33 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 67 Intellectual Property and Copyright Statements . . . . . . . 35 69 1. Terminology 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [1]. 75 To simplify discussions of the REFER method and its extensions, three 76 new terms are being used throughout the document: 78 o REFER-Issuer: the UA issuing the REFER request 80 o REFER-Recipient: the UA receiving the REFER request 82 o REFER-Target: the UA designated in the Refer-To URI 84 2. Introduction 86 The REFER [3] extension to SIP [2] defines a basis for remote call 87 control that is useful for implementing features such as call 88 transfer. In fact, originally the REFER was created by the SIP WG as 89 a generic request to ask another UA to perform an operation on your 90 behalf, which is much more powerful than just the phone-like transfer 91 feature.) 93 REFER has a few limitations with respect to implementing more 94 advanced features in conjunction with the dialog info event package 95 [7]. These limitations derive in part from the limited information 96 available in the message/sipfrag [4] content of the associated 97 NOTIFY. Another limiting factor is the requirement to compress the 98 semantics of the referred request in the Refer-To URI by encoding the 99 desired headers as parameters of that URI. Finally, there are 100 situations where the party issuing the REFER request does not need 101 the NOTIFY associated with the REFER, perhaps because that agent is 102 already subscribed to the appropriate package outside of the REFER 103 request. This represents additional unnecessary traffic and state in 104 the REFER-Issuer and REFER-Recipient. 106 This document proposes to generalize and extend REFER method for 107 facilitating various advanced functionalities within SIP systems. The 108 new extensions are explicitly signaled by inclusion of new option 109 tags in the Require header of REFER. 111 3. Requirements 113 Forking prevention: Prevent forking of a REFER request and allow 114 targeting of that REFER request to a specific device or class of 115 device. 117 Watching period: Allow the REFER-Issuer to watch the progress of the 118 operation triggered by REFER for the whole duration of the 119 requested operation. For example: Beyond the end of the INVITE 120 transaction and for the duration of the remotely established 121 dialog. 123 Richness of the retrieved information: Expose rich information about 124 the requested operation. For example: Expose the dialog 125 information, caller preferences, and user defined headers of the 126 dialog established at the REFER-Recipient as a result of the 127 REFER. 129 Operation efficiency: Reduce the number of messages exchanged to 130 perform a REFER operation. For example, suppress the implicit 131 subscription when the information is known by other means. 133 Operation abstraction: Reduce the amount of detailed knowledge about 134 the remote party that is required from the REFER-Issuer in order 135 to perform a REFER. For example, for remote-cc applications as 136 described in [11]. 138 4. Overview 140 4.1 The Extended REFER Framework 142 The extended REFER behavior is signaled by inclusion of 143 "extended-refer" option tag in the Require header of REFER. If the 144 REFER-Recipient does not understand or does not support the 145 "extended-refer" functionality defined in this specification, it MUST 146 return a 420 (Unsupported Extension) response to the REFER request 147 (as per baseline SIP behavior [2]). The REFER-Issuer SHOULD re-issue 148 the REFER request using URI escaping and only the Refer-To: URI to 149 convey the same information if possible. 151 Support for this extension can be queried in advance using a standard 152 OPTIONS request. 154 This extension defines the following normative functionality for 155 extended REFER method which differs from the basic REFER 156 specification: 158 o Refer-To header contains cid which points to the information 159 placed in the REFER body in MIME form. 161 o The actual format and the meaning of this information are 162 specified by the value of the Content-Type header of REFER. 164 o Additional application documents MAY introduce more complicate 165 behavior logic and MAY require to use multipart MIME body in order 166 to implement this logic. In these cases, the Content-Type header 167 can not provide enough information to specify this logic. In these 168 cases, the application template logic MUST be signaled by 169 additional means such as by inclusion of a new dedicated 170 "disposition type" in the Content-Disposition header of REFER. It 171 is expected that new disposition types will be defined and 172 registered with IANA per application for being used with extended 173 REFER. 175 o The REFER-Issuer MAY specify the request for subscription to any 176 event package by including its MIME type in an Accept header. 177 REFER-Recipient SHOULD maintain the subscription till the 178 operation, requested in REFER, is completed. 180 o REFER-Issuer MAY suppress the implicit refer subscription (by 181 using the norefersub extension) and subscribe to any event 182 package(s) of its interest independently from issuing the REFER. 184 4.2 Additional REFER Extensions and Behaviors 186 Additional REFER extensions and behaviors are defined by this 187 document. Although they are orthogonal to the extended-refer 188 framework, many times they will be used together in advanced SIP 189 applications: 191 o "norefersub" feature tag suppresses implicit REFER subscription. 192 In this case no dialog is established upon issuing REFER and 193 REFER-Issuer MUST ensure that no forking will be applied to REFER 194 in the network. 196 o "refer-response" feature tag allows for injecting responses into 197 remote dialogs. 199 o "isfocus" feature parameter being used with REFER allows for 200 conveying conferencing information to remote parties. 202 For examples of the extended REFER framework usage and additional 203 REFER extensions, please, refer to "SIP Remote CC" [11] and "Multiple 204 REFER" [10]. 206 The following sections discuss the need and specify the mechanism for 207 each of the extended REFER features. 209 5. Preventing Forking of REFER Requests 211 The REFER specification allows for the possibility of forking a REFER 212 request which is sent outside of an existing dialog. In many 213 situation, especially in conjunction with the extended-refer 214 mechanism, forking a REFER may result in absolutely incorrect 215 behavior. This is especially true when the REFER is intended to 216 target a specific device, perhaps with specific capabilities. 218 The REFER-Issuer can ensure that REFER doesn�t get forked by 219 specifying the REFER-Recipient as GRUU according to mechanism defined 220 in [12]. No extension is required. 222 6. Replacing Refer-To URI Syntax with a MIME Body 224 In the original REFER specification, much of the semantics of the 225 REFER request is encapsulated in the Refer-To URI. This URI will 226 commonly encode the method, From, To, Call-ID, Accept-Disposition, 227 Accept-Contact [9], and other headers all in a properly escaped URI. 228 Such a URI can become long, difficult to debug, and prone to URI 229 escaping errors in SIP implementations. The situation becomes more 230 complex if the method is itself a REFER complete with a Refer-To 231 which must contain URI-escaped characters. This double escaping 232 obfuscates things even more and increases the chances of improperly 233 escaping/unescaping of the Refer-To URI. 235 This specification makes use of the currently unused REFER body to 236 encapsulate all the information about the requested operation (and 237 that is placed and potentially escaped in the refer-To URI according 238 to the original specification). The possible information includes the 239 method, headers, and body of the request which is desired to be 240 created by the REFER-Recipient. One obvious candidate for this is the 241 message/sipfrag MIME type. This MIME type can express all of these: 242 the method, Request-URI, headers, and body. 244 Use of additional REFER MIME bodies MAY be defined in separate 245 application specifications. 247 According to this specification, a cid URI [6] is placed in the 248 Refer-To header to reference the MIME content in the body of the 249 REFER. 251 In the example below, the body of the extended REFER is of type 252 message/sipfrag. 254 According to the basic REFER specification: 256 REFER sip:b@tradewind.com SIP/2.0 257 Via: SIP/2.0/TCP issuer.tradewind.com;branch=z9hG4bK-a-1 258 From: ;tag=1a 259 To: 260 Call-ID: 1@issuer.tradewind.com 261 CSeq: 234234 REFER 262 Max-Forwards: 70 263 Refer-To: 265 Accept: application/dialog-info+xml;q=0.5, message/sipfrag;q=0.1 266 Contact: sip:a@issuer.tradewind.com 267 Content-Length: 0 269 According to this extended REFER specification: 271 REFER sip:b@tradewind.com SIP/2.0 272 Via: SIP/2.0/TCP issuer.tradewind.com;branch=z9hG4bK-a-1 273 From: ;tag=1a 274 To: 275 Call-ID: 1@issuer.tradewind.com 276 Supported: gruu 277 CSeq: 234234 REFER 278 Max-Forwards: 70 279 Refer-To: cid:1239103912039@issuer.tradewind.com 280 Accept: application/dialog-info+xml;q=0.5, message/sipfrag;q=0.1 281 Require: extended-refer 282 Contact: sip:a@issuer.tradewind.com 283 Content-Type: message/sipfrag 284 Content-Id: <1239103912039@issuer.tradewind.com> 285 Content-Length: ... 287 SIP/2.0 200 OK 288 Call-ID: 1@target.tradewind.com 289 From: b@tradewind.com;tag=2b 290 To: c@tradewind.com;tag=1c 292 If the REFER-Recipient does not understand or doesn�t support the 293 extended-refer option tag, it MUST return a 420 (Unsupported 294 Extension) response to the REFER request (as per baseline SIP 295 behavior [2]). The REFER-Issuer SHOULD re-issue the REFER request 296 using URI escaping and only the Refer-To: URI to convey the same 297 information if possible. 299 7. Using Arbitrary Event Packages with REFER 301 The REFER specification [3] mandates the use of the message/sipfrag 302 [4] MIME type for NOTIFYs of the refer event package. These NOTIFYs 303 are sent as part of the implicit subscription created by the REFER. 304 The purpose of the NOTIFY is to communicate the state of the 305 transaction between the REFER-Recipient and the REFER-Target that is 306 created as a result of the REFER 308 Where the purpose of sending the REFER is actually to ask to perform 309 an operation, for example through an INVITE, the derivative state of 310 interest is actually the progress and the result of this operation. 311 While in some cases this may be inferred from the contents of the 312 message/sipfrag body this information is neither general (abstract) 313 nor sufficient. 315 To address this shortcoming, this specification extends REFER to 316 allow the use of any event package format. (Furthermore, subscription 317 to the event package(s) MAY be decoupled from issuing the REFER. This 318 is done by suppressing the implicit subscription as defined later in 319 this document). 321 The REFER-Issuer MAY specify the request for subscription to a 322 specific package by including the MIME type in an Accept header. 323 REFER-Recipient SHOULD maintain the subscription till the completion 324 of the requested operation. For example, in case of method=INVITE, 325 for the duration of the resultant (INVITE) dialog and RECOMMENDED 326 that the subscription be maintained at least until the dialog is in 327 "confirmed" state. 329 In the INVITE example, two things that are generally lacking from the 330 message/sipfrag content are the dialog identifier (Call-ID plus local 331 and remote tags) and the state of the dialog. Not coincidentally, 332 this is the same information available in the application/ 333 dialog-info+xml MIME type [7] used for the dialog event package. 335 Figure 1: Example of using application/dialog-info+xml 337 REFER-Issuer REFER-Recipient REFER-Target 338 | | | 339 | M1 REFER (INVITE) | | 340 |--------------------------->| | 341 | M2 202 Accepted | | 342 |<---------------------------| | 343 | M3 NOTIFY | | 344 |<---------------------------| | 345 | M4 200 OK | | 346 |--------------------------->| | 347 | | M5 INVITE | 348 | |----------------------->| 349 | M6 NOTIFY | | 350 |<---------------------------| | 351 | M7 200 OK | | 352 |--------------------------->| | 353 | | M8 180 Ringing | 354 | |<-----------------------| 355 | M9 NOTIFY | | 356 |<---------------------------| | 357 | M10 200 OK | | 358 |--------------------------->| | 359 | | M11 200 OK | 360 | |<-----------------------| 361 | M12 NOTIFY | | 362 |<---------------------------| | 363 | M13 200 OK | | 364 |--------------------------->| M14 ACK | 365 | |----------------------->| 367 Message flow: 369 M1: The REFER-Issuer creates a REFER, specifying support for 370 extended-refer and expressing its interest in the application/ 371 dialog-info+xml MIME type. 373 REFER sip:b@tradewind.com SIP/2.0 374 Via: SIP/2.0/TCP issuer.tradewind.com;branch=z9hG4bK-a-1 375 From: ;tag=1ab 376 To: 377 Call-ID: 1@issuer.tradewind.com 378 Supported: gruu 379 CSeq: 234234 REFER 380 Max-Forwards: 70 381 Refer-To: cid:1239103912039@issuer.tradewind.com 382 Accept: application/dialog-info+xml 383 Require: extended-refer 384 Contact: sip:a@issuer.tradewind.com 385 Content-Type: message/sipfrag 386 Content-Id: <1239103912039@issuer.tradewind.com> 387 Content-Length: ... 389 M5: The REFER-Recipient creates an appropriate INVITE based on the 390 REFER and sends it to the REFER-Target. 392 INVITE sip:c@tradewind.com SIP/2.0 393 Via: SIP/2.0/TCP recipient.tradewind.com;branch=z9hG4bK-b-1 394 From: ;tag=1bc 395 To: 396 Call-ID: 1@recipient.tradewind.com 397 CSeq: 1234567 INVITE 398 Max-Forwards: 70 399 Contact: sip:b@recipient.tradewind.com 400 Content-Length: ... 402 404 M6: The REFER-Recipient sends a NOTIFY triggered by the INVITE being 405 sent to the REFER-Target. The body of the NOTIFY contains the 406 dialog identifier and current state ("trying"). 408 NOTIFY sip:a@issuer.tradewind.com SIP/2.0 409 Via: SIP/2.0/TCP recipient.tradewind.com;branch=z9hG4bK-b-2 410 From: ;tag=1ab 411 To: ;tag=1ba 412 Call-ID: 1@issuer.tradewind.com 413 CSeq: 1278784 NOTIFY 414 Max-Forwards: 70 415 Event: refer;id=234234 416 Subscription-State: active;expires=3600 417 Contact: sip:b@recipient.tradewind.com 418 Content-Type: application/dialog-info+xml 419 Content-Length: ... 421 422 426 429 trying 430 431 433 M9: The REFER-Recipient sends a NOTIFY triggered by the 180 Ringing 434 received from the REFER-Target. The body of the NOTIFY contains 435 the dialog identifier and current state ("early"). 437 NOTIFY sip:a@issuer.tradewind.com SIP/2.0 438 Via: SIP/2.0/TCP recipient.tradewind.com;branch=z9hG4bK-b-3 439 From: ;tag=1ab 440 To: ;tag=1ba 441 Call-ID: 1@issuer.tradewind.com 442 CSeq: 1278785 NOTIFY 443 Max-Forwards: 70 444 Event: refer;id=234234 445 Subscription-State: active;expires=3600 446 Contact: sip:b@recipient.tradewind.com 447 Content-Type: application/dialog-info+xml 448 Content-Length: ... 450 451 455 458 early 459 460 462 M12: The REFER-Recipient sends a NOTIFY triggered by the 200 OK 463 received from the REFER-Target. The body of the NOTIFY contains 464 the dialog identifier and current state ("confirmed"). 466 NOTIFY sip:a@issuer.tradewind.com SIP/2.0 467 Via: SIP/2.0/TCP recipient.tradewind.com;branch=z9hG4bK-b-4 468 From: ;tag=1ab 469 To: ;tag=1ba 470 Call-ID: 1@issuer.tradewind.com 471 CSeq: 1278786 NOTIFY 472 Max-Forwards: 70 473 Event: refer;id=234234 474 Subscription-State: active;expires=3600 475 Contact: sip:b@recipient.tradewind.com 476 Content-Type: application/dialog-info+xml 477 Content-Length: ... 479 480 484 487 confirmed 488 489 491 8. Suppressing the REFER Implicit Subscription 493 The REFER specification mandates that every REFER creates an implicit 494 subscription between the REFER-Issuer and the REFER-Recipient. This 495 subscription results in at least one NOTIFY being sent from the 496 REFER-Recipient to the REFER-Issuer. The REFER-Recipient may choose 497 to cancel the implicit subscription with this NOTIFY. The 498 REFER-Issuer may choose to cancel this implicit subscription with an 499 explicit SUBSCRIBE (Expires: 0) after receipt of the initial NOTIFY 500 or by sending a 481 response to this initial NOTIFY request. 502 The purpose of requiring the implicit subscription and initial NOTIFY 503 is to allow for the situation where the REFER request gets forked and 504 the REFER-Issuer needs a way to see the multiple dialogs that may be 505 established as a result of the forked REFER. This is the same 506 approach used to handle forking of SUBSCRIBE [5] requests. Where the 507 REFER-Issuer explicitly specifies that forking not occur, the 508 requirement that an implicit subscription be established is 509 unnecessary. 511 Another purpose of the NOTIFY is to inform the REFER-Issuer of the 512 progress of the SIP transaction that results from the REFER at the 513 REFER-Recipient. In the case where the REFER-Issuer is already aware 514 of the progress of the requested operation, such as when the 515 REFER-Issuer has an explicit subscription to the dialog event package 516 at the REFER-Recipient, the implicit subscription and resultant 517 NOTIFY traffic related to the REFER is superfluous and unnecessary 518 network overhead. 520 To avoid this unnecessary overhead, this document defines a new 521 option tag, norefersub, which specifies that an implicit subscription 522 for event package refer should not be created as a result of 523 accepting this REFER request. Consequently, no dialog is created as 524 the result of sending REFER with Require header containing the 525 norefersub option tag. 527 This MUST be used by the REFER-Issuer only when the REFER-Issuer can 528 be certain that the REFER request will not be forked. The 529 REFER-Recipient MUST signal support for this extension by inserting a 530 Supported: norefersub header in the 2xx response to the REFER 531 request. 533 Example of extended REFER which suppresses the implicit subscription 534 REFER sip:b@tradewind.com SIP/2.0 535 Via: SIP/2.0/TCP issuer.tradewind.com;branch=z9hG4bK-a-1 536 From: ;tag=1a 537 To: 538 Call-ID: 1@issuer.tradewind.com 539 Supported: gruu 540 CSeq: 234234 REFER 541 Max-Forwards: 70 542 Refer-To: 543 Require: extended-refer; norefersub 544 Accept-Contact: *;audio;require 545 Contact: sip:a@issuer.tradewind.com 546 Content-Type: message/sipfrag 547 Content-Id: <1239103912039@issuer.tradewind.com> 548 Content-Length: ... 550 9. Applying REFER to SIP Response Codes 552 The original REFER is defined to trigger the sending of a request 553 from the REFER-Recipient to the REFER-Target. The intention is most 554 often to initiate a dialog from the REFER-Recipient to the 555 REFER-Target. This is an excellent way to generate an action at the 556 REFER-Recipient based on an event or action that takes places at the 557 REFER-Issuer. The classic example is call transfer as a result of a 558 user at the REFER-Issuer taking some action. 560 With the use of the dialog event package, it is possible for one UA 561 to monitor events at another UA related to a dialog, such as the 562 receipt of an INVITE to establish a new dialog. What is lacking is a 563 way for the watcher to indicate what should be the response to such 564 an INVITE request. For example, the dialog watcher would like the 565 recipient of the session initiation request to accept the initiation 566 (send a 200 OK response to the INVITE request). One motivating 567 scenario for this is a set of co-operating User Agents (devices) that 568 belong to the same user. The user, while using one SIP device, wishes 569 to answer a call that is being received on another of that user's SIP 570 devices. This gives the user a single UI focus for control while 571 allowing multiple devices with differing capabilities. 573 To enable such a scenario, this document defines an extension to the 574 SIP(S) URI syntax as defined in SIP [2]. The extension is analogous 575 to the "method" uri-parameter that currently exists to communicate a 576 method for use in the Refer-To header. A new uri-parameter, 577 "response", is proposed that is used in conjunction with the "method" 578 uri-parameter and associated call-id, local tag, and remote tag to 579 request that the REFER-Recipient send a response within the 580 identified SIP transaction to the REFER-Target. 582 TBD: Generalize the discussion of the "response" uri-parameter to be 583 used with methods other than REFER. 585 The REFER-Issuer MUST specify a "method" parameter in addition to the 586 "response" parameter. The REFER-Issuer MUST also include the 587 appropriate local-uri, local-tag, remote-uri, and remote-tag encoded 588 as From and To headers in the Refer-To URI (or using a message/ 589 sipfrag body when used in conjunction with the extended-refer 590 mechanism). Note that in order to satisfy this requirement, the 591 REFER-Issuer must have access to this information. In particular, it 592 is assumed that the REFER-Issuer receives the local-uri and 593 remote-uri in the NOTIFY for the dialog event package from the 594 REFER-Recipient. These elements are optional in the XML schema. It is 595 anticipated that User Agents that support these REFER extensions will 596 also include these optional elements in the application/ 597 dialog-info+xml payload (as privacy concerns allow). 599 To ensure the REFER-Recipient conformant with RFC3515 does not 600 misinterpret this as a REFER to send a request of the specified 601 method, the REFER-Issuer MUST also include a Require: refer-response 602 header in the REFER request. REFER-Recipients which do not understand 603 this extension will return a 420 response. The REFER-Target does not 604 need to understand this extension for this to work. Support for this 605 extension can be queried in advance using a standard OPTIONS request. 607 The REFER-Issuer MUST request the use of the application/ 608 dialog-info+xml MIME type in NOTIFYs associated with a REFER request 609 which uses the "refer-response" extension. 611 Note that, although it is RECOMMENDED to use the "refer-response" 612 extension in conjunction to the "extended-refer" framework, the 613 extensions are orthogonal to each other. The extended REFER framework 614 does not include the "refer-response" behavior by default. The 615 "refer-response" extension can be used both with the original REFER 616 mechanism and with the extended REFER framework. 618 uri-parameters = *( ";" uri-parameter) 619 uri-parameter = transport-param / user-param / method-param 620 / ttl-param / maddr-param / lr-param / response-param / other-param 621 response-param = "response=" 1*3DIGIT 623 An example call flow follows: 625 Figure 2: Example of using the "response" uri-parameter in the 626 Refer-To header 628 REFER-Issuer REFER-Recipient REFER-Target 629 | | | 630 | N1 SUBSCRIBE (dialog) | | 631 |--------------------------->| | 632 | N2 202 Accepted | | 633 |<---------------------------| | 634 | N3 NOTIFY | | 635 |<---------------------------| | 636 | N4 200 OK | | 637 |--------------------------->| | 638 | | N5 INVITE | 639 | |<-----------------------| 640 | N6 NOTIFY | | 641 |<---------------------------| | 642 | N7 200 OK | | 643 |--------------------------->| | 644 | | N8 180 Trying | 645 | |----------------------->| 646 | N9 NOTIFY | | 647 |<---------------------------| | 648 | N10 200 OK | | 649 |--------------------------->| | 650 | | | 651 | N11 REFER (200) | | 652 |--------------------------->| | 653 | N12 200 OK | | 654 |<---------------------------| N13 200 | 655 | |----------------------->| 656 | N14 NOTIFY | | 657 |<---------------------------| | 658 | N15 200 OK | | 659 |--------------------------->| | 661 Message flow: 663 N1: The REFER-Issuer subscribes to the dialog event package at the 664 REFER-Recipient. 666 SUBSCRIBE sip:b@tradewind.com SIP/2.0 667 Via: SIP/2.0/TCP issuer.tradewind.com;branch=z9hG4bK-a-1 668 From: ;tag=1ab 669 To: 670 Call-ID: 1@issuer.tradewind.com 671 CSeq: 234234 SUBSCRIBE 672 Max-Forwards: 70 673 Event: dialog 674 Accept: application/dialog-info+xml 675 Contact: sip:a@issuer.tradewind.com 676 Content-Length: 0 678 N5: The REFER-Recipient receives an INVITE from the REFER-Target to 679 start a new call. 681 INVITE sip:b@tradewind.com SIP/2.0 682 Via: SIP/2.0/TCP target.tradewind.com;branch=z9hG4bK-c-1 683 From: ;tag=1cb 684 To: 685 Call-ID: 1@target.tradewind.com 686 CSeq: 1234567 INVITE 687 Max-Forwards: 70 688 Contact: sip:c@target.tradewind.com 689 Content-Length: ... 691 693 N6: The REFER-Recipient sends a NOTIFY triggered by the INVITE 694 received from the REFER-Target. The body of the NOTIFY contains 695 the dialog identifier and current state ("trying"). 697 NOTIFY sip:a@issuer.tradewind.com SIP/2.0 698 Via: SIP/2.0/TCP recipient.tradewind.com;branch=z9hG4bK-b-2 699 From: ;tag=1ab 700 To: ;tag=1ba 701 Call-ID: 1@issuer.tradewind.com 702 CSeq: 454545 NOTIFY 703 Max-Forwards: 70 704 Event: dialog;id=234234 705 Subscription-State: active;expires=3600 706 Contact: sip:b@recipient.tradewind.com 707 Content-Type: application/dialog-info+xml 708 Content-Length: ... 710 711 715 718 b@tradewind.com 719 c@tradewind.com 720 trying 721 722 724 N8: The REFER-Recipient sends a 180 Ringing response to the 725 REFER-Target. 727 SIP/2.0 180 Ringing 728 Via: SIP/2.0/TCP target.tradewind.com;branch=z9hG4bK-b-3 729 From: ;tag=1cb 730 To: ;tag=1bc 731 Call-ID: 1@target.tradewind.com 732 CSeq: 1234567 INVITE 733 Contact: sip:b@recipient.tradewind.com 734 Content-Length: 0 736 N9: The REFER-Recipient sends a NOTIFY triggered by the 180 Ringing 737 sent to the REFER-Target. The body of the NOTIFY contains the 738 dialog identifier and current state ("early"). 740 NOTIFY sip:a@issuer.tradewind.com SIP/2.0 741 Via: SIP/2.0/TCP recipient.tradewind.com;branch=z9hG4bK-b-4 742 From: ;tag=1ab 743 To: ;tag=1ba 744 Call-ID: 1@issuer.tradewind.com 745 CSeq: 454546 NOTIFY 746 Max-Forwards: 70 747 Event: dialog;id=234234 748 Subscription-State: active;expires=3600 749 Contact: sip:b@recipient.tradewind.com 750 Content-Type: application/dialog-info+xml 751 Content-Length: ... 753 754 758 761 b@tradewind.com 762 c@tradewind.com 763 early 764 765 767 N11: The REFER-Issuer creates a REFER, specifying that the 768 REFER-Recipient should send a 200 OK to accept the session 769 invitation. The From and To headers of the 200 OK are encoded in 770 the Refer-To URI. The local and remote tags for this are 771 determined from the information provided in the NOTIFY for the 772 dialog package. This allows the REFER-Issuer to specify a 773 particular dialog. Combined with the "method" parameter, this 774 identifies a specific transaction within the dialog. 776 REFER sip:b@tradewind.com SIP/2.0 777 Via: SIP/2.0/TCP issuer.tradewind.com;branch=z9hG4bK-a-2 778 From: ;tag=1ab 779 To: 780 Call-ID: 2@issuer.tradewind.com 781 CSeq: 818181 REFER 782 Max-Forwards: 70 783 Accept: application/dialog-info+xml;q=0.5, message/sipfrag;q=0.1 784 Require: refer-response 785 Refer-To: 787 Contact: sip:a@issuer.tradewind.com 788 Content-Length: 0 790 N13: The REFER-Recipient sends a 200 OK to the REFER-Target 791 constructed using the information in the Refer-To header. 793 SIP/2.0 200 OK 794 Via: SIP/2.0/TCP target.tradewind.com;branch=z9hG4bK-c-1 795 From: ;tag=1cb 796 To: ;tag=1bc 797 Call-ID: 1@target.tradewind.com 798 Supported: refer-response 799 CSeq: 1234567 INVITE 800 Contact: sip:b@recipient.tradewind.com 801 Content-Length: 0 803 N14: The REFER-Recipient sends a NOTIFY triggered by the 200 OK sent 804 to the REFER-Target. The body of the NOTIFY contains the dialog 805 identifier and current state ("confirmed"). 807 NOTIFY sip:a@issuer.tradewind.com SIP/2.0 808 Via: SIP/2.0/TCP recipient.tradewind.com;branch=z9hG4bK-b-4 809 From: ;tag=1ab 810 To: ;tag=1ba 811 Call-ID: 1@issuer.tradewind.com 812 CSeq: 454547 NOTIFY 813 Max-Forwards: 70 814 Event: dialog;id=234234 815 Subscription-State: active;expires=3600 816 Contact: sip:b@recipient.tradewind.com 817 Content-Type: application/dialog-info+xml 818 Content-Length: ... 820 821 825 828 b@tradewind.com 829 c@tradewind.com 830 confirmed 831 832 834 10. Adding callid and tag Parameters to Refer-To Header 836 TBD: Motivation and examples. 838 11. Using of isfocus Feature Parameter with REFER 840 This specification allows for using of isfocus feature parameter 841 defined in [8] with REFER. 843 TBD: Motivation and examples. 845 12. REFER with a Referred-By Header with aib 847 REFER with a Referred-By header with an authenticated identity body 848 (aib) with multipart MIME. 850 TBD: Mechanism and examples. 852 13. IANA Considerations 854 13.1 extended-refer Option Tag Registration 856 This document defines a new option tag, extended-refer, which 857 specifies that the recipient of the REFER request is expected to 858 understand and act upon the extended REFER framework as specified in 859 this document. This option tag is only meaningful for the REFER 860 request defined in RFC3515. 862 13.2 norefersub Option Tag Registration 864 This document defines a new option tag, norefersub, which specifies 865 that an implicit subscription for event package refer should not be 866 created as a result of accepting this REFER request. This option tag 867 is only meaningful for the REFER request defined in RFC3515. 869 13.3 refer-response Option Tag Registration 871 This document defines a new option tag, refer-response, which 872 specifies that the recipient of the REFER request is expected to 873 issue a response for the SIP transaction requested within the REFER. 874 This option tag is only meaningful for the REFER request defined in 875 RFC3515. 877 14. Security Considerations 879 Security considerations regarding inclusion of sensitive information 880 inside the REFER body in MIME format will be addressed in the next 881 version of this document. 883 15. Acknowledgements 885 The authors would like to thank Rohan Mahy, Gonzallo Camarillo, and 886 Fran�ois Audet for their insightful comments and inputs. The authors 887 would also like to thank Sriram Parameswar for his ideas being 888 originally presented in draft-parameswar-sipping-norefersub-00 and 889 incorporated in this document. 891 References 893 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 894 Levels", BCP 14, RFC 2119, March 1997. 896 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 897 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 898 Session Initiation Protocol", RFC 3261, June 2002. 900 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 901 Method", RFC 3515, April 2003. 903 [4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 904 November 2002. 906 [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 907 Notification", RFC 3265, June 2002. 909 [6] Levinson, E., "Content-ID and Message-ID Uniform Resource 910 Locators", RFC 2392, August 1998. 912 [7] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog 913 Event Package for the Session Initiation Protocol (SIP)", 914 draft-ietf-sipping-dialog-package-03 (work in progress), 915 October 2003. 917 [8] Rosenberg, J., "Indicating User Agent Capabilities in the 918 Session Initiation Protocol (SIP)", 919 draft-ietf-sip-callee-caps-03 (work in progress), January 2004. 921 [9] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller 922 Preferences for the Session Initiation Protocol (SIP)", 923 draft-ietf-sip-callerprefs-10 (work in progress), October 2003. 925 [10] Camarillo, G., "Refering to Multiple Resources in the Session 926 Initiation Protocol (SIP)", 927 draft-camarillo-sipping-multiple-refer-00 (work in progress), 928 February 2004. 930 [11] Mahy, R., "Remote Call Control in SIP using the REFER method 931 and the session-oriented dialog package", 932 draft-mahy-sip-remote-cc-01 (work in progress), February 2004. 934 [12] Rosenberg, J., "Obtaining and Using Globally Routable User 935 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 936 (SIP)", draft-ietf-sip-gruu-00 (work in progress), January 937 2004. 939 Authors' Addresses 941 Sean Olson 942 Microsoft Corporation 943 One Microsoft Way 944 Redmond, WA 98052 945 USA 947 Phone: +1-425-707-2846 948 EMail: seanol@microsoft.com 950 Orit Levin 951 Microsoft Corporation 952 One Microsoft Way 953 Redmond, WA 98052 954 USA 956 Phone: +1-425-722-2225 957 EMail: oritl@microsoft.com 959 Intellectual Property Statement 961 The IETF takes no position regarding the validity or scope of any 962 intellectual property or other rights that might be claimed to 963 pertain to the implementation or use of the technology described in 964 this document or the extent to which any license under such rights 965 might or might not be available; neither does it represent that it 966 has made any effort to identify any such rights. Information on the 967 IETF's procedures with respect to rights in standards-track and 968 standards-related documentation can be found in BCP-11. Copies of 969 claims of rights made available for publication and any assurances of 970 licenses to be made available, or the result of an attempt made to 971 obtain a general license or permission for the use of such 972 proprietary rights by implementors or users of this specification can 973 be obtained from the IETF Secretariat. 975 The IETF invites any interested party to bring to its attention any 976 copyrights, patents or patent applications, or other proprietary 977 rights which may cover technology that may be required to practice 978 this standard. Please address the information to the IETF Executive 979 Director. 981 Full Copyright Statement 983 Copyright (C) The Internet Society (2004). All Rights Reserved. 985 This document and translations of it may be copied and furnished to 986 others, and derivative works that comment on or otherwise explain it 987 or assist in its implementation may be prepared, copied, published 988 and distributed, in whole or in part, without restriction of any 989 kind, provided that the above copyright notice and this paragraph are 990 included on all such copies and derivative works. However, this 991 document itself may not be modified in any way, such as by removing 992 the copyright notice or references to the Internet Society or other 993 Internet organizations, except as needed for the purpose of 994 developing Internet standards in which case the procedures for 995 copyrights defined in the Internet Standards process must be 996 followed, or as required to translate it into languages other than 997 English. 999 The limited permissions granted above are perpetual and will not be 1000 revoked by the Internet Society or its successors or assignees. 1002 This document and the information contained herein is provided on an 1003 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1004 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1005 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1006 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1007 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1009 Acknowledgment 1011 Funding for the RFC Editor function is currently provided by the 1012 Internet Society.