idnits 2.17.1 draft-procter-bliss-call-park-extension-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 409. 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 : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 26, 2007) is 6268 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-12 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Procter 3 Internet-Draft Citel. 4 Intended status: Informational February 26, 2007 5 Expires: August 30, 2007 7 An approach to Call Park/Retrieve using SIP 8 draft-procter-bliss-call-park-extension-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 30, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Call Park and Call Retrieve are useful telephony services that are 42 normally found on traditional PBXs. Implementing these services 43 using the Session Initiation Protocol (SIP) in the way described in 44 the SIP Service Examples draft [1] is straightforward, but suffers 45 from a useability problem when implemented using SIP User Agents 46 resembling traditional business telephones. This draft discusses a 47 simple extension to cater for this style of endpoint. 49 1. Overview 51 When parking and retrieving a call, it is clearly important to be 52 able to identify a parked call to allow subsequent retrieval. The 53 approach described in [1] uses the SIP dialog ID between the parked 54 endpoint and the park server itself. This dialog ID is unique, 55 allocated by both the parked user and the Park Server, and also long. 56 Mechanisms for transferring this identifier between the parking party 57 and the retrieving party are outside the scope of [1], but given the 58 nature of the dialog ID, transferring this information electronically 59 is likely to be the only practical mechanism. 61 Traditional PBX users have become accustomed to parking a call 62 against a short number (typically 3 or 4 digits), and then using this 63 identifier to communicate to the retrieving party which call to 64 retrieve. This information may be passed verbally, or by means of 65 small paper notes. Whilst collisions may occur, they are generally 66 avoided satisfactorily by administrative policies. 68 This draft attempts to reconcile these two models by allowing the 69 parking party to specify a short tag to attach to the parked call 70 (the 'orbit'). The retrieving party can then use the same tag to 71 locate the relevant information to retrieve the parked call. 73 2. Call Park 75 This message flow of parking a call is identical to that illustrated 76 in [1]. The difference that this draft introduces is in the REFER 77 message to the Park Server. The details of the REFER message changes 78 are discussed below. 80 Alice Bob Park Server Carol 81 | | | | 82 | INVITE F1 | | | 83 |------------->| | | 84 |180 Ringing F2| | | 85 |<-------------| | | 86 | 200 OK F3 | | | 87 |<-------------| | | 88 | ACK F4 | | | 89 |------------->| | | 90 | RTP Media | | | 91 |<============>| | | 92 | Bob Parks Call | | 93 | | REFER Refer-To: A F5 | 94 | |------------->| | 95 | | 202 F6 | | 96 | |<-------------| | 97 | | NOTIFY F7 | | 98 | |<-------------| | 99 | | 200 F8 | | 100 | |------------->| | 101 | INVITE F9 Replaces: B | | 102 |<----------------------------| | 103 | 200 OK F10 | | 104 |---------------------------->| | 105 | ACK F11 | | 106 |<----------------------------| | 107 | RTP Music | | 108 |<===========================>| | 109 | BYE F12 | | | 110 |------------->| NOTIFY F14 | | 111 | 200 OK F13 |<-------------| | 112 |<-------------| 200 OK F15 | | 113 | |------------->| | 115 The URI is used instead of 116 directing the request to the URI . The 117 addition of the orbit parameter effectively tags the parked call with 118 a short memorable code entered by the user. 120 F5 REFER Bob -> Park Server 122 REFER sips:park@server.example.com;orbit=1234 SIP/2.0 123 Via: SIP/2.0/TLS client.biloxi.example.com:5061 124 ;branch=z9hG4bKnashds9 125 Max-Forwards: 70 126 From: Bob ;tag=02134 127 To: Park Server 128 Call-ID: 4802029847@biloxi.example.com 129 CSeq: 1 REFER 130 131 Refer-To: 134 135 Referred-By: 136 Contact: 137 Content-Length: 0 139 3. Call Retrieve 141 In order to retrieve the call using the approach described in [1], we 142 need to obtain the dialog identifiers, given only the orbit. In 143 fact, [1] points us to the solution in this extract: 145 Note that if the Park Server did not return the dialog identifiers 146 (Call-ID, To and From tags) in the NOTIFY, Carol could send a 147 SUBSCRIBE to retrieve this information. 149 By subscribing to the dialog event package [2] at the same URI used 150 for parking the call, i.e. , 151 all the information that is required for the call to be picked up by 152 C is delivered in the corresponding NOTIFY. 154 Alice Bob Park Server Carol 155 | | | | 156 | | | SUBSCRIBE F1 | 157 | | |<-------------| 158 | | | 200 OK F2 | 159 | | |------------->| 160 | | | NOTIFY F3 | 161 | | |------------->| 162 | | | 200 OK F4 | 163 | | |<-------------| 164 | | | | 165 | | | | 166 | INVITE Replaces: Park Server F5 | 167 |<-------------------------------------------| 168 | | | 200 F6 | 169 |------------------------------------------->| 170 | | | ACK F7 | 171 |<-------------------------------------------| 172 | RTP Media | 173 |<==========================================>| 174 | BYE F8 | | 175 |---------------------------->| | 176 | 200 OK F9 | | 177 |<----------------------------| | 178 | No more RTP Music | | 180 F1 SUBSCRIBE Carol -> Park Server 182 SUBSCRIBE sips:park@server.example.com;orbit=1234 SIP/2.0 183 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK92bz 184 Max-Forwards: 70 185 From: Carol ;tag=8672349 186 To: 187 Call-ID: xt4653gs2ham@chicago.example.com 188 CSeq: 1 SUBSCRIBE 189 Contact: 190 Event: dialog 191 Subscription-State: active;expires=0 192 Accept: application/dialog-info+xml 193 Content-Length: 0 194 F2 200 OK Park Server -> Carol 196 SIP/2.0 200 OK 197 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK92bz 198 ;received=192.0.2.114 199 Max-Forwards: 70 200 From: Carol ;tag=8672349 201 To: ;tag=1234567 202 Call-ID: xt4653gs2ham@chicago.example.com 203 CSeq: 1 SUBSCRIBE 204 Content-Length: 0 206 F3 NOTIFY Park Server -> Carol 208 NOTIFY sips:carol@client.chicago.example.com SIP/2.0 209 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca 210 Max-Forwards: 70 211 To: Carol ;tag=8672349 212 From: ;tag=1234567 213 Call-ID: xt4653gs2ham@chicago.example.com 214 CSeq: 2 NOTIFY 215 Contact: 216 Event: dialog 217 Subscription-State: terminated 218 Content-Type: application/dialog-info+xml 219 Content-Length: ... 221 222 225 229 confirmed 230 231 232 F4 200 OK Carol -> Park Server 234 SIP/2.0 200 OK 235 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca 236 To: Carol ;tag=8672349 237 From: ;tag=1234567 238 Call-ID: xt4653gs2ham@chicago.example.com 239 CSeq: 2 NOTIFY 240 Contact: 241 Content-Length: 0 243 The remainder of the frames are the same as the corresponding frames 244 from [1], since the required dialog ID has been obtained through the 245 SUBSCRIBE / NOTIFY cycle from the Park Server. 247 4. A failed attempt to park a call 249 If an attempt is made to park a call against an orbit that is already 250 in use, then the park attempt may fail. 252 Alice Bob Park Server Carol 253 | | | | 254 | INVITE F1 | | | 255 |------------->| | | 256 |180 Ringing F2| | | 257 |<-------------| | | 258 | 200 OK F3 | | | 259 |<-------------| | | 260 | ACK F4 | | | 261 |------------->| | | 262 | RTP Media | | | 263 |<============>| | | 264 | Bob Parks Call | | 265 | | REFER Refer-To: A F5 | 266 | |------------->| | 267 | |486 Busy Here | | 268 | |<-------------| | 270 Under these circumstances, Bob may choose to attempt to park the call 271 again, but using a different orbit number. 273 5. Enforcing a policy to avoid orbit collisions 275 Sometimes an orbit number assignment policy needs to be implemented. 276 This may be to ensure that all orbit numbers are a particular length, 277 or have a form that means that they can be dialled directly (given 278 suitable extensions to an Application Server). It may also be 279 implemented to eliminate the problem of trying to park more than one 280 call on the same orbit. 282 To enforce a policy, we ensure that the orbit number is not allocated 283 by the UA (entered by the user, or by configuration etc.) but is 284 instead allocated by the Park Server, and relayed to the UA. The 285 natural location for this information is for the Park Server to add 286 the orbit parameter to the Contact header that it returns in the 287 response to the REFER message. 289 Alice Bob Park Server Carol 290 | | | | 291 | INVITE F1 | | | 292 |------------->| | | 293 |180 Ringing F2| | | 294 |<-------------| | | 295 | 200 OK F3 | | | 296 |<-------------| | | 297 | ACK F4 | | | 298 |------------->| | | 299 | RTP Media | | | 300 |<============>| | | 301 | Bob Parks Call | | 302 | | REFER Refer-To: A F5 | 303 | |------------->| | 304 | |202 Accepted F6 | 305 | |<-------------| | 307 F5 REFER Bob -> Park Server 309 REFER sips:park@server.example.com SIP/2.0 310 Via: SIP/2.0/TLS client.biloxi.example.com:5061 311 ;branch=z9hG4bKnashdsB 312 Max-Forwards: 70 313 From: Bob ;tag=22134 314 To: Park Server 315 Call-ID: 4802029847@biloxi.example.com 316 CSeq: 1 REFER 317 318 Refer-To: 321 322 Referred-By: 323 Contact: 324 Content-Length: 0 325 F6 202 Accepted Park Server -> Bob 327 SIP/2.0 202 Accepted 328 Via: SIP/2.0/TLS client.biloxi.example.com:5061 329 ;branch=z9hG4bKnashdsB 330 ;received=192.0.2.105 331 From: Bob ;tag=22134 332 To: Park Server ;tag=56324 333 Call-ID: 4802029848@biloxi.example.com 334 CSeq: 1 REFER 335 Contact: 336 Content-Length: 0 338 This approach is analogous to the Conference Factory described in 339 [3], as it permits a single configurable value (the URI of the Park 340 Server) to be used by multiple UAs to provide unique parking orbits. 342 6. Security Considerations 344 None. 346 7. References 348 [1] Johnston, A., "Session Initiation Protocol Service Examples", 349 draft-ietf-sipping-service-examples-12 (work in progress), 350 January 2007. 352 [2] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 353 Initiated Dialog Event Package for the Session Initiation 354 Protocol (SIP)", RFC 4235, November 2005. 356 [3] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) 357 Call Control - Conferencing for User Agents", BCP 119, RFC 4579, 358 August 2006. 360 Author's Address 362 Michael Procter 363 Citel. 364 Wheatcroft Business Park 365 Landmere Lane, Edwalton 366 Nottingham NG12 4DG 367 UK 369 Email: michael.procter@citel.com 371 Full Copyright Statement 373 Copyright (C) The IETF Trust (2007). 375 This document is subject to the rights, licenses and restrictions 376 contained in BCP 78, and except as set forth therein, the authors 377 retain all their rights. 379 This document and the information contained herein are provided on an 380 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 381 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 382 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 383 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 384 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 385 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 387 Intellectual Property 389 The IETF takes no position regarding the validity or scope of any 390 Intellectual Property Rights or other rights that might be claimed to 391 pertain to the implementation or use of the technology described in 392 this document or the extent to which any license under such rights 393 might or might not be available; nor does it represent that it has 394 made any independent effort to identify any such rights. Information 395 on the procedures with respect to rights in RFC documents can be 396 found in BCP 78 and BCP 79. 398 Copies of IPR disclosures made to the IETF Secretariat and any 399 assurances of licenses to be made available, or the result of an 400 attempt made to obtain a general license or permission for the use of 401 such proprietary rights by implementers or users of this 402 specification can be obtained from the IETF on-line IPR repository at 403 http://www.ietf.org/ipr. 405 The IETF invites any interested party to bring to its attention any 406 copyrights, patents or patent applications, or other proprietary 407 rights that may cover technology that may be required to implement 408 this standard. Please address the information to the IETF at 409 ietf-ipr@ietf.org. 411 Acknowledgment 413 Funding for the RFC Editor function is provided by the IETF 414 Administrative Support Activity (IASA).