30 Oct
2020
30 Oct
'20
10:10 a.m.
On 29 Oct 2020, at 21:51, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
On 10/29/20 4:48 PM, Noah Mehl wrote:
Alex - aren’t you thinking UDP now?
For TCP, responses go the path of the request, back on the same socket that is already
open. From RFC 3261:
18.2.2 <https://tools.ietf.org/html/rfc3261#section-18.2.2> Sending Responses
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 [4 <https://tools.ietf.org/html/rfc3261#ref-4>] for servers in order to
determine the IP address and
port to open the connection and send the response to.
/O
Or the expectation is that the receiving side
will send replies to
port 5060 (which I guess is broken in Freeswitch sometimes?)
That is precisely the
expectation, because dispatcher doesn't keep dedicated listeners for replies to its
own OPTIONS requests.
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.