11 Jul
2012
11 Jul
'12
4:18 p.m.
Hey,
Been trying to understand the GRUU support in Kamailio. I see that the registrar saves
sip.instance - but I don't see any functions to generate gruu URIs or store them. A
public GRUU is valid forever for a sip.instance and should propably be saved into some
sort of database table. A temporary GRUU is only valid for as long as a device registers
with the same Call-ID.
Please give me pointers to what I have missed!
Thanks,
/O
---
* Olle E Johansson - oej(a)edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
11 Jul
11 Jul
4:28 p.m.
Hello,
On 7/11/12 3:18 PM, Olle E. Johansson wrote:
Hey,
Been trying to understand the GRUU support in Kamailio. I see that the registrar saves
sip.instance - but I don't see any functions to generate gruu URIs or store them. A
public GRUU is valid forever for a sip.instance and should propably be saved into some
sort of database table. A temporary GRUU is only valid for as long as a device registers
with the same Call-ID.
Please give me pointers to what I have missed!
if you follow the git log for
registrar and usrloc module during 3.3
development you will spot quicker the related parts of code.
The public gruu is built based on sip.instance value, as recommended by
rfc, therefore is no need to store anything else.
The temp gruu is the ruid (record unique id) value plus the hash code of
the aor - ruid is uniquely generated using the code from internal
libutils/sruid.{c,h}
Using these approaches, the gruu addresses are built reusing some values
from the location records, no need for special tables.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
4:36 p.m.
11 jul 2012 kl. 15:28 skrev Daniel-Constantin Mierla:
Hello,
On 7/11/12 3:18 PM, Olle E. Johansson wrote:
Will do... But you know my cravings for documentation .-)
Hey,
Been trying to understand the GRUU support in Kamailio. I see that the registrar saves
sip.instance - but I don't see any functions to generate gruu URIs or store them. A
public GRUU is valid forever for a sip.instance and should propably be saved into some
sort of database table. A temporary GRUU is only valid for as long as a device registers
with the same Call-ID.
Please give me pointers to what I have missed!
if you follow the git log for
registrar and usrloc module during 3.3 development you will spot quicker the related parts
of code.
The public gruu is built based on sip.instance value, as recommended by rfc, therefore is
no need to store anything else.
So how do I route a SIP request to a public GRUU
outside or inside of a dialog?
The temp gruu is the ruid (record unique id) value plus the hash code of the aor - ruid
is uniquely generated using the code from internal libutils/sruid.{c,h}
Using these approaches, the gruu addresses are built reusing some values from the
location records, no need for special tables.
Clever. ;-)
/O
4:42 p.m.
Hello,
On 7/11/12 3:36 PM, Olle E. Johansson wrote:
lookup(location) does automatically the logic - for outside of dialog is
the same like so far, no change in config.
For within dialog, you can use is_gruu() function to detect if the r-uri
is gruu and then you can call lookup(location). If r-uri is a gruu, then
lookup(location) searches for an exact match on temp/pub gruu value and
will not add extra branches with the rest of records for the AoR (if
pub-gruu), just updates with the record for the r-uri.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
11 jul 2012 kl. 15:28 skrev Daniel-Constantin Mierla:
this is
more devel insight documentation, not much to affect the users.
Hello,
On 7/11/12 3:18 PM, Olle E. Johansson wrote:
Will do... But you know my cravings for documentation .-) Hey,
Been trying to understand the GRUU support in Kamailio. I see that the registrar saves
sip.instance - but I don't see any functions to generate gruu URIs or store them. A
public GRUU is valid forever for a sip.instance and should propably be saved into some
sort of database table. A temporary GRUU is only valid for as long as a device registers
with the same Call-ID.
Please give me pointers to what I have missed!
if you follow the git log for
registrar and usrloc module during 3.3 development you will spot quicker the related parts
of code. The public gruu is built based on sip.instance
value, as recommended by rfc, therefore is no need to store anything else.
So how
do I route a SIP request to a public GRUU outside or inside of a dialog?
4:44 p.m.
11 jul 2012 kl. 15:42 skrev Daniel-Constantin Mierla:
Hello,
On 7/11/12 3:36 PM, Olle E. Johansson wrote:
lookup(location) does automatically the logic - for outside of dialog is the same like so
far, no change in config.
For within dialog, you can use is_gruu() function to detect if the r-uri is gruu and then
you can call lookup(location). If r-uri is a gruu, then lookup(location) searches for an
exact match on temp/pub gruu value and will not add extra branches with the rest of
records for the AoR (if pub-gruu), just updates with the record for the r-uri.
Sweet. Thanks for the response!
So it's all hidden in the user location magic. :-)
/O
11 jul 2012 kl. 15:28 skrev Daniel-Constantin
Mierla:
this is
more devel insight documentation, not much to affect the users.
Hello,
On 7/11/12 3:18 PM, Olle E. Johansson wrote:
Will do... But you know my cravings for documentation .-) Hey,
Been trying to understand the GRUU support in Kamailio. I see that the registrar saves
sip.instance - but I don't see any functions to generate gruu URIs or store them. A
public GRUU is valid forever for a sip.instance and should propably be saved into some
sort of database table. A temporary GRUU is only valid for as long as a device registers
with the same Call-ID.
Please give me pointers to what I have missed!
if you follow the git log for
registrar and usrloc module during 3.3 development you will spot quicker the related parts
of code. The public gruu is built based on sip.instance
value, as recommended by rfc, therefore is no need to store anything else.
So how
do I route a SIP request to a public GRUU outside or inside of a dialog?
6:54 p.m.
11 jul 2012 kl. 15:44 skrev Olle E. Johansson:
11 jul 2012 kl. 15:42 skrev Daniel-Constantin Mierla:
Reading source code and documentation again...
I see that the gruu_enabled() parameter enables gruu if there's an instance ID in the
contact.
The requirement is also that there has to be a supported: gruu
The instance ID is used without GRUU (like in OUTBOUND), so just checking that is not a
good indication
that you have GRUU support in the UA.
" When a UA compliant to this specification generates a REGISTER
request (initial or refresh), it MUST include the Supported header
field in the request. The value of that header field MUST include
"gruu" as one of the option tags. This alerts the registrar for the
domain that the UA supports the GRUU mechanism."
From RFC 5627.
Disclaimer: I've only read the source code. Ashamed that I haven't tried. Will do
a.s.a.p.
/O
Hello,
On 7/11/12 3:36 PM, Olle E. Johansson wrote:
lookup(location) does automatically the logic - for outside of dialog is the same like so
far, no change in config.
For within dialog, you can use is_gruu() function to detect if the r-uri is gruu and then
you can call lookup(location). If r-uri is a gruu, then lookup(location) searches for an
exact match on temp/pub gruu value and will not add extra branches with the rest of
records for the AoR (if pub-gruu), just updates with the record for the r-uri.
Sweet. Thanks for the response!
So it's all hidden in the user location magic. :-) 11 jul 2012 kl. 15:28 skrev Daniel-Constantin
Mierla:
this is more devel insight documentation, not much to affect the
users.
Hello,
On 7/11/12 3:18 PM, Olle E. Johansson wrote:
> Hey,
> Been trying to understand the GRUU support in Kamailio. I see that the registrar
saves sip.instance - but I don't see any functions to generate gruu URIs or store
them. A public GRUU is valid forever for a sip.instance and should propably be saved into
some sort of database table. A temporary GRUU is only valid for as long as a device
registers with the same Call-ID.
>
> Please give me pointers to what I have missed!
if you follow the git log for registrar and usrloc module during 3.3 development you will
spot quicker the related parts of code.
Will do... But you know my cravings for
documentation .-) The public gruu is built based on sip.instance
value, as recommended by rfc, therefore is no need to store anything else.
So how
do I route a SIP request to a public GRUU outside or inside of a dialog? 
6:57 p.m.
2012/7/11 Olle E. Johansson <oej(a)edvina.net>et>:
I see that the gruu_enabled() parameter enables gruu
if there's an instance ID in the contact.
The requirement is also that there has to be a supported: gruu
The instance ID is used without GRUU (like in OUTBOUND), so just checking that is not a
good indication
that you have GRUU support in the UA.
" When a UA compliant to this specification generates a REGISTER
request (initial or refresh), it MUST include the Supported header
field in the request. The value of that header field MUST include
"gruu" as one of the option tags. This alerts the registrar for the
domain that the UA supports the GRUU mechanism."
From RFC 5627.
I agree that checking "gruu" option tag in the Supported/Require
header of the REGISTER is needed.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
6:58 p.m.
11 jul 2012 kl. 17:57 skrev Iñaki Baz Castillo:
2012/7/11 Olle E. Johansson <oej(a)edvina.net>et>:
Remember that I might have missed that part of the code. I will try to test :-)
It might just be a documentation error.
/O
I see that the gruu_enabled() parameter enables
gruu if there's an instance ID in the contact.
The requirement is also that there has to be a supported: gruu
The instance ID is used without GRUU (like in OUTBOUND), so just checking that is not a
good indication
that you have GRUU support in the UA.
" When a UA compliant to this specification generates a REGISTER
request (initial or refresh), it MUST include the Supported header
field in the request. The value of that header field MUST include
"gruu" as one of the option tags. This alerts the registrar for the
domain that the UA supports the GRUU mechanism."
From RFC 5627.
I agree that checking "gruu" option tag in the Supported/Require
header of the REGISTER is needed.
7:01 p.m.
2012/7/11 Olle E. Johansson <oej(a)edvina.net>et>:
Remember that I might have missed that part of the
code. I will try to test :-)
It might just be a documentation error.
Sure, I just mean that it should work as you pointed out :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
7:06 p.m.
On 7/11/12 5:58 PM, Olle E. Johansson wrote:
11 jul 2012 kl. 17:57 skrev Iñaki Baz Castillo:
gruu addresses are built for REGISTER reply
only if the gruu tag is in
supported header, see code at:
modules_k/registrar/reply.c +190
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
2012/7/11 Olle E. Johansson
<oej(a)edvina.net>et>:
Remember that I might have missed that part of
the code. I will try to test :-)
It might just be a documentation error. I see that the gruu_enabled() parameter enables
gruu if there's an instance ID in the contact.
The requirement is also that there has to be a supported: gruu
The instance ID is used without GRUU (like in OUTBOUND), so just checking that is not a
good indication
that you have GRUU support in the UA.
" When a UA compliant to this specification generates a REGISTER
request (initial or refresh), it MUST include the Supported header
field in the request. The value of that header field MUST include
"gruu" as one of the option tags. This alerts the registrar for the
domain that the UA supports the GRUU mechanism."
From RFC 5627.
I agree that checking "gruu" option tag in the Supported/Require
header of the REGISTER is needed.
7:13 p.m.
11 jul 2012 kl. 18:06 skrev Daniel-Constantin Mierla:
On 7/11/12 5:58 PM, Olle E. Johansson wrote:
Ok! Great!
So I will file a documentation bug, assign that to myself for not noticing this and try to
commit and cause work for the rest of you :-)
Thanks for your patience, Daniel!
/O
11 jul 2012 kl. 17:57 skrev Iñaki Baz Castillo:
gruu addresses are built for REGISTER
reply only if the gruu tag is in supported header, see code at:
modules_k/registrar/reply.c +190 2012/7/11 Olle E. Johansson
<oej(a)edvina.net>et>:
Remember that I might have missed that part of
the code. I will try to test :-)
It might just be a documentation error. I see that the gruu_enabled() parameter enables
gruu if there's an instance ID in the contact.
The requirement is also that there has to be a supported: gruu
The instance ID is used without GRUU (like in OUTBOUND), so just checking that is not a
good indication
that you have GRUU support in the UA.
" When a UA compliant to this specification generates a REGISTER
request (initial or refresh), it MUST include the Supported header
field in the request. The value of that header field MUST include
"gruu" as one of the option tags. This alerts the registrar for the
domain that the UA supports the GRUU mechanism."
From RFC 5627.
I agree that checking "gruu" option tag in the Supported/Require
header of the REGISTER is needed.
4520
days inactive
4520
days old
11 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Olle E. Johansson