[sr-dev] uac_reg module use of l_uuid in Contact header

Ross McKillop ross at rsmck.co.uk
Tue Aug 17 14:58:58 CEST 2021


Ah, makes sense. 

I’ve got the opposite problem. A platform that only allows *its* expected username in the contact header (ostensibly as a ‘security measure’) 

So as a result I need to be able to send l_username in the contact header (I use l_uuid as a unique ID that’s tied to other things. 

Perhaps need to hack it myself to put the full URI in the contact_addr rather than just the host name 

Thanks 

Ross

> On 17 Aug 2021, at 13:05, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> That's definitely on purpose, the l_username can be the same for
> different local accounts in multi-domain deployments (e.g., 101 at a.com
> and 101 at b.com). The l_uuid can be anything that has to be unique per
> local accounts (e.g., random strings, uuid, ...), you can set it to the
> same value as l_username, if in your case they are unique.
> 
> Cheers,
> Daniel
> 
>> On 17.08.21 12:46, Ross McKillop wrote:
>> I've been trying to work out how to set the username element of the contact header in uac_reg outbound REGISTER requests and it seems it's hard coded in the source (uac_reg.c:990) to use the l_uuid. 
>> 
>> I'm curious why l_uuid is used here and not l_username which feels like it should be more consistent with the use of r_username? 
>> 
>> My C skills are sufficient to let me patch this locally for my application, but I wondered what the reason for this design decision is or if it's actually a very long lived 'bug' as it feels like l_username is the 'right' thing to use here? 
>> 
>> Alternatively, perhaps this would be considered a feature request to make it configurable via another parameter in the database (probably beyond my C unless I modelled it on the pull request that added contact_addr (#2470) 
>> 
>> Ross
>> _______________________________________________
>> Kamailio (SER) - Development Mailing List
>> sr-dev at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> 



More information about the sr-dev mailing list