Christer Holmberg wrote:
Hi,
So, what is the justification for generating a gruu, but
not returning it (after all, the gruu will be sent to the UA if it
registers to the regevent package, so...)???
Sending a header parameter to a UA that doesn't declare it supports it
seems to be inviting interop issues. I suspect this is the reason,
although I wasn't involved with that decision so I can't say
categorically what the reason was.
I also don't recall for certain what the reason was. I think perhaps
initially it was thought that gruus would only been generated when
requested. But that led to some logical inconsistencies around the
permanent gruu when others might need to observe the gruu. So it was
concluded that the presence of the gruu was coupled to the
AOR/Contact/Instance-ID tuple. I can't remember the exact problem cases
right now, though I think they did come from me. I can probably find
them in my mail history if I look hard enough. But there was so much
discussion on gruu it would take me a long time.
Fair enough, but the UA is still going to get it if it subscribes to the
regevent package, isn't it?
Yup. But ought to ignore any parts of the extension schema it doesn't
understand.
My question is still: if the REGISTER contains instance-id AND
Require:gruu, is a gruu generated?
On one side the presence of instance-id always creates a gruu, but on
the other side the text says that the precense of Require:gruu does
NOT
mandate the creation of a gruu.
OR, does the text simply mean that Require:gruu on its own (ie no
instance-id) does not mandate the creation of a gruu?
I think it is this last one. 'Require: gruu' has no special
meaning to a gruu-supporting registrar - it only prevents
non-supporting
registrars from handling the request.
That sounds reasonalble, but I think it should also be clarified.
What are we clarifying? We know what the standard meaning of Require is.
And we know that no additional meaning is provided. Why is more required?
Again, it may be clear to all of us now, but in order to avoid having
this same disucssion again in a couple of years....
If that is the point, the *maybe*. Given the state of the draft, it
would probably have to be in Auth 48 if Jonathan wants to do it. Else it
would be quite a pain.
A gruu-supporting registrar will follow section 5, which contains the
phrase:
"If there is no valid public GRUU, the registrar SHOULD construct a
public GRUU"
Assuming the UA includes a +sip.instance, and doesn't try to
do anything silly (register the AoR as a contact, register a gruu as a
contact),
then you SHOULD get a GRUU made for you.
Does instance-id AND Require:gruu also RETURN the gruu?
Or, if I want the gruu returned, and I want to mandate the registrar to
support gruu, do I have to send:
Instance-id AND Supported:gruu AND Require:gruu
I think the latter is correct. Require and Supported have different
uses. As defined, Supported says "I am willing to have the GRUU returned
to me, if it is available". My request still succeeds, but without
getting the GRUU, if the registrar doesn't support gruu. "Require" says
my request should fail if the registrar can't create the gruu.
This is all "SIP 101" stuff.
Thanks,
Paul
Whatever the answer to my question is - clarification would be
appretiated :)
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
_______________________________________________
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
