SIPPING Joachim Poetzl Internet Draft Martin Huelsemann Expires: December 2007 Deutsche Telekom Intended Status: Proposed Standard 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-bliss-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 December 6, 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. Therefore this document describes a SIP event package that enables subscribing to call-completion states. Furthermore this document extends the usage of the Allows-events header field to 180 Ringing and 486 Busy responses. Poetzl Expires December 2007 Page 1 Internet-Draft Call Completion June 2007 Table of Contents Status of this Memo.........................................1 Abstract..................................................1 Table of Contents..........................................2 1. Terminology.............................................3 2. Definitions.............................................3 3. Overview................................................3 4. Requirements motivating SIP extensions in support of call- completion services.........................................4 4.1 Reception of call-completion information ..................4 4.2 Call-completion possible indication.......................5 5. Solution................................................5 5.1 Proposed solution.......................................5 5.2 Possible other solutions.................................6 6. Call Completion event package.............................7 6.1 Event Package Name......................................7 6.2 Event Package Parameters.................................7 6.3 SUBSCRIBE Bodies........................................7 6.4 Subscription Duration...................................8 6.5 NOTIFY Bodies..........................................8 6.6 Subscriber Generation of SUBSCRIBE requests................8 6.7 Notifier Processing of SUBSCRIBE Requests..................9 6.8 Notifier Generation of NOTIFY Requests....................9 6.9 Subscriber Processing of NOTIFY Requests .................10 6.10 Handling of Forked Requests............................10 6.11 Rate of Notifications.................................10 6.12 State Agents.........................................10 6.13 Handling of the Allow-Events Header.....................10 7. Call-completion information format........................11 7.1 call-completion-state..................................11 7.2 service-retention......................................11 8. Signaling Flows ........................................13 9. Security Considerations.................................19 10. IANA Considerations....................................19 10.1 SIP Event Package Registration .........................19 11. References............................................19 11.1 Normative References..................................19 11.2 Informative References ................................19 12. Contributors..........................................20 13. Authors' Addresses.....................................21 14. Acknowledgments........................................22 15. Full Copyright Statement................................22 16. Intellectual Property..................................22 17. Acknowledgment ........................................23 Poetzl Expires December, 2007 Page 2 1. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and indicate requirement levels for compliant implementations. 2. Definitions For the purpose of this service, we provide the following definitions: CCBS: Completion of Calls to Busy Subscribers CCNR: Completion of Calls on No Reply 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. Call-completion queue: a buffer at the callee which queues automatically not answered calls due to busy or no reply. Callee: called user, busy when the first call arrives, target of the cal-completion call. Caller: calling user, encounters a busy callee at the first call, initiator of the call-completion call. Retain option: a characteristic of the call-completion service; if supported, call-completion calls which again encounter a busy callee will not be queued again, but the position of the caller's entry in the queue is retained 3. Overview 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 cability to queue not answered calls from several callers to a busy callee and to inform the caller that he can initiate a call-completion call after the callee has become not busy. Completion of Calls on no Reply (CCNR) provides the cability to queue not answered calls from several callers to a callee and to Poetzl Expires December, 2007 Page 3 Internet-Draft Call Completion June 2007 inform the caller that he can initiate a call-completion call after the callee has become not busy after having initiated an activity. A not answered call automatically results in an entry in a call- completion queue. The caller then has the possibility to decide if he wants to receive information about his cal-completion queue state. Usually call-completion queues are organized on a FIFO basis and limited in the number of entries, and a queue entry is temporary. If a queue entry reaches the top of the queue, it will be allowed to establish a call-completion call when the callee is available, and the caller is informed accordingly. A queue entry will be deleted when it matures or when the caller successfully has established a call-completion call to the callee. If a call-completion call cannot be answered (e.g. the callee has become busy again in the meantime), it depends on the service logic if the caller keeps his position in the queue, or if his current queue entry is deleted and a new queue entry for him is added. 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 Reception of call-completion information The CCBS and CCNR services require the capability to receive information of the caller's call-completion state. This includes the requirement that the caller can indicate that he is willing to receive these information. The call-completion state results from the user's position in a call-completion queue. A new entry for a caller in the queue is in the 'queued' state. If a queue entry reaches the top of the queue, the caller will be informed that he can establish a call-completion call when the callee is available. In this case the state of the caller changes from 'queued' to 'ready-for-call-completion' and the caller will be informed accordingly. The realization of call-completion services includes also suspending and resuming of receiving call-completion information, which gives the caller the possibility to pause receiving those information without loosing his position in the queue. Suspending a call-completion request occurs when the caller is not available for starting a call-completion call (i.e., the caller is busy) but wishes to retain the position of his entry on the call- Poetzl Expires December, 2007 Page 4 Internet-Draft Call Completion June 2007 completion queue 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). For the case that his call-completion call fails, the caller needs to be informed, if the position of his entry in the queue will remain the same, or if his entry will be deleted and a new entry will be added to the queue. This retention information is also needed for the interworking with the PSTN, where both possibilities exist. For the case that a caller indicates that he is willing to receive information about his call-completion state, but it is not possible to provide the caller with this information at this time, it is required to inform the caller about the denial reasons, which can be a short term denial if the call-completion queue has reached its limit, or a long term denial if a general error that prevents the call-completion service has occurred. The information about the denial reason is also required for the interworking with the PSTN, especially information about a short term denial results from this interworking because of different call-completion procedures in the PSTN, where a user is only added to the call-completion queue when he has requested it. 4.2 Call-completion possible indication In order to ensure that end-to-end functionality of the call- completion services is possible, there must be an indication to the caller during the attempted call establishment that call-completion information are available. 5. Solution 5.1 Proposed solution The Session Initiation Protocol (SIP) event framework is described in RFC 3265 [2]. 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 in section 7 a new SIP event package (call- completion event package) that enables subscribing to call- completion states. After being queued automatically, a caller can subscribe to a call-completion queue at a busy callee and receives Poetzl Expires December, 2007 Page 5 Internet-Draft Call Completion June 2007 notifications if he is still queued or if he can establish a call- completion call. The caller is also notified if the retention option is supported at the callee. After a successful subscription to the call-completion event package using the SIP SUBSCRIBE request, relevant changes in the call-completion state associated with the subscription are reported to the subscriber by means of the SIP NOTIFY requests, in accordance with the procedures described in RFC 3265 [2]. A NOTIFY request that reports that the callee is available for a call- completion call attempt to be made will cause the subscriber to trigger the establishment of that call, subject to the caller being available too. The SUBSCRIBE method is also used to suspend and to resume the subscription. Suspending is accomplished by using the Unsubscribing procedures, resuming is done by using the Subscribing procedures, as described in subclause 3.1.4 of RFC 3265 [2]. It is assumed that the call-completion service logic can distinguish between a new subscription and a resuming subscription, when there is an entry for the subscriber in the call completion queue. For a correlation between a suspended subscription and a new subscription, procedures according to draft-ietf-sip-subnot-etags- 00.txt may be used. Furthermore the present document specifies the usage of the Allow- events header field for the realization of call-completion services. The possibility to subscribe to the call-completion event package in case of CCBS is indicated by including the Allow-Events Header field (Allow-Events:call-completion) in a 486 Busy response. The possibility to subscribe to the call-completion event package in case of 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 events 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. 5.2 Possible other solutions 1) Usage of dialog event packages Poetzl Expires December, 2007 Page 6 Internet-Draft Call Completion June 2007 Different to the call-completion event package, the dialog event package is not intended for call-completion, because 'dialog terminated' does not equal 'ready for recall', and a user might want to receive information about dialog state as well as information about call-completion state. 2) BFCP RFC3265 obviously has a much greater implementation basis than BFCP, and because it has much greater implementation basis, the experience in inter-operability etc. is greater. Further, although BFCP may be easy to implement, the state-machine needed for BFCP and its need to exchange information with the SIP state-machine is something that's not very common and hasn't been done too extensively yet. Lastly, RFC3265 is part of the core spec as mentioned in the hitchhiker's guide, so the foundation on which the call-completion is to be implemented is very likely be there to start with. 3) HTTP polling HTTP Polling has no way for the server to find out if the message has been delivered (there is no equivalence to a 200 OK to a NOTIFY request), it causes a lot of message exchange and is inefficient as it polls even if there is no change in the status of the queue. 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 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 request for a Poetzl Expires December, 2007 Page 7 Internet-Draft Call Completion June 2007 call-completion package MAY contain a body. This body defines a filter to be applied to the subscription. Filter documents are not specified in this document. 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. The duration of the subscription is also coupled to the remaining duration of a queue entry. This means in case of resuming a subscription the resulting duration will be less than 3600 seconds. 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 a call-completion package MUST contain a body that describes the call-completion states. 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 8. 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". This "application/call-completion" data format is described in chapter 8. 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 Poetzl Expires December, 2007 Page 8 Internet-Draft Call Completion June 2007 Subscribers MUST generate SUBSCRIBE requests when they want to subscribe to the call-completion event package at the terminating side in order to receive call-completion notifications. 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. If a subscription is not successful because the call-completion queue has reached the maximum number of entries (short term denial), the notifier MUST send a 480 Temporarily Unavailable response to the subscriber. If a subscription is not successful because a general error that prevents the call-completion service has occurred (long term denial), the notifier MUST send a 403 Forbidden response to the subscriber. 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 "call-completion-state" parameter set to "queued" if the user is busy and the call- completion subscription was successful (i.e. initial call- completion subscription, or a call-completion subscription for resume reasons) and to "ready-for-call-completion" if the call- completion target is not busy. A NOTIFY sent as a confirmation of a request to unsubscribe MAY contain the "call-completion-state" parameter. When the callee's status changes from busy to not busy, the notifier MUST send a NOTIFY only to first queue entry with an Poetzl Expires December, 2007 Page 9 Internet-Draft Call Completion June 2007 active subscription. This NOTIFY MUST contain the "call- completion-state" parameter set to "ready-for-call-completion". If the call-completion subscription was successful and the retention option is supported at the callee, the NOTIFY MUST contain the "retention-option" 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. 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 - - - - - Poetzl Expires December, 2007 Page 10 Internet-Draft Call Completion June 2007 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 = [call-completion-state CLRF] [service-retention CLRF] A description of the above mentioned rules follows. 7.1 call-completion-state The call-completion-state parameter indicates the call-completion status of a particular user with an entry in a call-completion queue. call-completion-state = "call-completion-state" HCOLON ( "queued" / "ready-for-call-completion" ) 8.1.1 queued The value queued indicates that a user has an entry in a call- completion queue, but which has not reached the queue position that enables a call-completion call. 8.1.2 ready-for-call-completion The value ready-for-call-completion indicates that a user has an entry in a call-completion queue which has reached the queue position that enables a call-completion call. 7.2 service-retention The service-retention indicates the support of the retain option. The retain option, if supported at the callee, will maintain the entry in the call-completion 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 NOTIFY requests. service-retention = "service-retention" Poetzl Expires December, 2007 Page 11 Internet-Draft Call Completion June 2007 Poetzl Expires December, 2007 Page 12 Internet-Draft Call Completion June 2007 8. 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. Alice is added to the call-completion queue at Carol. In order to indicate to Alice that a call-completion notification Poetzl Expires December, 2007 Page 13 Internet-Draft Call Completion June 2007 is possible, she inserts 'Allow-events:call-completion' into the response. Alice subscribes to the call-completion event package at Carol. Bob also encounters the busy status when he calls Carol, so he subscribes to the call-completion event package, too. Then Carol hangs up, and Alice is informed of the call-completion condition and she initiates the call-completion call to Carol. 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 SUBSCRIBE Contact: Event: call-completion 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 Poetzl Expires December, 2007 Page 14 Internet-Draft Call Completion June 2007 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 call-completion-state: 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 call-completion-state: ready-for-call-completion F14 SIP/2.0 200 OK To: ;tag=3333 From: ;tag=2222 Call-ID: 123456@phone.example.org CSeq: 2 NOTIFY Contact: Poetzl Expires December, 2007 Page 15 Internet-Draft Call Completion June 2007 F15 INVITE sip:carol@example.org SIP/2.0 To: ; From: ;tag=4444 Call-ID: 222bbb@phone.example.org CSeq: 1 INVITE Contact: F16 SIP/2.0 200 OK To: ;tag=5555 From: ;tag=4444 Call-ID: 222bbb@example.org CSeq: 1 INVITE Contact: 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 If Bob wants to suspend his call completion subscription for a certain time (because e.g. he is busy), he terminates the subscription according to the procedures described in subclause 3.3.4 of RFC 3265 [2]. When Bob wants to resume the call- completion activation, he subscribes again to the call-completion event package. Poetzl Expires December, 2007 Page 16 Internet-Draft Call Completion June 2007 The suspend/resume procedures are shown in figure 2. Note the suspending a subscription doesn't change the position of the call- completion queue entry of the subscriber. Note also that in Carol's responses to Bob's subscriptions the Expires-header field is set to the current remaining duration of Bob's queue entry regardless of the value received in the Expires header field of Bob's subscription. 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: 0 F19 SIP/2.0 200 OK To: ;tag=8888 From: ;tag=7777 Call-ID: 654321@phone.example.org CSeq: 2 SUBSCRIBE Contact: 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: terminated F21 SIP/2.0 200 OK To: ;tag=8888 From: ;tag=7777 Call-ID: 654321@phone.example.org CSeq: 2 NOTIFY Contact: Poetzl Expires December, 2007 Page 17 Internet-Draft Call Completion June 2007 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 F23 SIP/2.0 200 OK To: ;tag=8888 From: ;tag=7777 Call-ID: 654321@phone.example.org CSeq: 3 SUBSCRIBE Contact: Expires: 1400 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 call-completion-state=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 December, 2007 Page 18 Internet-Draft Call Completion June 2007 9. Security Considerations 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. IANA Considerations 10.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. References 11.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 11.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 Poetzl Expires December, 2007 Page 19 Internet-Draft Call Completion June 2007 Subscriber (CCBS) supplementary service", EN 300 356-18 ed.1 (1995-02) [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. 12. 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 December, 2007 Page 20 Internet-Draft Call Completion June 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 13. 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 Nokia Siemens Networks 81359 Munich Germany Email: jean-marie.stupka@nsn.com Poetzl Expires December, 2007 Page 21 Internet-Draft Call Completion June 2007 14. Acknowledgments This draft was motivated based on the requirements in [12]. 15. 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. 16. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any Poetzl Expires December, 2007 Page 22 Internet-Draft Call Completion June 2007 copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 17. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Poetzl Expires December, 2007 Page 23