DISPATCH Working Group Amardeep Sinha Internet Draft Subhrajyoti De Intended Status: Informational Sunil Kumar Sinha Expires: April 2, 2012 October 4, 2011 The Continue Header Field for the Session Initiation Protocol (SIP) draft-sinha-dispatch-sip-continuation-option-02.txt Abstract Before placing a call, it is quite often useful for the Caller to know whether a Callee is in favourable 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 April 2, 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_&_Sinha Expires April 2012 [Page 1] Internet-Draft SIP Continuation Option October 2011 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..........................................11 7.4 Caller does not have Call Continuation Option feature....12 7.5 Callee does not support NDDND feature....................13 8. Implementation Recommendation................................13 9. IANA Considerations..........................................14 9.1 IANA Registration of Continue SIP Header field..........14 9.2 IANA Registration of continue SIP Option-tag............15 10. Security Considerations......................................15 11. Acknowledgements.............................................15 12. References...................................................15 12.1 Normative References...................................15 12.1 Informative References.................................15 13. Authors' Address.............................................16 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 favourable state of Callee. There are several reasons why the Caller wants to know the favourable 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 doesn't want to receiving 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_&_Sinha Expires April 2012 [Page 2] Internet-Draft SIP Continuation Option October 2011 (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 doesn't 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 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_&_Sinha Expires April 2012 [Page 3] Internet-Draft SIP Continuation Option October 2011 Caller gets a notification after placing its 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 Hard 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_&_Sinha Expires April 2012 [Page 4] Internet-Draft SIP Continuation Option October 2011 (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_&_Sinha Expires April 2012 [Page 5] Internet-Draft SIP Continuation Option October 2011 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 rejects 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_&_Sinha Expires April 2012 [Page 6] Internet-Draft SIP Continuation Option October 2011 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_&_Sinha Expires April 2012 [Page 7] Internet-Draft SIP Continuation Option October 2011 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 call 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 octel 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. Bob Proxy Alice | INVITE F1 | | |---------------------->| | | 100 Trying F2 | | |<----------------------| INVITE F3 | | |----------------------->| De_&_Sinha Expires April 2012 [Page 8] Internet-Draft SIP Continuation Option October 2011 | | | | | 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 From: Bob ;tag=67890 Call-ID: a84b4c76e66710 CSeq: 1 INVITE Supported:100rel,continue Contact: Content-Type: application/sdp Content-Length: ... (Bob's SDP not shown) /* 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. */ De_&_Sinha Expires April 2012 [Page 9] Internet-Draft SIP Continuation Option October 2011 F5 Message Proxy ->Bob SIP/2.0 182 Queued Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds8 To: Alice ;tag=12345 From: Bob ;tag=67890 Contact: 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 ;tag=67890 To: Alice ;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 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. De_&_Sinha Expires April 2012 [Page 10] Internet-Draft SIP Continuation Option October 2011 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 ;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 7.3 Caller Hungs Up De_&_Sinha Expires April 2012 [Page 11] Internet-Draft SIP Continuation Option October 2011 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 ;tag=67890 To: Alice ;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 doesn't support "Continue" header but Alice has enabled NDDND feature. In such a case Bob wouldn't 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_&_Sinha Expires April 2012 [Page 12] Internet-Draft SIP Continuation Option October 2011 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 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 Unfavourable 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 De_&_Sinha Expires April 2012 [Page 13] Internet-Draft SIP Continuation Option October 2011 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. 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. 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 De_&_Sinha Expires April 2012 [Page 14] Internet-Draft SIP Continuation Option October 2011 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. 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 and Manjunath Hanchinal 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. De_&_Sinha Expires April 2012 [Page 15] Internet-Draft SIP Continuation Option October 2011 [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. 13. Authors' Addresses Amardeep Sinha 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 De_&_Sinha Expires April 2012 [Page 16]