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: <sip:carol@example.org>;
From: <sip:alice@example.org>;tag=1111
Call-ID: 111aaa@phone.example.org
CSeq: 1 INVITE
Contact: <sip:alice@example.org>
F2
SIP/2.0 486 Busy
To: <sip:carol@example.org>;
From: <sip:alice@example.org>;tag=1111
Call-ID: 111aaa@phone.example.org
CSeq: 1 INVITE
Contact: <sip:carol@example.org>
Allow-events: call-completion
F3
SUBSCRIBE sip:carol@example.org SIP/2.0
To: <sip:carol@example.org>;
From: <sip:alice@example.org>;tag=2222
Call-ID: 123456@phone.example.org
CSeq: 1 SUBSCRIBE
Contact: <sip:alice@example.org >
Event: call-completion
Expires: 3601
F4
SIP/2.0 200 OK
To: <sip:carol@example.org>;tag=3333
From: <sip:alice@example.org>;tag=2222
Call-ID: 123456@phone.example.org
CSeq: 1 SUBSCRIBE
Contact: <sip:carol@example.org>
Expires: 3601
Poetzl Expires December, 2007 Page 14
Internet-Draft Call Completion June 2007
F5
NOTIFY sip:alice@example.org SIP/2.0
To: <sip:carol@example.org>;tag=3333
From: <sip:alice@example.org>;tag=2222
Call-ID: 123456@phone.example.org
CSeq: 1 NOTIFY
Contact: <sip:carol@example.org>
Event: call-completion
Subscription-state: active
call-completion-state: queued
F6
SIP/2.0 200 OK
To: <sip:carol@example.org>;tag=3333
From: <sip:alice@example.org>;tag=2222
Call-ID: 123456@phone.example.org
CSeq: 1 NOTIFY
Contact: <sip:alice@example.org>
F13
NOTIFY sip:alice@example.org SIP/2.0
To: <sip:carol@example.org>;tag=3333
From: <sip:alice@example.org>;tag=2222
Call-ID: 123456@phone.example.org
CSeq: 2 NOTIFY
Contact: <sip:carol@example.org>
Event: call-completion
Subscription-state: active
call-completion-state: ready-for-call-completion
F14
SIP/2.0 200 OK
To: <sip:carol@example.org>;tag=3333
From: <sip:alice@example.org>;tag=2222
Call-ID: 123456@phone.example.org
CSeq: 2 NOTIFY
Contact: <sip:alice@phone.example.org>
Poetzl Expires December, 2007 Page 15
Internet-Draft Call Completion June 2007
F15
INVITE sip:carol@example.org SIP/2.0
To: <sip:carol@example.org>;
From: <sip:alice@example.org>;tag=4444
Call-ID: 222bbb@phone.example.org
CSeq: 1 INVITE
Contact: <sip:alice@example.org>
F16
SIP/2.0 200 OK
To: <sip:carol@example.org>;tag=5555
From: <sip:alice@example.org>;tag=4444
Call-ID: 222bbb@example.org
CSeq: 1 INVITE
Contact: <sip:carol@phone.example.org>
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: <sip:carol@example.org>;tag=8888
From: <sip:bob@example.org>;tag=7777
Call-ID: 654321@phone.example.org
CSeq: 2 SUBSCRIBE
Contact: <sip:bob@example.org>
Event: call-completion
Expires: 0
F19
SIP/2.0 200 OK
To: <sip:carol@example.org>;tag=8888
From: <sip:bob@example.org>;tag=7777
Call-ID: 654321@phone.example.org
CSeq: 2 SUBSCRIBE
Contact: <sip:carol@phone.example.org>
F20
NOTIFY sip:bob@example.org SIP/2.0
To: <sip:carol@example.org>;tag=8888
From: <sip:bob@example.org>;tag=7777
Call-ID: 654321@phone.example.org
CSeq: 2 NOTIFY
Contact: <sip:carol@example.org>
Event: call-completion
Subscription-state: terminated
F21
SIP/2.0 200 OK
To: <sip:carol@example.org>;tag=8888
From: <sip:bob@example.org>;tag=7777
Call-ID: 654321@phone.example.org
CSeq: 2 NOTIFY
Contact: <sip:bob@phone.example.org>
Poetzl Expires December, 2007 Page 17
Internet-Draft Call Completion June 2007
F22
SUBSCRIBE sip:carol@example.org SIP/2.0
To: <sip:carol@example.org>;tag=8888
From: <sip:bob@example.org>;tag=7777
Call-ID: 654321@phone.example.org
CSeq: 3 SUBSCRIBE
Contact: <sip:bob@phone.example.org>
Event: call-completion
Expires: 3601
F23
SIP/2.0 200 OK
To: <sip:carol@example.org>;tag=8888
From: <sip:bob@example.org>;tag=7777
Call-ID: 654321@phone.example.org
CSeq: 3 SUBSCRIBE
Contact: <sip:carol@phone.example.org>
Expires: 1400
F24
NOTIFY sip:bob@example.org SIP/2.0
To: <sip:carol@example.org>;tag=8888
From: <sip:bob@example.org>;tag=7777
Call-ID: 654321@phone.example.org
CSeq: 3 NOTIFY
Contact: <sip:carol@phone.example.org>
Event: call-completion
Subscription-state: active
call-completion-state=queued]
F25
SIP/2.0 200 OK
To: <sip:carol@example.org>;tag=8888
From: <sip:bob@example.org>;tag=7777
Call-ID: 654321@phone.example.org
CSeq: 3 NOTIFY
Contact: <sip:bob@example.org>
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, <ultan.mulligan@etsi.org>
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,
<http://webapp.etsi.org/workprogram/Report_WorkItem.asp
?WKI_ID=10707>
[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, <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=2451>.
[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)
<http://webapp.etsi.org/exchangefolder/ets_30035618e01p.pdf>
[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), <http://webapp.etsi.org/???>
[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,
<http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?
WKI_ID=21150>
[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