SIPPING WG Venkatesh Venkataramanan Internet Draft Sunil Veluvali draft-venkatar-sipping-called-name-00.txt June 2003 Sylantro Systems Expires: Dec 2003 Enhancements to Asserted Identity to Enable Called Party Name Delivery using SIP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the expected business telephony requirements for delivering called party name towards SIP entities. A couple of mechanisms exist to deliver calling name and number to the called party. None exist for exposing the called party name or preferred identity to the calling party. This draft proposes a mechanism to provide this capability. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................3 Requirements for Called Name Delivery..............................3 Overview...........................................................4 Proxy Behavior.....................................................5 User Agent Client Behavior.........................................5 V. Venkataramanan et. al. 1 Internet Draft called-name 6/2/2003 The P-Asserted-Identity Header.....................................5 Open Issues........................................................5 Security Considerations............................................5 Acknowledgements...................................................6 References.........................................................7 Author's Addresses.................................................7 V. Venkataramanan et. al. 2 Internet Draft called-name 6/2/2003 Applicability This draft describes the modification to the P-Asserted-Identity [3] extensions to SIP [2] that enables a network of SIP entities to exchange called party information in a trusted network. The use of this extension follows the guidelines specified in RFC 3325 [3]. This document does not describe how to use network elements to determine the identity of an entity. Conventions used in this document 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 [1] and indicate requirement levels for compliant mechanisms. Introduction Delivering Called Name and Number is one of the many services provided by traditional business communication systems, and a service expected by most users of business communication systems. This same functionality is required in next-generation SIP based deployments. The baseline SIP specification, RFC 3261 [2] allows called UAÆs (the UAS) to place their display name and the number in SIP headers in order to indicate their identity to the calling UA. The "Contact" SIP header is one such example of this. However, use of the Contact header does not solve all the requirements for providing called name and number. This document presents a method to extend a simple mechanism to provide called party identification based on the requirements detailed below. Requirements for Called Name Delivery . The name and number of the UAS is delivered to the UAC before the call is established. . In the case of calls to numbers like hunt-groups or ACD numbers that are forked, every UAS that receives the INVITE will place its local contact information in the response to this request. The UAC will therefore know that the call was placed to an ACD group number but will not know which of these agents the call is being offered to. . A feature proxy providing called name look up services for a UA might have policies that define a particular SIP URL to be displayed in a particular format and/or language that differs V. Venkataramanan et. al. 3 Internet Draft called-name 6/2/2003 from the display preferences of the UAS that is registered for this URL. If such a conflict arises, the display policy implemented on the feature proxy will override that of the UAS. . A feature proxy providing called name lookup services for a user community may contain a list of users in a centralized directory database with content differing from that of the UAS. If this is the case, the information provided by the feature proxy will be displayed, rather than that of the UAS. . For URLÆs that are serviced via a PSTN gateway, the amount of information that can be displayed about a called party is restricted. Under such circumstances, a local feature proxy may be configured to provide information such as called name to the UA. . Once a session is established, the UA and UAS information may undergo many changes (transfer to a third party, the caller gets parked and picked up by another end user, etc). In such cases, it is desirable that the UA and the UAS are refreshed with the current calling and called names. Overview Some of the above requirements are already supported in the base SIP specification [2]. The UAS receiving the INVITE can place its display name and number (its SIP-URL) in the "Contact" header in a 1xx or a 200-class response, which can be rendered to the user by the UA. However, this does not cover or support all of the requirements specified above. For example, in cases where the call is forked to multiple user agents (like applications like ACD or hunt groups), while the ôToö header in the INVITE would indicate to the UAS receiving the INVITE some information as to where the call was initially directed towards, it would not provide details as to what the ôname corresponding to this number isö or what to set the Contact display name so that the ôdesiredö value may be rendered back to the UAC. Arguably some of this may be achieved by local configuration of some sort (tell the UAS what display name to use based on the To URL), but it necessitates that the UA's involved in all types of call flows know about all features, call redirection, and/or services offered by the network to be able to deliver this service correctly. Further services enabled by a feature proxy require that the proxy be able to add this information in a SIP message. The Contact header is a non-modifiable header by proxies in a 200 response per table 2 of the base SIP specification [2]. The draft proposes to use the P-Asserted-Identity header field as described in RFC 3325 [3] in SIP responses to achieve rendering called name and number to the UAC. V. Venkataramanan et. al. 4 Internet Draft called-name 6/2/2003 A proxy server that handles a SIP response message, or generates a 100 Trying response on receipt of an INVITE, MAY after inspecting the UACÆs profile add or modify the P-Asserted-Identity header in a SIP response message before forwarding the same to the UAC or its next hop. The guidelines for adding or removing the P-Asserted- Identity in responses, remains as defined in RFC 3325 [3]. Simply stated, the P-Asserted-Identity header is removed when forwarding responses towards un-trusted UAÆs or proxies. Proxy Behavior Proxies are allowed to remove and/or add P-Asserted-Identity header while processing any class of response. Any proxy that decides to insert a P-Asserted-Identity in a SIP response message MUST do so, only if the response being forwarded is to a trusted SIP entity. Consequently, a proxy forwarding a SIP response MUST remove the P- Asserted-Identity header if the same is being forwarded to an un- trusted entity. This is in conformance with the rules outlined in RFC 3325 [3]. User Agent Client Behavior The same rules as those detailed for a User Agent Server in RFC 3325 [3] apply to the UAC while handling the header in a SIP response. The draft RECOMMENDS that user agent render the contents of this header to the end user. The draft also RECOMMENDS that the UAC consider the identity provided in P-Asserted-Identity header field more trust-worthy than the ôFromö and ôContactö header field of a response. The P-Asserted-Identity Header This draft modifies the following entry to table 2 of [2]: Header Field where proxy INV BYE CANCEL OPTIONS REG ------------ ----- ----- --- --- ------ ------- --- P-Asserted-Identity 100 adm o o - - - P-Asserted-Identity 1xx adm o o - - - P-Asserted-Identity 2xx-6xx adm o o - - - SUB NOT REF INF UPD PRA --- --- --- --- --- --- - - o - o - Open Issues Is the usage of the P-Asserted-Identity header for accomplishing the same acceptable? Security Considerations V. Venkataramanan et. al. 5 Internet Draft called-name 6/2/2003 Since the draft extends the support of the P-Asserted-Identity header defined in [3], all security considerations detailed in [3] apply to this draft as well. Acknowledgements Many thanks to Cullen Jennings [3] for providing many useful comments and support during authoring of this draft. Many thanks to Kent Fritz, Mike Chack, John Weald, Sylantro Systems for their comments. V. Venkataramanan et. al. 6 Internet Draft called-name 6/2/2003 References 2 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol," Request for Comments 3261, Internet Engineering Task Force, June 2002. [3] C. Jennings, J. Peterson, ôPrivate Extensions to Session Initiation Protocol (SIP) for Asserted Identity in Trusted Networksö, November 2002 [4] J. Peterson, ôA Privacy Mechanism for the Session Initiation Protocol (SIP)ö, RFC 3323, November 2002 Author's Addresses Venkatesh Venkataramanan Email: venkatar@sylantro.com sip:venkatar@sip.sylantro.com (408) 626 3025 Sunil Veluvali Email: sunil.veluvali@sylantro.com sip:sunil.veluvali@sip.sylantro.com (408) 626 2309 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. V. Venkataramanan et. al. 7 Internet Draft called-name 6/2/2003 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. V. Venkataramanan et. al. 8