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]
