[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05                                             
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 <sips:park@server.example.com;orbit=1234> is used instead of
   directing the request to the URI <sips:park@server.example.com>.  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 <sips:bob@biloxi.example.com>;tag=02134
         To: Park Server <sips:park@server.example.com;orbit=1234>
         Call-ID: 4802029847@biloxi.example.com
         CSeq: 1 REFER
        <allOneLine>
         Refer-To: <sips:alice@client.atlanta.example.com?Replaces=
         12345601%40atlanta.example.com%3Bfrom-tag%3D314159
         %3Bto-tag%3D1234567>
        </allOneLine>
         Referred-By: <sips:bob@biloxi.example.com>
         Contact: <sips:bob@client.biloxi.example.com>
         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. <sips:park@server.example.com;orbit=1234>,
   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 <sips:carol@chicago.example.com>;tag=8672349
         To: <sips:park@server.example.com;orbit=1234>
         Call-ID: xt4653gs2ham@chicago.example.com
         CSeq: 1 SUBSCRIBE
         Contact: <sips:carol@client.chicago.example.com>
         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 <sips:carol@chicago.example.com>;tag=8672349
         To: <sips:park@server.example.com;orbit=1234>;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 <sips:carol@chicago.example.com>;tag=8672349
       From: <sips:park@server.example.com;orbit=1234>;tag=1234567
       Call-ID: xt4653gs2ham@chicago.example.com
       CSeq: 2 NOTIFY
       Contact: <sips:park@server.example.com;orbit=1234>
       Event: dialog
       Subscription-State: terminated
       Content-Type: application/dialog-info+xml
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
          version="0" state="full"
          entity="sips:park@park.server.example.com;orbit=1234">
       <dialog id="94992014524" call-id="12345600@atlanta.example.com"
          local-tag="3145678" remote-tag="1234567" direction="recipient"
          remote-uri="alice@atlanta.example.com"
          remote-target="alice@client.atlanta.example.com">
       <state>confirmed</state>
       </dialog>
       </dialog-info>












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 <sips:carol@chicago.example.com>;tag=8672349
         From: <sips:park@server.example.com;orbit=1234>;tag=1234567
         Call-ID: xt4653gs2ham@chicago.example.com
         CSeq: 2 NOTIFY
         Contact: <sips:carol@client.chicago.example.com>
         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 <sips:bob@biloxi.example.com>;tag=22134
         To: Park Server <sips:park@server.example.com>
         Call-ID: 4802029847@biloxi.example.com
         CSeq: 1 REFER
       <allOneLine>
         Refer-To: <sips:alice@client.atlanta.example.com?Replaces=
         12345601%40atlanta.example.com%3Bfrom-tag%3D314159
         %3Bto-tag%3D1234567>
       </allOneLine>
         Referred-By: <sips:bob@biloxi.example.com>
         Contact: <sips:bob@client.biloxi.example.com>
         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 <sips:bob@biloxi.example.com>;tag=22134
         To: Park Server <sips:park@server.example.com>;tag=56324
         Call-ID: 4802029848@biloxi.example.com
         CSeq: 1 REFER
         Contact: <sips:park@server.example.com;orbit=7001>
         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]