socket allocated (SOCKET_REPLY) in technical docs is wrong?

[vasilakisfil]

Hello again,

Another thing that I noticed while building the Rust lib, is that the socket reply that the technical docs describe does not seem to match the human-oriented documentation or the actual response I get from rtpproxy: in both cases I get just the port number, nothing about the IP address.

I assume the technical documentation is out of date ? Or is there any special case that I might get an IP as well?

[vasilakisfil]

I think I found something from Kamailio's code in rtpproxy module. If I read the code right though, I think the docs are wrong. Basically these are the cases:

• just port (like 5060): RTPProxy keeps the same AF as the request sent (so if it's IPv4, port is also in IPv4 // if it's IPv6 port is also in IPv6).
• port with IP (like 5060 127.0.0.1): according to Kamailio, for historical reasons if RTPProxy returns a bare address (port + IP), then it is assumed that the IP address is in IPv4)
• port with IP + '6' (like 5060 ::1 6): 6 here denotes that it's an IPv6.

In practice, in Rust parsing just the IP address using STD is possible to figure out if it's IPv4 or IPv6, but it's nice to have a complete documentation of what RTPProxy returns.

I am closing this ticket, but would be nice to get a confirmation from @sobomax

[sobomax]

@vasilakisfil thanks for your interest and sorry for a delay with the reply. The situation with the "IP" in the response is somewhat convoluted. It stems from the fact that initially both RTPProxy and control protocol had no notion of listening on a specific IP along with the fact that rtpproxy was supposed to run on the same machine as Kamailio/OpenSIPS. In this the most simplistic mode of operation the RTPproxy would use bind(INADDR_ANY) for its RTP/RTCP ports allowing call control component to pick whatever IP it deems the most appropriate.

As the time went on, it became clear that in multi-homed scenarios as well as in cases when RTPproxy is running on a separate node it needs to communicate both IP and port back to the call controller. Perhaps I will have to review this situation and see if the behavior can be collapsed to a single case somehow.