<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <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 class="moz-txt-link-rfc2396E" href="sip:32221660@194.255.22.44:5071"><sip:32221660@194.255.22.44:5071></a>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.<br>
      To: <a class="moz-txt-link-rfc2396E" href="sip:004540294149@127.0.0.1:5071"><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 class="moz-txt-link-rfc2396E" href="sip:u0@192.168.2.9"><sip:u0@192.168.2.9></a>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.<br>
      To:
<a class="moz-txt-link-freetext" href="sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297">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 class="moz-cite-prefix">On 06.11.20 09:31, Kjeld Flarup wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACRoYp-i-OaTSf6vMaq4kcBKF4i1rLvvqeThWe4zzu_OWFoxpw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
            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" 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>