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.
Fair enough, but the UA is still going to get it if it subscribes to the regevent package, isn't it? >>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. 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.... >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 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
