[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
    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