<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,</p>
<p>there is no association between a SIP call and a TCP connection.
SIP is not designed on TCP streams, the forwarding is based on the
headers. It doesn't matter if there are messages belonging to same
call or not, they can share same connection, or can open a new
one...<br>
</p>
<p>The BYE from caller gets to 194.247.61.32:5040, which cannot
deliver it further based on Route header. The system at
194.247.61.26:5070 must be able to accept connections on
advertised port of the Route address. Again, connection
interruption can happen from various cases, it cannot rely on
ephemeral ports, but on what the SIP system advertises as "listen"
address.</p>
<p>One can play with tcp port aliases, look at Kamailio core
cookbook, in case 194.247.61.32:5040 can do that. But that is not
the proper way for server to server communication, there will be
cases when the connection will be cut for various reasons (can be
also the IP routes in the path that get congested).</p>
<p>Otherwise, you can follow the code of tcp_send() function in the
tcp_main.c from core to see how tcp connection is matched, there
are various cases there, also a matter of the config parameters.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div class="moz-cite-prefix">On 09.11.20 10:13, Kjeld Flarup wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACRoYp-Eknw2=8X-N+Wrs+aapDqLwZYj-WGCHiZVP-mcQXCmfg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">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"
moz-do-not-send="true">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 moz-do-not-send="true"><sip:32221660@194.255.22.44:5071></a>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.<br>
To: <a moz-do-not-send="true"><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 moz-do-not-send="true"><sip:u0@192.168.2.9></a>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.<br>
To: <a moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">sr-users@lists.kamailio.org</a><br>
<a
href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">www.asipto.com</a>
<a href="http://www.twitter.com/miconda" target="_blank" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" target="_blank" moz-do-not-send="true">www.linkedin.com/in/miconda</a>
Funding: <a href="https://www.paypal.me/dcmierla" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">www.asipto.com</a>
<a href="http://www.twitter.com/miconda" target="_blank" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" target="_blank" moz-do-not-send="true">www.linkedin.com/in/miconda</a>
Funding: <a href="https://www.paypal.me/dcmierla" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">www.liberalismen.dk</a>
</pre>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Kamailio (SER) - Users Mailing List
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a>
<a class="moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Funding: <a class="moz-txt-link-freetext" href="https://www.paypal.me/dcmierla">https://www.paypal.me/dcmierla</a></pre>
</body>
</html>