<div dir="ltr"><div>Hello Daniel,</div><div><br></div><div>Thank you for the reply. Sure, I'll send one to your private email address. Thanks!</div><div><br></div><div>BR,</div><div>George<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 24 Jun 2020 at 12:06, Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hello,</p>
<p>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.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div>On 09.06.20 13:00, George
Diamantopoulos wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hello again,</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Here's a simplified version of the configuration routes
involved in this:</div>
<div><span style="font-family:monospace"><br>
</span></div>
<div style="margin-left:40px"><span style="font-family:monospace">request_route {<br>
...<br>
route(DISPATCH_PROVIDER);<br>
...<br>
}<br>
<br>
route[DISPATCH_PROVIDER] {<br>
if ( !ds_select_dst("10", "8") ) {<br>
t_send_reply("503", "Downstream carrier
unavailable");<br>
exit;<br>
}</span></div>
<div style="margin-left:40px"><span style="font-family:monospace"><br>
</span></div>
<div style="margin-left:40px"><span style="font-family:monospace">
t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");<br>
t_on_branch("PROVIDER_BRANCH");<br>
t_on_failure("DISPATCH_PROVIDER_FAILURE");</span></div>
<div style="margin-left:40px"><span style="font-family:monospace"><br>
</span></div>
<div style="margin-left:40px"><span style="font-family:monospace"> route(RELAY);<br>
exit;<br>
}<br>
<br>
failure_route[DISPATCH_PROVIDER_FAILURE] {<br>
if (t_is_canceled()) {<br>
exit;<br>
}<br>
if ( t_check_status("401|407") ) {<br>
$avp(arealm) = "<a href="http://authrealm.com" target="_blank">authrealm.com</a>";<br>
$avp(auser) = "authusername";<br>
$avp(apass) = "verys3kr1t";<br>
uac_auth();</span></div>
<div style="margin-left:40px"><span style="font-family:monospace"><br>
</span></div>
<div style="margin-left:40px"><span style="font-family:monospace">
t_on_branch("PROVIDER_BRANCH");<br>
t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");<br>
t_on_failure("DISPATCH_PROVIDER_FAILURE");</span></div>
<div style="margin-left:40px"><span style="font-family:monospace"><br>
</span></div>
<div style="margin-left:40px"><span style="font-family:monospace"> $du = "sip:" +
$T_rpl($si) + ":" + $T_rpl($sp); // I'll explain why this is
here later in this e-mail<br>
t_relay();<br>
exit;<br>
}<br>
}<br>
<br>
branch_route[PROVIDER_BRANCH] {<br>
uac_replace_from("$dlg_var(my_new_from)");<br>
uac_replace_to("$dlg_var(my_new_to)");<br>
$rU = "my new RURI user";<br>
}<br>
<br>
event_route[tm:branch-failure:DISPATCH_PROVIDER_FAILOVER] {<br>
if (t_is_canceled()) {<br>
exit;<br>
}<br>
if ( t_check_status("401|407") ) {<br>
return;<br>
# next DST - only for 5xx or local timeout<br>
} else if ( t_check_status("5[0-9][0-9]") ||
(t_branch_timeout() && !t_branch_replied()) ) {<br>
if ( ds_next_dst() ) {<br>
t_on_branch("PROVIDER_BRANCH");<br>
t_on_branch_failure("DISPATCH_PROVIDER_FAILOVER");<br>
t_on_failure("DISPATCH_PROVIDER_FAILURE");<br>
route(RELAY);<br>
exit;<br>
} else {<br>
xlog("L_NOTICE", "---
SCRIPT_DISPATCH_PROVIDER_FAILOVER: Failed to route request
to PROVIDER! Giving Up. Negative response will be sent
upstream.\n");<br>
}<br>
}<br>
}</span></div>
<div style="margin-left:40px"><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:monospace"><span style="font-family:arial,sans-serif">One will rightfully
wonder why use both branch-failure routes and
failure_route to handle things. Well,</span> <font face="arial,sans-serif">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.</font></span></div>
<div><span style="font-family:monospace"><font face="arial,sans-serif"><br>
</font></span></div>
<div><span style="font-family:monospace"><font face="arial,sans-serif">Regarding the line <span style="font-family:monospace">"$du = "sip:" +
$T_rpl($si) + ":" + $T_rpl($sp);"</span> 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.</font></span></div>
<div><span style="font-family:monospace"><font face="arial,sans-serif"><br>
</font></span></div>
<div><span style="font-family:monospace"><font face="arial,sans-serif">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).</font></span></div>
<div><span style="font-family:monospace"><font face="arial,sans-serif"><br>
</font></span></div>
<div><span style="font-family:monospace"><font face="arial,sans-serif">So I was wondering if this is to
be expected with this configuration, or if this should be
reported as a bug. Thanks!</font></span></div>
<div><span style="font-family:monospace"><font face="arial,sans-serif"><br>
</font></span></div>
<div><span style="font-family:monospace"><font face="arial,sans-serif">Best regards,</font></span></div>
<div><span style="font-family:monospace"><font face="arial,sans-serif">George<br>
</font></span></div>
<div><span style="font-family:monospace"><font face="arial,sans-serif"><br>
</font></span></div>
<div><span style="font-family:monospace"></span></div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Kamailio (SER) - Users Mailing List
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">www.asipto.com</a>
<a href="http://www.twitter.com/miconda" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" target="_blank">www.linkedin.com/in/miconda</a>
Funding: <a href="https://www.paypal.me/dcmierla" target="_blank">https://www.paypal.me/dcmierla</a></pre>
</div>
</blockquote></div>