SIPPING WG M. Procter Internet Draft CITEL Technologies Ltd Expires: October 2004 21 April 2004 An approach to Call Park/Retrieve using SIP draft-procter-sipping-call-park-extension-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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. 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 Procter Expires October 2004 [Page 1] Internet-Draft SIP Call Park Extension 21 April 2004 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. 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 | | |<----------------------------| | Procter Expires October 2004 [Page 2] Internet-Draft SIP Call Park Extension 21 April 2004 | 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. 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. Alice Bob Park Server Carol | | | | | | | SUBSCRIBE F1 | | | |<-------------| Procter Expires October 2004 [Page 3] Internet-Draft SIP Call Park Extension 21 April 2004 | | | 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 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 Procter Expires October 2004 [Page 4] Internet-Draft SIP Call Park Extension 21 April 2004 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 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. 3. A failed attempt to park a call Procter Expires October 2004 [Page 5] Internet-Draft SIP Call Park Extension 21 April 2004 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. 4. 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 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 | | | |<-------------| | | Procter Expires October 2004 [Page 6] Internet-Draft SIP Call Park Extension 21 April 2004 | 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 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. References [1] Johnston, et al., "Session Initiation Protocol Service Examples", draft-ietf-sipping-service-examples-06 (work in progress), February 2004. Procter Expires October 2004 [Page 7] Internet-Draft SIP Call Park Extension 21 April 2004 [2] Rosenberg, et al., "An INVITE Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", draft-ietf-sipping-dialog- package-04 (work in progress), February 2004. [3] Johnston, A., Levin, O., "Session Initiation Protocol Call Control - Conferencing for User Agents", draft-ietf-sipping-cc- conferencing-03 (work in progress), February 2004. Author's Address Michael Procter CITEL Technologies 1420 Fifth Avenue Suite 1711 Seattle WA 98101 USA EMail: michael.procter@citel.com Procter Expires October 2004 [Page 8]