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

Kjeld Flarup kjeld.flarup at liberalismen.dk
Thu Jan 23 21:02:30 CET 2020


Thanks for the suggestions.

Much to my surprise just setting $fu did the trick.


-------------------- 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

On 1/20/20 4:27 AM, Joel Serrano wrote:
> 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
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> 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/20200123/abea0714/attachment.html>


More information about the sr-users mailing list