Network Working Group M. Garcia
Internet Draft Ericsson
Expires: December 2002 June 2002
Private Session Initiation Protocol (SIP) extension
for Called Party Identity
<draft-garcia-sip-called-party-id-04.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments should
be directed to the authors.
Abstract
This memo describes a private extension to SIP in the form of a
P-Called-Party-ID header. A proxy inserts this header typically in an
INVITE, en-route to its destination. The header is populated with the
Request-URI received by the proxy in the request. The UAS identifies
which ID out of several IDs the invitation was sent to (for example,
the user may be using simultaneously a personal and a business SIP URI
to receive invitation to sessions). The UAS may use the information to
render different distinctive audiovisual alerting tones, depending on
the ID used to receive the invitation to the session.
Table of contents
Network Working Group Expiration 12/05/02 [Page 1]
Garcia The SIP Called Party ID header June 2002
1. Introduction......................................................2
2. Motivation and problem statement..................................2
3. Applicability statement...........................................4
4. The Called Party ID header........................................5
5. P-Called-Party-ID syntax and definition...........................5
6. Usage.............................................................5
6.1 Procedures at the UA.............................................5
6.2 Procedures at the proxy..........................................6
7. Security Considerations...........................................6
8. IANA Considerations...............................................6
9. Author's Addresses................................................7
10. Acknowledgements.................................................7
11. References.......................................................7
11.1 Normative references............................................7
11.2 Informative references..........................................7
1. Introduction
The 3rd Generation Partnership Project (3GPP) has chosen SIP [1] as
the signaling protocol for the IP Multimedia Subsystem (IMS). A
collection of 3GPP requirements related to SIP are stated in the "3GPP
requirements to SIP" [2].
Users in the 3GPP IP Multimedia Subsystem (IMS) may get one or several
SIP URIs to identify the user. For instance, a user may get a business
SIP URI and a personal one. As an example of utilization, the user may
make available the business SIP URI to co-workers and may make
available the personal SIP URI to members of the family.
At a certain point in time, both the business SIP URI and the personal
SIP URI are registered to the network, so both URIs can receive
invitations to new sessions. When the user receives an invitation to
join a session, he/she should be aware of which of the several
registered SIP URIs this session was sent to.
This requirement is stated in section 6.10.3 of the 3GPP requirements
on SIP Internet Draft [2].
2. Motivation and problem statement
The problem arises during the terminating side of a session
establishment. When the SIP server that is serving a user gets an
INVITE and, the SIP sever retargets the SIP URI in the Request-URI
field and replaces it by the SIP URI published by the user in the
Contact header field of the REGISTER message at registration time.
When the UAS receives the SIP request, it cannot determine which
identity the request was sent towards.
Someone can argue that the To header field conveys the semantics of
the called user, and therefore, this extension is not needed. Although
the To header field in SIP may convey the called party ID in most
Network Working Group Expiration 12/05/02 [Page 2]
Garcia The SIP Called Party ID header June 2002
situations, there are two particular cases when the above assumption
is not correct:
1. The session has been forwarded, redirected, etc. by previous
SIP entities, before arriving to the called user's proxy.
2. The UAC builds an INVITE request and the the To header field
is not the same as the Request-URI.
The problem of using the To header field is that this field is
populated by the UAC and not modified by proxies in the path. If the
UAC, for any reason, did not populate the To header field with the SIP
URI of the destination user, then the destination user is not able to
distinguish which ID the session is intended to be received.
Another possible solution to the problem is built upon the
differentiation of the Contact header value between different URIs at
registration time. The UA can differentiate each identity it registers
by assigning a different Contact header value. For instance, when the
UA registers sip:id1, the Contact value can be sip:id1@ua1; the
registration of sip:id2 can be bound to the Contact value siP:id2@ua2.
The solution described above assumes that the UA explicitly registers
each of his address-of-record URIs, and therefore, it has full control
over the contact address values assigned to each registration.
However, in the case the UA does not have full control of his address-
of-record URIs registered, because of, e.g., a 3rd party registration,
the solution does not work. This is the case of the 3GPP registration,
where the UA may have previously indicated to the network, by means
outside SIP, that some other address-of-record URIs may be
automatically registered when the UA registers a particular address-
of-record URI. The requirement is covered in section 6.10.2.2 of the
3GPP requirements on SIP [2].
In the next paragraphs we show an example of the problem, in the case
there has been some sort of call forwarding in the session, so that
the UAC is not aware of the intended destination URI in the current
INVITE.
Example of the current behavior: a user registers his business URI to
his/her registrar.
F1 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:user1-business@example.com
From: sip:user1-business@example.com;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
The user also registers his personal URI to his/her registrar.
Network Working Group Expiration 12/05/02 [Page 3]
Garcia The SIP Called Party ID header June 2002
F2 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8
To: sip:user1-personal@example.com
From: sip:user1-personal@example.com;tag=346249
Call-ID: 2Q3817637684230998sdasdh10
CSeq: 1827 REGISTER
Contact: <sip:user1@192.0.2.4>
Later, the proxy/registrar receives an INVITE destined to the user's
business SIP URI. We assume that this SIP INVITE has undergone some
sort of forwarding in the past, and as such, the To header field is
not populated with the SIP URI of the user. In this case, we assume
that the session was initiated to sip:other-user@othernetwork.com, who
has forwarded this session to sip:user1-business@example.com
F3 INVITE P2 -> P1
INVITE sip:user1-business@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
The proxy P1 retargets the user and replaces the Request-URI by the
SIP URI published during registration time in the Contact header
value.
F4 INVITE P1 -> UA
INVITE sip:user1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
When the UAS receives the INVITE, it cannot determine whether it got
the session invitation due to his registration of the business or the
personal ID. Neither the UAS, nor proxies or application servers can
provide this user a service based on the destination of the session.
We solve this problem by allowing the proxy that is responsible for
the home domain (as defined in RFC 3261 [1]) of the user to insert a
P-Called-Party-ID header that identifies the URI to which this session
is destined.
3. Applicability statement
The P-Called-Party-ID is applicable when the UAS needs to be aware of
the intended address-of-record in the request, before the proxy
retargeted to the contact address. The UAS may be interested in
Network Working Group Expiration 12/05/02 [Page 4]
Garcia The SIP Called Party ID header June 2002
applying different audiovisual alerting effects or other filtering
services, depending on the intended destination of the request. It is
specially valuable when the UAS has registered several address-of-
record URIs to his registrar, and therefore, is not aware of the
address-of-record that hit his proxy/registrar unless this extension
is used.
4. The Called Party ID header
The P-Called-Party-ID header field provides the UAS with the URI the
request was addressed to, before a proxy retargeted the request. This
information is intended to be used by subsequent proxies in the path
or by the destination UAS.
Typically, a SIP proxy, inserts the P-Called-Party-ID header field
when it retargets the user by replacing the Request-URI with the
contact address. The P-Called-Party-ID header value is populated with
the contents of the Request-URI in the request.
This extension MUST NOT be used in REGISTER request.
5. P-Called-Party-ID syntax and definition
The P-Called-Party-ID is an extension to SIP in the form of a SIP
header. The syntax of the P-Called-Party-ID header is based on the
ABNF of SIP [1] and its syntax is described as follows:
P-Called-Party-ID = "P-Called-Party-ID" HCOLON called-pty-id-spec
called-pty-id-spec = addr-spec
Table 1 below is an addition of the P-Called-Party-ID to the Table 2
in SIP [1], section 4.1 of the SIP-specific event notification [4],
tables 1 and 2 in the SIP INFO method [5], tables 1 and 2 in
Reliability of provisional responses in SIP [6], tables 1 and 2 in the
SIP UPDATE method [7], tables 1 and 2 in the SIP extension for Instant
Messaging [8] and table 1 in the SIP REFER method [9]:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
P-Called-Party-ID R amr - - - o o -
Header field SUB NOT PRA INF UPD MES REF
_______________________________________________________________
P-Called-Party-ID o - - - - o o
Table 1: Header field support
6. Usage
6.1 Procedures at the UA
Network Working Group Expiration 12/05/02 [Page 5]
Garcia The SIP Called Party ID header June 2002
A UAC SHOULD NOT insert a P-Called-Party-ID header field in any SIP
request or response.
A UAS may receive a P-Called-Party-ID header field. The header is
populated with the URI that the request was intended for.
The UAS may use the value in the P-Called-Party-ID header field to
provide services based on the destination of the called party, such as
filtering of calls depending on the date and time, distinctive
presentation services, distinctive alerting tones, etc.
6.2 Procedures at the proxy
A proxy that has authoritative information about the user, may insert
a P-Called-Party-ID header field in an INVITE, any other request that
initiates a dialog or any other standalone request outside a dialog
(such as MESSAGE [8]) except REGISTER. The header is typically
populated with the contents of the Request-URI in the SIP request that
the proxy received.
It is necessary that the proxy which inserts the P-Called-Party-ID
header have information about the user, in order to prevent a wrong
delivery of the called party ID. This information may have been learnt
through a registration process, for instance.
A proxy or application server that receives a request containing a P-
Called-Party-ID header may use the contents of the header to provide a
service to the user based on the URI of that header value.
7. Security Considerations
Due to the nature of the header this extension does not introduce any
security concern. It is possible for an attacker to modify the
contents of the header. However, this modification will not cause any
harm to the session establishment.
An eavesdropper may collect the list identities a user is registered.
This may have privacy implications. To mitigate this problem, it is
RECOMMENDED that this extension is used in a secured environment,
where encryption of SIP messages is provided either end-to-end or hop-
by-hop.
8. IANA Considerations
This document defines the SIP extension header "P-Called-Party-ID"
which should be included in the registry of SIP headers defined in SIP
[1]. As required by the SIP change process [3] the SIP extension
header name "Called-Party-ID" should also be registered in association
with this extension.
Network Working Group Expiration 12/05/02 [Page 6]
Garcia The SIP Called Party ID header June 2002
The following is the registration for the P-Called-Party-ID header
field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.]
Header Field Name: P-Called-Party-ID
Compact Form: none
The following is the registration for the Called-Party-ID header
field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.] (not yet specified, only reserved)
Header Field Name: Called-Party-ID
Compact Form: none
9. Author's Addresses
Miguel A. Garcia
Ericsson
FIN-02420, Jorvas, Finland
Tel: +358 9299 3553
e-mail: miguel.a.garcia@ericsson.com
10. Acknowledgements
The author would like to thank Andrew Allen, Gabor Bajko, Gonzalo
Camarillo, Keith Drage, Georg Mayer, Dean Willis, Rohan Mahy, Ya-Ching
Tan and the 3GPP CN1 Working Group members for their valuable comments
on this document.
11. References
11.1 Normative references
1. J. Rosenberg, H. Schulzrinne, G. Camarillo et al, Session
Initiation Protocol, RFC 3261, March 2002.
11.2 Informative references
2. M. Garcia et al, 3GPP requirements on SIP, draft-garcia-sipping-
3gpp-reqs-03.txt, Marcg 2002,work in progress.
3. S. Bradner, R. Mahy, A. Mankin, J. Ott, B. Rosen, D. Willis, SIP
change process, draft-tsvarea-sipchange-01.txt, February 2002,
work in progress.
4. A. Roach, SIP-Specific Event Notification, RFC 3265, March 2002.
5. S. Donovan, The SIP INFO method, RFC 2976, October 2000.
Network Working Group Expiration 12/05/02 [Page 7]
Garcia The SIP Called Party ID header June 2002
6. J. Rosenberg, H. Schulzrinne, Reliability of Provisional
Responses in SIP, RFC 3262, March 2002.
7. J. Rosenberg, The Session Initiation Protocol UPDATE Method,
draft-ietf-sip-update-02.txt, April 2002, work in progress.
8. B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle,
Session Initiation Protocol Extension for Instant Messaging,
draft-ietf-sip-message-04.txt, May 2002, work in progress.
9. R. Sparks, The SIP Refer method, draft-ietf-sip-refer-05.txt,
June 2002, work in progress.
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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. 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."
Expiration Date
This memo is filed as <draft-garcia-sip-called-party-id-04.txt> and
expires December 5, 2002.
Network Working Group Expiration 12/05/02 [Page 8]