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

The reason outbound and gruu are using the same instance-id is that both 
uses share the same definition of the concept of a UA instance.

	Thanks,
	Paul

[email protected] wrote:
> Hi, 
> 
>>> 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.
> 
>>> My question is still: if the REGISTER contains instance-id AND
>>> Require:gruu, is a gruu generated?
> 
>> Since reg-id isn't mentioned in gruu, its irrelevant to the gruu spec,
>> just as any other parameters are.
> 
> Right. Registrar compliant to the GRUU spec will create gruu
> when it sees the Contact header field in the REGISTER message to
> contain a "+sip.instance" header field parameter. The registrar
> does not need to understand other parameters specified in Outbound
> spec. I admit it is a bit confusing to use the same parameter in
> two different specs that should be orthogonal, but it just happens
> to be the specified behaviour.
> 
>> 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:
> 
> [email protected] wrote:
>> Hi Jonathan,
>>
>> 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.
> 
> 	Paul
> --
> 
> Perhaps this could have been worth mentioning in the GRUU spec.
> 
>> I think that the outbound spec should clarify that the 
>> instance-id, when used with outbound, will also create 
>> a gruu, according to the rules in the gruu-spec.
> 
> I understand the point that Outbound spec should actually NOT
> talk about creation of gruus, as that is the task of GRUU spec.
> However Outbound refers to GRUU spec twice, so what about 
> modifying the note within section 6 as like this:
> 
>    A Contact header field value with an instance-id media feature tag
>    but no reg-id header field parameter is valid (this combination can
>    be used in the GRUU [I-D.ietf-sip-gruu] specification as creation
>    of gruu is not dependent on the presence or absence of reg-id 
>    parameter), but one with a reg-id but no instance-id is not.  
> 
> Regards,
> 
> Erkki
> _______________________________________________
> 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