Re: Is GRUU generated in the case of registration withinstance-ID and reg-ID

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