Christer Holmberg wrote:
Hi,
Its been a long time, and the details are starting to get fuzzy in my
mind.

One should not have to remember the details - they should be clear by
reading the specs :)

Right. But I was being lazy.

But I'm quite sure Michael is right here. The first registration with
an instance id causes the
creation of a permanent gruu, and every registration with an instance
id results in creation of a temp gruu.
This is regardless of whether the registering UA indicates support for
gruu. If it does, then it receives a copy of the
gruu in the response.

Yes. The question was whether instance-id AND reg-id also create a gruu.
The answer seems to be yes, but I think it would be good to clarify that
somewhere.

Since reg-id isn't mentioned in gruu, its irrelevant to the gruu spec, just as any other parameters are.

So, either the outbound spec has a note saying that a gruu will always
be created.

...and/or, the gruu spec says that a gruu will always be created - even
when the instance-id is used as part of another feature (e.g. outbound).

That would require it to be aware that it was part of another feature.
IMO That's an unreasonable assumption.

The spec says what it means.

        Thanks,
        Paul

Regards,

Christer









Michael Procter wrote:
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


_______________________________________________
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

Reply via email to