Subject: [Sip] Comments on gruu-11

From: "Elwell, John" <[email-masked]>
Date: Mon, 06 Nov 2006 17:02:02 +0000

Jonathan,

Major comment:

Section 3.2: "Only when the contact expires, either through explicit
de-registration or timeout, will all of the temporary GRUUs be invalidated."
So how many temporary GRUUs does the domain proxy need to remember? If a UA
remains registered for a year, say, and refreshes its registration every
hour, say, that is a lot of storage.

Minor comments / nits:

Section 2: "remote target: The term "remote target" refers to a URI that a
user agent uses to identify itself for receipt of both mid-dialog and
out-of-dialog requests." This doesn't seem to be consistent with RFC 3261,
where a remote target doesn't identify the UA itself, but a remote UA.

Section 3: "GRUUs are issued by SIP domains and always route back to a proxy
in that domain." This is not always true now that UAs can provide their own
URIs with GRUU properties, as described in 3.2.

Section 3.4 on dereferencing a GRUU: "Because a GRUU is simply a URI, a UA
dereferences it in exactly the same way as it would any other URI.  However,
once the request has been routed to the appropriate proxy, the behavior is
slightly different...." A UA-assigned GRUU will be an exception to the
procedures in this paragraph.

Section 4.1 on generating a REGISTER request: 'Each such Contact header
field SHOULD NOT contain a "pub-gruu" or "temp-gruu" header field.' Change
"header field" to "header field parameter" or just "parameter".

Section 6.1 on request targeting: "If there are no registered contacts bound
to the GRUU, the server MUST return a 480." I believe this can apply only to
public GRUUs, since temporary GRUUs disappear when registration ceases, so
the proxy has no way of knowing whether this was previously a valid
temporary GRUU. Hence I would have expected a 404 rather than a 480
response. I think some clarification in the area might be beneficial.

Section 6.1 "In many cases, the new request is related to an existing
dialog, and may be an attempt to join it (using the Join header field [23])
or replace it (using the Replaces header field [24])." The request could
also relate to an existing dialog by means of RFC 4538.

John

_______________________________________________
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: Mon, 06 Nov 2006 13:24:55 -0500

One immediate response:

> hour, say, that is a lot of storage.

If you choose to implement this by literally storing GRUU, then yes, its 
a ton. But you wouldn't do that. It is far easier to implement this by 
constructing them algorithmically. This can be done with no additional 
storage (there is an algorithm in the annex), and there are several 
variations that require fixed storage per user (one integer) that can 
produce much shorter URI.

-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