Subject: [Sip] I-D on implementing GRUU

From: [email-masked]
Date: Tue, 20 Feb 2007 21:21:52 -0500

I've updated an Internet-Draft giving condensed instructions for UA
implementors on how to implement GRUU support.  (This is updated for
version -11 of the GRUU I-D, but it only discusses "public GRUUs",
which is what we need for our environment.)  In our product's
environment (a "true SIP", proxy-based PBX), we've found that to do
call control well, the UAs need to implement (public) GRUU.  This I-D
summarizes what UAs need to do

   Guidelines for Implementing the GRUU Support in User Agents
   draft-worley-sip-gruu-implement-02

   http://www.ietf.org/internet-drafts/draft-worley-sip-gruu-implement-02.txt

   Abstract

   Several applications of the Session Initiation Protocol (SIP) require
   a user agent (UA) to construct and distribute a URI which can be used
   by anyone on the Internet to route a request to that specific UA
   instance.  A URI which routes to a specific UA instance is called a
   Globally Routable UA URI (GRUU).  An Internet-Draft is progressing
   toward standardization that specifies procedures for proxies and UAs
   by which proxies can construct and delver GRUUs to UAs that request
   them.  This document summarizes for UA implementors how to obtain
   "public" GRUUs and gives guidance on effectively using public GRUUs.

Feel free to contact me with any comments.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2007 11:57:31 -0500

Dale,

I'm a bit nervous about this. Two things concern me.

One, if there is stuff that is not clear in GRUU, such that it requires 
clarification in this document, shouldn't we just clarify it in GRUU? If 
so, can you please make those comments directly?

Two, what about things in here that conflict with GRUU?

I'd like to get your thoughts on this.

I also don't understand the purpose of this draft, since you do in fact 
say that you don't plan on advancing it. Can you clarify what its 
purpose is?

Some specific comments, related to these two issues above:

> The feature tag for the GRUU extension is "gruu".
> 
>    Guideline 1:  The UA should add "Supported: gruu" to its requests and
>                  responses, and accept "Require: gruu" in requests.

This is a MUST in GRUU, not a SHOULD as you have here. So we have a 
conflict. The MUST in GRUU is important; its what triggers the server to 
inform the client of its gruu.

>  Guideline 2:  Some UAs implement non-standard mechanisms for handling
>                  URIs that compensate for the fact that heretofore many
>                  contact URIs have not been globally routable.  Since
>                  any URI containing the "gr" parameter is known to be
>                  globally routable, a UA should not apply such
>                  mechanisms to any URI containing the "gr" parameter.

So, here is a piece of advice which is not in gruu. Seems like it could 
be added. I'm not sure about what techniques UA apply to contacts; 
proxies, registrars and B2buas definitely do munge them. Is that what 
you mean?

> Guideline 3:  All GRUUs exist both in the "sip" and the "sips" URI
>                  schemes, and UAs must be capable of processing both
>                  varieties of their GRUUs (to the extent that they are
>                  capable of processing any contact URIs in those
>                  schemes).

well, this is not true anymore in gruu. The whole issue has been 
deferred to the sips-guidelines draft. So I would not want to put this 
into the core gruu document.

> Guideline 4:  Each UA instance has an "instance ID" which is globally
>                  unique through all space and time.  An instance ID
>                  persists through all ordinary operations, especially
>                  restarting and changes in network connectivity.  An
>                  instance ID is a URN [2].

all of this is said in sip-outbound.

> URNs can be created and assigned by many mechanisms.  For a network
>    host that is a dedicated UA ("SIP phone"), it is recommended that it
>    uses "version 1" of the UUID URN [3] (which contains the UA's MAC
>    address) as an instance ID.  Because the UA's instance ID is sent in
>    its REGISTER requests, it makes it possible for the proxy to
>    correlate the UA's contact URI with its MAC address, which in many
>    environments is used as the UA's identifier for configuration and
> 
> 
> 
> Worley                   Expires August 23, 2007                [Page 7]
> 
> Internet-Draft         Guidelines for GRUU Support         February 2007
> 
> 
>    provisioning.

this is reasonable, but NOT specified in sip-outbound. It you want this 
behavior, it should go there.

>  Guideline 6:  UAs that are not embodied in dedicated UA devices must
>                  generate their instance IDs in a manner that guarantees
>                  global uniqueness.  (E.g., a more complex use of
>                  Version 1 UUIDs, a name-based UUID derived from a
>                  suitable identification string, or an object-id
>                  assigned administratively [4].)  The "tel" namespace
>                  and similar namespaces should not be used, as
>                  conceptually they are AORs, not unique identifiers for
>                  swarms of user agents.
> 
>    Guideline 7:  As other SIP agents may use the instance ID and/or GRUU
>                  as a key to cache information about the UA and its
>                  capabilities, it is recommended that when a new version
>                  of software is installed into the UA, the UA should
>                  obtain a new instance ID.
>  Guideline 8:  The UA should always use the same character string to
>                  represent its instance ID (e.g., normalizing the case
>                  of letters), even if the URN scheme permits several
>                  different character strings to represent the same URN.

these all would belong in sip-outbound. They are not there now.

> Guideline 9:  A UA requests a GRUU for its instance ID and a
>                  particular AOR by extending its ordinary REGISTER
>                  requests for that AOR by: (1) adding a "Supported:
>                  gruu" header, and (2) adding an "instance" media
>                  feature tag to the Contact giving the UA's instance ID
>                  as its value.  If the registrar understands the GRUU
>                  extension, it may (but is not guaranteed to): (3)
>                  append to the returned Contact the same "instance"
>                  media feature tag and/or a "pub-gruu" field parameter
>                  giving the assigned GRUU.

this is all in GRUU-11 already. Is there something in GRUU-11 that you 
think needs to be clarified on this point?

>  the syntax of the "instance" tag is a field parameter
>    '+sip.instance="<{instance ID URN}>"'.  As '<' cannot appear in a
>    "token" [6], the value of the '+sip.instance' parameter must be
>    quoted with '"'.  The instance ID value itself must be contained
>    between '<' and '>' due to the rules of [5].  In addition, due to the
>    syntax of "quoted-string" in [6] and "qdtext-no-abkt" in [5], any
>    occurrence of '"', '<', '>', or '\' in the instance ID must be quoted
>    by preceding it with '\'.  Using '\' to quote other characters, while
>    allowed by [6], should be avoided to ensure unique representation of
>    instance IDs.

Most but not all of this is in sip-outbound. The stuff about escaping is 
not. Again if you think this is unclear, it should go in sip-outbound.

>  Guideline 10:  The UA should not attempt to recommend a GRUU to the
>                   registrar (by providing a "gr", "pub-gruu", or "temp-
>                   gruu" field parameter on the Contact header in the
>                   request).

already in gruu-11, and clear I think.

>  Guideline 11:  The GRUU should be treated opaquely by the UA.

this is not in gruu-11. I can add that.

> Guideline 12:  If a REGISTER returns a new GRUU for an AOR/instance
>                   ID combination, the UA must use the new GRUU.

this is in GRUU-11 and clear I think.

>   Guideline 13:  The UA should register distinct contact URIs for each
>                   AOR it services, so that incoming request-URIs
>                   uniquely identify the AOR through which the request
>                   was routed.  Note that it is not a sufficient policy
>                   to generate from each AOR a contact 'sips:{user-part}@
>                   {IP-address}', since it is common for a UA to service
>                   two AORs with the same user part but different host
>                   parts.  One common method to construct multiple
>                   contact addresses is to use the "line" URI-parameter
>                   to apply a unique value to what would otherwise be
>                   identical contact URIs.

this is NOT in gruu-11. It could be added there. The 'line' URI 
parameter is not something defined currently. I suspect this is a 
proprietary parameter you use in your implementation. BLISS is probably 
the right place to discuss the problems motivating it.

> Guideline 14:  When making an out-of-dialog request, the UA should
>                   use as Contact the GRUU corresponding to the AOR that
>                   it places in the To header.
> 
>    Guideline 15:  When responding to an out-of-dialog request, the UA
>                   should determine, based on the request-URI, the AOR
>                   through which the request was routed, and use as
>                   Contact the GRUU corresponding to that AOR.

both of these are in gruu already.

>   Guideline 16:  If a Contact value is a GRUU, target refresh requests
>                   will not change it, because the routing changes that
>                   would be otherwise be effected by modifying the target
>                   URI are effected by the proxy modifying how it routes
>                   requests addressed to the GRUU. [1] [7]

Maybe, maybe not. This guideline is dangerous, since it seems to tell 
implementors that they can ignore the contact in target refresh requests 
if the original one was a gruu. That is not true.

>  Guideline 18:  Since GRUUs are publicly visible, any screening of
>                   unwanted communications which is applied to an AOR
>                   must be applied to its GRUUs.  In addition, since an
>                   AOR's forking may be used to implicitly screen
>                   requests for one of its targets, it may be desirable
>                   to apply additional screening for requests to a GRUU
>                   for such an AOR.

this is mostly covered in gruu, but I don't understand the bit about 
forking.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Feb 2007 13:44:51 -0500

> proxies, registrars and B2buas definitely do munge them. Is that what 

Some things that might be different:

- sending in-dialog REFER vs out-of-dialog

- using the To-URI rather than the Contact for things like Refer-To

	Paul