<div dir="ltr">I see, basically "it's complicated" with TCP. Thanks for the detailed explanation. Using ipops resolution would be detrimental, I will look into the hash table suggestion.<div><br></div><div>Thanks!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at 1:48 PM Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>> wrote:<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>what's in kamailio memory related to a tcp connection may not be
      its actual state, because the kernel/tcp stack can be in
      reconnecting state without notifying the application layer. It can
      take up to a few minutes to get to timeout and report connection
      is closed. So I am not sure you can avoid send failure in
      t_relay(), and thus overall benefits could be minimal.</p>
    <p>Anyhow, look at the tcpops module, there is a function to get
      connection id by peer address/port, which you can get with
      next-hop variable before t_relay() (provided is not going to be
      fqdn, which may require mixing in ipops module).</p>
    <p>An alternative, if you need it for requests within dialog, you
      can use hash table to store the connection ID using call-id as key
      when processing the initial subscribe/invite, then you can
      retrieve it for bye/notify/...</p>
    <p>Cheers,<br>
      Daniel<br>
    </p>
    <div>On 02.11.20 19:04, Sergiu Pojoga wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi Daniel,
        <div><br>
        </div>
        <div>In my case it's for an edge proxy scenario doing transport
          conversion, UDP backend to TCP/TLS client. So it would be
          after loose_route() followed by t_relay(). The initial TCP
          connection is established when a phone SUBSCRIBEs, later on
          the backend sends the in-dialog NOTIFY which often fails
          because the client & TCP connection is gone by now,
          causing a t_relay() failure.
          <div><br>
          </div>
          <div>Thanks. Regards,</div>
          <div>--Sergiu</div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at 12:29
          PM Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>>
          wrote:<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>do you need it in a generic way, or after some specific
              operations like lookup("location")?</p>
            <p>Cheers,<br>
              Daniel<br>
            </p>
            <div>On 01.11.20 16:45, Sergiu Pojoga wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="ltr">Hi there,<br>
                <div><br>
                </div>
                <div>Is there a PV that exposes the outgoing TCP
                  connection ID? $conid seems to be for received only.</div>
                <div><br>
                </div>
                <div><i>$conid - The TCP connection ID of the connection
                    the current message arrived on for TCP, TLS, WS, and
                    WSS. Set to $null for SCTP and UDP.</i><br>
                </div>
                <div><br>
                </div>
                <div>The objective is to check the status of the egress
                  TCP connection like for e.g.:</div>
                <div>
                  <div style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Consolas,"Courier New",monospace;font-size:14px;line-height:19px;white-space:pre-wrap"><div><span style="color:rgb(86,156,214)">if</span>(!tcp_conid_state(<span style="color:rgb(206,145,120)">conid</span>)) {</div></div>
                </div>
                <div><br>
                </div>
                <div>Thanks.</div>
                <div>--Sergiu</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>
      <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>