diff options
Diffstat (limited to 'doc/rfc/rfc5628.txt')
| -rw-r--r-- | doc/rfc/rfc5628.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc5628.txt b/doc/rfc/rfc5628.txt new file mode 100644 index 0000000..58a3061 --- /dev/null +++ b/doc/rfc/rfc5628.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group P. Kyzivat +Request for Comments: 5628 Cisco Systems, Inc. +Category: Standards Track October 2009 + + + Registration Event Package Extension for + Session Initiation Protocol (SIP) + Globally Routable User Agent URIs (GRUUs) + +Abstract + + RFC 3680 defines a Session Initiation Protocol (SIP) event package + for registration state. This package allows a watcher to learn about + information stored by a SIP registrar, including its registered + contact. + + However, the registered contact is frequently unreachable and thus + not useful for watchers. The Globally Routable User Agent URI + (GRUU), defined in RFC 5627, is a URI that is capable of reaching a + particular contact. However this URI is not included in the document + format defined in RFC 3680. This specification defines an extension + to the registration event package to include GRUUs assigned by the + registrar. + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + + + + +Kyzivat Standards Track [Page 1] + +RFC 5628 Reg Event GRUU Extension October 2009 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 4 + 5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 4 + 6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 5 + 6.1. Managing Temporary GRUU Lifetime . . . . . . . . . . . . . 5 + 7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 7 + 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 8.1. Example: Welcome Notice . . . . . . . . . . . . . . . . . 8 + 8.2. Example: Implicit Registration . . . . . . . . . . . . . . 8 + 9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 11 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 12 + 10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 13 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 + + + + + + + + + + + + + + + + + +Kyzivat Standards Track [Page 2] + +RFC 5628 Reg Event GRUU Extension October 2009 + + +1. Introduction + + RFC 3680 [2] defines a Session Initiation Protocol (SIP) [5] event + package for registration state. This package allows a watcher to + learn about information stored by a SIP registrar, including the + registered contacts. + + However, a registered contact is frequently unreachable from hosts + outside of the domain of the User Agent (UA). It is commonly a + private address, or, when it is a public address, access to it may be + blocked by firewalls. + + The Globally Routable User Agent URI (GRUU), defined in RFC 5627 [3], + is a URI that reaches a particular UA instance, but is reachable by + any host on the Internet. GRUUs assigned by the registrar represent + additional registration state. However, GRUUs assigned by the + registrar are not included in the notifications provided by RFC 3680. + For many applications of the registration event package, a GRUU is + needed, and not the registered contact. + + For example, the Welcome Notices example in [2] will only operate + correctly if the contact address in the registration event + notification is reachable by the sender of the welcome notice. When + the registering device is using the GRUU extension, it is likely that + the registered contact address will not be globally addressable, and + a GRUU should be used as the target address for the MESSAGE. + + Another case where this feature may be helpful is within the Third + Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS). + IMS employs a technique where a REGISTER of a contact address to one + Address of Record (AOR) causes the implicit registration of the same + contact to other associated AORs. If GRUUs are requested and + obtained as part of the registration request, then additional GRUUs + will also be needed for the implicit registrations. While assigning + the additional GRUUs is straightforward, informing the registering UA + of them is not. In IMS, UAs typically subscribe to the registration + event, and subscriptions to the registration event for an AOR result + in notifications, each containing the registration state of all the + associated AORs. The proposed extension provides a way to easily + deliver the GRUUs for the associated AORs. + + As specified in RFC 5627 [3], temporary GRUUs are invalidated when + contact address bindings for the corresponding AOR and instance ID + are not refreshed, or when a registration to the AOR and instance ID + is performed with a new Call-ID. A UA cannot always determine with + certainty which temporary GRUUs are valid based solely on the + response to the REGISTER requests it has issued, or from + + + + +Kyzivat Standards Track [Page 3] + +RFC 5628 Reg Event GRUU Extension October 2009 + + + notifications according to RFC 3680 [2]. The extension defined in + this document provides sufficient information for a UA to determine + which temporary GRUUs are valid. + + The registration event package has provisions for including extension + elements within the <contact> element. This document defines new + elements that may be used in that context to deliver the public and + temporary GRUUs 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] + +3. Description + + Two new elements (<pub-gruu> and <temp-gruu>) are defined, each of + which contains a GRUU. The <temp-gruu> element also identifies the + oldest temporary GRUU that is currently valid. + + These optional elements may be included within the body of a NOTIFY + for the registration event package when GRUUs are associated with the + contact. The contact URI and the GRUUs are then all 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 registration event package [2] SHOULD include the + <pub-gruu> element when a contact has an instance ID and a public + GRUU is associated with the combination of the AOR and the instance + ID. When present, the <pub-gruu> element MUST be positioned as a + child of the <contact> element. + + A notifier for the registration event package [2] MAY include the + <temp-gruu> element when a contact has an instance ID and a temporary + GRUU is associated with the combination of the AOR and the instance + ID. This element SHOULD be included if the subscriber is also + authorized to register to the AOR. This element SHOULD NOT be + included if the subscriber is not authorized to register to the AOR, + unless there is an explicitly configured policy directing that it be + included. When present, the <temp-gruu> element MUST be positioned + as a child of the <contact> element. + + + + +Kyzivat Standards Track [Page 4] + +RFC 5628 Reg Event GRUU Extension October 2009 + + + Note that it is possible for multiple registered contacts to share + the same instance ID. In such a case, each <contact> element will + have child <pub-gruu> and <temp-gruu> elements, which are identical + to the corresponding child elements in those other <contact> elements + that share the same instance ID. Since a particular contact cannot + be associated with more than one instance ID, a <contact> element + will never have more than one <pub-gruu> and one <temp-gruu> child + element. + + If the notifier includes the <pub-gruu> element, it MUST populate the + element with the public GRUU that is associated with the instance ID + and AOR of the registered contact. + + If the notifier includes the <temp-gruu> element, it MUST populate + the element with the most recently assigned temporary GRUU that is + associated with the instance ID and AOR of the registered contact. + It MUST also populate the element with a "cseq" attribute + corresponding to the first (oldest) currently active temporary GRUU + that is associated with the instance ID and AOR of the registered + contact. The value of the "cseq" attribute is set to the value of + the CSeq header field of the REGISTER request that caused that first + temporary GRUU to be assigned. + +6. Subscriber Processing of NOTIFY Requests + + When a subscriber receives a registration event notification with a + <contact> containing a <pub-gruu>, it MAY associate the public GRUU + with the corresponding AOR and instance ID. Any previously received + public GRUU for the same AOR and instance ID MUST be discarded. (It + will no longer function.) + + When a subscriber receives a registration event notification with a + <contact> containing a <temp-gruu>, it MAY associate the temporary + GRUU, together with the "callid" and "cseq" attributes, with the + corresponding AOR and instance ID. + + Subscribers that are unaware of this extension will, as required by + [2], ignore the <pub-gruu> and <temp-gruu> elements. + +6.1. Managing Temporary GRUU Lifetime + + Section 4.2 of RFC 5627 [3] gives guidance for developers of UAs on + how to ensure that only valid temporary GRUUs are retained and used + by the UA. A UA cannot always determine with certainty which + temporary GRUUs are valid based solely on the information contained + in responses to the REGISTER requests it has issued or from the + information contained in notifications that conform solely to RFC + 3680 [2]. The extension defined in this document provides sufficient + + + +Kyzivat Standards Track [Page 5] + +RFC 5628 Reg Event GRUU Extension October 2009 + + + added information for a UA to determine which temporary GRUUs are + valid. The extension to RFC 3680 defined in this document provides + added information to help with that process. The following are steps + that the UA MAY take to ensure it only retains valid GRUUs: + + o The UA should subscribe to the registration event package for the + AOR it is registering. + + o When a UA receives a 2xx response to a REGISTER request, it may + extract and retain temporary GRUUs from the response for future + use, as long as they remain valid. Appropriate GRUUs to retain + are those corresponding to the contact address and instance ID it + has registered. (Typically, the UA will register only one contact + address, and so receive at most one temporary GRUU.) + + o The UA may add the temporary GRUU to the set of valid temporary + GRUUs associated with the AOR. (Note, in this case AOR is the + To-address of the REGISTER request.) To aid in tracking validity, + the UA should also associate a "callid" attribute and "cseq" + attribute with the temporary GRUU, with values obtained + respectively from the Call-ID and CSeq values of the REGISTER + response containing the temporary GRUU. + + o If the UA receives a registration event notification with an AOR + (that it supports) and a <contact>, for a contact address and + instance ID (that it has registered and that contains a <temp- + gruu>), it may update its set of valid temporary GRUUs associated + with the AOR, as follows: + + * It may add the temporary GRUU to the set. To aid in tracking + validity, the UA should associate the "callid" and "cseq" + attributes of the <contact> with the GRUU in the set. + + * It should remove any temporary GRUUs with a "callid" attribute + value different from that in the value of the "callid" + attribute of the <contact>, or with a "cseq" attribute with + value less than the value of the "first-cseq" attribute of the + <temp-gruu>. + + o If the UA receives a registration event notification with an AOR + that it supports, and there are no <contact> entries for its + instance ID, then it should discard all the temporary GRUUs it has + saved for that AOR. + + + + + + + + +Kyzivat Standards Track [Page 6] + +RFC 5628 Reg Event GRUU Extension October 2009 + + +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 [7] are used to describe + representation of long message lines. + + The following is an example registration information document that + includes the new element: + + <?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:user@example.com" id="as9" + state="active"> + <contact id="76" state="active" event="registered" + duration-registered="36001" expires="3599" + callid="1j9FpLxk3uxtm8tn@192.0.2.1" cseq="54321" + q="0.8"> + <uri>sip:user@192.0.2.1</uri> + <allOneLine> + <unknown-param name="+sip.instance"> + "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" + </unknown-param> + </allOneLine> + <allOneLine> + <gr:pub-gruu uri="sip:user@example.com + ;gr=hha9s8d-999a"/> + </allOneLine> + <allOneLine> + <gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@example.com + ;gr" first-cseq="54301"/> + </allOneLine> + </contact> + </registration> + </reginfo> + +8. Examples + + Note: In the following examples, the SIP messages have been + simplified, removing headers that are not pertinent to the example. + + When the value of the Content-Length header field is "...", this + means that the value should be the computed length of the body. + + + + + +Kyzivat Standards Track [Page 7] + +RFC 5628 Reg Event GRUU Extension October 2009 + + +8.1. Example: Welcome Notice + + Consider the Welcome Notices example in [2]. When the application + server receives a notification of a new registration containing the + reginfo shown in Section 7, it should address messages using the + contained public GRUU as follows: + + MESSAGE sip:user@example.com;gr=hha9s8d-999a SIP/2.0 + To: <sip:user@example.com> + From: "SIPland Notifier" <sip:notifier@example.com>;tag=7xy8 + Content-Type: text/plain + Content-Length: ... + + Welcome to SIPland! + Blah, blah, blah. + +8.2. Example: Implicit Registration + + In a 3GPP IMS setting, a UA may send a single register message, + requesting assignment of GRUUs, as follows: + + REGISTER sip:example.net SIP/2.0 + From: <sip:user_aor_1@example.net>;tag=5ab4 + To: <sip:user_aor_1@example.net> + Call-ID: faif9a@ua.example.com + CSeq: 23001 REGISTER + Contact: <sip:ua.example.com> + ;expires=3600 + ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" + Supported: path, gruu + Content-Length: 0 + + The response reports success of the registration and returns the + GRUUs assigned for the combination of AOR, instance ID, and Contact. + It also indicates (via the P-Associated-URI header [6]) that there + are two other associated AORs that may have been implicitly + registered using the same contact. Each of those implicitly + registered AORs will have unique GRUUs assigned. The REGISTER + response will not include those GRUUs; it will only include the GRUUs + for the AOR and instance ID explicitly included in the registration. + + SIP/2.0 200 OK + From: <sip:user_aor_1@example.net>;tag=5ab4 + To: <sip:user_aor_1@example.net>;tag=373392 + Call-ID: faif9a@ua.example.com + CSeq: 23001 REGISTER + Path: <sip:proxy.example.net;lr> + Service-Route: <sip:proxy.example.net;lr> + + + +Kyzivat Standards Track [Page 8] + +RFC 5628 Reg Event GRUU Extension October 2009 + + + Contact: <sip:ua.example.com> + ;expires=3600 + ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" + ;pub-gruu="sip:user_aor_1@example.net;gr=hha9s8d-999a" + ;temp-gruu="sip:8ffkas08af7fasklzi9@example.net;gr" + P-Associated-URI: <sip:user_aor_2@example.net>, + <sip:+358504821437@example.net;user=phone> + Content-Length: 0 + + The UA then subscribes to the registration event package as follows: + + SUBSCRIBE sip:user_aor_1@example.net SIP/2.0 + From: <sip:user_aor_1@example.net>;tag=27182 + To: <sip:user_aor_1@example.net> + Call-ID: gbjg0b@ua.example.com + CSeq: 45001 SUBSCRIBE + Route: <sip:proxy.example.net;lr> + Event: reg + Expires: 3600 + Accept: application/reginfo+xml + Contact: <sip:user_aor_1@example.net;gr=hha9s8d-999a> + 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. + + NOTIFY sip:user_aor_1@example.net;gr=hha9s8d-999a SIP/2.0 + From: <sip:user_aor_1@example.net>;tag=27182 + To: <sip:user_aor_1@example.net>;tag=262281 + Call-ID: gbjg0b@ua.example.com + CSeq: 633 NOTIFY + Subscription-State: active;expires=3600 + Event: reg + Content-Type: application/reginfo+xml + Contact: <sip:registrar.example.net> + 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:user_aor_1@example.net" id="a7" + state="active"> + <contact id="92" state="active" event="registered" + duration-registered="1" expires="3599" + + + +Kyzivat Standards Track [Page 9] + +RFC 5628 Reg Event GRUU Extension October 2009 + + + callid="faif9a@ua.example.com" cseq="23001"> + <uri> + sip:ua.example.com + </uri> + <allOneLine> + <unknown-param name="+sip.instance"> + "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" + </unknown-param> + </allOneLine> + <allOneLine> + <gr:pub-gruu uri="sip:user_aor_1@example.net + ;gr=hha9s8d-999a"/> + </allOneLine> + <allOneLine> + <gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@example.net + ;gr" first-cseq="54301"/> + </allOneLine> + </contact> + </registration> + <registration aor="sip:user_aor_2@example.net" id="a8" + state="active"> + <contact id="93" state="active" event="created" + duration-registered="1" expires="3599" + callid="faif9a@ua.example.com" cseq="23001"> + <uri> + sip:ua.example.com + </uri> + <allOneLine> + <unknown-param name="+sip.instance"> + "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" + </unknown-param> + </allOneLine> + <allOneLine> + <gr:pub-gruu uri="sip:user_aor_2@example.net + ;gr=hha9s8d-999b"/> + </allOneLine> + <allOneLine> + <gr:temp-gruu uri="sip:07hcovy36vp6vngvbia@example.net + ;gr" first-cseq="54301"/> + </allOneLine> + </contact> + </registration> + <registration + aor="sip:+358504821437@example.net;user=phone" + id="a9" + state="active"> + <contact id="94" state="active" event="created" + duration-registered="1" expires="3599" + + + +Kyzivat Standards Track [Page 10] + +RFC 5628 Reg Event GRUU Extension October 2009 + + + callid="faif9a@ua.example.com" cseq="23001"> + <uri> + sip:ua.example.com + </uri> + <allOneLine> + <unknown-param name="+sip.instance"> + "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" + </unknown-param> + </allOneLine> + <allOneLine> + <gr:pub-gruu uri="sip:+358504821437@example.net + ;user=phone;gr=hha9s8d-999c"/> + </allOneLine> + <allOneLine> + <gr:temp-gruu uri="sip:h99egjbv17fe8ibvlka@example.net + ;gr" first-cseq="54301"/> + </allOneLine> + </contact> + </registration> + </reginfo> + + The status indicates that the associated URIs all have the same + contact registered. It also includes the unique GRUUs that have been + assigned to each. The UA may then retain those GRUUs for use when + establishing dialogs using the corresponding AORs. + +9. XML Schema Definition + + The <pub-gruu> and <temp-gruu> elements are defined within a new XML + namespace URI. This namespace is "urn:ietf:params:xml:ns:gruuinfo". + The schema for these elements is: + + <?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:complexType name="pubGruu"> + <xs:attribute name="uri" type="xs:anyURI" + use="required"/> + </xs:complexType> + <xs:complexType name="tempGruu"> + <xs:complexContent> + <xs:extension base="tns:pubGruu"> + <xs:attribute name="first-cseq" + type="xs:unsignedLong" + use="required"/> + + + +Kyzivat Standards Track [Page 11] + +RFC 5628 Reg Event GRUU Extension October 2009 + + + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="pub-gruu" type="tns:pubGruu"/> + <xs:element name="temp-gruu" type="tns:tempGruu"/> + </xs:schema> + +10. IANA Considerations + + There are two 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:gruuinfo + + Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>, + Paul Kyzivat <pkyzivat@cisco.com> + + XML: + + 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 GRUU Extension Namespace</title> + </head> + <body> + <h1>Namespace for Reg Information GRUU Extension</h1> + <h2>urn:ietf:params:xml:ns:gruuinfo</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc5628.txt"> + RFC5628</a>.</p> + </body> + </html> + END + + + + + + + + + + +Kyzivat Standards Track [Page 12] + +RFC 5628 Reg Event GRUU Extension October 2009 + + +10.2. XML Schema Registration + + This section registers an XML schema per the procedures in [4]. + + URI: urn:ietf:params:xml:schema:gruuinfo. + + Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>, + Paul Kyzivat <pkyzivat@cisco.com> + + The XML for this schema can be found in Section 9. + +11. Security Considerations + + Security considerations for the registration event package are + discussed in RFC 3680 [2], and those considerations apply here. + + If a contact address obtained via subscription to the registration + event package is not reachable by the subscriber, then its disclosure + may arguably be considered a minimal security risk. In that case, + the inclusion of a GRUU may be considered to increase the risk by + providing a reachable address. On the other hand, requests addressed + to a GRUU are always first processed by the servicing proxy before + they reach the intended User Agent. The proxy may control access as + desired, just as it may for the AOR. For instance, the proxy + servicing a GRUU may accept requests from senders whose identity + appears on a white list, and reject other requests. In this respect, + disclosing a GRUU presents no more risk than disclosing the AOR. + + Temporary GRUUs have an additional security consideration. The + intent of the temporary GRUU is to provide a contact address that + cannot be correlated to the identity of the calling party. The + recipient of a call using a temporary GRUU may guess the identity of + the calling party and then attempt to obtain the temporary GRUUs + assigned to that caller to confirm the conjecture. Two possible + approaches to obtaining the temporary GRUUs are: + + o Send a REGISTER request to a conjectured caller. + + o Send a SUBSCRIBE request for the registration event package to the + conjectured caller. + + Typically, REGISTER is restricted to devices or users that are + authorized to originate and receive calls with the AOR. Anonymity + among users of the same AOR is hard to achieve and typically + unnecessary. It is recommended (see Section 5) that the + authorization policy for the registration event package permit only + those subscribers who are authorized to register to the AOR to + receive temporary GRUUs. With this policy, the confidentiality of + + + +Kyzivat Standards Track [Page 13] + +RFC 5628 Reg Event GRUU Extension October 2009 + + + the temporary GRUU will be the same with and without the registration + event package. User Agents that use a temporary GRUU should note + that confidentiality does not extend to parties that are permitted to + register to the AOR or to obtain the temporary GRUU when subscribing + to the registration event package. + +12. Acknowledgements + + The author would like to thank Jonathan Rosenberg for help with this + document, and Jari Urpalainen for assistance with the XML. + +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] Rosenberg, J., "Obtaining and Using Globally Routable User Agent + (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", RFC + 5627, October 2009. + + [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] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. + Schulzrinne, "Session Initiation Protocol (SIP) Torture Test + Messages", RFC 4475, May 2006. + + + + + + + + + +Kyzivat Standards Track [Page 14] + +RFC 5628 Reg Event GRUU Extension October 2009 + + +Author's Address + + Paul H. Kyzivat + Cisco Systems, Inc. + 1414 Massachusetts Avenue + Boxborough, MA 01719 + USA + + EMail: pkyzivat@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kyzivat Standards Track [Page 15] + |