Iñaki,
This is probably far from obvious.
The reason for creating new ones was because for anonymization purposes
you probably don't want to keep using the same one. It would have been
better to have an explicit mechanism to request when you want a new one,
but that didn't fit into the model well. (There were a lot of needs to
balance in doing this. The result is not very pretty.)
If you think about it for awhile, you will find that it is possible to
come up with an algorithm for constructing temp gruus that doesn't
require the registrar to keep permanent state for each one created. (Or
course its also possible to create algorithms that *do* require state,
but that is for you to decide.)
Thanks,
Paul
Iñaki Baz Castillo wrote:
> 2010/3/21 Iñaki Baz Castillo <i...@aliax.net>:
>> Hi, after reading the RFC 5627 I don't understand why the registrar
>> can create a new temp-gruu URI for each registration refresh.
>> If it does so, the registrar would end with a database full of temp-gruu
>> URI's.
>>
>> From the point of view of a registrar implementing GRUU, is it posible
>> to mantain an unique temp-gruu for each registration instance (as it
>> occurs for the public-gruu?
>> It would make the implementation easier (by adding two columns
>> "temp_gruu" and "public_gruu" in the location database table).
>>
>> Do I miss something? Also, the example in section 9 of RFC 5627 shows
>> the same temp-gruu for two different registration from same UA
>> instance (as it crashed and generates a new registration with
>> different Call-ID after rebooting).
>
>
> This is the exact point I cannot understand in RFC 5627:
>
> -----------------------------------------------------------------
> 3.2. Obtaining a GRUU
>
> When a user agent refreshes this registration prior to its
> expiration, the registrar will return back the same public GRUU, but
> will create a new temporary GRUU. Despite the fact that each refresh
> provides the UA with a new temporary GRUU, all of the temporary GRUUs
> learned from previous REGISTER responses during the lifetime of a
> contact remain valid as long as (1) a contact with that instance ID
> remains registered, and (2) the UA doesn't change the Call-ID in its
> REGISTER request compared to previous ones for the same reg-id
> -----------------------------------------------------------------
>
>
> By following this specification, if a phone is registered for one day
> by refreshing its registration hourly (same Call-ID), then the
> registrar would have to store 24 temp-gruu values for same
> registration. How could it make sense?
>
> So my question is: is it legal if the registrar mantains an *unique*
> temp-gruu per registration (according to AoR and sip.instance)?
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
