<div dir="ltr">Hello<br><br>I have attached a pcap received from the provider.<br><br>It is quite informative as it shows bits of how they forward the call.<br><br>We send to 194.247.61.26 which is a Kamailio proxy, that forwards the call to a SBC 194.247.61.32<br><br>My guess is that the 194.247.61.26 kamailio gets confused, and does not match the BYE with the ongoing TCP session.<br>Instead it sees it as a new session, and forwards it according to the route information.<br><br>Can anybody help explaining what fields Kamailio uses to match an ongoing TCP session.<br><br> Regards Kjeld<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den fre. 6. nov. 2020 kl. 10.50 skrev Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>>:<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>
<div>Hello,</div>
<div><br>
</div>
<div>from SIP specs point of view, can be
any port -- ACK and BYE do not have to follow same path as INVITE,
so they can even come from a different IP.<br>
</div>
<div><br>
</div>
<div>Then, the call can be closed after
30secs because also the ACK has the same problems with the header
as the BYE. Your pcap didn't include all the traffic, you have to
capture both directions on your kamailio server to see what
happens on each side.</div>
<div><br>
</div>
<div>Cheers,<br>
Daniel<br>
</div>
<div> </div>
<div><br>
</div>
<div><br>
</div>
<div>On 06.11.20 10:35, Kjeld Flarup wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Hi Daniel
<div><br>
</div>
<div>The Unknown Dialog comes because the server hang up the
call 30 seconds earlier. We never gets these BYE messages,
thus the door phone hangs times out and hangs up.</div>
<div><br>
</div>
<div>My question is still, which port is the BYE from the
server supposed to be sent to?</div>
<div><br>
</div>
<div>The original 37148</div>
<div>The new 37150</div>
<div>or the advertised 5071</div>
<div><br>
</div>
<div>Regards Kjeld</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Den fre. 6. nov. 2020 kl.
10.18 skrev Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>>:<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>I think you hunt a mirage problem here by looking at
the ports of tcp connections, if you think that being
different ports is the cause of BYE failure. The ACK fpr
200ok is independent of the INVITE transaction and can
have a completely different path than INVITE, thus is
completely valid to use another connection. Of course,
if follows the same path as INVITE, if the connection is
still open, it should be reused. But is a matter of
matching, it can be that the INVITE uses different
destination identifiers or the connection gets cut from
different reasons. But the point is that even if there
is a different connection, it should work.</p>
<p>So, I actually looked at the pcap capture you sent in
one of your previous emails and the BYE is sent out, but
gets back:</p>
<p>SIP/2.0 481 Unknown Dialog.</p>
<p>Therefore it gets to the end point, which doesn't match
it with any of its active calls. Looking at the headers,
the 200ok/INVITE has:</p>
<p>From: "Front Door"
<a><sip:32221660@194.255.22.44:5071></a>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.<br>
To: <a><sip:004540294149@127.0.0.1:5071></a>;tag=12003375157297.<br>
Call-ID:
***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.</p>
<p>And the BYE:</p>
<p>From: "Front Door" <a><sip:u0@192.168.2.9></a>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.<br>
To:
<a>sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297</a>.<br>
Call-ID:
***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.</p>
<p>While the dialog should be matched on call-id,
from/to-tags, the From/To URI should be the same to be
strict conformant with RFC3261 (that mandates unchanged
From/To for backward compatibility with RFC2543). Likely
you do some From/To header changes that are not done
correctly to update/restore the values for traffic
within dialog.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div>On 06.11.20 09:31, Kjeld Flarup wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Thanks Juha
<div><br>
</div>
<div>That makes it somehow easier to understand my
capture. My Kamailio must then have detected a
broken TCP connection, though I cannot see why in
the capture, neither in the log, but I only run on
debug level 2.</div>
<div>It receives a 200 OK on port 37148, and then
establishes 37150 to reply with an ACK. </div>
<div><br>
</div>
<div>However two seconds before receiving the 200 OK,
there are some spurious retransmissions and out of
order on 37148. Perhaps this has caused Kamailio to
deem the connection bad, but it still receives data
on it.</div>
<div>Now I assume that the providers server (Which
also is flying Kamailio) should detect the new port,
and continue using that. I got a trace from the
provider, where there is no disturbance. Thus the
server thinks that the connection is OK. </div>
<div><br>
</div>
<div>Now my next question is, what makes a Kamailio
detect this change?</div>
<div>Is it a problem that I only rewrite To and From
in the INVITE, thus the ACK contains some other
values. <br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>It is also a bit strange that I get this error
exactly, the same place in the conversation every
time I make a call. Somehow I suspect some NAT
timeout in the router. (it is not carrier grade
NAT).</div>
<div>Can I do anything to prevent a NAT timeout from
the client side?</div>
<div><br>
</div>
<div><br>
</div>
<div>Another thing. I assume that sending my
internal port in the From field, or any kind of
advertising, should be ignored by the server.</div>
<div><br>
</div>
<div>Regards Kjeld</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Den fre. 6. nov.
2020 kl. 07.45 skrev Juha Heinanen <<a href="mailto:jh@tutpro.com" target="_blank">jh@tutpro.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Kjeld Flarup
writes:<br>
<br>
> How is TCP SIP actually supposed to handle a
BYE, when the client is <br>
> behind NAT.<br>
<br>
Client behind NAT is supposed to keep its TCP
connection to SIP Proxy<br>
alive and use it for all requests of the call. If
the connection breaks<br>
for some reason, the client sets up a new one for
the remaining<br>
requests.<br>
<br>
-- Juha<br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<p>--------------------- Med Liberalistiske Hilsner
----------------------</p>
<pre cols="72"> 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 - <a href="http://www.liberalismen.dk" target="_blank">www.liberalismen.dk</a>
</pre>
</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>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<p>--------------------- Med Liberalistiske Hilsner
----------------------</p>
<pre cols="72"> 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 - <a href="http://www.liberalismen.dk" target="_blank">www.liberalismen.dk</a>
</pre>
</div>
</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>
<p><br>
</p>
<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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><p>--------------------- Med Liberalistiske Hilsner ----------------------</p><pre cols="72"> 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 - <a href="http://www.liberalismen.dk" target="_blank">www.liberalismen.dk</a>
</pre></div></div>