Hi Erkki, >>>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 :) > >I agree, however the specs often lack the rationale behind the agreed design choices. So even if you see something has specified in a certain >way, in some cases you will have hard time understanding why, unless you dig into the email archives.
It is not about the rationale - but to understand the spec :) >>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...)??? > >I also raised this question in march 2007 while reviewing GRUU spec and received an answer from Paul Kyzivat, who had a point: > > GRUU draft tells the registrar to create a public GRUU and a temporary > GRUU whenever it receives a REGISTER request with "+sip.instance" > Contact header parameter but only return them is the REGISTER request > contains Supported: gruu. > > Does this make any sense ? Why would the registrar have to create > those GRUUs if it would not return them to the UA ? > > The use case I am thinking is: > > - A registrar which supports both GRUU and Outbound > - An UA which supports Outbound but not GRUU > > Such an UA would send its Contact header with "+sip.instance" > parameter but it would not include Supported: gruu in its REGISTER. > Strictly speaking GRUU draft currently tells the registrar to create > GRUUs but not to return them to the UA. > > I would assume GRUU draft needs a small fix to tell the registrar to > create the GRUUs only if the REGISTER request contains "gruu" option > tag in Supported header. > > Do you agree or have I missed something ? > >This is partially one of those questions like "does a tree that falls make any noise if nobody is listening?" > >If in fact nobody will learn about this gruu then there is no need to create it. But that is all about the difference between the conceptual >model and the implementation, so it doesn't need to be stated. > >The problem arises when there are multiple observers of registration state. There are at least two ways this can happen: >- other UAs that register >- subscribers to the reg event package > >After you register, if others register they will get your contact back in the response to their register request, along with their own. If >they support gruu, then they will will see the permanent gruu and latest temp gruu for your contact. > >Similarly, when you register, any subscribers to the reg event package will get a notify telling of the change in registration state, >including your contact and the gruus that were "assigned" to you. > >Everything hangs together better this way. Still, if nobody is looking you don't have to assign these, as long as you do assign them when >somebody does start looking. If I don't support gruu, but I register to the regevent package, I WILL hear the tree falling, because I will receive the gruu in the NOTIFY :) 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
