DISPATCH Working Group Amardeep Sinha Internet Draft Subhrajyoti De Intended Status:Informational Sunil Kumar Sinha Expires: February 22, 2012 August 23, 2011 The Continue Header Field for the Session Initiation Protocol (SIP) draft-sinha-dispatch-sip-continuation-option-00.txt Abstract For placing a call, it is often useful to know the whether a Callee is in favorable state or not. This document defines an optional tag continue and a header field Continue which provides this information. The Continue header field is to confirm the session continuity with the Callee after an option for session continuity is placed by the Caller. 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 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 February 10, 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. Sinha Expires February 2012 [Page 1] Internet-Draft SIP Continuation Option August 2011 Table of Contents 1. Introduction.................................................02 1.1 Terminology.............................................03 2. Continue Header..............................................03 3. Examples.....................................................05 3.1. Call is Finally Placed by Calling Party...............05 3.2. Caller Hang Up........................................07 3.3. Call is Finally Not by Calling Party..................08 4. Implementation Recommendation................................09 5. Security Considerations......................................10 6. IANA Considerations..........................................10 6.1. IANA Registration of Continue SIP Header field........10 6.2. IANA Registration of continue SIP Option-tag..........10 7. Acknowledgments..............................................10 8 Normative References.........................................10 9. Authors' Address.............................................11 1. Introduction Session Initiation Protocol (SIP) allows Caller to establish sessions with Callee without informing whether Callee is in a position to accept session request or not. There is no means by which Caller can know the favorable state of Callee. The closest approach is an OPTION method. The OPTION method 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, codecs, etc. Secondly the nearest approach with respect to feature wise is a Do Not Disturber (DND) feature in which the caller is failed in placing an urgent call to callee. There are several reasons why the Caller wants to know the favorable state of Callee before finally placing the call. The Call Continuation Option is a new feature in TELECOMMUNICATION 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. o Time Zone to talk may be unfavourable for the Callee Applicable when Callee is mobile and the time zone is usually night or unfavourable to the Callee. o Callee in Non-Dedicated Do Not Disturb (NDDND) mode Non-Dedicated Dot Not Disturb (NDDND) is a state of Callee which portrays that the Callee is in DND mode with capability of receiving calls only if it is important or urgent. So a Sinha Expires February 2012 [Page 2] Internet-Draft SIP Continuation Option August 2011 mechanism to convey this information to the Caller to place the call to Callee only if the call is important or urgent is highlighted here. This can be the case when the Callee is in a meeting, theatre or having lunch / dinner with family or friends. Based on the call confirmation YES (i.e., TRUE) response from the Caller, the application places the call finally to Callee. Based on the call confirmation NO (i.e., FALSE) response from the Caller, the application terminates the call. 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[2]. 2. Continue Header The Call Continuation Option feature make use of Continue header and option tag continue which provide more control to Caller on establishing the session. The Continue header field MAY appear as an option extension header in PRACK 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" So ideally optionally used "Continue" header in SIP PRACK 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. Sinha Expires February 2012 [Page 3] Internet-Draft SIP Continuation Option August 2011 Header field where proxy ACK BYE CAN INV OPT REG PRACK REFER SUB NOT ---------------------------------------------------------------------- Continue R - - - - - - - o - - o Table 1: Summary of header fields The "where" column 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 last six columns relate to the presence of a header field in a method: m: the header field is mandatory. o: the header field is optional. -: the header field is not applicable. The Callee MUST send 182 Queued provisional response with the option tag continue if willing to implement Call Continuation Optional feature. If the Callee is unwilling to use Call Continuation Optional feature, it MUST proceed as RFC 3261. RFC 3261 describes guidelines for the sets of messages in which offers and answers [1] can appear. Based on those guidelines, this extension provides additional opportunities for offer/answer exchanges. Algorithm is defined to incorporate in Offer-Answer Model for the Call Continuation Option feature using SIP Continue header in PRACK shown in Figure 1. The Caller has 3 options to control session on receiving 182 Queued provisional response with option tag continue in Require header, before finally answered. (i) Continue: Yes Caller MUST inject Continue header with field value as "yes" or "YES" in the PRACK to support the Require header of provisional response. (ii) Continue: No Caller MUST inject Continue header with field value as "no" or "NO" in the PRACK to support the Require header of provisional response. (iii) Caller Hung Up Sinha Expires February 2012 [Page 4] Internet-Draft SIP Continuation Option August 2011 CANCEL is sent by Caller and normal call flows as per RFC 3261 follows based on implementation (based on terminating leg as SIP AS or Called UA) to terminate and clear this call leg. 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. Examples This section contains a number of examples that illustrate the use of the Continue header field. The primary objective of Call Continuation Option feature is the get final confirmation from the Caller before establishment of the session. Assume that the Callee, Alice, has enable Call Continuation Option feature in her profile. The Caller, Bob, sends INVITE request to Alice. 3.1 Call is Finally Placed by Calling Party The call flow for when Bob finally placed a call to Alice is shown in Figure 2. In this example, the Alice's phone rings only after Sinha Expires February 2012 [Page 5] Internet-Draft SIP Continuation Option August 2011 receiving confirmation from Bob. 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 /* Initially Alice's phone does not ring. 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 SIP/2.0 182 Queued Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK123; Max-Forward: 70 From: Bob ;tag=67890 To: Alice ;tag=12345 Call-ID: 12ka4@biloxi.example.com CSeq: 1 INVITE Require: continue Content-Length:0 /* Thus Bob comes to know that Alice is not willing to accept call if the call in not very important. So Bob has control on the call and can take a decision on his call. Assume Bob finally place the Sinha Expires February 2012 [Page 6] Internet-Draft SIP Continuation Option August 2011 call injecting "yes" or "YES" as the field value of Continue header in PRACK method (F6).*/ PRACK sip: sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK124 Max-Forward: 70 From: Bob sip:bob@biloxi.example.com;tag=67890 To: Alice ;tag=12345 Call-ID: 12ka4@biloxi.example.com CSeq: 2 PRACK Continue: YES Content-Length: 0 Alice's phone rings as it got confirmation. The guidelines of rest of messages flow is describes in RFC 3261. 3.2 Caller Hung Up In this example, Bob hang 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 3: Caller Hung Up /* Bob disconnects by initiating a Cancel (F6) request and the call is handled as per RFC 3261*/ CANCEL sip: sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK123 Max-Forward: 70 From: Alice ;tag=67890 Sinha Expires February 2012 [Page 7] Internet-Draft SIP Continuation Option August 2011 To: Bob sip:bob@biloxi.example.com; Call-ID: 12ka4@biloxi.example.com CSeq: 1 INVITE Content-Length: 0 The guidelines of rest of messages flow is describes in RFC 3261. 3.3 Call is Finally Not placed by Calling Party The call flow for when Bob finally not the call to Alice is shown in Figure 4. In this example, 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 | | 486 Busy Here F11 |<-----------------------| |<----------------------| | | | | * Rest of flow not shown * Figure 4: 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)*/ PRACK sip: sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK124 Max-Forward: 70 Sinha Expires February 2012 [Page 8] Internet-Draft SIP Continuation Option August 2011 From: Bob sip:bob@biloxi.example.com;tag=67890 To: Alice ;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. 4. 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. 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. Sinha Expires February 2012 [Page 9] Internet-Draft SIP Continuation Option August 2011 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 doesn't 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. 5. IANA Considerations This document registers a new header field name with a compact form and one new option tag. 5.1 IANA Registration of "Continue" SIP Header field Name of Header: Continue Compact Form: cn 5.2 IANA Registration of "continue" SIP Option-tag Name of option: continue Description: Support for the SIP Continue header 6. Security Considerations 7. Acknowledgments 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 and Dipankar Goswami for their input. 8. Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Sinha Expires February 2012 [Page 10] Internet-Draft SIP Continuation Option August 2011 Session Initiation Protocol", RFC 3261, June 2002. [2] Bradner, S., "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, March 1997. 9. Authors' Addresses Amardeep FF02, First Floor, Rainbow Residency, Green-Glen-Layout, Bellandur, Outer-Ring-Road Bangalore (Karnataka) India -560103 EMail: amardeep_sinha@rediffmail.com 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@rediffmail.com Sinha Expires February 2012 [Page 11]