[SR-Users] GRUU support in Kamailio

Olle E. Johansson oej at edvina.net
Wed Jul 11 17:54:17 CEST 2012


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


More information about the sr-users mailing list