[SR-Users] uac_replace_from and uac_auth fails to authenticate.

[Ben Merrills]

WE had an issue like with while using rtjson module. The solution for us, was to ensure that the auc_replace was being done in new branches (t_on_branch). If it wasn’t, uac_auth didn’t preserve any to/from changes between INVITE without and with auth.

https://www.mail-archive.com/sr-users@lists.kamailio.org/msg10808.html

Kind Regards,
Ben
From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Joel Serrano
Sent: 20 January 2020 03:27
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Subject: Re: [SR-Users] uac_replace_from and uac_auth fails to authenticate.

Have you tried setting $fU/$fd directly in failure_route before uac_auth()?


On Sun, Jan 19, 2020 at 14:35 Kjeld Flarup <kjeld.flarup at liberalismen.dk<mailto:kjeld.flarup at liberalismen.dk>> wrote:
Thanks for confirming.

As there seems to be no way to correct the From header in
failure_dialog, then the From header has to be modified before I receive
the call then. Which could be done by cascading with a Cascading
Kamailio instance.


-------------------- Med Liberalistiske Hilsner ----------------------
    Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
    Sofienlundvej 6B, 7560 Hjerm<https://www.google.com/maps/search/Sofienlundvej+6B,+7560+Hjerm?entry=gmail&source=g>, Tlf: 40 29 41 49
    Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk<http://www.liberalismen.dk>

On 1/19/20 11:22 PM, Alex Balashov wrote:
> In non-REGISTER requests, the From URI is the identity being asserted,
> and supported by the authentication credentials.
>
> If you have control over the upstream Kamailio server, you can tinker
> with authentication options which enforce equivalence between the
> authentication username/realm and the From URI user/domain --
> specifically, by turning off this enforcement.
>
> If you don't, then a modified From value will indeed be a problem
> insofar as it may deviate from the authentication credentials.
>
> -- Alex
>
> On Sun, Jan 19, 2020 at 11:19:26PM +0100, Kjeld Flarup wrote:
>
>> I have a setup where I have a fallback to a GSM number
>>
>> I look up the GSM number and provider information in a database and sets the
>> headers.
>>
>>                    dlg_manage();
>>                    $du = "sip:" + $dbr(ra=>[0,0]);
>>                    $tu = "sip:"+$rU+"@"+$dbr(ra=>[0,0]);
>>                    $ru = "sip:"+$rU+"@"+$dbr(ra=>[0,0]);
>> uac_replace_from("sip:"+$dbr(ra=>[0,1])+"@EXTERNALIP");
>>
>> After this the call goes to a failure_route to do uac_auth()
>>
>> Now my problem is that this works with the providers Asterisk server.
>> But if the call is send to the providers Kamailio server, authentication is
>> rejected.
>>
>> Removing uac_replace_from makes the call accepted on the Kamailio server
>>
>> The only possible problem I can see is that the first INVITE without
>> authentication, has correct From header.
>> But the second with the nonce and auth, uses the wrong From header. Thus two
>> different From headers in the same SIP dialog.
>>
>> Unfortunately uac_replace_from is not allowed in failure_route, so I could
>> test if this is the problem.
>>
>> Is the two different From headers a problem, and how could that be fixed.
>>
>>
>> --
>> -------------------- Med Liberalistiske Hilsner ----------------------
>>     Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
>>     Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>>     Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk<http://www.liberalismen.dk>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200120/a2d61820/attachment.html>