Sipping J. Arauz
Internet-Draft Ericsson
Intended status: Standards Track June 20, 2007
Expires: December 22, 2007
Registration Event Package Extension for IP Multimedia Subsystem (IMS)
Grouping of Addresses of Record (AoR)
draft-jarauz-sipping-grouping-reg-event-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on December 22, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This draft defines an extension to RFC 3680 [2] for representing the
grouping of AoRs associated with a user in registration event
notifications.
Arauz Expires December 22, 2007 [Page 1]
Internet-Draft Reg Event Grouping Extension June 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 5
5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 5
6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 6
7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 7
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Example: Implicit Registration . . . . . . . . . . . . . . 8
9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 11
10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Arauz Expires December 22, 2007 [Page 2]
Internet-Draft Reg Event Grouping Extension June 2007
1. Introduction
In IMS a user may own more than one AoR. All the AoRs owned by a
user are conceptually linked in a so-called User Profile. A user is
free to use any of the AoRs he/she owns as the originating party
identity when initiating traffic procedures, and other users may use
any of those AoRs to contact the user.
One of the leif motives of IMS is to support the provision of
network-based value-added services to its users. In order to achieve
this a service architecture and corresponding data model are defined.
A user may be provided with one or more so-called Service Profiles,
which are data structures containing information related to the
services enjoyed by that user. For instance, one of the most
relevant pieces of information stored in a Service Profile are the
patterns that determine when the user's home proxy must select an
Application Server (AS) as the next hop proxy for a SIP request.
Service Profiles are further categorized into Individual Service
Profiles and Shared Service Profiles. An Individual Service Profile
applies to one and only one of the AoRs owned by a given user. On
the contrary, a Shared Service Profile applies to two or more of the
AoRs owned by that user. Shared Service Profiles are useful when the
AoRs to which they are associated represent aliases for each other.
For example a user owning both a business AoR
(sip:robert@example.com) and a private AoR (sip:bob@example.net) will
probably have different Service Profiles associated to each of those
identities. The Service Profile for the business identity might
determine that sessions from/to that identity pass through the
company's virtual PBX AS while the Service Profile for the private
identity might instead determine that sessions to/from that identity
pass through the ISP's spam filter AS. But when the user owns
several AoRs that are aliases for each other
(sip:robert.sales@example.com and sip:robert.support@example.com) the
services afforded to those identities will be the same and thus it is
useful that the Service Profile describing those services is shared
between the alias identities.
Therefore in IMS it is possible to assign a Shared Service Profile to
multiple AoRs of a user in the IMS users database, the Home
Subscriber Server (HSS). The set of AoRs associated with the same
Shared Service Profile are known as a Grouped Identities Set. A user
may own multiple Grouped Identities Sets and it is commonly
understood that the AoRs within a Grouped Identities Set are aliases
to each other.
It is foreseen that network nodes that are not the user's home proxy
will need to know about the Grouped Identities Sets owned by a user.
Arauz Expires December 22, 2007 [Page 3]
Internet-Draft Reg Event Grouping Extension June 2007
One of these nodes is the first hop proxy that connects a UA to the
IMS network, the Proxy Call Signalling Control Function (P-CSCF).
The P-CSCF acts as a Policy Enforcing Point (PEP) for network access.
It would make sense that the same policies are applied to alias AoRs
so it would be interesting for the Policy Decision Point (PDP) to
know about the Grouped Identities Sets of a user in order to apply
the same policies to all the identities in the same set.
To allow the P-CSCF to know about the Grouped Identities Sets of a
user an extension to the reg-event package is proposed that describes
these sets. Once a user registers any of the AoRs he/she owns the
P-CSCF by virtue of its subscription to the reg-event package
receives the identities that have been actually registered, including
information about the Grouped Identities Set each AoR belongs to.
A UA may also need to know about which identities are alias to each
other. One case would be when different groups of alias identities
receive different charging rates. A subscriber is charged
differently depending on the AoR the user chooses for the
communication so the user should know about those groups to decide
which AoR to use at each moment. Another case would be when a user
has bound an AoR to a certain application (e.g. a work AoR is bound
to the Enterprise Communicator application while a personal AoR is
bound to the normal multi-media phone application). When an incoming
request is recieved at the UA for an AoR not explicitly bound by the
user, the expected behavior at the UA would be that the right
application is started and thus the UA needs to know the alias group
to which the implicitly-bound AoR belongs.
The extension described in this document can also be useful outside
the context of the IMS. &F;or instance, in the open Internet a UA
might implement a call barring service. When a user sets up a call
barring service usually he/she is trying to bar users, not
identities. The extension proposed in this document would allow a UA
to know about the alias identities of barred users, so that by
barring one of the identities the UA automatically bars any other
alias identities within the same group as the former.
The reg event package has provision for including extension elements
within the <registration> element. This document defines a new
element that may be used in that context to deliver the membership
status of each AoR to each Grouped Identities Set defined for the
user.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Arauz Expires December 22, 2007 [Page 4]
Internet-Draft Reg Event Grouping Extension June 2007
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]
[1].
3. Description
A new element (<gr-id-set>) is defined which describes a Grouped
Identities Set.
This optional element is included within the body of a NOTIFY for the
"reg" event package when one or more Grouped Identities Sets are
defined amongst the AoRs included in the NOTIFY. As many <gr-id-set>
elements as Grouped Identities Sets are defined for the set of AoRs
included in the NOTIFY are included by the notifier. In this way
both the AoR URI and the Grouped Identities Set it belongs to are
then available to the watcher (e.g. the P-CSCF).
The definition of a Grouped Identity Set is as follows: "the set of
AoRs that are alias to each other". This definition rules out
redundant sets (i.e. sets that span exactly the same AoRs) and
subsets (i.e. sets that span some AoRs from within those that are
part of a larger set), since as per the definition above they are
indeed the same set.
Also notice that the definition above has the transitive property, so
that if B is alias to A and C is alias to B then C is alias to A.
This means that any two sets that share at least one AoR are actually
a single set that spans the sum of the AoRs in the former sets.
A corollary to the above paragraphs is therefore that at any given
moment every AoR may belong to one and only one Grouped Identities
Set.
4. Notifier Processing of SUBSCRIBE Requests
Unchanged from RFC 3680 [RFC3680] [2].
5. Notifier Generation of NOTIFY Requests
A notifier for the "reg" event package [2] SHOULD include the <gr-id-
set> element when one or more Grouped Identities Sets are defined
amongst the AoR(s) included in the reg-event body of the NOTIFY.
When present, the <gr-id-set> element MUST be be positioned as an
instance of the <any> XSD element within the <registration> element.
Arauz Expires December 22, 2007 [Page 5]
Internet-Draft Reg Event Grouping Extension June 2007
If a notifier includes <gr-id-set> elements in event notifications,
for each AoR that belongs to a Grouped Identities Set the notifier
MUST include within the <registration> element which 'aor' attribute
value matches said AoR one and only one <gr-id-set> element.
For any two AoRs belonging to the same Grouped Identities Set, the
<gr-id-set> elements within their respective <registration> elements
MUST contain exactly the same text, with the only exception of
leading and trailing white spaces, tab and CR/LF characters.
For any two AoRs belonging to different Grouped Identities Sets, the
<gr-id-set> elements within their respective <registration> elements
MUST contain different text after discarding leading and trailing
white spaces, tab and CR/LF characters.
Note that the conditions in the two paragraphs above mutually exclude
each other, i.e. any two AoRs cannot simultaneously belong to the
same set and to different sets (since by the transitive property of
Grouped Identities Sets those different sets are actually one single
set).
6. Subscriber Processing of NOTIFY Requests
When a subscriber receives a "reg" event notification [2] with
<registration> element(s) containing one <gr-id-set> element, it MAY
compare the text within the respective <gr-id-set> elements after
discarding leading and trailing white spaces, tab and CR/LF
characters.
Any AoRs whose respective <registration> elements contain a <gr-id-
set> element with exactly the same text MUST be associated to the
same Grouped Identities Set by the subscriber. Any AoRs whose
respective <registration> elements contain a <gr-id-set> element with
different texts MUST be associated to different Grouped Identities
Sets by the subscriber. An AoR which <registration> element does not
contain any <gr-id-set> element is either not associated to any
Grouped Identities set by the subscriber, or associated to a singular
Grouped Identities Set that spans only that AoR.
The subscriber MAY use the information about the Grouped Identities
Sets as it sees fit. The identities within a given Grouped
Identities Set MUST be considered aliases for each other by the
subscriber and thus the subscriber can use them indistinctly when no
indication otherwise exists.
Subscribers that are unaware of this extension will, as required by
[2], ignore the <gr-id-set> element.
Arauz Expires December 22, 2007 [Page 6]
Internet-Draft Reg Event Grouping Extension June 2007
7. Sample reginfo Document
Note: This example and others in the following section are indented
for readability by the addition of a fixed amount of whitespace to
the beginning of each line. This whitespace is not part of the
example. The conventions of [8] are used to describe representation
of long message lines.
The following is an example registration information document
including the new element:
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:alias="urn:3gpp:params:xml:ns:aliasinfo"
version="0" state="full">
<registration aor="sip:alice@example.com" id="x2w"
state="active">
<contact id="15" state="active" event="registered"
duration-registered="256 q="0.8">
<uri>sip:user@192.0.2.1</uri>
</contact>
<alias:gr-id-set>1</alias:gr-id-set>
<alias:gr-id-set>2</alias:gr-id-set>
</registration>
<registration aor="tel:+34128256512" id="yz2"
state="active">
<contact id="15" state="active" event="registered"
duration-registered="256 q="0.8">
<uri>sip:user@192.0.2.1</uri>
</contact>
<alias:gr-id-set>1</alias:gr-id-set>
</registration>
<registration aor="sip:alice@example.net" id="33d"
state="active">
<contact id="15" state="active" event="registered"
duration-registered="256 q="0.8">
<uri>sip:user@192.0.2.1</uri>
</contact>
<alias:gr-id-set>2</alias:gr-id-set>
</registration>
</reginfo>
8. Examples
Note: In the following examples the SIP messages have been
simplified, removing headers that are not pertinent to the example.
Arauz Expires December 22, 2007 [Page 7]
Internet-Draft Reg Event Grouping Extension June 2007
8.1. Example: Implicit Registration
In an IMS network, a UA may send a single register message,
requesting registration of an AoR. The IMS network may actually
register other AoRs, in addition to the one conveyed in the
registration request (this is known as implicit registration in IMS,
and the set of AoRs that are actually registered is known as Implicit
Registration Set, IRS). All the other AoRs the registrar knows
belong to the same IRS as the AoR being requested by the UA get
registered together with that AoR, as follows:
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds7
From: <sip:alice@example.com>;tag=3n8cf
To: <sip:alice@example.com>
Contact: <sip:user@192.0.2.1>;expires=3600
Route: <sip:pcscf.foreign.net;lr>
Path: <sip:pcscf.foreign.net;lr>
Require: path
Content-Length: 0
The UE routes the request through the first hop proxy it knows it
must use to access the IMS, in this case pcscf@foreign.net.
The response reports success of the registration and returns the
contact(s) assigned for the explicitly registered AoR. It also
indicates (via the P-Associated-URI header [6]) that there are other
associated AoRs that may have been implicitly registered using the
same contact. But each of those implicitly registered AoRs may
belong to the same or different Grouped Identities Sets as the
explicitly registered AoR:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds7
From: <sip:alice@example.com>;tag=3n8cf
To: <sip:alice@example.com>;tag=fj3894f
Supported: path
Service-Route: <sip:scscf1.example.com;lr>
Contact: <sip:user@192.0.2.1>;expires=3600
P-Associated-URI: <sip:little_alice@example.com>,
<tel:+341234567890>
Content-Length: 0
The UA then subscribes to the 'reg' event package as follows:
Arauz Expires December 22, 2007 [Page 8]
Internet-Draft Reg Event Grouping Extension June 2007
SUBSCRIBE sip:alice@example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds8
From: <sip:alice@example.com>;tag=fj34890c
To: <sip:alice@example.com>
Route: <sip:pcscf.foreign.net;lr>
Route: <sip:scscf1.example.com;lr>
Event: reg
Expires: 3600
Accept: application/reginfo+xml
Contact: <sip:user@192.0.2.1>
Content-Length: 0
(The successful response to the subscription is not shown.) Once the
subscription is established an initial notification is sent giving
registration status. In IMS deployments the response includes, in
addition to the status for the requested URI, the status for the
other associated URIs.
Arauz Expires December 22, 2007 [Page 9]
Internet-Draft Reg Event Grouping Extension June 2007
NOTIFY sip:user@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds8
Via: SIP/2.0/UDP pcscf.foreign.net;branch=z9hG4bKnashdq4
Via: SIP/2.0/UDP scscf1.example.com;branch=z9hG4bKnashdr2
From: <sip:alice@example.com>;tag=fj34890c
To: <sip:alice@example.com>;tag=j23902
Subscription-State: active;expires=3600
Event: reg
Content-Type: application/reginfo+xml
Contact: <sip:scscf1.example.com>
Content-Length: (...)
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:alias="urn:3gpp:params:xml:ns:reginfo"
version="1" state="full">
<registration aor="sip:alice@example.com" id="x2y"
state="active">
<contact id="15" state="active" event="registered"
duration-registered="1" expires="512">
<uri>sip:user@192.0.2.1</uri>
</contact>
<alias:gr-id-set>1</alias:gr-id-set>
</registration>
<registration aor="sip:little_alice@example.com" id="x2z"
state="active">
<contact id="16" state="active" event="created"
duration-registered="1" expires="512">
<uri>sip:user@192.0.2.1</uri>
</contact>
<alias:gr-id-set>2</alias:gr-id-set>
</registration>
<registration aor="tel:+341234567890" id="x2x"
state="active">
<contact id="17" state="active" event="created"
duration-registered="1" expires="512">
<uri>sip:user@192.0.2.1</uri>
</contact>
<alias:gr-id-set>1</alias:gr-id-set>
</registration>
</reginfo>
The status indicates that the associated AoRs all have the same
contact registered. It also includes the Grouped Identities Sets to
whose each AoR belong. The UA may then retain those sets for use
them when the subscriber needs them.
Arauz Expires December 22, 2007 [Page 10]
Internet-Draft Reg Event Grouping Extension June 2007
9. XML Schema Definition
A Grouped Identities Set document is an XML document that MUST be
well-formed and SHOULD be valid. TRUU documents MUST be based on XML
1.0 and MUST be encoded using UTF-8. This specification makes use of
XML namespaces for identifying TRUU documents. The namespace URI for
elements defined for this purpose is a URN, using the namespace
identifier 'ietf'. This URN is:
urn:ietf:params:xml:ns:aliasinfo
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:3gpp:params:xml:ns:reginfo"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:3gpp:params:xml:ns:reginfo">
<xs:element name="gr-id-set" type="xs:Integer"/>
</xs:schema>
END
10. IANA Considerations
There are no IANA considerations associated with this specification.
10.1. URN Sub-Namespace Registration
This section registers a new XML namespace, per the guidelines in
[4].
URI: The URI for this namespace is urn:ietf:params:xml:ns:aliasinfo
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Javier Arauz <jesus.javier.arauz@ericsson.com>
XML:
Arauz Expires December 22, 2007 [Page 11]
Internet-Draft Reg Event Grouping Extension June 2007
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Reg Information Alias Extension Namespace</title>
</head>
<body>
<h1>Namespace for Reg Information Alias Extension</h1>
<h2>urn:ietf:params:xml:ns:aliasinfo</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX [[NOTE
TO RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of
this specification]]</a>.</p>
</body>
</html>
END
10.2. XML Schema Registration
This section registers an XML schema per the procedures in [4].
URI: urn:ietf:params:xml:schema:aliasinfo.
The XML for this schema can be found in Section 9.
11. Security Considerations
Security considerations for the registration event package is
discussed in RFC 3680 [2], and those considerations apply here.
The addition of Grouped Identity Sets information to the registration
event package provides a way for a subscriber to that package to find
out the alias relationship between those AoRs belonging to the same
set. Since the network behavior is exactly the same for any AoR
within the same group, revealing those relationships should not raise
any security/privacy concern, since using an alias AoR does not open
any new possibilities to parties using the alias AoR instead of the
AoR they already know.
12. Acknowledgements
This work is heavily based on a similar one carried out by Paul E.
Kyzivat in relation to GRUU[9].
Arauz Expires December 22, 2007 [Page 12]
Internet-Draft Reg Event Grouping Extension June 2007
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
13.2. Informative References
[I-D.ietf-sipping-torture-tests]
Sparks, R., "Session Initiation Protocol Torture Test
Messages", draft-ietf-sipping-torture-tests-09 (work in
progress), November 2005.
Author's Address
Javier Arauz
Ericsson
Via de los Poblados 13
Madrid, Madrid 28033
SP
Phone: +34 91 339 2997
Email: jesus.javier.arauz@ericsson.com
Arauz Expires December 22, 2007 [Page 13]
Internet-Draft Reg Event Grouping Extension June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Arauz Expires December 22, 2007 [Page 14]