[sr-dev] GRUU and publish registration status

Daniel-Constantin Mierla miconda at gmail.com
Thu Aug 30 18:43:44 CEST 2012


On 8/30/12 3:58 PM, Olle E. Johansson wrote:
> 30 aug 2012 kl. 11:42 skrev Daniel-Constantin Mierla <miconda at gmail.com>:
>
>> On 8/30/12 11:22 AM, Iñaki Baz Castillo wrote:
>>> 2012/8/30 Olle E. Johansson <oej at edvina.net>:
>>>>> AFAIK that's not "needed". When a request arrives to the proxy having
>>>>> ;gr param in the RURI, the proxy extracts the gr value, "decodes" it
>>>>> somehow (not need to have such a mapping in a DB) and gets the
>>>>> associated binding, so just such a binding would be retrieved form
>>>>> usrloc table when calling lookup().
>>>> That means that one - knowing the algorithm - can reach all contacts directly, regardless
>>>> if they have a gruu or not. Or?
>>> I expect that Kamailio generates a random key on startup for encoding
>>> GRUU values and thus, it would be not possible to generate the same
>>> GRUU value (for the same URI binding) without having such a key.
>> A random key at startup is making impossible to deal with gruu values in the ongoing dialogs, because there was an encoding key before startup and another one after, which is not able to decode previously encoded values.
>>
>> Anyhow, the algorithm is known, because it is open source, but unique id generation is taking in consideration server id, startup time, pid, a counter or random (depending on option, for gruu is counter) and hash over AoR. All together results in a very random value, where another encoding makes no much sense.
>>
>> This is for temp gruu, because for public gruu the rfc recommends usage of instance value, which is set by client.
>>
>>>
>>>
>>>>>> - If so, is that reachable information for the pua-regloc to publish the gruu's?
>>>>> Note that such a feature would require implementing RFC 5628:
>>>>>
>>>>> http://tools.ietf.org/html/rfc5628
>>>>>
>>>>> "Registration Event Package Extension for SIP
>>>>>   Globally Routable User Agent URIs (GRUUs)"
>>>> Yes. But to make it possible and to make it possible to restart kamailio without loosing information, I think we have no other option but to store a gruu flag in usrloc.
>>> I see no problem at all in adding two new fields to the usrloc table:
>>> gr_public, gr_temp.
>> There is no need, the values for these fields are in the other fields. If the client does not support gruu, the instance is not published, so it is stored.
> Instance alone is not an indication of gruu support.
it's the other way for usrloc, no instance is indication of no gruu 
support. If a flag could help somewhere, is fine to store, but storing 
temp/pub gruus is just duplicated data.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat




More information about the sr-dev mailing list