Network Working Group M. Garcia
Internet Draft Ericsson
Expires: October 2002 April 2002
Private SIP 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. The home serving proxy inserts this header
typically in an INVITE, en-route to its destination. The header is
populated with the 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 10/30/02 Page 1
Garcia The SIP Called Party ID header April 2002
1. Introduction......................................................2
2. Motivation and problem statement..................................2
3. Applicability statement...........................................4
4. The Called Party ID header........................................4
5. P-Called-Party-ID syntax and definition...........................4
6. Usage.............................................................5
6.1 Procedures at the UA.............................................5
6.2 Procedures at the proxy..........................................5
7. Security Considerations...........................................5
8. IANA Considerations...............................................5
9. Author's Addresses................................................6
10. Acknowledgements.................................................6
11. References.......................................................6
11.1 Normative references............................................6
11.2 Informative references..........................................6
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" [3].
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 [3].
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 modifies 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.
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
situations, there are two particular cases when the above assumption
is not correct:
Network Working Group Expiration 10/30/02 Page 2
Garcia The SIP Called Party ID header April 2002
1. The session has been forwarded, redirected, etc by previous
SIP entities, before arriving to the called user's proxy.
2. 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, didn't 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.
In the next paragraphs we show an example of the current behavior, 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 ID 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 ID to his/her registrar.
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 suffered 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=03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230@998sdasdh09
Network Working Group Expiration 10/30/02 Page 3
Garcia The SIP Called Party ID header April 2002
CSeq: 101 INVITE
The proxy P1 replaces the Request-URI by the SIP URI published during
registration time in the Contact.
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=g48sh128
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230@998sdasdh09
CSeq: 101 INVITE
When the UA gets the INVITE, it cannot determine whether it got the
session invitation due to his registration of the business or the
personal ID. Neither the UA, 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 ID 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 home proxy with one or more SIP URIs.
2. The home proxy receives an INVITE destined to a user's ID.
4. The Called Party ID header
The P-Called-Party-ID header field provides the URI the request was
addressed to. This information is intended to be used by subsequent
proxies in the path or by the destination UAS.
Typically, a SIP home 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.
5. P-Called-Party-ID syntax and definition
The P-Called-Party-ID is an extension 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 *(SEMI called-pty-id-param)
called-pty-id-param = generic-param
Network Working Group Expiration 10/30/02 Page 4
Garcia The SIP Called Party ID header April 2002
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.
Addition of P-Called-Party-ID to the Table 2 in SIP [1] and section
4.1 of the SIP-specific event notification [2]:
Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
_____________________________________________________________________
P-Called-Party-ID R amr - - - o o - - o -
6. Usage
6.1 Procedures at the UA
A UAC should not insert a P-Called-Party-ID header field.
A UAS MAY receive a P-Called-Party-ID header field. The header is
populated with the URI that the session was received to.
The UAS may use the information 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 is located in a home network and has authoritative
information about the user, may insert a P-Called-Party-ID header
field in an INVITE or any other standalone request or 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 not allow 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 that contains 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 field.
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.
8. IANA Considerations
Network Working Group Expiration 10/30/02 Page 5
Garcia The SIP Called Party ID header April 2002
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 [4] 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
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 and the 3GPP CN1 WG
members for the 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.
2. A. Roach, SIP-Specific Event Notification, RFC 3265, March 2002.
11.2 Informative references
3. M. Garcia et al, 3GPP requirements on SIP, draft-sipping-garcia-
3gpp-reqs-03.txt, work in progress.
4. 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.
Network Working Group Expiration 10/30/02 Page 6