Hello,
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.
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:
SIP/2.0 481 Unknown Dialog.
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:
From: "Front Door"
<sip:32221660@194.255.22.44:5071>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
To: <sip:004540294149@127.0.0.1:5071>;tag=12003375157297.
Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
And the BYE:
From: "Front Door"
<sip:u0@192.168.2.9>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
To:
sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297.
Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
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.
Cheers,
Daniel
On 06.11.20 09:31, Kjeld Flarup wrote:
Thanks Juha
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.
It receives a 200 OK on port 37148, and then establishes 37150 to
reply with an ACK.
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.
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.
Now my next question is, what makes a Kamailio detect this change?
Is it a problem that I only rewrite To and From in the INVITE, thus
the ACK contains some other values.
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).
Can I do anything to prevent a NAT timeout from the client side?
Another thing. I assume that sending my internal port in the From
field, or any kind of advertising, should be ignored by the server.
Regards Kjeld
Den fre. 6. nov. 2020 kl. 07.45 skrev Juha Heinanen <jh(a)tutpro.com
<mailto:jh@tutpro.com>>:
Kjeld Flarup writes:
How is TCP SIP actually supposed to handle a BYE,
when the
client is
behind NAT.
Client behind NAT is supposed to keep its TCP connection to SIP Proxy
alive and use it for all requests of the call. If the connection
breaks
for some reason, the client sets up a new one for the remaining
requests.
-- Juha
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
--------------------- 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 -
www.liberalismen.dk
<http://www.liberalismen.dk>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)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