Internet-Draft CCBS/CCNR June 2006 Sipping Working Group Internet Draft Joachim Poetzl Expires: December 14, 2006 Martin Huelsemann Deutsche Telekom Jean-Marie Stupka Siemens June 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-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 November 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). This document describes two SIP event packages that enable monitoring of queues. These event packages are intended for the limited use of Completion of Calls to Busy Subscribers (CCBS) and Completion of Calls on No Reply (CCNR). Table of Contents 1. Overview 2. Introduction 3. Definitions 4. Requirements motivating SIP extensions in support of CCBS/CCNR 4.1 Queue management capability 4.2 CCBS/CCNR subscription capability indication 4.3 Prioritization of CCBS and CCNR recalls 5. Call completion event package 5.1 CCBS event package definition 5.1.1 Event Package Name 5.1.2 Event Package Parameters 5.1.3 SUBSCRIBE Bodies 5.1.4 Subscription Duration 5.1.5 NOTIFY Bodies 5.1.6 Subscriber generation of SUBSCRIBE requests Poetzl Expires - December 2006 [Page 1] Internet-Draft CCBS/CCNR June 2006 5.1.7 Notifier Processing of SUBSCRIBE Requests 5.1.8 Notifier Generation of NOTIFY Requests 5.1.9 Subscriber Processing of NOTIFY Requests 5.1.10 Handling of Forked Requests 5.1.11 Rate of Notifications 5.1.12 State Agents 5.2 CCNR event package definition 5.2.1 Event Package Name 5.2.2 Event Package Parameters 5.2.3 SUBSCRIBE Bodies 5.2.4 Subscription Duration 5.2.5 NOTIFY Bodies 5.2.6 Subscriber generation of SUBSCRIBE requests 5.2.7 Notifier Processing of SUBSCRIBE Requests 5.2.8 Notifier Generation of NOTIFY Requests 5.2.9 Subscriber Processing of NOTIFY Requests 5.2.10 Handling of Forked Requests 5.2.11 Rate of Notifications 5.2.12 State Agents 6. The P-Service-Indication-Header 6.1 UAC Behaviour 6.2 UAS Behaviour 6.3 Proxy Behaviour 6.4 Example 6.5 Header Field Definitions 6.6 Augmented BNF 7. Signalling Flows 8. Security Considerations 9. IANA Considerations 9.1 SIP Event Package Registration 10. References 10.1. Normative References 10.2. Informational References 11. Contributors 12. Authors' Addresses 13. Acknowledgments 14. Intellectual Property and Copyright Statements 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 documents describes two SIP event packages that enable monitoring of queues. These event packages are intended for the limited use of Completion of Calls to Busy Subscribers (CCBS) and Completion of Calls on No Reply (CCNR). 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. Poetzl Expires - December 2006 [Page 2] Internet-Draft CCBS/CCNR June 2006 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 service provides queue management to arbitrate several CCBS/CCNR requests to the same callee and 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 two new completion event packages for managing the CCBS and CCNR requests and a new header to transport the service indication. 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/CCNR request: an instance of an activation of the CCBS/CCNR service which is held in a queue pending the correct conditions for the CCBS/CCNR service to be completed. Suspended CCBS/CCNR request: a CCBS/CCNR 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. CCBS call: a call generated by the network connecting the caller to the callee, resulting from the callers' acceptance of a CCBS recall. CCBS recall: an indication informing the caller that the network is ready to initiate a CCBS call to the callee and that the network is awaiting a response to this indication. CCSS indication: a parameter indicating a CCBS or CCNR 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. 4 Requirements motivating SIP extensions in support of CCBS/CCNR This section collects the CCBS/CCNR services requirements that cannot be fulfilled with existing SIP capabilities. 4.1 Queue management capability The CCBS and CCNR services require the sending of queue management messages and of notifications of changes in the status of those queues. A subscription to a queue is requested when the completion of a call towards a target user requires a service condition to be met. In the CCBS case the service condition is met upon transition Poetzl Expires - December 2006 [Page 3] Internet-Draft CCBS/CCNR June 2006 from a busy condition to a non-busy condition. For the CCNR case, the service condition is met when the target user has completed a new call with a third party user. This document defines two event packages. The mechanisms necessary to handle the queues (notifications, temporary suspension, resumption and cancellation of subscription entries) are described in section 5 of this memo (Call Completion event packages). 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:ccbs) in a 486 Busy response. The possibility to activate CCNR is indicated by including the Allow- Events Header (Allow-Events:ccnr) in a 180 Ringing response. 4.3 Prioritization of CCBS and CCNR recalls Calls triggered as a result of the execution of a call completion service MUST be distinguishable from new incoming calls. This enables prioritization of these calls above new incoming calls and relays therequired information to be interworked with the PSTN, where a specific “CCSS indication” is required on CCBS/CCNR recalls. For this reason, this document defines a new header, the P-Service- Indication header, described in section 6. 5 Call Completion event packages The Call completion event packages aim at managing subscriptions to the CCBS and CCNR service, and especially targets queues management, in a similar manner to the procedures described in [5] and [6]. 5.1 CCBS event package definition This section fills in the details needed to specify an event package as defined in Section 4.4 of RFC 3265 [2]. 5.1.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 "ccbs". As specified in RFC 3265 [2], this value appears in the Event header present in SUBSCRIBE and NOTIFY requests. 5.1.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 parameter: - "queue-operation", which indicates the requested action. This Parameter is present in the SUBSCRIBE method and can assume the following values: - "add", indicating the subscription must be added in the queue. This parameter can only be present in initial SUBSCRIBE requests. - "suspend", indicating that subscription must be suspended, but not removed from its place in the queue. This parameter can only be present in SUBSCRIBE requests refreshing a subscription - "resume", indicating that a previously suspended subscription must be resumed. This parameter can only be present in SUBSCRIBE requests refreshing a subscription. - "queue-state", which indicates the status of the request in the Poetzl Expires - December 2006 [Page 4] Internet-Draft CCBS/CCNR June 2006 queue. This parameter is present in NOTIFY and can assume the following values: - "request-queued", which indicates the CCBS request was accepted. - "user-free-for-recall", which indicates that the callee has become not busy. - "caller", which uniquely identifies the user that has originated the CCBS subscription. This parameter MUST be present in any initial SUBSCRIBE. - "service-retention", which indicates the support of the retention feature. If present, this parameter indicates that the retain option is supported in the network, otherwise it is not supported. This parameter MAY be present in SUBSCRIBE and/or NOTIFY requests. - "cancellation-reason", which MAY be present if the Expires Header field is valued to 0 and MUST NOT be present otherwise. This parameter details the reason why the CCBS or CCNR subscription is being cancelled and can assume one of the following values: - "operation-timeout": This value corresponds to the expiry of the timer Supervising the response to a "CCBS request" sent from the originating network to the destination network (i.e. the initial NOTIFY). 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": This value corresponds to the expiry of the timer that specifies the maximum time the service will remain activated. 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": This value corresponds to the expiry of the timer that specifies the maximum time the originating network will wait for a response from user A to a CCBS/CCNR recall. 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]. - "CCSS-completed"”: This value indicates that the CCBS service is completed. This value MAY be present in a NOTIFY message and MUST NOT be present in a SUBSCRIBE message. - "denial-reason". This parameter details the reason why the CCBS subscription has been denied and can assume one of the following values: - "short-term-denial": This value indicates that the network temporarily cannot accept user A's request to activate the CCBS service. A later attempt to activate the CCBS service for the same destination B may succeed. This reason will be given e.g.: - if there are already the maximum number of requests queued against destination B; - if there is an interaction with a service which temporarily prevents the activation of the CCBS service; - if no compatible terminal is found at destination B. This value MAY be present in a NOTIFY message and MUST NOT be present in a SUBSCRIBE message. - "long-term-denial": This value indicates that the network cannot accept user A's request to activate the CCBS service and a later attempt to activate the CCBS service for the same destination B 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 RFC3261, such as EQUAL, DQUOTE, and token. queue-operation = "queue-operation" EQUAL ( "add" / "suspend" / "resume" ) queue-state = "queue-state" EQUAL ( "request-queued" / "user-free-for-recall" ) caller = "caller" EQUAL name-addr /addr-spec service-retention = "service-retention" cancellation-reason = “cancellation-reason” EQUAL ( "operation- timeout" / "service-duration" / "recall-timeout" / "CCSS-completed" ) denial-reason = “denial-reason” EQUAL ( "short-term-denial" / "long-term-denial" ) Poetzl Expires - December 2006 [Page 5] Internet-Draft CCBS/CCNR June 2006 5.1.3 SUBSCRIBE Bodies RFC 3265 [2] requires package definitions to define the usage, if any, of bodies in SUBSCRIBE requests. A SUBSCRIBE for CCBS Events MUST NOT contain a Body. 5.1.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 a value higher than 3600 seconds which corresponds to the highest timer alue recommended for the CCBS service in ETSI and ITU-T. 5.1.5 NOTIFY Bodies RFC 3265 [2] requires package definitions to describe the allowed set f body types in NOTIFY requests, and to specify the default value to e used when there is no Accept header field in the SUBSCRIBE request A NOTIFY for CCBS Events MUST NOT contain a Body. 5.1.6 Subscriber generation of SUBSCRIBE requests Subscribers MUST generate SUBSCRIBE requests when a CCBS service condition occurs at the originating network that needs to be sent towards the destination network. This includes the following CCBS operations: CCBS request, CCBS suspend, CCBS resume, and any of the CCBS cancellation operations described in section 5.1.2. The generation of SUBSCRIBE requests MAY imply the usage of CCBS service specific timers. An example of such an implementation can be found in ETSI TS 183 042 [9]. 5.1.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 CCBS event package specified in this document is intended to be sed in private domains (e.g. IMS) where authentication and authorization are provided via means out of scope of this document 5.1.8 Notifier Generation of NOTIFY Requests Notifiers MUST generate NOTIFY requests when a CCBS service condition occurs at the terminating network that needs to be sent towards the originating network. 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 CCBS operation was successful (i.e. CCBS request, CCBS suspend, or CCBS resume) and to "user-free-for-recall" if the user 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 CCBS 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 contain the "queue-state" parameter set to "user-free-for-recall". If the CCBS queuing was denied by the terminating network, the NOTIFY sent as a confirmation of the subscription MUST contain the "denial- reason" parameter. 5.1.9 Subscriber Processing of NOTIFY Requests Poetzl Expires - December 2006 [Page 6] Internet-Draft CCBS/CCNR June 2006 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.1.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 this event type. 5.1.11 Rate of Notifications RFC 3265 [2] mandates that packages define a maximum rate of notifications for their package. The CCBS service typically involves a single notification per notifier and per subscription but MAY involve several notifications separated by a CCBS call that failed due to a busy condition. 5.1.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 this package. 5.2 CCNR event package definition This section fills in the details needed to specify an event package as defined in Section 4.4 of RFC 3265 [2]. 5.2.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 "ccnr". As specified in RFC 3265 [2], this value appears in the Event header present in SUBSCRIBE and NOTIFY requests. 5.2.2 Event Package Parameters The SIP event framework allows event packages to define additional parameters carried in the Event header field. The CCNR package defines the following event header parameter: - "queue-operation", which indicates the requested action. This parameter is present in the SUBSCRIBE method and can assume the following values: - "add", indicating the subscription must be added in the queue. This parameter can only be present in initial SUBSCRIBE requests. - "suspend", indicating that subscription must be suspended, but not removed from its place in the queue. This parameter can only be present in SUBSCRIBE requests refreshing a subscription. - "resume", indicating that a previously suspended subscription must be resumed. This parameter can only be present in SUBSCRIBE requests refreshing a subscription. - "queue-state", which indicates the status of the request in the queue. This parameter is present in NOTIFY and can assume the following values: - "request-queued", which indicates the CCNR request was accepted. - "user-free-for-recall", which indicates that the callee has become not busy. - "caller", which uniquely identifies the user that has originated the CCNR subscription. This parameter MUST be present in any Poetzl Expires - December 2006 [Page 7] Internet-Draft CCBS/CCNR June 2006 initial SUBSCRIBE. - "service-retention", which indicates the support of the retention feature. If present, this parameter indicates that the retain option is supported in the network, otherwise it is not supported. This parameter MAY be present in SUBSCRIBE and/or NOTIFY requests. - "cancellation-reason", which MAY be present if the Expires Header field is valued to 0 and MUST NOT be present otherwise. This parameter details the reason why the CCBS or CCNR subscription is being cancelled and can assume one of the following values: - "operation-timeout": This value corresponds to the expiry of the timer Supervising the response to a "CCNR request" sent from the originating network to the destination network (i.e. the initial NOTIFY). This reason value corresponds to the expiry of CCNR-T2 In the PSTN/ISDN if present in a SUBSCRIBE request as described in [8]. - "service-duration": This value corresponds to the expiry of the timer that specifies the maximum time the service will remain activated. This reason value corresponds to CCNR-T3 expiry in the PSTN/ISDN if present in a SUBSCRIBE request, to CCNR-T7 expiry in the PSTN/ISDN if present in a NOTIFY request as described in [8] - "recall-timeout": This value corresponds to the expiry of the timer that specifies the maximum time the originating network will wait for a response from user A to a CCNR recall. This reason value corresponds to CCNR-T4 expiry in the PSTN/ISDN if present in a SUBSCRIBE request, to CCNR-T9 expiry in the PSTN/ISDN if present in a NOTIFY request as described in [8]. - "CCSS-completed"”: This value indicates that the CCNR service is completed. This value MAY be present in a NOTIFY message and MUST NOT be present in a SUBSCRIBE message. - "denial-reason". This parameter details the reason why the CCNR subscription has been denied and can assume one of the following values: - "short-term-denial": This value indicates that the network temporarily cannot accept user A's request to activate the CCNR service. A later attempt to activate the CCBNR service for the same destination B may succeed. This reason will be given e.g.: - if there are already the maximum number of requests queued against destination B; - if there is an interaction with a service which temporarily prevents the activation of the CCNR service; - if no compatible terminal is found at destination B. This value MAY be present in a NOTIFY message and MUST NOT be Present in a SUBSCRIBE message. - "long-term-denial": This value indicates that the network cannot accept user A's request to activate the CCNR service and a later attempt to activate the CCNR service for the same destination B 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 RFC3261, such as EQUAL, DQUOTE, and token. queue-operation = "queue-operation" EQUAL ( "add" / "suspend" / "resume" ) queue-state = "queue-state" EQUAL ( "request-queued" / "user-free-for-recall" ) caller = "caller" EQUAL name-addr /addr-spec service-retention = "service-retention" cancellation-reason = “cancellation-reason” EQUAL ( "operation- timeout" / "service-duration" / "recall-timeout" / "CCSS-completed" ) denial-reason = “denial-reason” EQUAL ( "short-term-denial" / "long-term-denial" ) The request-URI specifies the user whose data is being subscribed to. Expires: copied from SIP:SUBSCRIBE 5.2.3 SUBSCRIBE Bodies RFC 3265 [2] requires package definitions to define the usage, if any, of bodies in SUBSCRIBE requests. Poetzl Expires - December 2006 [Page 8] Internet-Draft CCBS/CCNR June 2006 A SUBSCRIBE for CCNR Events MUST NOT contain a Body. 5.2.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 a value higher than 3600 (may be higher for CCNR than CCBS) seconds which corresponds to the highest timer value recommended for the CCNR service in ETSI and ITU-T. 5.2.5 NOTIFY Bodies RFC 3265 [2] requires package definitions to describe the allowed set of 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 CCNR Events MUST NOT contain a Body. 5.2.6 Subscriber generation of SUBSCRIBE requests Subscribers MUST generate SUBSCRIBE requests when a CCNR service condition occurs at the originating network that needs to be sent towards the destination network. This includes the following CCNR operations: CCNR request, CCNR suspend, CCNR resume, and any of the CCNR cancellation operations described in section 5.2.2. The generation of SUBSCRIBE requests MAY imply the usage of CCNR service specific timers. An example of such an implementation can be found in ETSI TS 183 042 [9]. 5.2.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 CCNR 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. 5.2.8 Notifier Generation of NOTIFY Requests Notifiers MUST generate NOTIFY requests when a CCNR service condition occurs at the terminating network that needs to be sent towards the originating network. 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 CCNR operation was successful (i.e. CCNR request, CCNR suspend, or CCNR resume) and to "user-free-for-recall" if the user 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 CCNR 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 contain the "queue-state" parameter set to "user-free-for-recall". If the CCNR queuing was denied by the terminating network, the NOTIFY sent as a confirmation of the subscription MUST contain the "denial- reason" parameter. 5.2.9 Subscriber Processing of NOTIFY Requests The subscriber processing of NOTIFY requests MAY trigger additional CCNR service procedures (e.g. CCNR recall, usage of CCNR timers…). An example of such procedures can be found in ETSI TS 183 042 [9]. Poetzl Expires - December 2006 [Page 9] Internet-Draft CCBS/CCNR June 2006 5.2.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 this event type. 5.2.11 Rate of Notifications RFC 3265 [2] mandates that packages define a maximum rate of notifications for their package. The CCNR service typically involves a single notification per notifier and per subscription. 5.2.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 this package. 5.3 Handling of the Allow-Events Header The Call Completion event packages introduce two new Allow-Events header types (Allow-Events:ccbs and Allow-Events:ccnr) 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 fieldwhere 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 treatment when processing 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 can 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 request one or more services to the networks 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. 6.2 UAS Behavior An UAS receiving a request message MAY inspect the P-Service- Indication headers contained therein, in order to apply service- specific features. 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 Poetzl Expires - December 2006 [Page 10] Internet-Draft CCBS/CCNR June 2006 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 CCBS recall, as an example, requires the entity performing CCBS 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 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 CCBS/CCNR recall. Additional tokens can be registered using IANA and the procedures in Section 9. 7. Signalling Flows A successful CCBS flow of messages would be: Subscriber Notifier |-----SUBSCRIBE---->| Subscription to the CCBS target |<-------200--------| Acknowledge subscription |<------NOTIFY----- | Return current state information |--------200------->| | | CCBS Target state becomes not busy |<------NOTIFY----- | Return updated state information |--------200------->| At the end of the above flow the subscriber is now able to initiate the CCBS recall on behalf of user A except if user A is determined busy in which case the following suspend/resume flow applies: Poetzl Expires - December 2006 [Page 11] Internet-Draft CCBS/CCNR June 2006 Subscriber Notifier ... | | Subscriber determines User A is busy |-----SUBSCRIBE---->| Subscriber performs a CCBS suspend operation |<-------200--------| Acknowledge subscription |<------NOTIFY----- | Return current state information |--------200------->| | | Subscriber determines User A is not busy |-----SUBSCRIBE---->| Subscriber performs a CCBS resume operation |<-------200--------| Acknowledge subscription |<------NOTIFY----- | Return current state information |--------200------->| ... 8. Security Considerations 8.1 CCBS and CCNR event packages Security considerations for SIP event packages are discussed in RFC 3265 [2], and those considerations apply here. CCBS and CCNR 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 indipendently. Since the “ccss” tag on a request can be abused to obtain priviledged 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: ccbs Type: package Contact: Ultan Mulligan, Change Controller: SIPPING Working Group delegated from the IESG Published Specification: RFCXXXX Package name: ccnr 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) 9.3. IANA P-Service-Indication Tags Registration Poetzl Expires - December 2006 [Page 12] Internet-Draft CCBS/CCNR June 2006 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 TagDescription Reference ------------------------ ----------------------- --------- ccss Indication of CCBS recall RFC XXXX 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 (...), [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-00 (work in progress), June 2005. 11 Contributors Poetzl Expires - December 2006 [Page 13] Internet-Draft CCBS/CCNR June 2006 Roland Jesske Deutsche Telekom Deutsche-Telekom-Allee 1 Darmstadt 64307 Germany Email: r.jesske@t-com.net Silvia Tessa Telecom Italia Via Reiss Romoli 274 10148 Torino Italy Email: silvia.tessa@telecomitalia.it Alberto Cuda Telecom Italia Via Reiss Romoli 274 10148 Torino Italy Email: alberto.cuda@telecomitalia.it Sebastien Garcin France Telecom 38-40 Rue du Général Leclerc 92794 Issy Les Moulineaux France Email: sebastien.garcin@orange-ft.com 12 Authors' Addresses Joachim Poetzl Deutsche Telekom Deutsche-Telekom-Allee 1 Darmstadt 64307 Germany Email: joachim.poetzl@t-com.net Martin Huelsemann Deutsche Telekom Deutsche-Telekom-Allee 1 Darmstadt 64307 Germany Email: martin.huelsemann@t-com.net Jean-Marie Stupka Siemens AG Munich 81359 Germany Email: jean-marie.stupka@siemens.com 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." Poetzl Expires - December 2006 [Page 14] Internet-Draft CCBS/CCNR June 2006 "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 - December 2006 [Page 15]