Network Working Group M. Garcia
Internet Draft Ericsson
Expires: November 2002 May 2002
Private Session Initiation Protocol extension
for Called Party Identity
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 11/30/02 Page 1
Garcia The SIP Called Party ID header May 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................................................6
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 11/30/02 Page 2
Garcia The SIP Called Party ID header May 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 field 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
all his URIs, and therefore, it has full control over the Contact
values assigned to each registration. However, in the case the UA does
not have full control of his IDs 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 URIs may be automatically
registered when the UA registers some of its URIs. 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 terminating ID of 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>
A user also registers his personal URI to his/her registrar.
F2 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Network Working Group Expiration 11/30/02 Page 3
Garcia The SIP Called Party ID header May 2002
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 serving the user
to insert a P-Called-Party-ID that identifies the URI to which this
session is destined.
3. Applicability statement
The P-Called-Party-ID header is applicable whenever the following
circumstances are met:
1. The UA registers to his proxy with one or more SIP URIs.
2. The proxy receives an INVITE destined to a user's ID.
Network Working Group Expiration 11/30/02 Page 4
Garcia The SIP Called Party ID header May 2002
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
with the contents of the SIP URI received in the Request-URI of the
INVITE or any other standalone method or method that initiates a
dialog.
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
The allowable usage of headers is described in Table 2 of SIP [1]. The
following additions to this table are needed for the P-Called-Party-
ID.
The allowable usage of headers is described in Table 2 of SIP [1].
Addition of 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
6. Usage
6.1 Procedures at the UA
A UAC SHOULD NOT insert a P-Called-Party-ID header field in any SIP
request or response.
Network Working Group Expiration 11/30/02 Page 5
Garcia The SIP Called Party ID header May 2002
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 or any other standalone
request, except REGISTER, or any other request that initiates a
dialog. The header is typically populated with the contents Request-
URI in the SIP request that the proxy received.
It is necessary that the proxy who 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.
9. Author's Addresses
Miguel A. Garcia
Ericsson
FIN-02420, Jorvas, Finland
Tel: +358 9299 3553
Network Working Group Expiration 11/30/02 Page 6
Garcia The SIP Called Party ID header May 2002
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 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-sipping-garcia-
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.
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, May 2002, work in progress.
9. R. Sparks, The REFER method, draft-sparks-sip-refer-split-00.txt,
April 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
Network Working Group Expiration 11/30/02 Page 7
Garcia The SIP Called Party ID header May 2002
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-01.txt>, and
expires November 20, 2002.
Network Working Group Expiration 11/30/02 Page 8