[OpenSIPS-Users] socket_in(port) vs socket_in(advertised_port)

[Ross McKillop]

On 16 Nov 2022, at 11:35, Liviu Chircu <liviu at opensips.org> wrote:
> 
> On 25.10.2022 19:11, Ross McKillop via Users wrote:
>> 
>> I would have expected $socket_in(port) to contain the actual port that was used (53235) and $socket_in(advertised_port) to contain the port that is advertised as the listening port for that socket (e.g. 7700) - however $socket_in(port) contains 7700 and $socket_in(advertised_port) is null. 
>> 
>> Is this the intended behaviour and, if so, is there any way to access the *actual* destination port that was used (even if it’s ephemeral)?
>> 
>> Any advice anyone can offer would be much appreciated :)
> 
> Hey, Ross!
> 
> Regarding $socket: there is the READ-ONLY $socket_in [1], concerning the ingress traffic and $socket_out [2], READ-WRITE and fully optional, controlling the egress traffic.  And an OpenSIPS listener MAY additionally have an "advertised" component, for scenarios where it's sitting behind a NAT.
> I can't think of many good ways of fetching/printing the ephemeral source port allocated by the Operating System for a TCP connection:
> * Request time: you cannot print it while processing the INVITE since the source port is not even allocated until you run the very last t_relay()
> * Reply time: replies will be routed using topmost Via, so *maybe* you have a chance at printing this port, by looking at the topmost Via header (OpenSIPS-generated), using transformations [3].  Even if OpenSIPS strips this header during loose_route(), you should still have access to it thanks to the "SIP message lumps" lazy evaluation mechanism.

Thanks for this! 

> Still: may I ask why you need the "egress ephemeral source port" information?  Maybe there is an alternative to the problem itself!

Looking at replacing something that already has it with OpenSIPS and trying to minimise the changes, but you’re right, it’s often the case that there might be a better way to achieve the same outcome! 

The only thing I do wish I was able to achieve (although,  off-topic for this thread) is being able to change the listening ports without a restart (e.g. make an MI request to start listening on a new socket or close one) but can’t imagine there’s much demand for that! 

Best,
Ross