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