Network Working Group M. Procter Internet-Draft Citel. Intended status: Informational February 26, 2007 Expires: August 30, 2007 An approach to Call Park/Retrieve using SIP draft-procter-bliss-call-park-extension-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Call Park and Call Retrieve are useful telephony services that are normally found on traditional PBXs. Implementing these services using the Session Initiation Protocol (SIP) in the way described in the SIP Service Examples draft [1] is straightforward, but suffers from a useability problem when implemented using SIP User Agents resembling traditional business telephones. This draft discusses a simple extension to cater for this style of endpoint. Procter Expires August 30, 2007 [Page 1] Internet-Draft SIP Call Park Extension February 2007 1. Overview When parking and retrieving a call, it is clearly important to be able to identify a parked call to allow subsequent retrieval. The approach described in [1] uses the SIP dialog ID between the parked endpoint and the park server itself. This dialog ID is unique, allocated by both the parked user and the Park Server, and also long. Mechanisms for transferring this identifier between the parking party and the retrieving party are outside the scope of [1], but given the nature of the dialog ID, transferring this information electronically is likely to be the only practical mechanism. Traditional PBX users have become accustomed to parking a call against a short number (typically 3 or 4 digits), and then using this identifier to communicate to the retrieving party which call to retrieve. This information may be passed verbally, or by means of small paper notes. Whilst collisions may occur, they are generally avoided satisfactorily by administrative policies. This draft attempts to reconcile these two models by allowing the parking party to specify a short tag to attach to the parked call (the 'orbit'). The retrieving party can then use the same tag to locate the relevant information to retrieve the parked call. 2. Call Park This message flow of parking a call is identical to that illustrated in [1]. The difference that this draft introduces is in the REFER message to the Park Server. The details of the REFER message changes are discussed below. Procter Expires August 30, 2007 [Page 2] Internet-Draft SIP Call Park Extension February 2007 Alice Bob Park Server Carol | | | | | INVITE F1 | | | |------------->| | | |180 Ringing F2| | | |<-------------| | | | 200 OK F3 | | | |<-------------| | | | ACK F4 | | | |------------->| | | | RTP Media | | | |<============>| | | | Bob Parks Call | | | | REFER Refer-To: A F5 | | |------------->| | | | 202 F6 | | | |<-------------| | | | NOTIFY F7 | | | |<-------------| | | | 200 F8 | | | |------------->| | | INVITE F9 Replaces: B | | |<----------------------------| | | 200 OK F10 | | |---------------------------->| | | ACK F11 | | |<----------------------------| | | RTP Music | | |<===========================>| | | BYE F12 | | | |------------->| NOTIFY F14 | | | 200 OK F13 |<-------------| | |<-------------| 200 OK F15 | | | |------------->| | The URI is used instead of directing the request to the URI . The addition of the orbit parameter effectively tags the parked call with a short memorable code entered by the user. Procter Expires August 30, 2007 [Page 3] Internet-Draft SIP Call Park Extension February 2007 F5 REFER Bob -> Park Server REFER sips:park@server.example.com;orbit=1234 SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Bob ;tag=02134 To: Park Server Call-ID: 4802029847@biloxi.example.com CSeq: 1 REFER Refer-To: Referred-By: Contact: Content-Length: 0 3. Call Retrieve In order to retrieve the call using the approach described in [1], we need to obtain the dialog identifiers, given only the orbit. In fact, [1] points us to the solution in this extract: Note that if the Park Server did not return the dialog identifiers (Call-ID, To and From tags) in the NOTIFY, Carol could send a SUBSCRIBE to retrieve this information. By subscribing to the dialog event package [2] at the same URI used for parking the call, i.e. , all the information that is required for the call to be picked up by C is delivered in the corresponding NOTIFY. Procter Expires August 30, 2007 [Page 4] Internet-Draft SIP Call Park Extension February 2007 Alice Bob Park Server Carol | | | | | | | SUBSCRIBE F1 | | | |<-------------| | | | 200 OK F2 | | | |------------->| | | | NOTIFY F3 | | | |------------->| | | | 200 OK F4 | | | |<-------------| | | | | | | | | | INVITE Replaces: Park Server F5 | |<-------------------------------------------| | | | 200 F6 | |------------------------------------------->| | | | ACK F7 | |<-------------------------------------------| | RTP Media | |<==========================================>| | BYE F8 | | |---------------------------->| | | 200 OK F9 | | |<----------------------------| | | No more RTP Music | | F1 SUBSCRIBE Carol -> Park Server SUBSCRIBE sips:park@server.example.com;orbit=1234 SIP/2.0 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK92bz Max-Forwards: 70 From: Carol ;tag=8672349 To: Call-ID: xt4653gs2ham@chicago.example.com CSeq: 1 SUBSCRIBE Contact: Event: dialog Subscription-State: active;expires=0 Accept: application/dialog-info+xml Content-Length: 0 Procter Expires August 30, 2007 [Page 5] Internet-Draft SIP Call Park Extension February 2007 F2 200 OK Park Server -> Carol SIP/2.0 200 OK Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK92bz ;received=192.0.2.114 Max-Forwards: 70 From: Carol ;tag=8672349 To: ;tag=1234567 Call-ID: xt4653gs2ham@chicago.example.com CSeq: 1 SUBSCRIBE Content-Length: 0 F3 NOTIFY Park Server -> Carol NOTIFY sips:carol@client.chicago.example.com SIP/2.0 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca Max-Forwards: 70 To: Carol ;tag=8672349 From: ;tag=1234567 Call-ID: xt4653gs2ham@chicago.example.com CSeq: 2 NOTIFY Contact: Event: dialog Subscription-State: terminated Content-Type: application/dialog-info+xml Content-Length: ... confirmed Procter Expires August 30, 2007 [Page 6] Internet-Draft SIP Call Park Extension February 2007 F4 200 OK Carol -> Park Server SIP/2.0 200 OK Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca To: Carol ;tag=8672349 From: ;tag=1234567 Call-ID: xt4653gs2ham@chicago.example.com CSeq: 2 NOTIFY Contact: Content-Length: 0 The remainder of the frames are the same as the corresponding frames from [1], since the required dialog ID has been obtained through the SUBSCRIBE / NOTIFY cycle from the Park Server. 4. A failed attempt to park a call If an attempt is made to park a call against an orbit that is already in use, then the park attempt may fail. Alice Bob Park Server Carol | | | | | INVITE F1 | | | |------------->| | | |180 Ringing F2| | | |<-------------| | | | 200 OK F3 | | | |<-------------| | | | ACK F4 | | | |------------->| | | | RTP Media | | | |<============>| | | | Bob Parks Call | | | | REFER Refer-To: A F5 | | |------------->| | | |486 Busy Here | | | |<-------------| | Under these circumstances, Bob may choose to attempt to park the call again, but using a different orbit number. 5. Enforcing a policy to avoid orbit collisions Sometimes an orbit number assignment policy needs to be implemented. This may be to ensure that all orbit numbers are a particular length, or have a form that means that they can be dialled directly (given Procter Expires August 30, 2007 [Page 7] Internet-Draft SIP Call Park Extension February 2007 suitable extensions to an Application Server). It may also be implemented to eliminate the problem of trying to park more than one call on the same orbit. To enforce a policy, we ensure that the orbit number is not allocated by the UA (entered by the user, or by configuration etc.) but is instead allocated by the Park Server, and relayed to the UA. The natural location for this information is for the Park Server to add the orbit parameter to the Contact header that it returns in the response to the REFER message. Alice Bob Park Server Carol | | | | | INVITE F1 | | | |------------->| | | |180 Ringing F2| | | |<-------------| | | | 200 OK F3 | | | |<-------------| | | | ACK F4 | | | |------------->| | | | RTP Media | | | |<============>| | | | Bob Parks Call | | | | REFER Refer-To: A F5 | | |------------->| | | |202 Accepted F6 | | |<-------------| | F5 REFER Bob -> Park Server REFER sips:park@server.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashdsB Max-Forwards: 70 From: Bob ;tag=22134 To: Park Server Call-ID: 4802029847@biloxi.example.com CSeq: 1 REFER Refer-To: Referred-By: Contact: Content-Length: 0 Procter Expires August 30, 2007 [Page 8] Internet-Draft SIP Call Park Extension February 2007 F6 202 Accepted Park Server -> Bob SIP/2.0 202 Accepted Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashdsB ;received=192.0.2.105 From: Bob ;tag=22134 To: Park Server ;tag=56324 Call-ID: 4802029848@biloxi.example.com CSeq: 1 REFER Contact: Content-Length: 0 This approach is analogous to the Conference Factory described in [3], as it permits a single configurable value (the URI of the Park Server) to be used by multiple UAs to provide unique parking orbits. 6. Security Considerations None. 7. References [1] Johnston, A., "Session Initiation Protocol Service Examples", draft-ietf-sipping-service-examples-12 (work in progress), January 2007. [2] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [3] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006. Procter Expires August 30, 2007 [Page 9] Internet-Draft SIP Call Park Extension February 2007 Author's Address Michael Procter Citel. Wheatcroft Business Park Landmere Lane, Edwalton Nottingham NG12 4DG UK Email: michael.procter@citel.com Procter Expires August 30, 2007 [Page 10] Internet-Draft SIP Call Park Extension February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Procter Expires August 30, 2007 [Page 11]