Hi All, At the risk of possibly dragging up an old thread (https://lists.kamailio.org/pipermail/sr-users/2021-June/112791.html <https://lists.kamailio.org/pipermail/sr-users/2021-June/112791.html>) I’m seeing unusual behaviour where $Rp is still showing what I think is the ‘wrong’ behaviour, but given Daniel’s reply on the earlier thread I want to be sure this isn’t the intended behaviour. The thread above confirms that $Rp is not taken from the IP layer but is intended to give the attribute of the listen socket associated with the SIP traffic, which is fine and what I’m expecting, but in my case it doesn’t seem to be working this way. (I’ve tried with and without tcp_reuse_port=yes and tcp_connection_match=1 too just in case one of the above parameters has changed this behaviour) If Kamailio listening on multiple ports e.g. listen=tcp:10.30.22.73:7701 listen=tcp:10.30.22.73:7702 listen=tcp:10.30.22.73:7703 listen=tls:10.30.22.73:7801 listen=tls:10.30.22.73:7802 listen=tls:10.30.22.73:7803 And I use $fs to force the socket of an outbound message to one of the above before t_relay() it works as expected (with tcp_reuse_port it originates from the given port number above, without that set it will originate from a different ephemeral port even to the same destination, so $fs is working as expected) Then, in reply_route{} I have a simple line to add the port it was received on to the headers (I’ve also tried with $RAp) append_hf("X-Rcvd-Port: $Rp\r\n”); In every case, the reply seems to contain the *first* port of the protocol type (so in the above example every TCP reply irrespective of whether it is to 7701/02/03 will show $Rp 7701, and every TLS reply will show 7801) Any advice or insight anyone can offer would be much appreciated. Thanks, Ross