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@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
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
11 jul 2012 kl. 15:28 skrev Daniel-Constantin Mierla:
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?
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
Hello,
On 7/11/12 3:36 PM, Olle E. Johansson wrote:
11 jul 2012 kl. 15:28 skrev Daniel-Constantin Mierla:
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 .-)
this is more devel insight documentation, not much to affect the users.
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?
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
11 jul 2012 kl. 15:42 skrev Daniel-Constantin Mierla:
Hello,
On 7/11/12 3:36 PM, Olle E. Johansson wrote:
11 jul 2012 kl. 15:28 skrev Daniel-Constantin Mierla:
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 .-)
this is more devel insight documentation, not much to affect the users.
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?
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:44 skrev Olle E. Johansson:
11 jul 2012 kl. 15:42 skrev Daniel-Constantin Mierla:
Hello,
On 7/11/12 3:36 PM, Olle E. Johansson wrote:
11 jul 2012 kl. 15:28 skrev Daniel-Constantin Mierla:
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 .-)
this is more devel insight documentation, not much to affect the users.
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?
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. :-)
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
2012/7/11 Olle E. Johansson oej@edvina.net:
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.
11 jul 2012 kl. 17:57 skrev Iñaki Baz Castillo:
2012/7/11 Olle E. Johansson oej@edvina.net:
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.
Remember that I might have missed that part of the code. I will try to test :-) It might just be a documentation error. /O
2012/7/11 Olle E. Johansson oej@edvina.net:
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 :)
On 7/11/12 5:58 PM, Olle E. Johansson wrote:
11 jul 2012 kl. 17:57 skrev Iñaki Baz Castillo:
2012/7/11 Olle E. Johansson oej@edvina.net:
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.
Remember that I might have missed that part of the code. I will try to test :-) It might just be a documentation error.
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
11 jul 2012 kl. 18:06 skrev Daniel-Constantin Mierla:
On 7/11/12 5:58 PM, Olle E. Johansson wrote:
11 jul 2012 kl. 17:57 skrev Iñaki Baz Castillo:
2012/7/11 Olle E. Johansson oej@edvina.net:
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.
Remember that I might have missed that part of the code. I will try to test :-) It might just be a documentation error.
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
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
2012/7/11 Olle E. Johansson oej@edvina.net:
Thanks for your patience, Daniel!
And even more thanks for the code! I will test it in depth very soon.
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Olle E. Johansson