DISPATCH J. Bakker, Ed. Internet-Draft Research in Motion Corporation Intended status: Informational R. Avasarala Expires: September 25, 2013 Polycom March 24, 2013 A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service draft-avasarala-dispatch-comm-div-notification-11.txt Abstract 3GPP and TISPAN are defining the protocol specification for the Communication Diversion (CDIV) service using IP Multimedia (IM) Core Network (CN) subsystem (IMS) supplementary service. As part of CDIV, a SIP based event package is used for notifying users about diversions (re-directions or forwarding) of requests for communication sessions targetting the user. This document defines the SIP event package to support subscription and notification of diversions. The proposed event package is applicable to the CDIV supplementary service in IMS and may not be applicable to the general internet. 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 September 25, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Bakker & Avasarala Expires September 25, 2013 [Page 1] Internet-Draft SIP Communication Diversion Notification March 2013 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 4. Abbreviations and Definitions . . . . . . . . . . . . . . . . 4 4.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Package Definition . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 6 6.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 6 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 6 6.5. Notify bodies . . . . . . . . . . . . . . . . . . . . . . 6 6.6. Notifier Processing of SUBSCRIBE requests . . . . . . . . 7 6.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 7 6.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 7 6.7. Notifier Generation of NOTIFY requests . . . . . . . . . . 8 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 8 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 8 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9 6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9 7. Comm-div-info filter and notifier documents . . . . . . . . . 10 8. Structure of Comm-div-info filter and notifier formats . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10.1. Communication Diversion Information Event Package Registration . . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Bakker & Avasarala Expires September 25, 2013 [Page 2] Internet-Draft SIP Communication Diversion Notification March 2013 1. Introduction 3GPP is currently maintaining and specifying communication diversion mechanisms which allow users to forward and/or redirect incoming communications to other destinations. A common example is Communication Forward On Busy (CFB) wherein users can instruct a server in the network to redirect incoming requests, whilst they are participating in a session. Similarly, other variants of communication diversion are well defined and used in practice such as Communication Forward on subscriber Not Reachable (CFNRc), Communication Forward Unconditional (CFU), Communication Forwarding No Reply (CFNR), Communication Deflection (CD), and Communication Forwarding on Not Logged-in (CFNL). 3GPP is currently maintaining and specifying a mechanism for users to configure Communication Diversion Services (3GPP TS 24.604 [1]) for their incoming communications. The mechanism for users to configure Communication Diversion Services (3GPP TS 24.604 [1]) may cause a variety of rules to be provisioned in the network at the same time. For instance, a user may have, in addition to other communication diversion rules, various CDIV services configured, e.g. some rules based on the time-of-the-day and some rules based on the calling party's identity. It is possible that the user loses track of the various rules and undesirable diversions may occur. If the user cann't notified of the diversions, then it is hard for the user to determine that the combination of rules have caused undesirable diversions. CDIV Notification (CDIVN) is a CDIV service providing the user the capability to receive notifications about all diverted communications (CFU, CFB, CFNR, CD, CFNRc and CFNL). If CDIVN is configured, when a communication is diverted on behalf of the subscriber, the Subcsriber receives a notification. The subscriber is then in able to determine whether the communication diversion which just occurred, was indeed as per their expectation. For example, a subscriber intended to divert all incoming calls to voice-mail, between 3.00 p.m. to 4.00 p.m. Yet, by mistake she configures the time-duration as 3.00 to 4.00 p.m. It would be very difficult for her to spot this error while manually reviewing her complete set of communication diversion services, with their various configurations. Instead, if the subscriber receives a real-time notification of any communication diversion occurring after 4 p.m., she would be able to immediately guess that something is 'wrong' or not as per her intention and take corrective action. Such corrective action could be manual verification of the specific rule which triggered the communication diversion, wherein she will be able to spot the "mistake" more easily. Thus, for effective subscriber services management of multiple Bakker & Avasarala Expires September 25, 2013 [Page 3] Internet-Draft SIP Communication Diversion Notification March 2013 configurations of various Communication Diversion services, a notification-based mechanism may work well. Such a mechanism would involve notifying subscribers about diversions of their incoming communications, as and when the communication diversion happens or with a slight delay (as per subscriber service configuration). As such diversion-related information is conveyed almost instantly or within a small time-frame, the subscribers can verify whether the particular communication diversion is indeed correct at that instant of time. This document defines a SIP event package that allows a SIP User Agents to subscribe to and be notified of communication diversions enacted on their behalf using the CDIV service. The protocol specification for the CDIV service (using IMS core networks) can be found in 3GPP TS 24.604 [1]. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant implementations. 3. Applicability Statement It is believed that the SIP event package defined here is not applicable to the general Internet; it has been designed to serve the architecture of the CDIV service (see 3GPP TS 24.604 [1]) in IMS core networks 3GPP TS 24.229 (see [9]). The aim of this memo is to follow the procedure indicated in RFC 5727. [3] and to register a new event package with event name "comm-div-info" with IANA. 4. Abbreviations and Definitions 4.1. Abbreviations CDIV: Communication Diversion. CDIVN: Communication Diversion Notification. TISPAN: Telecommunications and Internet Converged Services and Protocols for Advanced Networking. Bakker & Avasarala Expires September 25, 2013 [Page 4] Internet-Draft SIP Communication Diversion Notification March 2013 4.2. Definitions Subscriber - The User Agent who has subscribed to the Communication diversion notification service. User - Another term for the subscriber. Diverting User - The User Agent who has configured a Communication Diversion. This could be the User Agent who has configured the CDIV service rules in the network, in accordance with 3GPP TS 24.604 [1]. Diverted-To Entity/User - The User Agent who is the new target of the incoming communication, post execution of any configured CDIV service rules. Originating User - The User Agent who is the originator of the incoming communication, which was initially targeted towards the Diverting User, but finally sent to the Diverted-To User. The Originating User is also referred to as the Caller. IMS Core Network - This refers to the IMS based SIP based network that conforms to the [9] and not the general SIP network as defined in [4]. 5. Requirements The CDIVN service enables a user to receive notification about the diversion of any of his/her incoming communications, which were addressed to the user's address. A comprehensive description of all the requirements that affect the CDIVN service developed by 3GPP and TIPSAN is found in [5] and [1]. 6. Package Definition This section fills in the details needed for an event package as defined in Section 4.4 of [6]. 6.1. Event Package Name The SIP Events specification requires package definitions to specify the name of their package or template-package. The name of this package is "comm-div-info". As specified in [6], this value appears in the Event header present in SUBSCRIBE and NOTIFY requests. Bakker & Avasarala Expires September 25, 2013 [Page 5] Internet-Draft SIP Communication Diversion Notification March 2013 6.2. Event Package Parameters The SIP Events specification [6] allows packages to define additional parameters. This event package "comm-div-info" does not define additional parameters. 6.3. SUBSCRIBE bodies The SIP Events specification requires package or template-package definitions to define the usage, if any, of message bodies in SUBSCRIBE requests. Furthermore, the SIP Events specification requires that message bodies are specified or that detailed specifications for the syntax and semantics of such a message body are cited. A SUBSCRIBE for Communication Diversion event MAY contain a message body. The purpose of the body depends on its type. Subscriptions to the Comm-div-info event package SHALL only include a message body of MIME type "application/vnd.3gpp.comm-div-info+xml". The syntax and semantics of the message body can be found in 3GPP TS 24.604 [1]. A body of the SUBSCRIBE request with content type set to MIME type "application/comm-div-info-filter+xml" contains information about the communication diversion notification information filter criteria and notification trigger criteria. The subscriber SHALL also verify that this information conforms to a valid XML document as defined in [11]. The subscriber SHALL also verify that the information contained in the XML document contains elements defined in [1]. 6.4. Subscription Duration The default expiration time for subscriptions within this package is 3600 seconds. As per [6], the subscriber MAY specify an alternate expiration in the Expires header field. 6.5. Notify bodies The SIP Events specification requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified. The NOTIFY message contains an event body. This event body is in a format listed in the Accept header field of the SUBSCRIBE request or a package specific default format if the Accept header field was omitted from the SUBSCRIBE request. Furthermore, the SIP Events specification requires that event bodies are specified or that detailed specifications for the syntax and semantics of such a event body are cited. Bakker & Avasarala Expires September 25, 2013 [Page 6] Internet-Draft SIP Communication Diversion Notification March 2013 In this event package, the body of the notification contains the communication diversion information pertaining to the diversion that occurred in the network on behalf of the subscriber. The package specific body has the MIME type "application/ vnd.3gpp.comm-div-info+xml". The syntax and semantics of the event body can be found in 3GPP TS 24.604 [1]. A subscriber must always Accept receiving a NOTIFY with Content-Type "application/vnd.3gpp.comm-div-info+xml". The notifiers MUST be capable of accepting the "application/vnd.3gpp.comm-div-info+xml" data format as described in 3GPP TS 24.604 [1]. If the notifier sends a NOTIFY, it MUST include contents according to 3GPP TS 24.604 [1] and include the content-type header field set to "application/ vnd.3gpp.comm-div-info+xml". The default Accept header field for SUBSCRIBE is "application/ vnd.3gpp.comm-div-info+xml" (assuming Event header has a value of "comm-div-info-ntfy"). 6.6. Notifier Processing of SUBSCRIBE requests The contents of a "application/vnd.3gpp.comm-div-info+xml" XML document in a NOTIFY request can contain sensitive information that can reveal some privacy information. Therefore, such documents MUST only be sent to authorized subscribers. In order to determine if a subscription originates in an authorized user, the subscriber MUST be authenticated as described in Section 6.6.1 and then the user MUST be authorized to be a subscriber as described in Section 6.6.2. The Notifier MUST check if the SUBSCRIBE request contains a body part. If there is a body part, the Notifier MUST do the following. Check if a SUBSCRIBE request body part conforms to "application/ vnd.3gpp.comm-div-info+xml" XML Schema document in 3GPP TS 24.604 [1]. If it conforms then the Notifier processes the document and generates notifications accordingly. 6.6.1. Authentication Notifiers MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in [4] and other authentication extensions. 6.6.2. Authorization Once authenticated, the notifier makes an authorization decision. A notifier MUST NOT accept a subscription unless authorization has been provided by the user. The means by which authorization are provided Bakker & Avasarala Expires September 25, 2013 [Page 7] Internet-Draft SIP Communication Diversion Notification March 2013 are outside the scope of this document. 6.7. Notifier Generation of NOTIFY requests The SIP Events specification details the formatting and structure of NOTIFY messages. However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the "comm-div-info" event package. A notifier sends a NOTIFY request when a communication diversion is enacted on behalf of the user. If there is a stored filter criteria for the user, then the notifier MUST look into the filter criteria. If the filter criteria matches, then the notifier generates a NOTIFY request and sends the NOTIFY request to the user. If the filter criteria do not match, then the notifier does not generate a NOTIFY request. A body part of the NOTIFY has a content-type set to "application/vnd.3gpp.comm-div-info+xml" and must contain the elements defined in 3GPP TS 24.604 [1]. Notifiers could detect that a communication diversion was enacted on behalf of the subscriber via a "History-Info" header field [7] value, per 3GPP TS 24.604 [1], sent from an application server hosting the CDIV service. 6.8. Subscriber Processing of NOTIFY Requests The SIP Events specification expects event packages to describe the process followed by the subscriber upon receipt of a NOTIFY request. In this specification, each NOTIFY request contains a XML document for the content type "application/vnd.3gpp.comm-div-info+xml" (see 3GPP TS 24.604 [1]). 6.9. Handling of Forked Requests The SIP Events specification requires each package to describe handling of forked Requests. This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request. This guarantees that only a single notifier is generating notifications for a particular subscription to a particular user. But if forking is allowed, then the server that receives multiple subscriptions should be able to generate a single dialog on behalf of all the subscriptions that are received. Any subsequent subscriptions should be mapped to the generated dialog. Similarly Bakker & Avasarala Expires September 25, 2013 [Page 8] Internet-Draft SIP Communication Diversion Notification March 2013 when the server receives a single notification for the generated dialog, it should be generate the corresponding number of notifications towards the received notifications. 6.10. Rate of Notifications The SIP Events specification requires each package to specify maximum rate at which notifications can be sent . Comm-div-info notifiers SHOULD NOT generate notifications for a single subscription at a rate of more than once every five seconds. 6.11. State Agents An FSM associated with the subscriber is created in the "IDLE" state, e.g. upon receiving filter criteria. Whenever a communication diversion is detected for a URI of the subscriber, a state transition occurs. Depending on whether a filter is matched, a state is entered. In the DIVERSION_NOTIFIED state, notification information is sent to the subscriber. If notification information needs to be sent, the Notifier generates the notification information and sends the information to the subscriber. If a diversion is detected but no filter is matched, a transition to DIVERSION_NOT_NOTIFIED occurs. The FSM for CDIVN is shown in below Figure. +-----------+ First diversion & Filter match | +-------------------------------+ | IDLE | | | | | +-----+-----+ | First | | diversion | | & No | | filter(s) | | match V Next diversion & V +-----------+ Filter match +-------+-------+ | DIVERSION +---------------------->+ | | NOT | | | DIVERSION | | NOTIFIED +--+ +--+ NOTIFIED | +-----+-----+ | +-------+-------+ ^ | | +--------+----------------------------+ Next diversion & No filter(s) match Bakker & Avasarala Expires September 25, 2013 [Page 9] Internet-Draft SIP Communication Diversion Notification March 2013 Figure 1: Diverted URI State Machine The subscriber could receive, as part of the notification information, the state the FSM was in prior to detecting the diversion. o [IDLE]: meaning that no diversions have occured since setting the present "filter". o [DIVERSION_NOTIFIED]: meaning that since receiving the last NOTIFY request for this even package, no additional diversions have occured. o [DIVERSION_NOT_NOTIFIED]: meaning that one or more diversions have occured since setting the present "filter" or since receiving the last NOTIFY request for this even package. 7. Comm-div-info filter and notifier documents Comm-div-info document is an XML document [10] that MUST be well- formed and SHOULD be valid. Communication Diversion Information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8 [11]. 8. Structure of Comm-div-info filter and notifier formats The o structure of the filter and notifier format; o examples of the use of subscribtion and notification bodies; and o XML Schema of subscribtion and notification bodies, have been described in 3GPP TS 24.604 [1]. 9. Security Considerations Authentication and authorization of subscriptions have been discussed in Section 6.6. Lack of authentication or authorization may provide comm-div-info information to unauthorized parties and can reveal sensitive information with regards to the user's call receiving patterns. For example, who calls the user and at what time, etc. Integrity protection and confidentiality of notifications are also Bakker & Avasarala Expires September 25, 2013 [Page 10] Internet-Draft SIP Communication Diversion Notification March 2013 discussed in Section 6.7. If a notifier does not encrypt bodies of NOTIFY requests, an eavesdropper could learn the status of a SIP user agent and use it to create malicious sessions. If the notifier does not integrity protect the bodies of NOTIFY requests, a man-in- the- middle attacker or malicious SIP proxy could modify the contents of the comm-div-info event package notification. Although this does not cause harm, it can create annoyances. 10. IANA Considerations This document registers the new SIP Event Package. 10.1. Communication Diversion Information Event Package Registration Package Name: Comm-div-info Type: Package Contact: John Merdith, Published Specification: RFC XXXX (Note to RFC Editor) 11. Acknowledgements The authors would like to thank Mary Barnes, Samir Saklikar, Subir Saha, Ban Al-Bakri, Roland Jesske, Jose Miguel Torres, Paul Kyzivat, John Elwell , Keith Drage , Gonzalo Camarillo, Olle E. Johansson, Atle Monrad and Dean Willis for their valuable comments and suggestions. 12. References 12.1. Normative References [1] 3GPP, "Communication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification", 3GPP TS 24.604 10.5.0, June 2012. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Bakker & Avasarala Expires September 25, 2013 [Page 11] Internet-Draft SIP Communication Diversion Notification March 2013 Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010. [4] 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. [5] 3GPP, "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services; Stage 1", 3GPP TS 22.173 10.5.0, June 2012. [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [7] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. [8] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006. 12.2. Informative References [9] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 10.11.0, March 2013. [10] Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, . [11] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. Appendix A. Change log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-avasarala-dispatch-comm-div-notification-10 o The SIP Events specification (RFC 3265) requires that bodies to be used as part of the event package are specified or that detailed Bakker & Avasarala Expires September 25, 2013 [Page 12] Internet-Draft SIP Communication Diversion Notification March 2013 specifications for the syntax and semantics of such a body are cited. With that knowledge, the authors could greatly reduce the size of this draft; the detailed specification is in 3GPP TS 24.604. o Editorial clean up. Changes from draft-avasarala-dispatch-comm-div-notification-09 o No changes of substance. An update addressing the comments on the list and offline, will follow. Changes from draft-avasarala-dispatch-comm-div-notification-08 o Corrected text to not preclude use of S/MIME or multipart. o Updated Finite State Machine diagram. o Updated the schema for CDIVN notification document to reflect FSM updates. Changes from draft-avasarala-dispatch-comm-div-notification-07 o Added MIME type for communication diversion filter criteria. o Updated the State Agents section to add state diagram for CDIVN Service. o Updated the schema for CDIVN notification document. o Updated the Acknowledgements section. Changes from draft-avasarala-dispatch-comm-div-notification-06 o Changed the namespace for XML schema to "http://urn.etsi.org" aligning with 3GPP TS 24.504 o Updated the XML schema and removed the word "optional" for "diverting-user-info" Changes from draft-avasarala-dispatch-comm-div-notification-05 o Updated Requirements section o Incorporated expert review comments for state information, notification content and subscribe bodies Bakker & Avasarala Expires September 25, 2013 [Page 13] Internet-Draft SIP Communication Diversion Notification March 2013 o Modified the section on examples for subscription and notification body Changes from draft-avasarala-dispatch-comm-div-notification-04 o Incorporated review comments o Added text for SUBSCRIBE body and NOTIFY body and checking of filter criteria. o Updated Communication Diversion Notification Information document and XML schema to add Diversion and notification count information as optional parameters. Changes from draft-avasarala-dispatch-comm-div-notification-03 o Added State information to Notifiers. o Modified diverting-URI definition and element in communication diversion information selection criteria as optional parameter . Changes from draft-avasarala-dispatch-comm-div-notification-02 o Modified the applicability statement to make it more IMS specific. o Added a definition for IMS Core network. o Updated authors list and Acknowledgement sections. Changes from draft-avasarala-dispatch-comm-div-notification-01 o Incorporated review comments. o Modified contact details for co author Subir Saha. Changes from draft-avasarala-sipping-comm-div-notification-00 o Changed contact details of co author Subir Saha. o Moved from SIPPING to DISPATCH WG. Changes from draft-avasarala-dispatch-comm-div-notification-00 o Added comm-div-info document structure information and schema for the event package. o Added more elaborate description for various sections in comm-div- info document Bakker & Avasarala Expires September 25, 2013 [Page 14] Internet-Draft SIP Communication Diversion Notification March 2013 Authors' Addresses John Luc Bakker (editor) Research in Motion 5000 Riverside Drive, Building 6, Suite 100 Irving, Texas 75039 USA Email: jbakker@blackberry.com Ranjit Avasarala Polycom Technology India Pvt Ltd Manyata Embassy Business Park, Bangalore 560045 India Email: ranjit.avasarala@polycom.com Bakker & Avasarala Expires September 25, 2013 [Page 15]