<div dir="ltr"><div>Hello,</div><div><br></div><div>This is on the 3.1.3~20210731~b333a222f-1 from the Debian 3.1-nightly repo.</div><div><br></div><div>Typically I run with</div><div><br></div><div><span style="font-family:monospace">  modparam("tm", "auto_100trying", 0)</span></div><div><br></div><div>so I can manually send a 100 with</div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">  sl_send_reply(100, "Trying");</span></div><div><br></div><div>earlier in the script, before blocking processes like DB lookups and such.  No problem...until today.  On a TCP (TLS) connection, the <span style="font-family:monospace">sl_send_reply()</span> function opens a new TCP socket to the UAC on the IP:port listed in the original message's Contact, rather than sending the 100 on the existing socket (using the ephemeral port) the UAC used for its TCP socket to us.  Future downstream replies are relayed back upstream to the ephemeral port.  In other words, only the 100 Trying message from <span style="font-family:monospace">sl_send_reply()</span> is opening a new socket back upstream.</div><div><br></div><div>The <span style="font-family:monospace">auto_100trying</span> option from tm, however, sends its 100 messages to the ephemeral port of the UAC.</div><div><br></div><div>How can I get the <span style="font-family:monospace">sl_send_reply()</span> function to reply on the existing TCP socket?</div><div><br></div><div><br></div><div>Regards,</div><div>Jeff</div><div><br></div></div>