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

Re: [Sip] GRUU and grid

Dale,

If header parameters had been made mandatory in 3261 this would probably work well. But inclusion of header parameters into requests is discretionary in 3261, and there are warnings of how it can be dangerous, so I don't believe it can be relied upon.

If it were only the proxy handing out the gruu that had to be relied upon it wouldn't be a problem, because we could make it a mandatory part of gruu support. But that isn't the case. Done as you suggest it is the server that is putting the request into the R-URI of a request that must do it. So I think it would be a quite unreliable mechanism.

	Paul

Dale.Worley at comcast.net wrote: 
I was distracted during part of the last phone call, so I think I
heard the following idea discussed and largely agreed on.  But maybe
not.  Can people fill me in, or explain the ramifications of this
idea?

In previous drafts, a UA could convert a GRUU into a series of GRUU
URIs that would all route to the UA by adding a URI-parameter
"grid=(value)":

	sip:gruu-6 at example.com --> sip:gruu-6 at example.com;grid=abcde

Then the proxy responsible for the GRUU would carry the grid parameter
into the contact URI that was the final request-URI:

	sip:gruu-6 at example.com;grid=abcde routes to
		sip:10.1.1.1;grid=abcde

EKR among others noted that this was rather clunky and non-orthogonal
to the rest of the SIP addressing structure.

But the same effect could be obtained by using a header (in RFC 3261
terminology):

	sip:gruu-6 at example.com --> sip:gruu-6 at example.com?grid=abcde

At whatever stage of processing (UAC or proxy) this URI is inserted as
a request-URI, the header will be removed from the URI and turned into
a header field (RFC 3261 terminology):

	INVITE sip:gruu-6 at example.com
	grid: abcde

The header field will be copied by all proxies and eventually reach
the UAS.

The UAS can thus test for the "grid" header field in the same way that
it could previously test for the "grid" URI-parameter in the previous
proposals.

This new scheme has a number of advantages:

- It requires no new mechanisms, as this processing of headers into
  header fields is specified by RFC 3261.

- It is as easy for the UA to use as the URI-parameter.

- It requires reserving one header field name vs. reserving one
  URI-parameter name.

- UAs (or different layers of processing) could use the same mechanism
  for multiple additional values (as long as they use different header
  field names).

Dale

_______________________________________________
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