Internet DRAFT - draft-jarauz-sipping-truu-reg-event
draft-jarauz-sipping-truu-reg-event
Sipping J. Arauz
Internet-Draft Ericsson
Expires: November 21, 2006 May 19, 2006
Registration Event Package Extension for Session Initiation Protocol
(SIP) Temporarily Routeable User Agent URIs (TRUUs)
draft-jarauz-sipping-truu-reg-event-00
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 November 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This draft defines an extension to RFC 3680 [2] for representing the
TRUU(s) associated with registered contact addresses in registration
event notifications.
Arauz Expires November 21, 2006 [Page 1]
Internet-Draft Reg Event TRUU Extension May 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 3
5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 3
6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 3
7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 3
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Example: Implicit Registration . . . . . . . . . . . . . . 4
9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
13.1. Normative References . . . . . . . . . . . . . . . . . . . 9
13.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Arauz Expires November 21, 2006 [Page 2]
Internet-Draft Reg Event TRUU Extension May 2006
1. Introduction
The addition of TRUU (Temporarily Routable User-agent URI) support to
the REGISTER transaction, defined in [3], introduces yet another
element of state in the registrar. Subscribers to the registration
event package [2] may need to have knowledge of the new state in
certain situations.
The most relevant amongst these situations is the IP Multi-media
Subsystem (IMS). In IMS a User Agent (UA) is forced to access
the SIP network through a single SIP proxy, and it must use the same
proxy as long as it is registered. An IMS user may have several AoRs,
e.g. one for friends and another one for business. When the IMS user
registers her UA in the IMS using one of her AoRs, all the other AoRs associated to that user get implicitly registered as well.
If a TRUU is requested and obtained for the explicitly registered AoR
as part of the registration transaction, then additional TRUUs will
also be needed for the implicitly registered AoRs. While assigning
the additional TRUUs is straightforward, informing the registering UA
of them is not. Moreover, the SIP proxy used by the registering UA
to access the IMS must also be aware of the TRUUs associated to the
registered AoRs since when a SIP request issued by a UA does include
a TRUU as the only identification of the requesting user, since the
proxy must add to the request the AoR to which the TRUU is associated
to allow identity verification and charging within the IMS.
In IMS, both the UAs and the SIP proxies used to access the IMS must
subscribe to the 'reg' event, and subscriptions to the 'reg' event
for an AoR result in notifications containing registration state for
all the associated AoRs. The proposed extension provides a way to
easily deliver the TRUUs associated to the AoRs to both the UE and
the SIP proxy.
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 TRUU
corresponding to the contact.
2. Terminology
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]
Arauz Expires November 21, 2006 [Page 3]
Internet-Draft Reg Event TRUU Extension May 2006
3. Description
A new element (<truu>) is defined which contains a TRUU.
This optional element is included within the body of a NOTIFY for the
"reg" event package when a TRUU is associated with the AoR. As many
<truu> elements as TRUUs are associated to the AoR are included by
the notifier. In this way both the AoR URI and its associated TRUU(s)
are then available to the watcher.
4. Notifier Processing of SUBSCRIBE Requests
Unchanged from RFC 3680 [2].
5. Notifier Generation of NOTIFY Requests
A notifier for the "reg" event package [2] SHOULD include the <truu>
element when a TRUU is associated with that AoR. As many <truu>
elements as TRUUs are associated to the AoR SHOULD be included by the
notifier. When present, the <truu> element MUST be be positioned as
an instance of the <any> element within the <registration> element.
6. Subscriber Processing of NOTIFY Requests
When a subscriber receives a "reg" event notification [2] with a
<registration> containing a <truu>, it MAY use the TRUU instead of the
corresponding <uri> when sending SIP requests to the contact.
Subscribers that are unaware of this extension will, as required by
[2], ignore the <truu> element.
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:
Arauz Expires November 21, 2006 [Page 4]
Internet-Draft Reg Event TRUU Extension May 2006
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"
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>
<unknown-param name="trid">1</unknown-param>
<unknown-param name="truu-expires">300</unknown-param>
</contact>
<allOneLine>
<gr:truu>sip:fsj5y8gh94vn4@example.com
;trid=1;truu-expires=100</gr:truu>
</allOneLine>
<allOneLine>
<gr:truu>sip:4895unifr8932@example.com
;trid=1;truu-expires=300</gr:truu>
</allOneLine>
</registration>
</reginfo>
8. Examples
Note: In the following examples the SIP messages have been
simplified, removing headers that are not pertinent to the example.
8.1. Example: Implicit Registration
In an IMS network, a UA may send a single register message,
requesting assignment of a TRUU, 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:wonderland.foreign.net>;expires=3600;trid=1
Route: <sip:pcscf.foreign.net;lr>
Path: <sip:pcscf.foreign.net;lr>
Require: path
Proxy-Require: truu
Content-Length: 0
The UE routes the request through the SIP proxy it knows it must use
to access the IMS, in this case pcscf@foreign.net.
Arauz Expires November 21, 2006 [Page 5]
Internet-Draft Reg Event TRUU Extension May 2006
The response reports success of the registration and returns the
TRUU(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
will have one or more unique TRUU(s) assigned, and there is no way
defined to report that assignment in the response.
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
Require: truu
Service-Route: <sip:scscf1.example.com;lr>
Contact: <sip:wonderland.foreign.net>;expires=3600;trid=1
P-Associated-URI: <sip:little_alice@example.com>,
<tel:+341234567890>
Indirect-Contact: <sip:348gh3x3k0e@example.com>
;trid=1;truu-expires=300
Content-Length: 0
The UA then subscribes to the 'reg' event package as follows:
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:wonderland.foreign.net>
Content-Length: 0
(The successful response to the subscription is not shown.) Once the
Arauz Expires November 21, 2006 [Page 6]
Internet-Draft Reg Event TRUU Extension May 2006
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.
NOTIFY sip:wonderland.foreign.net 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:gr="urn:ietf:params:xml:ns:gruuinfo"
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:wonderland.foreign.net</uri>
<unknown-param name="trid">1</unknown-param>
<unknown-param name="truu-expires">300</unknown-param>
</contact>
<allOneLine>
<gr:truu>sip:fsj5y8gh94vn4@example.com
;trid=1;truu-expires=100</gr:truu>
</allOneLine>
<allOneLine>
<gr:truu>sip:4895unifr8932@example.com
;trid=1;truu-expires=300</gr:truu>
</allOneLine>
</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:wonderland.foreign.net</uri>
Arauz Expires November 21, 2006 [Page 7]
Internet-Draft Reg Event TRUU Extension May 2006
</contact>
<allOneLine>
<gr:truu>sip:pefpqwhjiasdjl@example.com
;truu-expires=300</gr:truu>
</allOneLine>
</registration>
<registration aor="tel:+341234567890" id="x2x"
state="active">
<contact id="17" state="active" event="created"
duration-registered="1" expires="512">
<uri>sip:wonderland.foreign.net</uri>
</contact>
<allOneLine>
<gr:truu>sip:hcfnfiawlcadhvf@example.com
;truu-expires=300</gr:truu>
</allOneLine>
</registration>
</reginfo>
The status indicates that the associated AoRs all have the same
contact registered. It also includes the TRUUs that have been
assigned to each AoR. The UA may then retain those TRUUs for use
them when establishing dialogs instead of the corresponding AoRs.
Notice how the explicitly registered AoR (sip:alice@example.com)
does have two simultaneously active TRUUs. One of them will be valid
during 100 seconds more only, while the other one will be valid
during 300 seconds. This is because the UA has requested a new TRUU
while a previously assigned one has not expired yet, hence the
differences in life times.
9. XML Schema Definition
A TRUU 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:gruuinfo
Arauz Expires November 21, 2006 [Page 8]
Internet-Draft Reg Event TRUU Extension May 2006
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:gruuinfo"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:gruuinfo">
<xs:element name="truu" type="xs:anyURI"/>
</xs:schema>
END
10. IANA Considerations
There are no IANA considerations associated with this specification.
11. Security Considerations
Security considerations for the registration event package is
discussed in RFC 3680 [2], and those considerations apply here.
The addition of TRUU information to the registration event package provides a way for a subscriber to that package to find out the
relationship between a TRUU and its associated contact address.
The relationship between a contact address and an AoR is already part
of the package so combining both relationships a subscriber has a way
to find out also the AoR to which a TRUU is associated.
Since the main motivation of TRUU is to provide privacy and disallow
direct contact, the ability to discover the TRUU<->contact<->AoR
associations defeats the purpose of TRUU. Therefore access to the
registration event information MUST be restricted to trusted parties.
Access MAY be allowed to non-trusted parties but in that case the
TRUU information MUST be filtered out from the event information.
12. Acknowledgements
This work is heavily based on a similar one carried out by Paul E.
Kyzivat in relation to GRUU[9].
Arauz Expires November 21, 2006 [Page 9]
Internet-Draft Reg Event TRUU Extension May 2006
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[3] Van Bemmel, J., "Obtaining and Using Temporarily Routable User
Agent (UA) URIs (TRUU) in the Session Initiation Protocol
(SIP)",
draft-jbemmel-sip-truu-02 (work in progress), April 2006.
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
13.2. Informative References
[5] 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.
[6] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header
(P-Header) Extensions to the Session Initiation Protocol (SIP)
for the 3rd-Generation Partnership Project (3GPP)", RFC 3455,
January 2003.
[7] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
RFC 3840, August 2004.
[8] Sparks, R., "Session Initiation Protocol Torture Test Messages",
draft-ietf-sipping-torture-tests-09 (work in progress),
November 2005.
[9] Kyzivat, P., "Registration Event Package Extension for Session
Initiation Protocol (SIP) Globablly Routeable User Agent URIs
(GRUUs)", draft-ietf-sipping-gruu-reg-event-04 (work in
progress), April 2006
Arauz Expires November 21, 2006 [Page 10]
Internet-Draft Reg Event TRUU Extension May 2006
Author's Address
Javier Arauz
Ericsson
Via de los Poblados 13
Madrid 28033
SPAIN
Email: jesus.javier.arauz@ericsson.com
Arauz Expires November 21, 2006 [Page 11]
Internet-Draft Reg Event TRUU Extension May 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Arauz Expires November 21, 2006 [Page 12]
Internet-Draft Reg Event TRUU Extension May 2006
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arauz Expires November 21, 2006 [Page 13]
