[SR-Users] Confusion about TCP worker ports

[Olle E. Johansson]

> On 29 Oct 2020, at 21:51, Alex Balashov <abalashov at evaristesys.com> wrote:
> 
> On 10/29/20 4:48 PM, Noah Mehl wrote:
> 
>> 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.
> 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201030/ca2a2956/attachment.htm>