Internet DRAFT - draft-sinha-dispatch-sip-continuation-option

draft-sinha-dispatch-sip-continuation-option



DISPATCH Working Group                                    Amardeep Sinha
Internet Draft                                            Subhrajyoti De
Intended Status: Informational                         Sunil Kumar Sinha
Expires: October 1, 2012                             Manjunath Hanchinal
                                                           April 2, 2012


  The Continue Header Field for the Session Initiation Protocol (SIP)
          draft-sinha-dispatch-sip-continuation-option-03.txt

Abstract

   Before placing a call, it is quite often useful for the Caller to
   know whether a Callee is in favorable state to receive a call or 
   not. This document defines an optional tag "continue" and a header
   "Continue" to address the purpose.  The "Continue" header field is
   to confirm the session continuity with the Callee from the Caller
   after an option for session continuity is placed by the Callee based
   on the unfavorable state of the Callee.  This functionality is needed
   to resolve the unwillingness of the Callee to receive any call. An
   option is given to the Callee by the Service Provider or by the
   Handset Manufacturer or by the Carrier to establish this requirement.


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF).  Note that
   other groups may also distribute working documents as
   Internet-Drafts.  The list of current Internet-Drafts is at
   http://datatracker.ietf.org/drafts/current.

   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."

   This Internet-Draft will expire on October 1, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.

De,Hanchinal,Sinha           Expires October 2012               [Page 1]

Internet-Draft              SIP Continuation Option           April 2012

Table of Contents
   1.   Introduction.................................................02
        1.1  Terminology.............................................04
   2.   Overall Operation............................................04
   3.   UAS Behavior.................................................05
   4.   UAC Behavior.................................................06
   5.   The Continue Header Definition...............................06
   6.   Backwards Compatibility......................................08
   7.   Examples and Use cases.......................................08
        7.1 Call is Finally Placed by Calling Party..................08
        7.2 Call is Finally Not Placed by Calling Party..............10
        7.3 Caller Hungs Up..........................................12
        7.4 Caller does not have Call Continuation Option feature....12
        7.5 Callee does not support NDDND feature....................13
        7.6 SIP-ISDN Interworking with Call Continuation feature.....13
        7.7 SIP-FXS Interworking with Call Continuation feature......17
   8.   Implementation Recommendation................................20
   9.   IANA Considerations..........................................21
        9.1  IANA Registration of Continue SIP Header field..........21
        9.2  IANA Registration of continue SIP Option-tag............21
  10.   Security Considerations......................................21
  11.   Acknowledgements.............................................21
  12.   References...................................................22
        12.1  Normative References...................................22
        12.2  Informative References.................................22
  13.   Authors' Address.............................................22

1. Introduction

   Session Initiation Protocol (SIP) allows Caller to establish sessions
   with Callee without knowing whether Callee is in a position to accept
   session request or not.  There is no way by which Caller can know
   the favorable state of Callee.  There are several reasons why the
   Caller wants to know the favorable state of Callee before finally
   placing the call, because Callee may be in a different time zone,
   Callee may be in a meeting, theatre, having lunch with family/friends
   ,etc.  Callee may not want to be disturbed but may like to receive
   calls which is urgent and of good interest to him.  Another example
   Bob may not like office calls on weekends or at his personal/family
   time, but a project which requires his consent to progress or
   business gets affected can be treated as urgent and he would like to
   hear them.  Same in case he's in a business meeting and doesnot want 
   to receive call from family or his team but anything which requires
   his urgent attention, it would be important for him to accept.  The
   nearest approach or solutions to such problem available till date is
   described below along with the appropriate cause why this document is
   not considering this for implementation.  These approaches are not
   sufficient enough to address all concerns and not giving the control 
   on the call to the Caller for urgent call irrespective of Callee's 
   priority.
   
De,Hanchinal,Sinha           Expires October 2012               [Page 2]

Internet-Draft              SIP Continuation Option           April 2012

   (a) By OPTION Method - It is used to determine the capabilities of 
       SIP User Agent (UA).  This OPTION method allows a SIP User Agent 
       Client (UAC) to discover information about the supported method, 
       content types, extensions, codec, etc for a client which is 
       registered with the Server. OPTION method is given by the Caller 
       to know either Server Capabilities or Client Capabilities and not
       to its callee's state.

   (b) By Priority Header - Priority Header can be used to override a
       ongoing call, DND option or any voice feature based on the 
       Priority of the call as set by the Caller and as agreed with the 
       Operator. If Called Party supports the feature and Caller does 
       not support Priority, then this feature will be just DND. 

   (c) By Do Not Disturb (DND) - When user enable DND on the phone, this
       parameter allows user to specify how the DND features handle
       incoming calls:

      (c.1) Call Reject - This option specifies that no incoming call
       information gets presented to the user.  Depending on how user
       configure the DND Incoming Call Alert parameter, the phone may
       play a beep or display a flash notification of the call.

      (c.2) Ringer Off - This option turns off the ringer, but incoming 
       call information gets presented to the device, so that the user 
       can accept the call.

      DND feature doesnot serve the requirement of Caller to make a call
      in diverted to voicemail. 

   (d) By Presence[1] Feature - The use of PRESENCE with UAC clients
       restricted to higher end-mobile devices. It is also not necessary 
       that caller and callee both are in each-other's buddy's list or 
       connected to same social-networks as it is not necessary that 
       call is between two known persons.

    Therefore the purpose of this document to give the control to the 
    Caller. It also describes a mechanism for a Callee to
    convey the information to a Caller to place a call only when call is
    urgent by introducing "Call Continuation Option" and "Non-Dedicated 
    Dot Not Disturb (NDDND)" as two new features in TELECOMMUNICATION.

Definition

    o Non-Dedicated Do Not Disturb (NDDND)- is a state of Callee which
      portrays that the Callee is in a non-dedicated or slight DND mode
      with willingness to receive calls only if it is urgent.  However
      the decision is driven by the Caller whether to finally place a
      call or not.  By setting this option at the Callee UE or at voice
      services of Callee on the operator side, it ensures that the
	  
De,Hanchinal,Sinha           Expires October 2012               [Page 3]

Internet-Draft              SIP Continuation Option           April 2012
	  
      Caller gets a notification after placing a call that Callee is
      in a unfavorable state to receive call at this moment but in a
      position to accept any call if caller thinks its urgent.

    o Call Continuation Option - is a feature where an option is given
      to the Caller after Caller dials the Callee number to confirm the
      application whether to finally place the call or not based on
      certain configuration at the Callee User Equipment (UE) or at the 
      Voice Feature Service of Callee.

1.1 Terminology

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
    this document are to be interpreted as described in RFC 2119[5].

2. Overall Operation

   Callee is willing to receive only urgent call by enabling NDDND. This
   will convey the information to Caller that Callee is not in a 
   favorable state to receive calls and option will be given to the 
   Caller to place a call only if it is urgent. This can be achieved by 
   adding an optional tag "continue" in the Require header of 182 
   (Queued) provisional response from Callee. If Callee does not enable 
   this feature, operation will be as per RFC 3261[2].

   Caller is keen to know whether the Callee is free or not to take a
   call.  So Caller sends INVITE with option tag "continue" in the
   Supported header.  The Callee interprets the Caller up-to-date and 
   inline capabilities and responds with 182(Queued)response with 
   Require header value as "continue" if the feature NDDND is set at the
   Callee. This SIP response is interpreted at the Caller with a message
   popup or some in call information (device implementation) telling the
   unfavorable state of Callee to receive calls but tells its 
   availability state also with an "Y" or "N" which can also be 
   simulated by Call-Place GREEN Button or Call-Cancel RED Button 
   as per Caller wishes to perform the needful action. This is described
   in details in the mentioned use cases in Section 7. Accordingly PRACK
   [3] or UPDATE [4] with "Continue" header value as "Yes" (if 'Y' 
   option is selected or GREEN button is pressed)or "No" (if 'N' option 
   is selected) to be sent to Callee or the CANCEL request from Caller 
   will be initiated if Hard RED Button is pressed.

   The Caller will have following 3 options to the control session.

   (i) Continue: Yes

      Caller MUST inject "Continue" header with field value as "yes" or
      "YES" in the PRACK or UPDATE to support the Require header of 
      provisional response.

De,Hanchinal,Sinha           Expires October 2012               [Page 4]

Internet-Draft              SIP Continuation Option           April 2012

   (ii) Continue: No

      Caller MUST inject "Continue" header with field value as "no"
      or "NO" in the PRACK or UPDATE to support the Require header of 
      provisional response.

   (iii) Caller Hungs Up

      CANCEL request is sent by Caller and call gets terminated as per 
      described in RFC 3261.

    Note-If the Caller does not act on received 182 (Queued) provisional
    responses, retransmission timer implemented as per RFC 3261.

                               ^
                              / \
                             /   \
                            /     \                  +-------------+
                           /       \                 |             |
              No          / PLACE A \      Yes       | PLACE CALL  |
    +<-------------------<    Call   >-------------->| TO CALLEE   |
    |    CALLER PRESS     \         /  CALLER PRESS  |             |
    |    RED BUTTON        \       /   GREEN BUTTON  +-------------+
    |                       \     /
    |                        \   /
    |                         \ /
    |                          v
    |                          |
    |                          | CALLER HUNG UP
    |                          |
    |                          V
    |                    +----------------+
    |                    |                |
    |                    | Terminate Call |
    |                    |                |
    |                    +----------------+
    |                             ^
    V                             |
    +---------------------------->+

       Figure 1: Algorithm for Call Continuation Option feature

3. UAS Behavior

   A UAS MAY send 182 (Queued) provisional (by adding Require header 
   field with the option tag "continue") response if the initial INVITE
   request contains a Supported header field with the option tag 
   "continue". If the UAS is unwilling to do so, it MUST ignore the 
   option tag "continue" and proceed as per guidelines described in RFC
   3261.

De,Hanchinal,Sinha           Expires October 2012               [Page 5]

Internet-Draft              SIP Continuation Option           April 2012

   A UAS MUST send 182 (Queued) provisional (by adding Require header
   field with the option tag "continue") response if the initial INVITE
   request contained a Require header field with the option tag 
   "continue". If the UAS is unwilling to do so, UAS responds with 180 
   (Ringing) provisional response.

   A UAS MUST NOT send 182 (Queued) provisional (by adding Require 
   header field with the option tag "continue") response if the initial
   INVITE request did not include either a Supported or Require header 
   field indicating this feature.

   A UAS MUST NOT send 182 (Queued) provisional (by adding Require 
   header field with the option tag "continue") response if the initial
   INVITE request include Priority header with high value.

   If more than one "Continue" header field is present in PRACK or 
   UPDATE with two different field values, the UAS MUST reject the 
   request with a 400 (Bad Request) response.

   If a "Continue" header field is present in a request other than PRACK
   or UPDATE, the UAS MUST reject the request with a 400 (Bad Request)
   response.


4. UAC Behavior

   When the UAC creates a new request, it can insist for Call 
   Continuation Option in the provisional response for the request. To
   do that, it inserts a Require header with the value "continue" as
   option tag in the request. A Require header with the value "continue"
   MUST NOT be present in any requests except INVITE.

   If the UAC does not wish to insist on usage of Call Continuation
   Option in the provisional response, a Supported header MUST be
   include in the request with the option tag "continue". The UAC SHOULD
   include this in all INVITE requests.

   If a provisional response is received for an initial request and that
   response contains a Require header field containing the option tag
   "continue", the response is send in field value of "Continue" header 
   in PRACK or UPDATE request.

   If a provisional response is received for an initial request and that
   response contains a Require header field containing the option tag
   "continue" and UAC is unwilling to establish a session, it MUST 
   reject with CANCEL request.

5. The "Continue" Header Definition

   

De,Hanchinal,Sinha           Expires October 2012               [Page 6]

Internet-Draft              SIP Continuation Option           April 2012

    The Call Continuation Option feature makes use of "Continue" header
    which provides control to Caller on establishing the session. It MAY
    appear as an option extension header in PRACK or UPDATE request of 
    the Call Continuation Option feature. 

    The syntax of "Continue" header field follows the standard SIP 
    parameter syntax.

          Continue = "Continue" HCOLON continue_value
          continue_value = "YES" / "yes" / "NO" / "no"

    For example, the used "Continue" header in SIP PRACK or UPDATE 
    request would look like

          Continue: "YES"
          Continue: "yes"
          Continue: "NO"
          Continue: "no"

    The information about "Continue" header field in this document in
    relation to method and proxy is summarized in Table 1.
 
    The "where" column, in the Table 1, describes the request and 
    response types in which the header field may be used. The header may
    not appear in other types of SIP messages. Values in the where 
    column is:

          R: header field may only appear in requests.

    The proxy column and last fourteen columns relate to the presence of
    a "Continue" header field in a method:


          o: the header field is optional.
          -: the header field is not applicable.


Header field where proxy ACK BYE CAN INV OPT REG PRACK REFER SUB NOT
----------------------------------------------------------------------
Continue       R     -    -   -   -   -   -   -    o     -    -   -



Header field where                                   INF UPD MSG PUB
---------------------------------------------------------------------
Continue       R                                     -    o   -   -

       Table 1: Additional Table Entries for the "Continue" Header



De,Hanchinal,Sinha           Expires October 2012               [Page 7]

Internet-Draft              SIP Continuation Option           April 2012
	   
6. Backwards Compatibility

   This feature or SIP implementation does not have any impact on
   existing Network designs and Handsets. This draft proposes the use of
   additional header called SIP "Continue" header in order to 
   incorporate this feature of NDDND.

   Handsets or Network who do not understand this feature shall not
   handle and normal SIP behavior follows as per RFC 3261.

   There are 2 use cases for backward compatibility:

   o Caller Not Updated, Callee Updated 

   o Caller Updated, Callee Not Updated 

   Handling of SIP messages for the above two mentioned scenarios are 
   clearly mentioned in Section 7.4 and Section 7.5 respectively.


7. Examples and Use cases

   This section contains a number of examples and use cases that
   illustrate the use of the "Continue" header field.  For simplicity,
   header fields are usually shown in the same order.  Usually only the
   minimum required header field set is shown.  Also, message body
   content lengths are often not calculated, but instead shown as "..."
   where the actual octet count would be.

   Messages are identified in the figures as F1, F2, F3, etc. This 
   references the message details in the table that follows the figure.
   
   Comments in the message details are shown in the following form:
   /* Comments. */

7.1 Call is Finally Placed by Calling Party

   In this scenario, Alice has enabled NDDND feature in her profile. Bob
   sends initial INVITE with option tag "continue" in Support header. 
   Alice asks for confirmation of urgent call before ringing by 182 
   (Queued) provisional response with option tag "continue" in Require
   header. Bob confirmed as urgent call by providing yes as "Continue"
   header field value.  Alice's phone rings finally.

 
 
 
 
 
 
		 
De,Hanchinal,Sinha           Expires October 2012               [Page 8]

Internet-Draft              SIP Continuation Option           April 2012		 

        Bob                    Proxy                    Alice
         |    INVITE     F1      |                        |
         |---------------------->|                        |
         |    100 Trying   F2    |                        |
         |<----------------------|       INVITE   F3      |
         |                       |----------------------->|
         |                       |                        |
         |                       |     182 Queued   F4    |
         |    182 Queued   F5    |<-----------------------|
         |<----------------------|                        |
         |                       |                        |
         |       PRACK      F6   |                        |
         |---------------------->|       PRACK   F7       |
         |                       |----------------------->|
         |                       |                        |
         |                       |       200 OK   F8      |
         |      200 OK    F9     |<-----------------------|
         |<----------------------|                        |
         |                       |                        |
         |                       |   180 Ringing   F10    |
         |    180 Ringing  F11   |<-----------------------|
         |<----------------------|                        |
         |                       |                        |
                    * Rest of flow not shown *


            Figure 2: Call is Finally Placed by Calling Party

   Message Details

  /* The initial INVITE request has option tag "continue" in Support 
     header. */

    F1 Message Bob->Proxy

    INVITE sip:alice@proxy.com SIP/2.0
    Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds8
    Max-Forwards: 70
    To: Alice <sip:alice@atlanta.example.com>
    From: Bob <sip:bob@biloxi.example.com>;tag=67890
    Call-ID: a84b4c76e66710
    CSeq: 1 INVITE
    Supported:100rel,continue
    Contact: <sip:bob@client.biloxi.example.com>
    Content-Type: application/sdp
    Content-Length: ...

    (Bob's SDP not shown)



De,Hanchinal,Sinha           Expires October 2012               [Page 9]

Internet-Draft              SIP Continuation Option           April 2012	
	
  /* Alice supporting the new header extension "Continue", initially 
     her phone does not ring upon receiving initial INVITE request. It 
     will include option tag "continue" in Require header while sending
     182 (Queued) provisional response to Bob. The response, F5, 
     received at Bob, might look like this. */


    F5 Message Proxy ->Bob

    SIP/2.0 182 Queued
    Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds8
    To: Alice <sip:alice@atlanta.example.com>;tag=12345
    From: Bob <sip:bob@biloxi.example.com>;tag=67890
    Contact: <sip:bob@192.0.2.4>
    Require: 100rel,continue
    Call-ID: a84b4c76e66710
    CSeq: 1 INVITE
    Content-Type: application/sdp
    Content-Length: ...

    (Alice's SDP not shown)

  /* Thus Bob comes to know that Alice is not willing to accept call
    if the call is not very important.  So Bob has control on the call
    and can take a decision on his call.  Assume Bob finally place the
    call include "yes" or "YES" as the field value of "Continue"
    header in PRACK method (F6).*/


    F6 Message Bob -> Proxy

    PRACK sip: sip:alice@proxy.com SIP/2.0
    Via: SIP/2.0/UDP client.biloxi.example.com:5060;
    branch=z9hG4bKnash009
    Max-Forward: 70
    From: Bob <sip:bob@biloxi.example.com>;tag=67890
    To: Alice <sip:alice@atlanta.example.com>;tag=12345
    Call-ID: a84b4c76e66710
    Require: 100rel,continue
    CSeq: 2 PRACK
    RAck: 1 1 INVITE
    Continue: YES
    Content-Length: 0

    Alice's phone rings as it got the confirmation. The guidelines of 
    rest of messages flow is described in RFC 3261.

7.2 Call is Finally Not Placed by Calling Party

    
    
De,Hanchinal,Sinha           Expires October 2012              [Page 10]

Internet-Draft              SIP Continuation Option           April 2012	
	
    In this scenario, Bob finally decided not placed the call to Alice
    as his call is not very urgent and Alice is willing to receive only
    urgent call at this moment.  The Alice's phone does not ring and
    call is forward to preset destination if any.
   
        Bob                    Proxy                    Alice
         |       INVITE     F1   |                        |
         |---------------------->|                        |
         |    100 Trying   F2    |                        |
         |<----------------------|       INVITE   F3      |
         |                       |----------------------->|
         |                       |                        |
         |                       |     182 Queued   F4    |
         |    182 Queued   F5    |<-----------------------|
         |<----------------------|                        |
         |                       |                        |
         |       PRACK    F6     |                        |
         |---------------------->|       PRACK   F7       |
         |                       |----------------------->|
         |                       |                        |
         |                       |       200 OK   F8      |
         |      200 OK    F9     |<-----------------------|
         |<----------------------|                        |
         |                       |                        |
         |                       |                        |
         |                       |   486 Busy Here  F10   |
         |                       |<-----------------------|
         |                       |                        |
                     * Rest of flow not shown *

         Figure 3: Call is Finally Not Placed by Calling Party

  /* Assume Bob finally wish not to place the call with Alice as his
     call is not very important.  So he injects "no" or "NO" as the
     field value of "Continue" header in PRACK method (F6)*/

    F6 Message Bob -> Proxy

    PRACK sip: sip:bob@biloxi.example.com SIP/2.0
    Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bK124
    Max-Forward: 70
    From: Bob sip:bob@biloxi.example.com;tag=67890
    To: Alice <sip:alice@atlanta.example.com>;tag=12345
    Call-ID: 12ka4@ biloxi.example.com
    CSeq: 2 PRACK
    Continue: NO
    Content-Length: 0

    Alice's phone does not ring as it got confirmation as no.  PRACK is
    responded by 200 (OK) followed by 486 (Busy Here) as per RFC 3261 

De,Hanchinal,Sinha           Expires October 2012              [Page 11]

Internet-Draft              SIP Continuation Option           April 2012

7.3 Caller Hungs Up

   In this example, Bob hangs up the call with Alice when he comes to
   know that Alice need confirmation about importance of call before
   ringing, which is shown in Figure 3.

        Bob                    Proxy                    Alice
         |      INVITE     F1    |                        |
         |---------------------->|                        |
         |    100 Trying   F2    |                        |
         |<----------------------|       INVITE    F3     |
         |                       |----------------------->|
         |                       |                        |
         |                       |     182 Queued   F4    |
         |    182 Queued   F5    |<-----------------------|
         |<----------------------|                        |
         |                       |                        |
         |       CANCEL    F6    |                        |
         |---------------------->|      CANCEL    F7      |
         |                       |----------------------->|
                   * Rest of flow not shown *


                   Figure 4: Caller Hungs Up


  /* Bob disconnects by initiating a Cancel (F6) request and the call
    is handled as per RFC 3261*/

    F6 Message Bob -> Proxy

    CANCEL sip: sip:bob@biloxi.example.com SIP/2.0
    Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK123
    Max-Forward: 70
    From: Bob <sip:bob@biloxi.example.com>;tag=67890
    To: Alice <sip:alice@atlanta.example.com>;tag=12345
    Call-ID: 12ka4@biloxi.example.com
    CSeq: 1 INVITE
    Content-Length: 0

   The guidelines of rest of messages flow is described in RFC 3261.

7.4 Caller does not have Call Continuation Option feature

   There might be cases when Bob doesnot support "Continue" header
   but Alice has enabled NDDND feature.  In such a case Bob wouldnot be
   facilitated with continue advantages.  Bob sends initial INVITE
   without option tag "continue" in Support or Require header and will
   receive 480 (Temporarily Unavailable) responses.  Alice phone will
   not ring.
   
De,Hanchinal,Sinha           Expires October 2012              [Page 12]

Internet-Draft              SIP Continuation Option           April 2012   


    Bob                    Proxy                   Alice (NDDND enabled)
       |      INVITE     F1    |                        |
       |---------------------->|                        |
       |    100 Trying   F2    |                        |
       |<----------------------|       INVITE    F3     |
       |                       |----------------------->|
       |                       |                        |
       |                       | 480 Temporarily        |
       |                       |      Unavailable   F5  |
       |                       |<-----------------------|
       |                       |                        |
                       * Rest of flow not shown *

      Figure 5: Caller does not has Call Continuation Option feature

   NDDND feature will be overwritten and Alice phone ring if the initial
   INVITE request include Priority header with high value.  Basic
   intention of Alice is not to block urgent or emergency call but to
   avoid unimportant call as busy.

7.5 Callee does not support NDDND feature

   Alice phone rings which even though option tag "continue" present in
   Support header of initial INVITE send by Bob.

     Bob                    Proxy                 Alice (NDDND disabled)
       |      INVITE     F1    |                        |
       |---------------------->|                        |
       |    100 Trying   F2    |                        |
       |<----------------------|       INVITE    F3     |
       |                       |----------------------->|
       |                       |                        |
       |                       |   180 Ringing   F4     |
       |                       |<-----------------------|
                   * Rest of flow not shown *

            Figure 6: Callee does not support NDDND feature

7.6 SIP-ISDN Interworking with Call Continuation feature

    In this scenario, ISDN terminal(Intelligent mode) has enabled
    NDDND feature in his/her profile.  SIP UAC sends initial INVITE
    with option tag "continue" in Support header.  ISDN terminal asks
    for confirmation of urgent call before ringing by sending Q 931
    Information Element (IE) in ISDN Facility message.  SIP UAC
    confirmed as urgent call by providing yes as "Continue" header
    field value.  ISDN terminal phone rings finally.
	

	
De,Hanchinal,Sinha           Expires October 2012              [Page 13]

Internet-Draft              SIP Continuation Option           April 2012	
	
	
        SIP UAC (Bob)         SIP Gateway         ISDN Terminal (Alice)
         |    INVITE     F1      |                        |
         |---------------------->|                        |
         |    100 Trying   F2    |                        |
         |<----------------------|  Q 931 SETUP   F3      |
         |                       |----------------------->|
         |                       |                        |
         |                       | Call Proceeding   F4   |
         |    182 Queued   F5    |<-----------------------|
         |<----------------------|                        |
         |                       |                        |
         |       PRACK      F6   |                        |
         |---------------------->| INFO [Continue] F7     |
         |                       |----------------------->|
         |                       |                        |
         |                       |                        |
         |      200 OK    F8     |                        |
         |<----------------------|                        |
         |                       |                        |
         |                       |   Alerting   F9        |
         |    180 Ringing  F10   |<-----------------------|
         |<----------------------|                        |
         |                       |                        |
                    * Rest of flow not shown *

        Figure 7: Interworking Call is Finally Placed by Calling Party
                  Message Details

 /* The initial INVITE request has option tag "continue" in Support 
    header. */

    F1 Message Bob->Proxy

    INVITE sip:alice@proxy.com SIP/2.0
    Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds8
    Max-Forwards: 70
    To: Alice <sip:alice@atlanta.example.com>
    From: Bob <sip:bob@biloxi.example.com>;tag=67890
    Call-ID: a84b4c76e66710
    CSeq: 1 INVITE
    Supported:100rel,continue
    Contact: <sip:bob@client.biloxi.example.com>
    Content-Type: application/sdp
    Content-Length: ...

    (Bob's SDP not shown)


	
	
De,Hanchinal,Sinha           Expires October 2012              [Page 14]

Internet-Draft              SIP Continuation Option           April 2012	
	
  /* Alice supporting the new header extension "Continue", initially 
     her phone does not ring upon receiving initial INVITE request.  It 
     will include option tag "continue" in Require header while sending
     182 (Queued) provisional response to Bob.  The response, F5, 
     received at Bob, might look like this. */

    F5 Message Proxy ->Bob

    SIP/2.0 182 Queued
    Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds8
    To: Alice <sip:alice@atlanta.example.com>;tag=12345
    From: Bob <sip:bob@biloxi.example.com>;tag=67890
    Contact: <sip:bob@192.0.2.4>
    Require: 100rel,continue
    Call-ID: a84b4c76e66710
    CSeq: 1 INVITE
    Content-Type: application/sdp
    Content-Length: ...

    (Alice's SDP not shown)

  /* Thus Bob comes to know that Alice is not willing to accept call
    if the call is not very important.  So Bob has control on the call
    and can take a decision on his call.  Assume Bob finally place the
    call include "yes" or "YES" as the field value of "Continue"
    header in PRACK method (F6).*/

    F6 Message Bob -> Proxy

    PRACK sip: sip:alice@proxy.com SIP/2.0
    Via: SIP/2.0/UDP client.biloxi.example.com:5060;
    branch=z9hG4bKnash009
    Max-Forward: 70
    From: Bob <sip:bob@biloxi.example.com>;tag=67890
    To: Alice <sip:alice@atlanta.example.com>;tag=12345
    Call-ID: a84b4c76e66710
    Require: 100rel,continue
    CSeq: 2 PRACK
    RAck: 1 1 INVITE
    Continue: YES
    Content-Length: 0


 F3 Q931 Signaling message (IE) SIP Gateway -> ISDN Terminal
 
    03:29:41.816 line:5/0 L3 rx SETUP callref:5.
    03:29:41.817 hex01: 08 01 05 05 04 03 80 90 a3 6c 06 01 81 33 30 30
    03:29:41.817 hex02: 31 70 05 81 33 30 30 32 a1
    03:29:41.817 Called Number : 3002
    03:29:41.817 Calling Number : 3001
	
De,Hanchinal,Sinha           Expires October 2012              [Page 15]

Internet-Draft              SIP Continuation Option           April 2012	
	
    03:29:41.819 line:5/0 L1 frame sent.
    03:29:41.819 line:5/0 L2 tx RR P/F=0 NR=13 C/R=0 TEI=0.
    03:29:41.819 hex: 00 01 01 1a

 F4 Q.931 Signaling message (IE) SIP Gateway <- ISDN Terminal

    03:29:41.859 line:5/0 L1 frame sent.
    03:29:41.860 line:5/0 L2 tx INFO P=0 NR=13 NS=12 C/R=1 TEI=0.
    03:29:41.860 hex: 02 01 18 1a
    03:29:41.860 line:5/0 L3 tx CALL PROCEEDING callref:5.
    03:29:41.861 hex01: 08 01 85 02 18 01 89
    03:29:41.861 line:5/7 L1 frame sent.
    03:29:41.862 line:5/7 L2 tx INFO P=0 NR=4 NS=4 C/R=1 TEI=0.
    03:29:41.862 hex: 02 01 08 08

 F7 Q931 Facility message (IE) SIP Gateway -> ISDN Terminal

    03:29:41.965 line:5/7 L1 frame received.
    03:29:41.965 line:5/7 L2 rx INFO P=0 NR=5 NS=6 C/R=0 TEI=0.
    03:29:41.965 hex: 00 01 0c 0a

    Fac(1c): 08 01 6e 05 1c 31 9f aa 0b 80 01 01 a1 03 80 01 30 82 01
    00 8b 01 00 a1 1e 02 01 01 02 01 23 30 16 30 14 a1 0f 81 04 45 55
    52 4f a2 07 81 02 0f 99 82 01 06 82 01 00


    08|00001000     Protocol discriminator: DSS1
    01|00000001       Length of callReference: 1
    6e|0-------       Call reference flag: Origination Side
      |-1101110       Call reference: 110
    05|00000101     Message type: SETUP
    1c|00011100     I-Element: Facility information element identifier
    31|00110001       Length = 49
    9f|10011111       Protocol Profile:
    aa|10101010       Tag/Class/Form: aa/Context specific/Constructed ()
    0b|00001011         Length (small) = 11
    80|10000000         Not decoded
    01|00000001         Not decoded
    01|00000001         Not decoded
    a1|10100001         Not decoded
    03|00000011         Not decoded
    80|10000000         Not decoded
    01|00000001         Not decoded
    30|00110000         Not decoded
    82|10000010         Not decoded
	
De,Hanchinal,Sinha           Expires October 2012              [Page 16]

Internet-Draft              SIP Continuation Option           April 2012	
	
    01|00000001         Not decoded
    00|00000000         Not decoded
    8b|10001011       Tag/Class/Form: 8b/Context specific/Primitive ()
    01|00000001         Length (small) = 1
    00|00000000         Not decoded
    a1|10100001       Tag/Class/Form: a1/Context specific/Constructed
                       (Invoke)
    1e|00011110         Length (small) = 30
    02|00000010         Tag/Class/Form: 02/Universal/Primitive (integer)
                        (Invoke ID)
    01|00000001           Length (small) = 1
    01|00000001           Invoke ID: 1
    02|00000010         Tag/Class/Form: 02/Universal/Primitive (integer)
                        (Operation value)
    01|00000001           Length (small) = 1
    23|00100011           Operation value: 35, Continue
    30|00110000         Tag/Class/Form: 30/Universal/Constructed
                         (sequence) 
    16|00010110           Length (small) = 22
    30|00110000           Tag/Class/Form: 30/Universal/Constructed
                          (sequence) 



    The guidelines of rest of messages flow is described in RFC 3261
    and ETSI TS 183 036 V3.4.1 document.

7.7 SIP-FXS Interworking with Call Continuation feature

    In this scenario, FXS phone (Intelligent mode) has enabled NDDDND
    NDDND feature in his/her analog-user-profile with dial-peer 
    configured for SIP-FXS call with route provisioned in Voice
    Gateway. SIP UAC sends initial INVITE with option tag "continue"
    in Support header. FXS phone asks for confirmation of urgent call
    call before ringing by sending FXS event-triggered Continue
    message. SIP UAC confirmed as urgent call by providing yes as 
    "Continue" header field value. FXS phone rings finally.
	













De,Hanchinal,Sinha           Expires October 2012              [Page 17]

Internet-Draft              SIP Continuation Option           April 2012

      SIP UAC (Bob)       Voice Gateway        Intelligent FXS(Alice)
         |                       |                        |
         |    INVITE     F1      |                        |
         |---------------------->|                        |
         |    100 Trying   F2    |                        |
         |<----------------------| F3 event incoming call |
         |                       |----------------------->|
         |                       | on local port 5/1 recvd|
         |    182 Queued   F4    |
         |<----------------------|                        |
         |                       |                        |
         |       PRACK      F5   |                        |
         |---------------------->| event-trigger F6       |
         |                       |----------------------->|
         |                       |    [Continue] received |
         |                       |                        |
         |      200 OK    F7     |                        |
         |<----------------------|                        |
         |                       |                        |
         |                       | event FXS port 5/1     |
         |    180 Ringing  F9    |<-----------------------|
         |<----------------------|  status: ringing F8    |
         |                       |                        |
                    * Rest of flow not shown *

        Figure 8: Interworking Call is Finally Placed by Calling Party


    Message Details

  F1 Message Bob->Voice Gateway

    INVITE sip:6666@20.20.2.71:5060 SIP/2.0
    Via: SIP/2.0/UDP <20.20.2.10:5062>;branch= 
    z9hG4bKa34888322e87a14e8.b688156c7e0985838
    Max-Forwards: 70
    From: "1004" <sip:1004@20.20.2.10:5062>;tag=6e8892955e
    To: "6666" <sip:6666@20.20.2.71:5060>
    Call-ID: 5d2e26590f35cc8b
    CSeq: 18826 INVITE
    Allow:  INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, 
    PRACK,SUBSCRIBE, INFO
    Require:100rel,continue
    Allow-Events: talk, hold, conference, LocalModeStatus
    Contact: sip:1004@20.20.2.10:5062
    Content-Type: application/sdp
    Content-Length: ....

 F2 Message Voice Gateway -> Bob




De,Hanchinal,Sinha            Expires October 2012             [Page 18]

Internet-Draft              SIP Continuation Option           April 2012

    SIP/2.0 100 Trying
    Allow:PRACK,ACK,CANCEL,BYE,SUBSCRIBE,NOTIFY,INVITE,REFER, 
    OPTIONS,INFO,UPDATE, REGISTER
    Call-ID: 5d2e26590f35cc8b
    CSeq: 18826 INVITE
    From: "1004" <sip:1004@20.20.2.10:5062>;tag=6e8892955e
    To: "6666" <sip:6666@20.20.2.71:5060>
    Via: SIP/2.0/UDP <20.20.2.10:5062>;received=20.20.2.10;
    branch=z9hG4bKa34888322e87a14e8.b688156c7e0985838

  F3 Voice Gateway -> FXS Phone 

    event "Incoming call on local port: 5/1, calling:1004 , called:
    6004, call- id: 8" received
    event "UAC <20.20.2.71:5060> <- UAS <20.20.2.10:5062> INVITE" 
    received

  F4 Message Voice Gateway -> Bob

    SIP/2.0 183 Session Progress
    Allow-Events: hold,talk
    Call-ID: 5d2e26590f35cc8b
    Require: 100rel,continue
    CSeq: 18826 INVITE
    From: "1004" <sip:1004@20.20.2.10:5062>;tag=6e8892955e
    To: "6666" <sip:6666@20.20.2.71:5060>;tag=2704
    Via: SIP/2.0/UDP <20.20.2.10:5062>;received=20.20.2.10;branch=
    z9hG4bKa34888322e87a14e8.b688156c7e0985838

  F5 Message Bob  -> Voice Gateway 

    PRACK sip: sip:alice@proxy.com SIP/2.0
    Via: SIP/2.0/UDP client.biloxi.example.com:5060;
    branch=z9hG4bKnash009
    Max-Forward: 70
    From: Bob <sip:bob@biloxi.example.com>;tag=67890
    To: Alice <sip:alice@atlanta.example.com>;tag=12345
    Call-ID: a84b4c76e66710
    Require: 100rel,continue
    CSeq: 2 PRACK
    RAck: 1 1 INVITE
    Continue: YES
    Content-Length: 0

 F6 Message Voice-Gateway -> FXS Phone (Intelligent)

    Event Continue is received on local port: 5/1

 F7 Message Voice Gateway -> Bob 



De,Hanchinal,Sinha            Expires October 2012             [Page 19]

Internet-Draft              SIP Continuation Option           April 2012

    SIP/2.0 180 Ringing
    Allow-Events: hold,talk
    Call-ID: 5d2e26590f35cc8b
    CSeq: 18826 INVITE
    From: "1004" <sip:1004@20.20.2.10:5062>;tag=6e8892955e
    To: "6666" <sip:6666@20.20.2.71:5060>;tag=2704
    Via: SIP/2.0/UDP <20.20.2.10:5062>;received=20.20.2.10;
    branch=z9hG4bKa34888322e87a14e8.b688156c7e0985838


 F8 Message FXS Phone -> Voice Gateway

    FXS port 5/1 status: ringing on
	
8. Implementation Recommendation

    "Session Continuation Option" feature in SIP is a new call control
    feature proposed in this document applicable in favour of Callee
    that gives option to Caller requesting for a confirmation to place
    a call to Callee based on the following new applications at the
    Callee.

   o    Callee unfavorable Time to Receive Call (usually when the
        Callee is sleeping or travelling, based on Callee time zone
        which is based on his location that needs to be updated by
        Callee in case of VoIP subscriber, and manually or 
        automatically done by Mobile Service Provider based on 
        Daylight Savings for 3G/4G subscriber).

   o    Callee has set a Non-Dedicated Do-Not-Disturb (NDDND) that is
        DND with lower priority when the Callee is in a theatre,
        meeting, driving, lunch/dinner, etc.  - Callee is willing to
        receive the call only when it is very urgent.

    This application is totally based on SIP Call Session 
    Establishment principles (Offer-Answer Model) with minor 
    deviation in call flows and is implementation specific and
    driven based on configuration at.

   o    SIP UA or Voice Over Internet Protocol (VoIP) End Device, 
        3G/4G Handsets (Device Driven) - Device plays more important 
        role in Call Handling.

   o    SIP Back-To-Back User Agent (B2BUA) server as a part of Voice
        Feature Services given by the Service Provider (Service
        Provider Driven) - Network plays more important role in Call
        Handling instead of SIP Terminals or 3G/4G Handsets.

		
		
		
De,Hanchinal,Sinha            Expires October 2012             [Page 20]

Internet-Draft              SIP Continuation Option           April 2012	
		
    This Call Feature Application handling behaviour and subsequent
    actions at the Calling and Callee and SIP AS is clearly defined
    later using State Diagrams based on the call confirmation options
    handled by Calling Party and relevant configurations / services
    provided by the Network Service Provider.

    This feature can be implemented using SIP with minor changes at
    protocol level by introducing "Continue" header in SIP PRACK
    Request and slight changes in the basic Offer-Answer Model
    implementation in both UAs and SIP AS based on implementation,
    calls of which are discussed in detail later on.  There will be an
    additional need of changes in UA Application and also at SIP AS in
    case this feature is driven by a SIP AS instead of Callee.

    This feature is fully backward compatible and doesnot have any
    impact on existing Subscribers, Devices, Network Setup and
    Operation.  The Service Provider may need to upgrade their SIP
    Application server in case they wish to give this new voice 
    feature as a new service to their subscribers.  Similarly Device
    Manufacturer needs to upgrade the application of their handsets or
    introduce as a new application feature in their new Handsets or
    Devices.

9. IANA Considerations

    This document registers a new header field name with a compact 
    form and one new option tag.

9.1  IANA Registration of "Continue" SIP Header field

    Name of Header:        Continue
    Compact Form:          g

9.2  IANA Registration of "continue" SIP Option-tag

    Name of option:         continue
    Description:            Support for the SIP Continue header.
	
10. Security Considerations

    The Continue header in this document does not in itself have 
    security considerations. However, as mentioned in RFC 3427[6], an 
    important reason for the IETF to manage the extensions of SIP is to 
    ensure that all extensions and parameters are able to provide secure
    usage.

11. Acknowledgements

    Thanks to Paul Kyzivat, Worley, Dale R (Dale), John Elwell and Ram
    Mohan R who provided helpful comments, feedback and suggestions.

De,Hanchinal,Sinha            Expires October 2012             [Page 21]

Internet-Draft              SIP Continuation Option           April 2012
	
    Also the authors would like to thank Mayur Saxena, Jay Prakash
    Dubey, Lakshmi P Vijay Badithe, Prasad Kulkarni, Rajesh Batagurki,
    Vineet Hada, Ayan Ghosh, Reetesh Gupta, Nishesh Shukla, Dipankar
    Goswami, Gagandeep Singh and Gauri Kshirsagar for their input.

12. References

12.1  Normative References

    [1] Rosenberg, J., "A Presence Event Package for the Session
        Initiation Protocol (SIP)", RFC 3856, August 2004.

    [2] 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.

    [3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
        Responses in the Session Initiation Protocol (SIP)", RFC 3262,
        June 2002.

    [4] Rosenberg, J., "The Session Initiation Protocol (SIP)UPDATE 
        Method", RFC 3311, October 2002.

12.2   Informative References

    [5] Bradner, S., "Key words for use in RFCs to indicate requirement
        levels," BCP 14, RFC 2119, March 1997.
	
    [6] Peterson, J., Jennings, C., and R. Sparks, "Change Process for
        the Session Initiation Protocol (SIP) and the Real-time 
        Applications and Infrastructure Area", BCP 67,RFC 5727, 
        March 2010.
		
    [7] Q.931 : ISDN user-network interface layer 3 specification for
        basic call control

13. Authors' Addresses

    Amardeep Sinha
    FF02, First Floor,
    Rainbow Residency,
    Green-Glen-Layout,
    Bellandur, Outer-Ring-Road
    Bangalore (Karnataka)
    India -560103

    EMail: sinha.amardeep@gmail.com

 


De,Hanchinal,Sinha            Expires October 2012             [Page 22]

Internet-Draft              SIP Continuation Option           April 2012

 
    Subhrajyoti De
    F.E. 91 SECTOR 3
    SALT LAKE CITY
    KOLKATA - 700 106.
    WEST BENGAL. INDIA.

    EMail: de_subhrajyoti@yahoo.co.uk


    Sunil Kumar Sinha
    FF01, First Floor,
    Rainbow Residency,
    Green-Glen-Layout,
    Bellandur, Outer-Ring-Road
    Bangalore (Karnataka)
    India -560103

    EMail: sunilkumarsinha9@gmail.com
   
   
    MANJUNATH Hanchinal
    64, C-101, GAGAN DARSHAN APARTMENTS,
    10TH A CROSS KANAKA NAGAR, 
    R.T. NAGAR, 
    Bangalore (Karnataka)
    India -560032
   
    EMail: manjugd@gmail.com
   
   
   
   
   




   
   
   

   
   
   
   
   
   
   
   
   
De,Hanchinal,Sinha           Expires October 2012              [Page 23]