30 aug 2012 kl. 11:42 skrev Daniel-Constantin Mierla <[email protected]>:
> > On 8/30/12 11:22 AM, Iñaki Baz Castillo wrote: >> 2012/8/30 Olle E. Johansson <[email protected]>: >>>> 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. /O
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
