SIPPING Joachim Poetzl Internet Draft Martin Huelsemann Expires: February 15, 2007 Deutsche Telekom Jean-Marie Stupka Siemens August 15, 2006 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-01 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 December 14 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies the extensions to the Session Initiation Protocol (SIP) for the call completion simulation 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. Further on this document extends the usage of the Allows-events header to 180 Poetzl Expires February 15, 2007 Page 1 Internet-Draft Call Completion July 2006 Ringing and 486 Busy responses, and specifies an indication used for the prioritization of call-completion calls. Table of Contents 1. Overview................................................3 2. Introduction............................................3 3. Definitions.............................................4 4. Requirements motivating SIP extensions in support of call completion services.........................................5 4.1 Queue subscription and management capability...............5 4.2 CCBS/CCNR subscription capability indication...............6 4.3 Prioritization of call-completion calls...................6 5. Call Completion event package.............................6 5.1 Event Package Name......................................7 5.2 Event Package Parameters.................................7 5.3 SUBSCRIBE Bodies.......................................10 5.4 Subscription Duration..................................10 5.5 NOTIFY Bodies.........................................10 5.6 Subscriber Generation of SUBSCRIBE requests...............10 5.7 Notifier Processing of SUBSCRIBE Requests.................10 5.8 Notifier Generation of NOTIFY Requests...................11 5.9 Subscriber Processing of NOTIFY Requests .................11 5.10 Handling of Forked Requests............................11 5.11 Rate of Notifications.................................11 5.12 State Agents.........................................12 5.13 Handling of the Allow-Events Header.....................12 6. The P-Service-Indication Header..........................12 6.1 UAC Behavior..........................................12 6.2 UAS Behavior..........................................13 6.3 Proxy Behavior ........................................13 6.4 Example...............................................13 6.5 Header Field Definitions................................13 6.6 Augmented BNF.........................................14 7. Signaling Flows ........................................14 8. Security Considerations.................................21 8.1 Call Completion event package...........................21 8.2 P-Service-Indication header.............................21 9. IANA Considerations.....................................21 9.1 SIP Event Package Registration..........................21 9.2 P-Service-Indication Header Registration .................21 9.3 IANA P-Service-Indication Tags Registration...............22 10. References............................................22 10.1 Normative References..................................22 10.2 Informative References ................................22 11. Contributors..........................................23 12. Authors' Addresses.....................................24 13. Acknowledgments........................................25 14. Intellectual Property and Copyright Statements............25 Poetzl Expires February 15, 2007 Page 2 Internet-Draft Call Completion July 2006 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 the creation of a multimedia fixed network. Generally NGN is largely 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 provided support to existing Integrated Services Digital Network and Public Switched Telephone Network (ISDN/PSTN) supplementary services has been also acknowledged. We refer to supplementary services provided with SIP in the context of NGN as "simulation services". They are referred to as simulation services because they need to be adapted to be provided with SIP, so small variations are expected when compared with the equivalent ISDN/PSTN supplementary service. 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) simulation 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 supplementary 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 supplementary service description is defined in ETSI EN 301 134 [6]. The call completion service provides the capability to queue several CCBS/CCNR requests to the same callee on a FIFO basis, Poetzl Expires February 15, 2007 Page 3 Internet-Draft Call Completion July 2006 therefore it requires functionalities like notifying changes of queue states and managing queues. The Session Initiation Protocol (SIP) event framework is described in RFC 3265 [1]. It defines a generic framework for subscription 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. Further on it specifies the usage of the Allow-events header 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 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 service 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: a parameter indicating a call-completion call. Retain option: the retain option, if supported in both the originating and destination network, will maintain the CCBS or the CCNR request in the destination B queue, if a CCBS or a CCNR call has failed due to destination busy condition. Poetzl Expires February 15, 2007 Page 4 Internet-Draft Call Completion July 2006 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 subscription and management capability The CCBS and CCNR services require the capability to subscribe to and to manage call completion queues and to send notifications of changes in the status of those queues. A subscription to a call completion queue is needed, if a session establishment was not successful, but the target user is able to inform the calling user about the call completion condition (the possibility to successfully reinitiate the session invitation), and he is able to provide this information in a sequential manner, if session invitations from several callers failed (FIFO queue). When the calling user does not need information about the call completion condition any longer, he can cancel the call completion queue subscription. 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. In the CCBS case the call completion condition is met upon transition of the target user from a busy condition to a non-busy condition. In the CCNR case the call completion condition is met when the target user has completed a new call with a third user. The sending of queue management messages is needed, if a user wants to suspend or resume his call completion subscription. Suspension of a call completion subscription means the user does not want to receive notifications about the call completion condition for a certain time, e.g. because he is not able to make use of this information as he is busy himself, but he also does not want to unsubscribe to the queue and lose his position in the queue. When the user again wants to be informed of the call completion condition, he resumes his call completion subscription. Queue management also includes notifications about the reasons for the denial or cancellation of a call completion request. This document defines in section 5 a new event package (Call Completion event package), describing the mechanisms necessary to handle the queues (notifications, temporary suspension, resumption and cancellation of subscription entries). Poetzl Expires February 15, 2007 Page 5 Internet-Draft Call Completion July 2006 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 that the CCBS/CCNR service is possible. The possibility to activate CCBS is indicated by including the Allow-Events Header (Allow-Events:call-completion) in a 486 Busy response. The possibility to activate CCNR is indicated by including the Allow-Events Header (Allow-Events:call-completion) in a 180 Ringing response. 4.3 Prioritization of call-completion calls Calls triggered as a result of the execution of a call completion service (call-completion call) MUST be distinguishable from new incoming calls. This enables prioritization of these calls above new incoming calls and avoids that a call-completion call is rejected at the destination because there are still call-completion requests queued, which can have a higher priority because of the call-completion service logic. The call-completion call prioritization is also a required information for the interworking with the PSTN, where a specific ‘CCSS indication’ is required for CCBS/CCNR calls. For this reason, this document defines a new header, the P-Service- Indication header, described in section 6. 5. Call Completion event package The Call completion event package aims at subscribing to and at managing call completion queues. This event package is useful in situations, where a session establishment was not successful, but the target of the session invitation (callee) is able to provide information to the session initiator (caller) when it is possible to successfully reinitiate the session invitation and to provide this information in a sequential manner, if session invitations from several origins (callers) failed. Typical examples for this situation are the CCBS and CCNR procedures described in [5] and [6]. Further on the subscriber to this event package has the possibility to suspend his subscription for a certain time and later resume the subscription. In this time he is not informed of a possible session reinitiating, but the call completion service logic which is out of scope of the present document ensures that the subscriber holds his place in the queue. This section fills in the details needed to specify an event package as defined in Section 4.4 of RFC 3265 [2]. Poetzl Expires February 15, 2007 Page 6 Internet-Draft Call Completion July 2006 5.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 header present in SUBSCRIBE and NOTIFY requests. 5.2 Event Package Parameters The SIP event framework allows event packages to define additional parameters carried in the Event header field. The CCBS package defines the following event header parameters: "queue-nature" This parameter indicates the nature of the call completion event and may be present in SUBSRIBE and NOTIFY requests. It can take the following values: - "CCBS", which indicates a CCBS queue; - "CCNR", which indicates a CCNR queue; It is possible that further values are needed in future, they can be defined by the RFCs which extend the present functionality. "queue-operation" This parameter indicates the requested action and is present in SUBSCRIBE requests. It can take the following values: - "add", which indicates that the subscription must be added in the queue. This value can only be present in initial SUBSCRIBE requests. - "suspend", which indicates 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 - "resume", which indicates that a previously suspended subscription must be resumed. This value can only be present in SUBSCRIBE requests refreshing a subscription. "queue-state" This parameter indicates the status of the request in the queue and is present in NOTIFY requests. It can take the following values: - "request-queued", which indicates the call-completion queue request was accepted and is active. - "user-free-for-recall", which indicates the call-completion condition. Poetzl Expires February 15, 2007 Page 7 Internet-Draft Call Completion July 2006 "caller" This parameter uniquely identifies the user that has originated the call completion request and MUST be present in any initial SUBSCRIBE request. "service-retention" This parameter 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 that the retain option is supported, otherwise it is not supported. This parameter MAY be present in SUBSCRIBE and/or NOTIFY requests. "cancellation-reason" This parameter 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 and can take one of the following values: - "operation-timeout", which 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]. - "service-duration", which 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]. - "recall-timeout", which 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]. - "service-completed", which 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 February 15, 2007 Page 8 Internet-Draft Call Completion July 2006 "denial-reason" This parameter details the reason why the call completion request has been denied and can take one of the following values: - "short-term-denial", which 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. - "long-term-denial", which 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 ABNF for these parameters is shown below. It refers to many constructions from the ABNF of RFC 3261, such as EQUAL, DQUOTE, and token. queue-nature = "queue-nature" EQUAL ( "CCBS" / "CCNR" ) queue-operation = "queue-operation" EQUAL ( "add" / "suspend" / "resume" ) queue-state = "queue-state" EQUAL ( "request-queued" / "user-free-for-recall" ) caller = "caller" EQUAL addr-spec service-retention = "service-retention" cancellation-reason = "cancellation-reason" EQUAL ( "operation- timeout" / "service-duration" / "recall-timeout" / "service-completed" ) denial-reason = "denial-reason" EQUAL ( "short-term-denial" / "long-term-denial" ) The request-URI specifies the user whose data is being subscribed to. Poetzl Expires February 15, 2007 Page 9 Internet-Draft Call Completion July 2006 5.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 NOT contain a Body. 5.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. 5.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 NOT contain a Body. 5.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.1.2. 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]. 5.7 Notifier Processing of SUBSCRIBE Requests Upon receiving a subscription refresh, the notifier MUST set the Expires 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. Poetzl Expires February 15, 2007 Page 10 Internet-Draft Call Completion July 2006 5.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. 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. 5.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]. 5.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. 5.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. Poetzl Expires February 15, 2007 Page 11 Internet-Draft Call Completion July 2006 5.12 State Agents RFC 3265 [2] asks packages to consider the role of state agents in their design. State agents have no rule in the handling of the call completion package. 5.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. 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 - - - - - 6. 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. 6.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. Poetzl Expires February 15, 2007 Page 12 Internet-Draft Call Completion July 2006 6.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. 6.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. 6.4 Example A call completion call, as an example, requires the entity performing call completion to add a P-Service-Indication header in the INVITE request, as follows: 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 6.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 Poetzl Expires February 15, 2007 Page 13 Internet-Draft Call Completion July 2006 6.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 9. 7. 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 Poetzl Expires February 15, 2007 Page 14 Internet-Draft Call Completion July 2006 Alice Bob Carol | | | | 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 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 (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 Poetzl Expires February 15, 2007 Page 15 Internet-Draft Call Completion July 2006 F3 SUBSCRIBE sip:carol@example.org SIP/2.0 To: ; From: ;tag=2222 Call-ID: 123456@phone.example.org CSeq: 1 SUBSCRIBE Contact: Event: call-completion;queue-nature=ccbs;queue- operation=add;caller= Expires: 3601 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;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: Poetzl Expires February 15, 2007 Page 16 Internet-Draft Call Completion July 2006 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;queue-nature=ccbs;queue-state=user-free-for- recall; 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. Poetzl Expires February 15, 2007 Page 17 Internet-Draft Call Completion July 2006 The suspend/resume procedures are shown in figure 2. Note that in Carol’s responses the Expires-header is set to the current remaining duration of the subscription regardless of the value received in the Expires header of Bob’s subscription refreshes. 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;queue-nature=ccbs;queue- operation=suspend;caller= Expires: 3601 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 February 15, 2007 Page 18 Internet-Draft Call Completion July 2006 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;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;queue-nature=ccbs;queue- operation=resume;caller= Expires: 3601 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 February 15, 2007 Page 19 Internet-Draft Call Completion July 2006 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;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 February 15, 2007 Page 20 Internet-Draft Call Completion July 2006 8. Security Considerations 8.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. 8.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. 9. IANA Considerations 9.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 9.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 February 15, 2007 Page 21 Internet-Draft Call Completion July 2006 9.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 10. References 10.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 10.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 February 15, 2007 Page 22 Internet-Draft Call Completion July 2006 [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. 11. 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 February 15, 2007 Page 23 Internet-Draft Call Completion July 2006 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 12. 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 February 15, 2007 Page 24 Internet-Draft Call Completion July 2006 13. Acknowledgments This draft was motivated based on the requirements in [12]. 14. Intellectual Property and Copyright Statements "Copyright (C) The Internet Society (2006). 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 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 February 15, 2007 Page 25