Christer Holmberg wrote: > Hi, > > >> GRUU is a little more subtle than that. If a UA provides an instance-id >> to a GRUU-supporting registrar, then the registrar will create a GRUU >> for that UA, whether it indicates support or not. >> > > Then the question is: if I only want to use outbound, is it always ok that > the registrar creates a GRUU for me (no matter whether it returns it or not)? >
I raised much the same question last year (March/April time), and I think the conclusion was that creating the GRUU doesn't cause problems and should be considered a Good Thing. > Then the text in 5.1, about the Require header is a little confusing. It says > that Require:gruu will NOT require the registrar to even generate a gruu - > only that the registrar is required to support gruu. > > OR, does the text refer to the case when the request ONLY contains > Require:gruu, but no instance-id? > > "A REGISTER request might contain a Require header field with the > "gruu" option tag; this indicates that the registrar has to > understand this extension in order to process the request. It does > not require the registrar to create GRUUs, however." > I think this is the normal Require processing. Putting 'Require: gruu' in your REGISTER will ensure that it will only succeed on a GRUU-aware registrar. It doesn't control or enforce any particular GRUU-related processing, only that the registrar understands GRUU. This behaviour (requiring understanding, not invoking) is common for many but not all SIP options. > Maybe it would be good to clarify, in the outbound spec, that a gruu will be > generated if the registrar supports gruu. Because, at least in 3GPP there has > been some confusion about that, and I believe such clarification would > prevent future interop problems. > I'm certainly in favour of reducing ambiguity, where it exists, but I'm not sure outbound is the place to talk about GRUUs. How did the confusion arise? The GRUU spec seems reasonably clear on this point. Regards, Michael _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
