[SR-Users] dialog's track_cseq_updates seems to break uac_auth() in this configuration

[Daniel-Constantin Mierla]

Hello,

can you send a pcap with a call reproducing such case? I can check it
with the c code and see if something is mismatched.

Cheers,
Daniel

On 09.06.20 13:00, George Diamantopoulos wrote:
> Hello again,
>
> This might turn out to be a bug, but I'm posting here first because my
> config is fairly complicated and it might not be the sanest it could
> be. The problem manifests as follows: with the sole change being the
> enabling of track_cseq_updates for the dialog module, kamailio fails
> to process the 100 Trying it receives following authentication
> initiated by the uac_auth() function. Without the track_cseq_updates
> option enabled, the call proceeds successfully, albeit with the CSeq
> for the auth-carrying INVITE having the same value as the original.
>
> Here's a simplified version of the configuration routes involved in this:
>
> request_route {
>     ...
>     route(DISPATCH_PROVIDER);
>     ...
> }
>
> route[DISPATCH_PROVIDER] {
>     if ( !ds_select_dst("10", "8") ) {
>         t_send_reply("503", "Downstream carrier unavailable");
>         exit;
>     }
>
>     t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");
>     t_on_branch("PROVIDER_BRANCH");
>     t_on_failure("DISPATCH_PROVIDER_FAILURE");
>
>     route(RELAY);
>     exit;
> }
>
> failure_route[DISPATCH_PROVIDER_FAILURE] {
>     if (t_is_canceled()) {
>         exit;
>     }
>     if ( t_check_status("401|407") ) {
>         $avp(arealm) = "authrealm.com <http://authrealm.com>";
>         $avp(auser) = "authusername";
>         $avp(apass) = "verys3kr1t";
>         uac_auth();
>
>         t_on_branch("PROVIDER_BRANCH");
>         t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");
>         t_on_failure("DISPATCH_PROVIDER_FAILURE");
>
>         $du = "sip:" + $T_rpl($si) + ":" + $T_rpl($sp); // I'll
> explain why this is here later in this e-mail
>         t_relay();
>         exit;
>     }
> }
>
> branch_route[PROVIDER_BRANCH] {
>     uac_replace_from("$dlg_var(my_new_from)");
>     uac_replace_to("$dlg_var(my_new_to)");
>     $rU = "my new RURI user";
> }
>
> event_route[tm:branch-failure:DISPATCH_PROVIDER_FAILOVER] {
>     if (t_is_canceled()) {
>         exit;
>     }
>     if ( t_check_status("401|407") ) {
>         return;
>     # next DST - only for 5xx or local timeout
>     } else if ( t_check_status("5[0-9][0-9]") || (t_branch_timeout()
> && !t_branch_replied()) ) {
>         if ( ds_next_dst() ) {
>             t_on_branch("PROVIDER_BRANCH");
>             t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");
>             t_on_failure("DISPATCH_PROVIDER_FAILURE");
>             route(RELAY);
>             exit;
>         } else {
>             xlog("L_NOTICE", "--- SCRIPT_DISPATCH_PROVIDER_FAILOVER:
> Failed to route request to PROVIDER! Giving Up. Negative response will
> be sent upstream.\n");
>         }
>     }
> }
>
> One will rightfully wonder why use both branch-failure routes and
> failure_route to handle things. Well, it's not obvious from this
> because the relevant parts are removed for brevity, but I'm generally
> using branch failure event routes to try other destinations in the
> same destination set, and failure routes to additionally try other
> downstream "providers" in case all entries is the current destination
> set have failed. I don't think these actions/routes are relevant
> because the problem manifests without any of these failover mechanisms
> (of switching over to the next provider) engaging.
>
> Regarding the line "$du = "sip:" + $T_rpl($si) + ":" + $T_rpl($sp);"
> in the failure_route, which might seem a little odd, this was added
> because without it, uac_auth() will send the auth-carrying INVITE
> always to the first destination in the destination set even if
> ds_next_dst has been called from the branch-failure event route.
> Unfortunately I haven't been able to determine if this actually
> helped, because I have only received a 5xx error once from the
> downstream peer before the "fix" and haven't been able to reproduce
> this since then. But that's another issue unrelated to the one I'm
> asking about here.
>
> So what happens with track_cseq_updates enabled is, after uac_auth()
> successfully sends the authenticated INVITE and the peer starts
> sending provisional responses, kamailio doesn't seem to acknowledge
> them. Instead, it will retransmit the auth INVITE as if there was a
> firewall preventing the 1xx responses from being admitted. Then, the
> timeout will engage and the configuration script will behave as if
> t_branch_timeout returns true (it will do ds_next_dst).
>
> So I was wondering if this is to be expected with this configuration,
> or if this should be reported as a bug. Thanks!
>
> Best regards,
> George
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200624/4f1412b0/attachment.html>