Cisco Systems, Inc.

101 Cooper Street Santa Cruz CA 95060 USA rohan@cisco.com

Transport SIPPING WG I-D Internet-Draft park There are several useful features that can be modeled in SIP in a unified way by creating a service which exists merely to "park" sessions (provide a temporary place to maintain a session with another participant until one or more new participants are available). This document describes several example features that are easily implemented in such an environment, describes authorization issues around these features, and provides example call flows.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119.

Parking Server is a SIP User Agent which provides temporary sessions to parked participants and allows later retrieval by other participants. A Park Server maintains several URIs with distinctive properties. A Parking Space has a unique URI and corresponds to a single parked session. A Parking Lot is a collection of Parking Spaces with similar policies. A single Parking Server could support multiple Parking Lots each with potentially unique policies. Park Servers support two abstract services, parking, and retrieval. Parking is accomplished by referencing a park URI which can refer to either a parking space or an entire parking lot. Once a park (invitation) request is accepted, the park server returns the retrieval URI for the assigned parking space in the Contact header of the 200 OK response to that invitation. Retrieval is accomplished in one of two ways. The first mechanism involves sending an invitation with a Replaces header to the parked participant. This mechanism is acceptable when the park server and the retrieving user agent have a close relationship (representing the same user or organization), and when the parked user can be reasonably expected to authorize the replacement based on that relationship. The dialog information needed to populate the Replaces header could be obtained through a subscription to the dialog package, or some out-of-band mechanism (for example, the park server could send a SIP instant message to the retriever with the appropriate information, perhaps embedded in a URI). The second mechanism requires the retrieving participant to send an invitation to a retrieval URI which is unique for each parking space. Upon receiving a retrieval URI, the park server authorizes the request, and if authorized accepts the invitation from the retriever and completes a transfer between the retrieving and the parked participants.

There are many, many variations of this category of features. The names of the example features below are not normative in any way. While they were selected to minimize confusion, they may conflict with terms used for variations of related features used by specific vendors or products. This list of features is not exhaustive, it is intended to illustrate general concepts only.

Note that in some environments where parking services are used, the retrieving user may only have an interface that can easily generate retrieval URIs which resemble telephone numbers (ex: IP phones, or other phones connected via a gateway). In these environments the park server can be configured to generate retrieval URIs which are easy to access. Either the phone or gateway is configured with a suitable dial plan, or a proxy retargets numbers in the retrieval range to a suitable URI referencing the park server.

The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234.

This document introduces no considerations for IANA.

***