<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Daniel</p>
<p>The Record route in the INVITE from 194.247.61.26 sets this pair<br>
</p>
<p>Record-Route:
<a class="moz-txt-link-rfc2396E" href="sip:194.255.22.44:7071;transport=tcp;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1"><sip:194.255.22.44:7071;transport=tcp;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1></a><br>
Record-Route:
<a class="moz-txt-link-rfc2396E" href="sip:194.255.22.44:7071;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1"><sip:194.255.22.44:7071;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1></a></p>
<p>The Bye requests this route<br>
</p>
<p>Route:
<a class="moz-txt-link-rfc2396E" href="sip:194.255.22.44:7071;transport=tcp;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1"><sip:194.255.22.44:7071;transport=tcp;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1></a><br>
Route:
<a class="moz-txt-link-rfc2396E" href="sip:194.255.22.44:7071;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1"><sip:194.255.22.44:7071;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1></a><br>
</p>
<p>But the real port on 194.255.22.44 is 36059</p>
<p>It is my invite to 194.247.61.26 that sets the 7071 port, which
automatically comes from the listen statement.<br>
I suspect that it might work if the invite was using 36059, but
how can I know this port, if the NAT router decides to map it to
another port.</p>
<p><br>
</p>
<p>What is the correct behaviour. Should my Kamailio somehow set the
correct port?</p>
<p>Should the providers Kamailio rewrite the route information?</p>
<p>Or something else?<br>
</p>
<p><br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">-------------------- 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 - <a class="moz-txt-link-abbreviated" href="http://www.liberalismen.dk">www.liberalismen.dk</a></pre>
<div class="moz-cite-prefix">On 1/11/21 10:18 AM, Daniel-Constantin
Mierla wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d28dfb48-8f86-87dd-37c7-53523eb5362c@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>The From/To/Call-ID are not used to match the connection. The
connection is matched based on target IP and port. For BYE,
these are taken from Route header, if there is one for next hop,
otherwise it is the request URI. Check these two to see if
something is not as expected. Otherwise, you have to discuss
with the provider and see the reason it returns back the 477
response.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div class="moz-cite-prefix">On 08.01.21 20:36, Kjeld Flarup
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bdb71f5f-d1dd-ce06-414c-6064ee54720e@liberalismen.dk">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Happy New Year everyone.</p>
<p><br>
</p>
<p>I haven't solved this problem yet. Although is it not
critical, it is a bit annoying.</p>
<p>I have tried to simplify things, and have a reference setup
that works. <br>
My linphone sends a TCP call and my Asterisk answers, plays a
speak and hangs up. <br>
</p>
<p><br>
</p>
<p>If I instead sends the call to my PBX, which handles the
authentication via UAC, it fails with this error, which the
customer site also generated. </p>
<blockquote>
<p>Status-Line: SIP/2.0 477 Unfortunately error on sending to
next hop occurred (477/SL)<br>
</p>
</blockquote>
<p>Unfortunately the error is not generated by my Kamailio, but
by a Kamailio at the provider, when it gets a Bye forwarded
via their SBC. <br>
</p>
<p><br>
</p>
<p>I have attached a capture which the provider send me. This is
the setup</p>
<blockquote>
<p>linphone -> My Kamailio PBX (194.255.22.44:36089) ->
provider Kamailio(194.247.61.26) -> SBC(194.247.61.32)
-> provider Kamailio(194.247.61.26) -> my Asterisk
(194.255.22.44:45075)</p>
</blockquote>
<p>A note on the providers Kamailio. It listens on both port
5060 and 5070, and both UDP/TCP. <br>
It is also used as access point for both my PBX and my
Asterisk, thus the trace may be a little confusing to read.<br>
</p>
<p>As far as I can see, the provider Kamailio gets the correct
To/From and CallID in the bye. Thus it should be able to match
the TCP connection. <br>
The flow is also clean, there is no change of ports etc. <br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>I have this reference setup which works</p>
<blockquote>
<p>linphone -> provider Kamailio -> SBC -> provider
Kamailio -> my Asterisk</p>
</blockquote>
The only differences towards the reference I can see these. I do
not have a capture from the provider on this. <br>
<ul>
<li>There is an extra Via step.</li>
<li>Contact points to the Linphone IP, not the Kamailio IP</li>
</ul>
<p>Any hint will be appreciated.</p>
<p><br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">-------------------- 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 - <a class="moz-txt-link-abbreviated" href="http://www.liberalismen.dk" moz-do-not-send="true">www.liberalismen.dk</a></pre>
<div class="moz-cite-prefix">On 11/9/20 12:06 PM,
Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a4fe56e7-2d76-2eae-1d0a-fc624ba1d528@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<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" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a class="moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" moz-do-not-send="true">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" moz-do-not-send="true">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda" moz-do-not-send="true">www.linkedin.com/in/miconda</a>
Funding: <a class="moz-txt-link-freetext" href="https://www.paypal.me/dcmierla" moz-do-not-send="true">https://www.paypal.me/dcmierla</a></pre>
</blockquote>
<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" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a class="moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" moz-do-not-send="true">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" moz-do-not-send="true">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda" moz-do-not-send="true">www.linkedin.com/in/miconda</a>
Funding: <a class="moz-txt-link-freetext" href="https://www.paypal.me/dcmierla" moz-do-not-send="true">https://www.paypal.me/dcmierla</a></pre>
</blockquote>
</body>
</html>