[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Sip] GRUU and Grid alternative



I'd like to point one thing out from the annals of the way-back
machine...

At IETF-59 in Seoul, I made a presentation, which I recall being well
received by at least a few folks (I believe Cullen was one of them) in
which a separate, but related problem space to GRUU was being discussed:
the GUID.

The draft has expired long ago
(http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-stucker-si
p-guid-00.txt) but the introduction captures the problem space fairly
succintly:

---
      Within SIP, there arise situations where it is necessary to ensure

      that an action is applied to a particular user agent (UA)
instance, 
      but the existing mechanisms within SIP are not always reliable.
For 
      example, although registrations identify a routable address and
port 
      of a particular UA, in an environment that uses dynamically
assigned 
      IP addresses (NATs, VPNs, short-lease DHCP networks) there is no 
      ready way of always tying registrations together across time for a

      particular UA instance. In these environments, the usual IP/port 
      combination that defines a particular routing location of a UA is 
      unreliable over time as an identifier of that UA. 

      As a result, an identifier that UAs can use as a "finger-printing"

      mechanism to identify themselves is useful. Whereas the Globally 
      Routable UA URIs (GRUU) draft [4] seeks to address a
server-generated 
      identifier for the UA, this draft seeks to define a
client-generated 
      approach to a similar problem. 

      The mechanism defined in this document allows a particular UA 
      instance to construct a globally unique identifier which can be
used 
      by SIP services to process requests that require, or are enhanced
by, 
      the ability to identify a particular UA instance in the network
over 
      a long period of time. 
---

This notion was folded into the GRUU draft as a property of the grid
parameter (ie. the grid could be used as a GUID).

If we're to remove the grid from gruu, I think we still want to maintain
this property of the grid: it's still very useful.

Regards,
Brian

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com] 
> Sent: Tuesday, October 03, 2006 11:17 PM
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] GRUU and Grid alternative
> 
> Jonathan Rosenberg wrote:
> 
> > The basic idea would be to remove the grid mechanism 
> entirely from the 
> > gruu draft. Instead, a separate specification would be 
> developed which 
> > would allow for loose routing to apply to user agents. So, 
> consider a 
> > UA which registers. It would include a contact and a 
> Supported header 
> > field with the value "ua-route". The registrar, assuming it 
> > understands this, notes that the UA supports UA loose routing and 
> > stores the contact. When an incoming call arrives for the 
> AOR, rather 
> > than rewriting the R-URI with the registered contact, it pushes the 
> > registered contact into a Route header and leaves the R-URI alone 
> > (assuming the registered UA supports this mechanism).
> 
> I'd like to go on record as saying that this apparently 
> resolves one of the Great Fundamental Evils of SIP that I've 
> so often sermonized and thereby either makes me happy and 
> fulfilled or leaves me looking for something else to whine 
> about. In either case, it is a very good fix, and long overdue.
> 
> --
> Dean
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> sip-implementors at cs.columbia.edu for questions on current sip 
> Use sipping at ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip