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
That's definitely on purpose, the l_username can be the same for different local accounts in multi-domain deployments (e.g., 101@a.com and 101@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
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@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@a.com and 101@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@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