Here is the long explanation:

There are two sources of temp gruu information to the UA:
- that which is returned in the response to REGISTER requests
- that which is returned in notifications by the reg event package

Seemingly you wouldn't need the reg event package for this - you can 
simply accumulate all (or as many as you want) of those temp gruus 
returned in register responses.

BUT, its possible for some of those to become invalid. Specifically, 
support it is almost time for you to refresh your registration, but that 
you turn out to be late. So your old registration expires, and with it 
all the assigned temp gruus. Then, almost immediately, the REGISTER you 
intended as a refresh arrives to the registrar, who treats it as a *new* 
registration. It then assigns and returns a new temp gruu.

Unfortunately you cannot tell that this has happened based on the 
response to the REGISTER. So you will treat this as just another temp 
gruu to be added to your pot.

The "first-cseq" rule provides a way for you to tell, via the next 
NOTIFY, that all your *old* temp gruus have become invalid.

        Thanks,
        Paul

hanifa.mohammed wrote:
> all,
> 
> Pl find the below snippet in RFC 5628!
>       *  It should remove any temporary GRUUs with a "callid" attribute
>          value different from that in the value of the "callid"
>          attribute of the <contact>, or with a "cseq" attribute with
>          value less than the value of the "first-cseq" attribute of the
>          <temp-gruu>.
> 
>     It means that the Registrar shall invalidate the temporary GRUU, when a
> certain limit is reached. And, the limit shall be conveyed to UE using 
> reg-ev
> package. Is this true?
> 
>     It contradicts the fact that RFC5627 mentions that the temporary
> GRUU is valid till the user deregister or registers with a different Call-Id 
> header.
> 
>     What is the real need for "first-cseq" attribute in this RFC?
> 
> Best Regards,
> Mohammed Hanifa 
> 
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to