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
