<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 29 Oct 2020, at 21:51, Alex Balashov <<a href="mailto:abalashov@evaristesys.com" class="">abalashov@evaristesys.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 10/29/20 4:48 PM, Noah Mehl wrote:<br class=""><br class=""><blockquote type="cite" class="">Or the expectation is that the receiving side will send replies to<br class="">port 5060 (which I guess is broken in Freeswitch sometimes?)<br class=""></blockquote>That is precisely the expectation, because dispatcher doesn't keep dedicated listeners for replies to its own OPTIONS requests.<br class=""><br class="">That's what I meant about asymmetric signalling: it is completely legal to send from an actual port of Y while having a Via header that says "hit me back at port X". That's exactly what FS should do.<br class=""><br class=""></div></div></blockquote><div>Alex - aren’t you thinking UDP now?</div><div><br class=""></div>For TCP, responses go the path of the request, back on the same socket that is already open. From RFC 3261:</div><div><br class=""></div><pre class="newpage" style="font-size: 13.333333015441895px; margin-top: 0px; margin-bottom: 0px; break-before: page;"><span class="h4" style="display: inline; font-size: 1em; font-weight: bold;"><h4 style="display: inline; font-size: 1em;" class=""><a class="selflink" name="section-18.2.2" href="https://tools.ietf.org/html/rfc3261#section-18.2.2" style="color: black; text-decoration: none;">18.2.2</a> Sending Responses</h4></span>
The server transport uses the value of the top Via header field in
order to determine where to send a response. It MUST follow the
following process:
o If the "sent-protocol" is a reliable transport protocol such as
TCP or SCTP, or TLS over those, the response MUST be sent using
the existing connection to the source of the original request
that created the transaction, if that connection is still open.
This requires the server transport to maintain an association
between server transactions and transport connections. If that
connection is no longer open, the server SHOULD open a
connection to the IP address in the "received" parameter, if
present, using the port in the "sent-by" value, or the default
port for that transport, if no port is specified. If that
connection attempt fails, the server SHOULD use the procedures
in [<a href="https://tools.ietf.org/html/rfc3261#ref-4" title=""SIP: Locating SIP Servers"" class="">4</a>] for servers in order to determine the IP address and
port to open the connection and send the response to.</pre><div class=""><br class=""></div><div class="">/O</div></body></html>