SIPPING Joachim Poetzl Internet Draft Martin Huelsemann Expires: August 2007 Deutsche Telekom Jean-Marie Stupka Siemens Extensions to the Session Initiation Protocol (SIP) for the support of the Call Completion Services for the European Telecommunications Standards Institute, draft-poetzl-sipping-call-completion-02 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 15, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies the extensions to the Session Initiation Protocol (SIP) for the call completion services provided in the context of ETSI Next Generation Networks (NGN). Therefore this document describes a SIP event package that enables subscribing to and managing call completion queues. Furthermore this document extends the usage of the Allows-events header field to 180 Ringing Poetzl Expires August 15 2007 Page 1 Internet-Draft Call Completion February 2007 and 486 Busy responses, and specifies an indication used for the prioritization of call-completion calls. Table of Contents Status of this Memo.........................................1 Abstract..................................................1 Table of Contents..........................................2 1. Overview................................................4 2. Introduction............................................4 3. Definitions.............................................5 4. Requirements motivating SIP extensions in support of call completion services.........................................6 4.1 Queue monitoring and management capability.................6 4.2 CCBS/CCNR subscription capability indication...............7 4.3 Prioritization of call-completion calls...................7 5. Overview of the solution .................................7 6. Call Completion event package.............................8 6.1 Event Package Name......................................8 6.2 Event Package Parameters.................................8 6.3 SUBSCRIBE Bodies........................................9 6.4 Subscription Duration...................................9 6.5 NOTIFY Bodies..........................................9 6.6 Subscriber Generation of SUBSCRIBE requests...............10 6.7 Notifier Processing of SUBSCRIBE Requests.................10 6.8 Notifier Generation of NOTIFY Requests...................10 6.9 Subscriber Processing of NOTIFY Requests .................11 6.10 Handling of Forked Requests............................11 6.11 Rate of Notifications.................................11 6.12 State Agents.........................................11 6.13 Handling of the Allow-Events Header.....................11 7. Call-completion information format........................12 7.1 queue-nature..........................................12 7.2 queue-operation........................................12 7.3 queue-state...........................................13 7.4 caller ...............................................13 7.5 service-retention......................................13 7.6 cancellation-reason....................................14 7.7 denial-reason.........................................15 8. The P-Service-Indication Header..........................15 8.1 UAC Behavior..........................................16 8.2 UAS Behavior..........................................16 8.3 Proxy Behavior ........................................16 8.4 Example...............................................16 8.5 Header Field Definitions................................17 8.6 Augmented BNF.........................................17 9. Signaling Flows ........................................18 10. Security Considerations ................................25 10.1 Call Completion event package..........................25 10.2 P-Service-Indication header............................25 11. IANA Considerations....................................25 Poetzl Expires August 15, 2007 Page 2 Internet-Draft Call Completion February 2007 11.1 SIP Event Package Registration .........................25 11.2 P-Service-Indication Header Registration.................25 11.3 IANA P-Service-Indication Tags Registration..............26 12. References............................................26 12.1 Normative References..................................26 12.2 Informative References ................................26 13. Contributors..........................................27 14. Authors' Addresses.....................................28 15. Acknowledgments........................................29 16. Intellectual Property and Copyright Statements............29 Poetzl Expires August 15, 2007 Page 3 1. Overview The European Telecommunications Standards Institute (ETSI) Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) is defining the release 2 of the TISPAN Next Generation Network (NGN) aiming at the creation of a multimedia fixed network. Generally NGN is based on the 3rd Generation mobile Partnership Project (3GPP) IP Multimedia Subsystem (IMS) Release 7 with additions required to support the fixed access. While ETSI is committed to the creation of new multimedia applications and services, the importance of providing support to existing Integrated Services Digital Network and Public Switched Telephone Network (ISDN/PSTN) supplementary services has also been acknowledged. This document describes SIP extensions needed for the realization of the Completion of Calls to Busy Subscribers (CCBS) and Completion of Calls on No Reply (CCNR) service. All mentioned 3GPP and ETSI Standards are free available under http://pda.etsi.org/pda/queryform.asp and http://www.3gpp.org/ftp/Specs/html-info. 2. Introduction The Completion of Calls to Busy Subscriber (CCBS) and the Completion of Calls on no Reply (CCNR) services are very similar in nature, thus we describe requirements and solutions for both services at the same time. Completion of Calls to Busy Subscriber (CCBS) provides the caller with the ability to complete a requested call to a busy callee without having to make a new call attempt when the callee becomes not busy. The CCBS service description is defined in ETSI EN 300 357 [5]. Completion of Calls on no Reply (CCNR) provides the caller with the ability to complete a requested call to a callee without having to make a new call attempt when the callee becomes not busy after having initiated an activity. The CCNR service description is defined in ETSI EN 301 134 [6]. The call completion services provide the capability to queue several CCBS/CCNR requests to the same callee on a FIFO basis. It therefore requires functionalities like notifying changes of queue states and managing queues. The Session Initiation Protocol (SIP) event framework is described in RFC 3265 [2]. It defines a generic framework for subscription Poetzl Expires August 15, 2007 Page 4 Internet-Draft Call Completion February 2007 to, and notification of, events related to SIP systems. The framework defines the methods SUBSCRIBE and NOTIFY, and introduces the notion of a package. A package is a concrete application of the event framework to a particular class of events. This document defines a SIP event package that enables subscribing to and managing call completion queues. Furthermore it specifies the usage of the Allow-events header field in 486 Busy responses for the realization of a Completion of Calls to Busy Subscribers (CCBS) service and the usage of the Allow-events header field in 180 Ringing responses for the realization of a Completion of Calls on No Reply (CCNR) service, as well as an indication to prioritize call-completion calls. 3. Definitions For the purpose of this service, we provide the following definitions (sources: ETSI EN 300 357 [5], ETSI EN 301 134 [6], ETSI EN 300 356-18 [7] and EN 300 356-20 [8]): CCBS: Completion of Calls to Busy Subscribers CCNR: Completion of Calls on No Reply Call-completion request: an instance of an activation of the call- completion service which is held in a queue pending the correct conditions for the call-completion service to be completed. Suspended call-completion request: a call-completion request which cannot be served even if the callee is in the appropriate state because the caller is busy. CCBS/CCNR service duration timer: maximum time the CCBS/CCNR request will remain activated for the caller within the network. Call-completion call: a call from the call-completion user to the call-completion target, triggered as a result of the execution of a call completion service. CCSS indication: an indication that a call is a call-completion call. Retain option: an optional capability of the originating and destination networks whereby they cooperate in maintaining the call-completion request in the queue if a call-completion call has failed due to destination busy. A queue: a buffer at the originating network for the control of call-completion requests associated with user A. Poetzl Expires August 15, 2007 Page 5 Internet-Draft Call Completion February 2007 B queue: a buffer at the destination network for the control of call-completion requests associated with the destination user B. The buffer is used to support the monitoring of user B to become not busy. 4. Requirements motivating SIP extensions in support of call completion services This section collects the CCBS/CCNR services requirements that cannot be fulfilled with existing SIP capabilities. 4.1 Queue monitoring and management capability The CCBS and CCNR services require the capability to to manage and monitor call completion queues . A call-completion queue is a queue of call-completion requests against a single callee and is generally managed in a FIFO manner, except for requests that have been suspended (see below). A call-completion request that reaches the front of the queue will be allowed to mature (resulting in an attempt to establish a call-completion call) when the callee is available. Managing a call-completion queue involves the following actions: - adding a call-completion request to the back of a call-completion queue; - suspending an existing call-completion request; - resuming a suspended call-completion request; - cancelling a call-completion request (removing it from the queue). Adding a call-completion request to a call-completion queue normally occurs after call establishment has failed due to busy (CCBS) or nor reply (CCNR). Suspending a call-completion request occurs when the caller is not available for making a call-completion call (i.e., the caller is busy) but wishes to retain the call-completion request in anticipation of making the call-completion call later. Resuming a call-completion request occurs when the condition that led to suspension has been removed (i.e., the caller is free again). Cancelling a call-completion request can occur for reasons such as cancellation by the user or expiry of the CCBS/CCNR service duration timer. It can also occur when the call-back request is completed successfully. Monitoring a call completion queue involves monitoring a particular call-completion request to determine when the callee is available Poetzl Expires August 15, 2007 Page 6 Internet-Draft Call Completion February 2007 for the call-completion call to be attempted. In the CCBS case this is on transition from a busy condition to a non-busy condition. In the CCNR case this is when the callee has initiated and optionally, if the initiation was successfull, released a new call with a third user. Monitoring is required to start when a call-completion request is added to the queue and to cease when that request is cancelled or completed successfully. Furthermore notifications of changes in the status of call completion queues are needed, when the call completion service towards a target user meets the call completion service condition. 4.2 CCBS/CCNR subscription capability indication In order to assure that end-to-end functionality of the CCBS and CCNR services is possible, there must be an indication in the backward direction during attempted call establishment that the CCBS/CCNR service is possible and can be used to advise the caller that CCBS or CCNR is available. 4.3 Prioritization of call-completion calls Calls triggered as a result of the execution of a call completion service (call-completion calls) MUST be distinguishable from new incoming calls. This permits rejection of new incoming calls when there are outstanding call-completion requests in the queue, whilst admitting call-completion calls from sources that have been notified that the callee is available. The call-completion call indication is also required for the interworking with the PSTN, where a specific ‘CCSS indication’ is required for CCBS/CCNR calls. 5. Overview of the solution This document defines in section 6 a new event package (call- completion event package) in support of queue management and monitoring. An agent acting on behalf of the caller acts as subscriber and an agent acting on behalf of the call-completion queue at the callee acts as notifier. Subscription to the event package using the SIP SUBSCRIBE method initiates monitoring and of a call-completion request that is placed in the callee's call-completion queue at the same time. Thus the subscribe request includes details of the call-completion request to be added, including whether it is for CCBS or CCNR. Having subscribed successfully, relevant changes in queue state that impact the call-completion request associated with the subscription are reported to the subscriber by means of the SIP NOTIFY requests. A NOTIFY request that reports that the callee is available for a call-completion call attempt to be made will cause Poetzl Expires August 15, 2007 Page 7 Internet-Draft Call Completion February 2007 the subscriber to trigger the establishment of that call, subject to the caller being available too. The SUBSCRIBE method is also used to cancel the subscription and thereby cancel the call-completion request. Cancellation can also be initiated by the notifier, in which case a NOTIFY request will indicate that the susbscription has been cancelled. Suspension and resumption of a request are achieved by performing a subscription refresh in which the SUBSCRIBE request carries the instruction to suspend or resume. The possibility to activate CCBS is indicated by including the Allow-Events Header field (Allow-Events:call-completion) in a 486 Busy response. The possibility to activate CCNR is indicated by including the Allow-Events Header field (Allow-Events:call-completion) in a 180 Ringing response. This enables the recipient of the 180 or 486 messages to identify that the remote server is capable of receiving a subscription for call-completion event associated with the INVITE transaction. Although RFC 3265 section 3.3.7 indicates that a node implementing an event package should indicate this in all methods which initiate dialogs and their responses, this document recommends restricting the indication to particular responses in order to only match the call-completion possible situations on the destination side. In order to prioritize a call-completion call, this document defines a new header field, the P-Service-Indication header field, described in section 8. 6. Call Completion event package This section fills in the details needed to specify an event package as defined in Section 4.4 of RFC 3265 [2]. 6.1 Event Package Name The SIP Events specification requires package definitions to specify the name of their package or template-package. The name of this package is "call-completion". As specified in RFC 3265 [2], this value appears in the Event and Allow-events header fields. 6.2 Event Package Parameters Poetzl Expires August 15, 2007 Page 8 Internet-Draft Call Completion February 2007 No package specific Event header parameters are defined for this event package. 6.3 SUBSCRIBE Bodies RFC 3265 [2] requires package definitions to define the usage, if any, of bodies in SUBSCRIBE requests. A SUBSCRIBE for call completion events MUST contain a body that describes the call-completion operations described in section 5. This body is formatted in the "application/call-completion" data format described in section 7. In this event package, the body of the subscription contains a call-completion document. All subscribers and notifiers MUST support the "application/call-completion" data format described in section 7. The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/call-completion". If the header field is present, it MUST include "application/call-completion". 6.4 Subscription Duration RFC 3265 [2] requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified. It is recommended to set the default duration of subscriptions to call completion events to a value higher than 3600 seconds which corresponds to the highest timer value recommended for the call completion services in ETSI and ITU-T. 6.5 NOTIFY Bodies RFC 3265 [2] requires package definitions to describe the allowed set if body types in NOTIFY requests, and to specify the default value to be used when there is no Accept header field in the SUBSCRIBE request A NOTIFY for call completion events MUST contain a body that describes the call-completion operations described in section 5. As described in RFC 3265 [2], the NOTIFY message will contain bodies that describe the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE, or in a package-specific default format if the Accept header field was omitted from the SUBSCRIBE. In this event package, the body of the notification contains a call-completion document. All subscribers and notifiers MUST support the "application/call-completion" data format described in section 7. The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/call-completion". If the header field is present, Poetzl Expires August 15, 2007 Page 9 Internet-Draft Call Completion February 2007 it MUST include "application/call-completion". This "application/call-completion" data format is described in chapter 6. Of course, the notifications generated by the server MUST be in one of the formats specified in the Accept header field in the SUBSCRIBE request. 6.6 Subscriber Generation of SUBSCRIBE requests Subscribers MUST generate SUBSCRIBE requests when a call completion service condition occurs at the originating side that needs to be sent towards the terminating side. This includes the following CCBS operations: call completion request, call completion suspend, call completion resume, and any of the call completion cancellation operations described in section 5. The generation of SUBSCRIBE requests MAY imply the usage of call completion service specific timers. An example of such an implementation can be found in ETSI TS 183 042 [9]. 6.7 Notifier Processing of SUBSCRIBE Requests Upon receiving a subscription refresh, the notifier MUST set the “expires” parameter of the Subscription-State header to the current remaining duration of the subscription regardless of the value received in the Expires header (if present) of the subscription refresh. The call completion information can be sensitive. Therefore, all subscriptions SHOULD be authenticated and then authorized before approval. The call completion event package specified in this document is intended to be used in private domains (e.g. IMS) where authentication and authorization are provided via means out of scope of this document. 6.8 Notifier Generation of NOTIFY Requests Notifiers MUST generate NOTIFY requests when a call completion service condition occurs at the terminating side that needs to be sent towards the originating side. A NOTIFY sent as a confirmation of the initial subscription or of a subscription refresh MUST contain the "queue-state" parameter set to "request-queued" if the user is busy and the call completion action was successful (i.e. call completion request, call completion suspend, or call completion resume) and to "user-free- for-recall" if the call completion target is not busy. A NOTIFY sent as a confirmation of a request to unsubscribe MUST NOT contain the "queue-state" parameter since the user has not longer any queue state. Poetzl Expires August 15, 2007 Page 10 Internet-Draft Call Completion February 2007 When the call completion target status changes from busy to not busy, the notifier MUST send a NOTIFY only to first non-suspended user in the queue. This NOTIFY MUST contains the "queue-state" parameter set to "user-free-for-recall". If the call completion queuing was denied by the terminating network, the NOTIFY sent as a confirmation of the subscription MUST contain the "denial-reason" parameter. 6.9 Subscriber Processing of NOTIFY Requests The subscriber processing of NOTIFY requests MAY trigger additional CCBS service procedures (e.g. CCBS recall, usage of CCBS timers?). An example of such procedures can be found in ETSI TS 183 042 [9]. 6.10 Handling of Forked Requests The SIP Events framework mandates that packages indicate whether or not forked SUBSCRIBE requests can install multiple subscriptions. Forked requests are NOT ALLOWED for the call completion event type. 6.11 Rate of Notifications RFC 3265 [2] mandates that packages define a maximum rate of notifications for their package. The call completion service typically involves a single notification per notifier and per subscription but MAY involve several notifications separated by a call completion call that failed due to a busy call completion target. 6.12 State Agents RFC 3265 [2] asks packages to consider the role of state agents in their design. State agents have no role in the handling of the call completion package. 6.13 Handling of the Allow-Events Header The Call Completion event package introduces a new Allow-Events header type (Allow-Events:call-completion) to indicate the possibility to activate CCBS or CCNR in a 486 Busy response or 180 Ringing response respectively. Poetzl Expires August 15, 2007 Page 11 Internet-Draft Call Completion February 2007 Two new lines are added to the table in section 7.2 of RFC 3265 [2]. Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT ------------------------------------------------------------------- Allow-Events 180 - - - o - - - - - Allow-Events 486 - - - o - - - - - 7. Call-completion information format The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in RFC 2234. The formal syntax for the application/call-completion MIME type is described below. call-completion = [queue-nature CLRF] [queue-operation CLRF][queue-state CLRF][caller CLRF] [service-retention CLRF][cancellation-reason CLRF] A description of the above mentioned rules follows. 7.1 queue-nature The queue-nature indicates the nature of the call completion event and may be present in SUBSRIBE and NOTIFY requests. queue-nature = "queue-nature" HCOLON ( "CCBS" / "CCNR" ) It is possible that further values are needed in future, they can be defined by the RFCs which extend the present functionality. 7.1.1 CCBS The CCBS class states it is a request for a CCBS queue. 7.1.2 CCNR The CCNR class states it is a request for a CCNR queue. 7.2 queue-operation The queue-operation class indicates the requested action and is present in SUBSCRIBE requests. queue-operation = "queue-operation" HCOLON ( "add" / "suspend" / "resume" ) Poetzl Expires August 15, 2007 Page 12 Internet-Draft Call Completion February 2007 7.2.1 add The add class states that the subscription must be added in the queue. This value can only be present in initial SUBSCRIBE requests. 7.2.2 suspend The suspend class states that the subscription must be suspended, but not removed from its position in the queue. This value can only be present in SUBSCRIBE requests refreshing a subscription. 7.2.3 resume The resume class states that a previously suspended subscription must be resumed. This value can only be present in SUBSCRIBE requests refreshing a subscription. 7.3 queue-state The queue-state indicates the status of the request in the queue and is present in NOTIFY requests. queue-state = "queue-state" HCOLON ( "request-queued" / "user-free-for-recall" ) 7.3.1 request-queued The request-queued indicates the call-completion queue request was accepted and is active. 7.3.2 user-free-for-recall The user-free-for-recall indicates the call-completion condition. 7.4 caller The caller uniquely identifies the user that has originated the call completion request and MUST be present in any initial SUBSCRIBE request. caller = "caller" HCOLON addr-spec 7.5 service-retention The service-retention indicates the support of the retain option. The retain option, if supported on both the originating and terminating side, will maintain the call completion request in the destination B queue, if a call completion call has failed due to destination busy condition. If present, this parameter indicates Poetzl Expires August 15, 2007 Page 13 Internet-Draft Call Completion February 2007 that the retain option is supported, otherwise it is not supported. This parameter MAY be present in SUBSCRIBE and/or NOTIFY requests. service-retention = "service-retention" 7.6 cancellation-reason The cancellation-reason MAY be present if the Expires Header field is valued to 0 and MUST NOT be present otherwise. It details the reason why the call completion subscription is being cancelled. cancellation-reason = "cancellation-reason" HCOLON ( "operation-timeout" / "service-duration" / "recall-timeout" / "service-completed" ) 7.6.1 operation-timeout The operation-timeout corresponds to the expiry of the timer supervising the response to a call completion request sent from the originating side to the terminating side (i.e. the initial NOTIFY). Note that this reason value corresponds to the expiry of CCBS-T2 timer in the PSTN/ISDN if present in a SUBSCRIBE request as described in [7]. 7.6.2 service-duration The service-duration corresponds to the expiry of the timer that specifies the maximum time the call completion request will remain activated. Note that this reason value corresponds to CCBS-T3 expiry in the PSTN/ISDN if present in a SUBSCRIBE request, to CCBS- T7 expiry in the PSTN/ISDN if present in a NOTIFY request as described in [7]. 7.6.3 recall-timeout The recall-timeout corresponds to the expiry of the timer that specifies the maximum time the originating side will wait for a response from user A to a ‘user-free-for-recall’ indication (call completion recall). Note that this reason value corresponds to CCBS-T4 expiry in the PSTN/ISDN if present in a SUBSCRIBE request, to CCBS-T9 expiry in the PSTN/ISDN if present in a NOTIFY request as described in [7]. 7.6.4 service-completed The service-completed indicates that the call completion service is completed. This value MAY be present in a NOTIFY message and MUST NOT be present in a SUBSCRIBE message. Poetzl Expires August 15, 2007 Page 14 Internet-Draft Call Completion February 2007 7.7 denial-reason The denial-reason details the reason why the call completion request has been denied. denial-reason = "denial-reason" HCOLON ( "short-term-denial" / "long-term-denial" ) 7.7.1 short-term-denial The short-term-denial indicates that the terminating side temporarily cannot accept a call completion request from the originating side. A later attempt from the originating side to subscribe to a call completion queue on the terminating side may succeed. This reason will be given e.g. if there are already the maximum number of call completion requests queued against the terminating side, if there is an interaction with another event which temporarily prevents the subscription to the call completion queue, or if no compatible terminal is found at the terminating side. This value MAY be present in a NOTIFY message and MUST NOT be present in a SUBSCRIBE message. 7.7.2 long-term-denial The long-term-denial indicates that the terminating side cannot accept a call completion request from the originating side and a later attempt from the originating side to subscribe to a call completion queue on the terminating side will also be rejected. This value MAY be present in a NOTIFY message and MUST NOT be present in a SUBSCRIBE message. The request-URI specifies the user whose data is being subscribed to. 8. The P-Service-Indication Header The P-Service-Indication header is meant to be used in certain deployment scenarios where there is a need for SIP elements to request each other to apply a special processing of a SIP request or response. The P-Service-Indication Header does not strictly mandate a special handling by SIP elements, it suggests it. In case no element in the path supports this header semantic, the message processing is not affected. In particular, a SIP element can not reject a request if it contains the P-Service-Indication with an indication that it does not understand. The header semantic is a list of service indications (SI) represented by tokens. In order to prevent misuse of this header, list of attribute-value pairs is not allowed. Poetzl Expires August 15, 2007 Page 15 Internet-Draft Call Completion February 2007 8.1 UAC Behavior A caller wishing to invoke one or more special processings for a request from the network which will handle an outbound transaction includes one or more P-Service-Indication header fields in the request. No additional behavior is required after the request is sent. The P-Service-Indication header fields in an ACK for a non- 2xx final response and in a CANCEL request MUST NOT contain any P- Service-Indication Header fields. This does not apply to ACK requests for 2xx final responses. An UAC receiving a response message MAY behave differently depending on the list of service indications received in it. In the case of a CCBS/CCNR call, the UAC shall insert a P-Service- indication header field with the value ‘ccss’ in the INVITE request 8.2 UAS Behavior An UAS receiving a request message MAY inspect the P-Service- Indication headers contained therein, in order to apply a special (service-specific) processing for that request. When generating a response, it MAY include one or more P-Service-Indication header fields containing a list of service indications the UAS wishes to communicate to intermediate elements upstream. There is no relationship between the list of service indications received in the request and the ones generated in the response. In particular, a response MAY contain a list of service indications also if the original request did not contain any P-Service-Indication header fields, and vice versa. In the case of CCBS/CCNR, on the receipt of an INVITE request with a P-Service-indication header field with the value ‘ccss’, this INVITE shall have priority about new incoming requests without such an indication. 8.3 Proxy Behavior When receiving a SIP request or response containing a list of P- Service-Indication header fields, a Proxy MAY ignore them, or it MAY iterate over all of them looking for service indications that can affect the message processing. SIP proxies MAY add or remove P- Service-Indication header fields. 8.4 Example A call completion call, as an example, requires the entity performing call completion to add a P-Service-Indication header field in the INVITE request, as follows: Poetzl Expires August 15, 2007 Page 16 Internet-Draft Call Completion February 2007 INVITE sip:bob@example.com SIP/2.0 Via: UDP/SIP/2.0 10.10.0.1;branch=z9hG4bKkjshdyff From: sip:alice@example.com;tag=a-94f94 To: sip:bob@example.com Call-Id: abcd@10.10.0.1 Max-Forwards: 70 CSeq: 19392 INVITE P-Service-Indication: ccss 8.5 Header Field Definitions This specification defines a new header field, P-Service- Indication. Figure 1 is an extension of Table 2 of RFC 3261 [1] for P-Service- Indication header fields. Header field where proxy ACK BYE CAN INV OPT REG MSG P-Service-Indication ar o o - o o o o Table 1: Summary of methods 8.6 Augmented BNF The BNF for the P-Service-Indication header field is: P-Service-Indication = "P-Service-Indication" HCOLON service- request * (COMMA service-request) service-request= "ccss" / token The "ccss" parameter provides the indication of a CCBS/CCNR call. Additional tokens can be registered using IANA and the procedures in section 11. Poetzl Expires August 15, 2007 Page 17 Internet-Draft Call Completion February 2007 9. Signaling Flows Alice Bob Carol | | | | F1 INVITE | | |---------------------------------->| | F2 486 Busy | | |<----------------------------------| | F3 SUBSCRIBE | | |---------------------------------->| | F4 200 OK | | |<----------------------------------| | F5 NOTIFY | | |<----------------------------------| | F6 200 OK | | |---------------------------------->| | | | | | F7 INVITE | | |---------------->| | | F8 486 Busy | | |<----------------| | | F9 SUBSCRIBE | | |---------------->| | | F10 200 OK | | |<----------------| | | F11 NOTIFY | | |<----------------| | | F12 200 OK | | |---------------->| | | | | | Carols hangs up | | | | F13 NOTIFY | | |<----------------------------------| | F14 200 OK | | |---------------------------------->| | F15 INVITE | | |---------------------------------->| | F16 200 OK | | |<----------------------------------| | F17 ACK | | |---------------------------------->| Figure 1: Call completion on busy subscriber signaling flow Figure 1 shows an example for a basic call completion on busy subscriber signaling flow. In this example Alice wants to call Carol, but Carol is already in a call and answers with a 486 Busy response. In order to indicate to Alice that call completion is Poetzl Expires August 15, 2007 Page 18 Internet-Draft Call Completion February 2007 possible, she inserts ‘Allow-events: call-completion’ into the response. Alice activates call completion by subscribing to the call- completion event package at Carol and adding herself to the call- completion queue. Bob also encounters the busy status when he calls Carol, so he activates to call completion, too. Then Carol hangs up, and Alice is informed of the call-completion condition and she initiates the call-completion call to Carol, using the P-Service-Indication header field (P-service- Indication:ccss). F1 INVITE sip:carol@example.org SIP/2.0 To: ; From: ;tag=1111 Call-ID: 111aaa@phone.example.org CSeq: 1 INVITE Contact: F2 SIP/2.0 486 Busy To: ; From: ;tag=1111 Call-ID: 111aaa@phone.example.org CSeq: 1 INVITE Contact: Allow-events: call-completion F3 SUBSCRIBE sip:carol@example.org SIP/2.0 To: ; From: ;tag=2222 Call-ID: 123456@phone.example.org CSeq: 1 SUBSCRIBEOLO queue-nature: ccbs queue-operation: add caller: Poetzl Expires August 15, 2007 Page 19 Internet-Draft Call Completion February 2007 F4 SIP/2.0 200 OK To: ;tag=3333 From: ;tag=2222 Call-ID: 123456@phone.example.org CSeq: 1 SUBSCRIBE Contact: Expires: 3601 F5 NOTIFY sip:alice@example.org SIP/2.0 To: ;tag=3333 From: ;tag=2222 Call-ID: 123456@phone.example.org CSeq: 1 NOTIFY Contact: Event: call-completion Subscription-state: active queue-nature: ccbs queue-state: request-queued F6 SIP/2.0 200 OK To: ;tag=3333 From: ;tag=2222 Call-ID: 123456@phone.example.org CSeq: 1 NOTIFY Contact: F13 NOTIFY sip:alice@example.org SIP/2.0 To: ;tag=3333 From: ;tag=2222 Call-ID: 123456@phone.example.org CSeq: 2 NOTIFY Contact: Event: call-completion Subscription-state: active queue-nature: ccbs; queue-state: user-free-for-recall] Poetzl Expires August 15, 2007 Page 20 Internet-Draft Call Completion February 2007 F14 SIP/2.0 200 OK To: ;tag=3333 From: ;tag=2222 Call-ID: 123456@phone.example.org CSeq: 2 NOTIFY Contact: F15 INVITE sip:carol@example.org SIP/2.0 To: ; From: ;tag=4444 Call-ID: 222bbb@phone.example.org CSeq: 1 INVITE Contact: P-Service-Indication: ccss F16 SIP/2.0 200 OK To: ;tag=5555 From: ;tag=4444 Call-ID: 222bbb@phone.example.org CSeq: 1 INVITE Contact: If Bob wants to suspend his call completion activation for a certain time (because e.g. he is busy), but he doesn’t want to lose his place in the call completion queue, he refreshes his subscription to the call-completion queue, suspending his call- completion request. When Bob wants to resume the call-completion activation, he refreshes his subscription to call-completion queue again, resuming his call-completion request. The suspend/resume procedures are shown in figure 2. Note that in Carol’s responses the Expires-header field is set to the current remaining duration of the subscription regardless of the value received in the Expires header field of Bob’s subscription refreshes. Poetzl Expires August 15, 2007 Page 21 Internet-Draft Call Completion February 2007 Bob Carol | F18 SUBSCRIBE | |----------------->| | F19 200 OK | |<-----------------| | F20 NOTIFY | |<-----------------| | F21 200 OK | |----------------->| | | | F22 SUBSCRIBE | |----------------->| | F23 200 OK | |<-----------------| | F24 NOTIFY | |<-----------------| | F25 200 OK | |----------------->| Figure 2: Call completion suspend/resume procedures F18 SUBSCRIBE sip:carol@example.org SIP/2.0 To: ;tag=8888 From: ;tag=7777 Call-ID: 654321@phone.example.org CSeq: 2 SUBSCRIBE Contact: Event: call-completion Expires: 3601 queue-nature=ccbs queue-operation=suspend caller= F19 SIP/2.0 200 OK To: ;tag=8888 From: ;tag=7777 Call-ID: 654321@phone.example.org CSeq: 2 SUBSCRIBE Contact: Expires: 2700 Poetzl Expires August 15, 2007 Page 22 Internet-Draft Call Completion February 2007 F20 NOTIFY sip:bob@example.org SIP/2.0 To: ;tag=8888 From: ;tag=7777 Call-ID: 654321@phone.example.org CSeq: 2 NOTIFY Contact: Event: call-completion Subscription-state: active queue-nature: ccbs; queue-state: request-queued F21 SIP/2.0 200 OK To: ;tag=8888 From: ;tag=7777 Call-ID: 654321@phone.example.org CSeq: 2 NOTIFY Contact: F22 SUBSCRIBE sip:carol@example.org SIP/2.0 To: ;tag=8888 From: ;tag=7777 Call-ID: 654321@phone.example.org CSeq: 3 SUBSCRIBE Contact: Event: call-completion Expires: 3601 queue-nature=ccbs queue-operation=resume caller= F23 SIP/2.0 200 OK To: ;tag=8888 From: ;tag=7777 Call-ID: 654321@phone.example.org CSeq: 3 SUBSCRIBE Contact: Expires: 1400 Poetzl Expires August 15, 2007 Page 23 Internet-Draft Call Completion February 2007 F24 NOTIFY sip:bob@example.org SIP/2.0 To: ;tag=8888 From: ;tag=7777 Call-ID: 654321@phone.example.org CSeq: 3 NOTIFY Contact: Event: call-completion Subscription-state: active queue-nature=ccbs; queue-state=request-queued] F25 SIP/2.0 200 OK To: ;tag=8888 From: ;tag=7777 Call-ID: 654321@phone.example.org CSeq: 3 NOTIFY Contact: Poetzl Expires August 15, 2007 Page 24 Internet-Draft Call Completion February 2007 10. Security Considerations 10.1 Call Completion event package Security considerations for SIP event packages are discussed in RFC 3265 [2], and those considerations apply here. Call Completion information is sensitive, potentially private, information. Subscriptions to these event packages SHOULD be authenticated and authorized according to local policy. In addition, notifications SHOULD be sent in such a way to ensure confidentiality, message integrity and verification of subscriber identity, such as sending subscriptions and notifications using a SIPS URL or protecting the notification bodies with S/MIME. 10.2 P-Service-Indication header Every RFC documenting an extension of the P-Service-Indication Header tag, MUST consider security issues independently. Since the "ccss" tag on a request can be abused to obtain privileged treatment, request containing the "ccss" tag SHOULD be authenticated and authorized according to local policy. When crossing trust boundaries, SIP proxies MAY add or remove P-Service- Indication header fields containing the "ccss" tag. 11. IANA Considerations 11.1 SIP Event Package Registration Package name: call-completion Type: package Contact: Ultan Mulligan, Change Controller: SIPPING Working Group delegated from the IESG Published Specification: RFCXXXX 11.2 P-Service-Indication Header Registration This specification registers a new SIP header field, according to the process of RFC 3261 [1]. The following is the registration for the P-Service-Indication header field: RFC Number: RFC XXXX [Note to IANA: Fill with the RFC number of this specification]. Header Field Name: P-Service-Indication Compact Form: (none) Poetzl Expires August 15, 2007 Page 25 Internet-Draft Call Completion February 2007 11.3 IANA P-Service-Indication Tags Registration A new registry ("P-Service-Indication Tags") in the sip-parameters section of IANA has been created, taking a form similar to this table below: Service-Indication Tag Description Reference -------------------------------------------------------------- ccss Indication of a RFC XXXX call-completion call Legend ------ Service-Indication Tag Token to be inserted into the P-Service-Indication Tag Description Short description of the usage for this service indication Reference Reference to RFC documenting usage and scope of this service indication 12. References 12.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Roach, A. B., " Session Initiation Protocol (SIP)-Specific Event Notification ", RFC 3265, June 2002 12.2 Informative References [5] ETSI, "Integrated Services Digital Network (ISDN); Completion of Calls to Busy Subscriber (CCBS) Supplementary Service; Service Description", ETSI EN 300 357 v1.2.1, May 2001, [6] ETSI, "Integrated Services Digital Network (ISDN); Completion of Calls on No Reply (CCNR) Supplementary Service; Service Description", ETSI EN 301 134 v1.1.1, October 1998, . [7] ETSI, "Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 18: Completion of Calls to Busy Subscriber (CCBS) supplementary service", EN 300 356-18 ed.1 (1995-02) Poetzl Expires August 15, 2007 Page 26 Internet-Draft Call Completion February 2007 [8] ETSI, "Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 3 for the international interface; Part 20: Completion of Calls on No Reply (CCNR) supplementary service", EN 300 356-20 V3.2.8 (1998-09), [9] ETSI, "Technical Specification, Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); NGN Signalling Contreol Protocol; Completion of Communications to Busy Subscriber (CCBS) and Completion of Communications on No Reply (CCNR) PSTN/ISDN Simulation Services", ETSI ES 183 042, [12] Jesske, R., "Analysis of the Input Requirements for the Session Initiation Protocol (SIP) in support for the European Telecommunications Standards Institute (ETSI) Next Generation Networks (NGN) simulation service", draft-jesske-sipping-tispan-analysis-03 (work in progress), June 2005. 13. Contributors Roland Jesske Deutsche Telekom Deutsche-Telekom-Allee 1 64307 Darmstadt Germany Email: r.jesske@t-com.net Silvia Tessa Telecom Italia Via Reiss Romoli 274 10148 Torino Italy Email: silvia.tessa@telecomitalia.it Poetzl Expires August 15, 2007 Page 27 Internet-Draft Call Completion February 2007 Alberto Cuda Telecom Italia Via Reiss Romoli 274 10148 Torino Italy Email: alberto.cuda@telecomitalia.it Sebastien Garcin France Telecom 38-40 Rue du General Leclerc 92794 Issy Les Moulineaux France Email: sebastien.garcin@orange-ft.com 14. Authors' Addresses Joachim Poetzl Deutsche Telekom Deutsche-Telekom-Allee 1 64307 Darmstadt Germany Email: joachim.poetzl@t-com.net Martin Huelsemann Deutsche Telekom Deutsche-Telekom-Allee 1 64307 Darmstadt Germany Email: martin.huelsemann@t-com.net Jean-Marie Stupka Siemens AG 81359 Munich Germany Email: jean-marie.stupka@siemens.com Poetzl Expires August 15, 2007 Page 28 Internet-Draft Call Completion February 2007 15. Acknowledgments This draft was motivated based on the requirements in [12]. 16. 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. Poetzl Expires August 15, 2007 Page 29