<div dir="ltr">This issue has been raised on this list a number of times, either it is a bug or a feature. However, you need to explicitly provide the `proto` to force_send_socket (based on `transport=tls` and direction of your message). I know this has been documented and will even give you an error in versions 2.x. <a href="https://github.com/OpenSIPS/opensips/issues/447">https://github.com/OpenSIPS/opensips/issues/447</a><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 24, 2015 at 2:42 AM, microx <span dir="ltr">&lt;<a href="mailto:acmicrox@gmail.com" target="_blank">acmicrox@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
In my testing environment, I have one SIP outbound proxy and one internal<br>
SIP server. The SIP outbound proxy listens tls:<a href="http://172.16.1.1:5061" rel="noreferrer" target="_blank">172.16.1.1:5061</a>,<br>
udp:<a href="http://172.16.1.1:5060" rel="noreferrer" target="_blank">172.16.1.1:5060</a>, and udp:<a href="http://10.1.1.1:5060" rel="noreferrer" target="_blank">10.1.1.1:5060</a> while the SIP server listens on<br>
udp:<a href="http://10.1.1.2:5060" rel="noreferrer" target="_blank">10.1.1.2:5060</a>. For the SIP outbound proxy, tls:<a href="http://172.16.1.1:5061" rel="noreferrer" target="_blank">172.16.1.1:5061</a> and<br>
udp:<a href="http://172.16.1.1:5060" rel="noreferrer" target="_blank">172.16.1.1:5060</a> are used for receiving SIP messages from outside clients<br>
and udp:<a href="http://10.1.1.1:5060" rel="noreferrer" target="_blank">10.1.1.1:5060</a> is used for communicating with the internal SIP<br>
server.<br>
<br>
When receiving an INVITE from a caller, the SIP outbound proxy uses<br>
force_send_socket(udp:<a href="http://10.1.1.1:5060" rel="noreferrer" target="_blank">10.1.1.1:5060</a>) to relay the INVITE to the SIP server.<br>
The SIP server send the INVITE to udp:<a href="http://10.1.1.1:5060" rel="noreferrer" target="_blank">10.1.1.1:5060</a> to make SIP outbound<br>
proxy send to the callee. The SIP outbound proxy calls<br>
force_send_socket(172.16.1.1) to send the INVITE to the callee. In OpenSIPS<br>
1.9, the force_send_socket function will use udp:<a href="http://172.16.1.1:5060" rel="noreferrer" target="_blank">172.16.1.1:5060</a> if the<br>
callee registers via UDP and use tls:<a href="http://172.16.1.1:5061" rel="noreferrer" target="_blank">172.16.1.1:5061</a> if the callee registers<br>
via TLS. However, in OpenSIPS 1.11.5, the force_send_socket will use<br>
udp:<a href="http://172.16.1.1:5060" rel="noreferrer" target="_blank">172.16.1.1:5060</a> even when the callee register via TLS.<br>
<br>
How could I config OpenSIPS such that it can use the right socket to send<br>
INVITEs to callees based on the UDP or TLS the callee register via? Thanks<br>
for any comment.<br>
<br>
Best regards,<br>
Chen-Che<br>
<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://opensips-open-sip-server.1449251.n2.nabble.com/Multiple-sockets-and-force-send-socket-tp7599170.html" rel="noreferrer" target="_blank">http://opensips-open-sip-server.1449251.n2.nabble.com/Multiple-sockets-and-force-send-socket-tp7599170.html</a><br>
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Aron Podrigal<div>-</div><div>&#39;1000001&#39;, &#39;1110010&#39;, &#39;1101111&#39;, &#39;1101110&#39;   &#39;1010000&#39;, &#39;1101111&#39;, &#39;1100100&#39;, &#39;1110010&#39;, &#39;1101001&#39;, &#39;1100111&#39;, &#39;1100001&#39;, &#39;1101100&#39;</div><div><br></div><div>P: &#39;2b&#39;, &#39;31&#39;, &#39;33&#39;, &#39;34&#39;, &#39;37&#39;, &#39;34&#39;, &#39;35&#39;, &#39;38&#39;, &#39;36&#39;, &#39;30&#39;, &#39;39&#39;, &#39;39&#39;<br></div><div><br></div></div></div></div></div>
</div>