Hi,
>> So, the following applies:
>>
>>
>> request response
>> -------------------------------------------------------
>>
>> instance-id AND Supported:gruu = gruu
>> instance-id AND reg-id = outbound
>> instance-id AND reg-id AND Supported:gruu = outbound AND gruu
>> instance-id = n/a
>>
>>Correct?
>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)?
>If it indicates support ('Supported: gruu') then it will receive the
>GRUU in the 200 response to the REGISTER. If it doesn't indicate
>support, then it won't receive the GRUU. See section 5.2 of the GRUU
>draft for more details.
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."
>Note that the GRUU is still created for non-GRUU UAs, and that the GRUU
>can be discovered by other devices using (for example)
>draft-ietf-sipping-gruu-reg-event.
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.
Regards,
Christer
_______________________________________________
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
