idnits 2.17.1 draft-worley-sip-many-refers-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 304. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 18, 2006) is 6521 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP D. R. Worley 3 Internet-Draft Pingtel 4 Expires: December 20, 2006 June 18, 2006 6 The Five Meanings of the REFER Method 7 draft-worley-sip-many-refers-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 20, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The REFER method is defined in RFC 3515. That RFC defines the syntax 41 of the REFER request and some of the machinery involved in its 42 execution, but it defines the semantics of the method only so far as 43 to specify that the recipient will initiate a request to the target 44 specified in the Refer-To header. But since almost all requests that 45 can be sent by the recipient are inherently part of an encompassing 46 UA action that affects the state of the recipient in ways that are 47 not directly reflected in SIP protocol actions, the standardized 48 action of initiating a request implicitly has further consequences 49 which are often not clearly specified. As a result, various SIP 50 call-control proposals assume that a UA receiving a REFER will 51 perform the UA operation that is needed at that moment without 52 specifying clearly how the UA recognizes which UA operation is 53 needed. As a result there are now five semantically distinct defined 54 uses of REFER. All five uses bear a family resemblance, and each 55 involves sending a SIP request, but the exact meaning of each use is 56 logically independent of the others, and the rules by which a UA 57 distinguishes the five cases are at best implicit. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. The Meanings . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Remote Dial . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Third-Party Conference Departure . . . . . . . . . . . . . 4 66 2.4. Remote Hangup . . . . . . . . . . . . . . . . . . . . . . 5 67 2.5. Remotely Induced Response . . . . . . . . . . . . . . . . 5 68 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 5. Informative References . . . . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 Intellectual Property and Copyright Statements . . . . . . . . . . 10 74 1. Introduction 76 The REFER method is defined in [1]. That RFC defines the syntax of 77 the REFER request, that its recipient is expected to "contact" the 78 resource designated by the Refer-To URI, and some of the machinery 79 involved in its execution. But the RFC does not specify what the 80 request causes the recipient to do in relationship to other SIP 81 dialogs, its users, etc. This allows a SIP call-control process to 82 assume that a REFER will cause the UA to perform the operation that 83 would be convenient for that particular call-control process - an 84 operation which would naturally be implemented by sending the SIP 85 request specified, but unfortunately, the implementing SIP request 86 does not uniquely determine the UA operation. As a result, there are 87 now five defined uses of REFER. All five uses bear a family 88 resemblance, but the exact meaning of each use is logically 89 independent of the others. 91 The purpose of this document is to enumerate all semantically 92 distinct uses of REFER, expose the logic that is used to determine 93 which use is implied by any particular REFER request, and to make 94 people aware of the need to clearly specify any additional uses they 95 desire to create. The reader is expected to be familiar with the 96 machinery of the REFER request as described in [1]. 98 2. The Meanings 100 2.1. Remote Dial 102 The simplest application of REFER can be called "remote dial" [2]. 103 In this usage, a REFER is sent out-of-dialog to a recipient UA. The 104 recipient UA sends a dialog-initiating INVITE to the Refer-To URI, to 105 establish a dialog for its user. 107 At first sight, this use may appear unlikely in practice, but sending 108 such a REFER to a UA can be used to induce it to join a conference 109 [4]. (That is feasible because each conference has a unique 110 "conference URI".) Similarly, a remote dial REFER can be sent to a 111 conference focus to induce it to send an INVITE to a UA that one 112 wishes to have join the conference. This is a natural way to 113 implement "click-to-dial" functionality. 115 2.2. Transfer 117 The most popular use of REFER is for transferring calls [3]. From a 118 user perspective, there are several different kinds of call transfer, 119 but in all cases, the crucial step is performed by a REFER request. 120 Using the terminology of [3], there is an existing dialog between 121 Transferor and Transferee. Transferor wants to terminate that 122 dialog, changing Transferee's focus from the existing dialog to a new 123 dialog with Transfer Target. 125 This action is done by Transferor sending a REFER in the existing 126 dialog to Transferee. Transferee sends a dialog-initiating INVITE to 127 Transfer Target. If and when the INVITE receives a successful 128 response, Transferee terminates the original dialog and changes its 129 focus to the new dialog. 131 2.3. Third-Party Conference Departure 133 Another envisioned use of REFER is to delete a third party from a 134 conference [5]. In this use, the executor sends a REFER with a 135 Refer-To containing the header parameter "method=BYE" to a conference 136 focus, causing it to send a BYE to the participant. 138 In this use of REFER, the recipient UA is requested to insert a BYE 139 request into an existing dialog, rather than sending an out-of-dialog 140 request. The dialog in question is implicitly identified by the 141 Refer-To URI, which is expected to be the URI of a participant in the 142 conference. Of course, this requires that there be only one 143 participant in the conference that entered using that URI. 145 2.4. Remote Hangup 147 REFER can also be used more generally to terminate a dialog by 148 causing one UA in the dialog to send a BYE request. The dialog to be 149 terminated is specified by using Call-ID, To, and From header 150 parameters in the Refer-To URI [2] to specify that the BYE should be 151 sent within the specified dialog. The example given in [2] is (after 152 correcting the escaping): 154 sip:bob@babylon.biloxi.example.com;method=BYE 155 ?Call-ID=13413098 156 &To=%3Csip:bob%40biloxi.com%3E%3Btag%3D879738 157 &From=%3Csip:alice%40atlanta.example.com%3E%3Btag%3D023214 159 Beware that using header parameters to specify Call-ID and From 160 headers contravenes section 19.1.5 of RFC 3261 [8]. We interpret 161 this contradiction to mean that the values specified must be 162 validated by the UA to match one of its dialogs (and that the REFER 163 requester is allowed to manipulate that dialog). 165 2.5. Remotely Induced Response 167 The Internet-Draft [6] proposes a URI parameter "response" to be used 168 in the Refer-To URI. Its presence indicates that the recipient of 169 the REFER should send a response to one of its existing early 170 dialogs, using the value of the "response" URI parameter as the 171 response code. The early dialog in question is identified by the 172 Target-Dialog header in the REFER request. 174 However, it is not clear (to this author) whether this use of Target- 175 Dialog is semantically compatible with the definition given in [7], 176 which specifies that Target-Dialog is to be used to authorize a 177 request because "it indicates to the recipient that the sender is 178 aware of an existing dialog with the recipient". 180 3. Summary 182 +----------+--------------------+-----------------------------------+ 183 | Meaning | Distinguishing | Action | 184 | | features | | 185 +----------+--------------------+-----------------------------------+ 186 | Remote | Out-of-dialog, | UA sends a dialog-initiating | 187 | Dial | method=INVITE | INVITE to Refer-To URI. | 188 | | | | 189 | Transfer | In-dialog, | UA sends a dialog-initiating | 190 | #1 | method=INVITE | INVITE to Refer-To URI. When new | 191 | | | dialog is confirmed, UA | 192 | | | terminates the original dialog | 193 | | | transfers its focus to the new | 194 | | | dialog. | 195 | | | | 196 | Transfer | Out-of-dialog, | (Same implementation as Transfer | 197 | #2 | method=INVITE, | #1.) UA sends a dialog- | 198 | | Replaces header | initiating INVITE with a Replaces | 199 | | parameter | header to Refer-To URI. when new | 200 | | | dialog is conformed (thus | 201 | | | replacing the specified dialog | 202 | | | at the Refer-To URI), UA | 203 | | | terminates the original dialog | 204 | | | and transfers its focus to the | 205 | | | new dialog. | 206 | | | | 207 | Transfer | Out-of-dialog, | (Same implementation as Remote | 208 | #3 | method=INVITE, | Dial.) UA sends a dialog- | 209 | | Replaces header | initiating INVITE with a Replaces | 210 | | parameter | header to Refer-To URI. New | 211 | | | dialog replaces the specified | 212 | | | dialog at the Refer-To UA. | 213 | | | | 214 | Third- | recipient is conf. | Conference focus uses Refer-To | 215 | Party | URI, method=BYE | URI to look up a dialog currently | 216 | Conf. | | in the conference, then | 217 | Depart. | | terminates it by sending BYE on | 218 | | | it. | 219 | | | | 220 | Remote | method-BYE, | UA terminates the specified | 221 | Hangup | Call-ID, To, and | dialog by sending BYE on it. | 222 | | From header | | 223 | | parameters | | 224 | | | | 225 +----------+--------------------+-----------------------------------+ 226 | Meaning | Distinguishing | Action | 227 | | features | | 228 +----------+--------------------+-----------------------------------+ 229 | (cont'd.) | 230 | | | | 231 | Remotely | response URI | UA sends the specified response | 232 | Induced | parameter, Target- | to the early dialog identified by | 233 | Response | Dialog header | the Target-Dialog header. | 234 +----------+--------------------+-----------------------------------+ 236 4. Security Considerations 238 None. 240 5. Informative References 242 [1] Sparks, R., "The Session Initiation Protocol (SIP) Refer 243 Method", RFC 3515, April 2003. 245 [2] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D., 246 and A. Johnston, "A Call Control and Multi-party usage framework 247 for the Session Initiation Protocol (SIP)", March 2006. 249 [3] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation 250 Protocol Call Control - Transfer", March 2006. 252 [4] Rosenberg, J., "A Framework for Conferencing with the Session 253 Initiation Protocol (SIP)", RFC 4353, February 2006. 255 [5] Johnston, A. and O. Levin, "Session Initiation Protocol Call 256 Control - Conferencing for User Agents", June 2005. 258 [6] Mahy, R. and C. Jennings, "Remote Call Control in SIP using the 259 REFER method and the session-oriented dialog package", 260 October 2005. 262 [7] Rosenberg, J., "Request Authorization through Dialog 263 Identification in the Session Initiation Protocol (SIP)", 264 December 2005. 266 [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 267 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 268 Session Initiation Protocol", RFC 3261, June 2002. 270 Author's Address 272 Dale R. Worley 273 Pingtel Corp. 274 400 West Cummings Park, Suite 2200 275 Woburn, MA 01801 276 US 278 Phone: +1 781 938 5306 x173 279 Email: dworley@pingtel.com 280 URI: http://www.pingtel.com 282 Intellectual Property Statement 284 The IETF takes no position regarding the validity or scope of any 285 Intellectual Property Rights or other rights that might be claimed to 286 pertain to the implementation or use of the technology described in 287 this document or the extent to which any license under such rights 288 might or might not be available; nor does it represent that it has 289 made any independent effort to identify any such rights. Information 290 on the procedures with respect to rights in RFC documents can be 291 found in BCP 78 and BCP 79. 293 Copies of IPR disclosures made to the IETF Secretariat and any 294 assurances of licenses to be made available, or the result of an 295 attempt made to obtain a general license or permission for the use of 296 such proprietary rights by implementers or users of this 297 specification can be obtained from the IETF on-line IPR repository at 298 http://www.ietf.org/ipr. 300 The IETF invites any interested party to bring to its attention any 301 copyrights, patents or patent applications, or other proprietary 302 rights that may cover technology that may be required to implement 303 this standard. Please address the information to the IETF at 304 ietf-ipr@ietf.org. 306 Disclaimer of Validity 308 This document and the information contained herein are provided on an 309 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 310 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 311 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 312 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 313 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 314 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 316 Copyright Statement 318 Copyright (C) The Internet Society (2006). This document is subject 319 to the rights, licenses and restrictions contained in BCP 78, and 320 except as set forth therein, the authors retain all their rights. 322 Acknowledgment 324 Funding for the RFC Editor function is currently provided by the 325 Internet Society.