30 Aug
2012
30 Aug
'12
11:01 a.m.
Hi!
Since we've learned that GRUU's are more or less semi-automatic I have of course a
few more questions:
- Is the usrloc module aware that a specific contact is using GRUU's
- If so, is that reachable information for the pua-regloc to publish the gruu's?
- For a restart, is that status saved in the db?
/O
30 Aug
30 Aug
11:22 a.m.
2012/8/30 Olle E. Johansson <oej(a)edvina.net>et>:
Hi!
Since we've learned that GRUU's are more or less semi-automatic I have of course
a few more questions:
- Is the usrloc module aware that a specific contact is using GRUU's
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().
- 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)"
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:15 p.m.
30 aug 2012 kl. 10:22 skrev Iñaki Baz Castillo <ibc(a)aliax.net>et>:
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.
Of course, I might be totally wrong :-)
/O
2012/8/30 Olle E. Johansson <oej(a)edvina.net>et>:
That means that one - knowing the algorithm -
can reach all contacts directly, regardless
if they have a gruu or not. Or?
Hi!
Since we've learned that GRUU's are more or less semi-automatic I have of course
a few more questions:
- Is the usrloc module aware that a specific contact is using GRUU's
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(). - 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)"
12:22 p.m.
2012/8/30 Olle E. Johansson <oej(a)edvina.net>et>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.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.
- 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)" 
12:42 p.m.
On 8/30/12 11:22 AM, Iñaki Baz Castillo wrote:
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.
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
2012/8/30 Olle E. Johansson <oej(a)edvina.net>et>:
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.
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? - 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)"
4:58 p.m.
30 aug 2012 kl. 11:42 skrev Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
On 8/30/12 11:22 AM, Iñaki Baz Castillo wrote:
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
2012/8/30 Olle E. Johansson
<oej(a)edvina.net>et>:
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.
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?
> - 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.
7:43 p.m.
On 8/30/12 3:58 PM, Olle E. Johansson wrote:
30 aug 2012 kl. 11:42 skrev Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
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
On 8/30/12 11:22 AM, Iñaki Baz Castillo wrote:
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. 2012/8/30 Olle E. Johansson
<oej(a)edvina.net>et>:
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.
> 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. >> - 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.
7:49 p.m.
2012/8/30 Olle E. Johansson <oej(a)edvina.net>et>:
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.
Just a flag? so you mean that when sending a NOTIFY for registration
event, kamailio would check whether a binding has or not such a GRUU
flag (in usrloc table) and then "calculate" their values to include
them in the NOTIFY body?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4467
days inactive
4467
days old
7 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Olle E. Johansson