Subject: RE: [Sipping] Re: Comment on GRUU requirements

From: Adam Roach <[email-masked]>
Date: Mon, 18 Aug 2003 13:44:42 -0500

Yes, this was my original proposal; however, I
appreciate the concern that this approach requires
all requests -- even those in a dialog -- to go
through a GRUU server.

After considerable thought, I believe that this
approach coupled with Alan's suggestion that
non-firewalled clients can generate their own
GRUUs seems to allay those concerns.

So, as long as "colocating a GRUU server with a UAS"
is explicitly supported, I'm happy to see this as
a solution.

/a

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Monday, August 18, 2003 10:50
> To: Christer Holmberg (JO/LMF); Rohan Mahy; Jonathan Rosenberg
> Cc: Adam Roach; 'Alan Johnston'; [email-masked]'
> Subject: RE: [Sipping] Re: Comment on GRUU requirements
> 
> 
> I believe this was Adam's original suggestion. Works
> for me.
> 
> --- "Christer Holmberg (JO/LMF)"
> <[email-masked]> wrote:
> > 
> > Hi,
> > 
> > I don't know if this has been discussed, but how
> > about putting the GRUU in the Contact header, AND
> > define a "gruu" header/uri parameter. Now, existing
> > nodes will, as Rohan put it, be as broken as they
> > are today, but they will still work, and nodes
> > supporting GRUU will use the gruu parameter to
> > indicate/detect that the uri in the Contact header
> > is a GRUU. But, no new header needs to be defined (I
> > think we already have too many headers carrying
> > URIs, many of which we don't use - or even don't
> > know how or when to use), and there would be no
> > backward compability issues, and no need to redefine
> > existing headers/functionality.
> > 
> > Regards,
> > 
> > Christer Holmberg
> > Ericsson Finland
> > 
> > > -----Original Message-----
> > > From: Sean Olson [mailto:[email-masked]]
> > > Sent: 16. elokuuta 2003 1:50
> > > To: Rohan Mahy; Jonathan Rosenberg
> > > Cc: Adam Roach; 'Alan Johnston';
> > [email-masked]'
> > > Subject: Re: [Sipping] Re: Comment on GRUU
> > requirements
> > > 
> > > 
> > > I have to agree with Rohan. I don't understand the
> > > purpose of NOT placing the GRUU in the Contact:
> > header
> > > if possible. Whether or not this GRUU ties into a
> > > proxy is up for debate, but in practice I believe
> > it
> > > will be the rule rather than the exception.
> > Similar
> > > (but not identical) to the fact that a registrar
> > is
> > > not absolutely necessary to use SIP but it sure
> > makes
> > > things easier in practice.
> > > 
> > > 
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! SiteBuilder - Free, easy-to-use web site
> > design software
> > > http://sitebuilder.yahoo.com
> > > 
> > > _______________________________________________
> > > Sipping mailing list 
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the
> > application of SIP
> > > Use [email-masked] for questions
> > on current sip
> > > Use [email-masked] for new developments of core SIP
> > > 
> > 
> > _______________________________________________
> > Sipping mailing list 
> > https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application
> > of SIP
> > Use [email-masked] for questions
> > on current sip
> > Use [email-masked] for new developments of core SIP
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> 

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 Aug 2003 16:30:06 -0500

Rohan Mahy [mailto:[email-masked]] writes:

> I take "Contact" to mean a URI where a particular user or
> service can be reached.  This makes a Contact in a REGISTER
> no different from a Contact in an INVITE or a <contact> in
> the dialog package.  I believe that any other definition of
> Contact is completely contrived.

Contrived, perhaps -- but practical and necessary. Without
the context provided by a route set, many of the applications
of contact you describe don't necessarily resolve from the
Internet. In an ideal world, your characterization of Contact
would be spot on; the real world, however, isn't always so
cooperative.

/a