SRTP Stream switches ports

[AndreHeber]

rtpengine version the issue has been seen with
mr11.5.1.24

Used distribution and its version
Alpine 3.19.1

Linux kernel version used
5.10.218-208.862.amzn2.x86_64

CPU architecture issue was seen on (see uname -m)
x86_64

Expected behaviour you didn't see
SRTP stream as advertised in SDP packets

Unexpected behaviour you saw
The SRTP stream starts from another port and switches the port in the call.
The thing is: I assume that the underlying kubernetes is the reason for that behavior.

I have an incoming call and the remote wants to receive the SRTP packets at port 40110 and rtpengine wants to receive the SRTP packets at port 42046. That is advertised in the SDP packets.

From the rtpengine logs:
RTPEngine sends SRTP from port 42046 to port 40110. Then it receives the first remote SRTP packet coming from port 44701. Therefore, it sends the next SRTP packets from port 42046 to port 44701.

From the pcap (captured with tcpdump):
RTPEngine sends SRTP from port 35957 to port 40110. Then it receives the first remote SRTP packet coming from port 40110 and sent to port 42046. Then RTPEngine send the SRTP now to from port 42046 to port 40110.

I don't know why there are differences in the captured traffic and logged traffic. I investigated this and could replicate that behavior with sipp sending many calls with media to pods on different kubernetes nodes. The pods are running with hostNetwork: true, which means that the network isn't isolated.

I can also replicate that behavior on a local docker installation. As soon as I run calls in a container, I can see that behavior. When I run calls natively, everythin is fine.

Why does the SRTP stream has this behavior and how can that be avoided?

[Richard Fuchs]

On 25/06/2024 11.28, 'AndreHeber' via Sipwise rtpengine wrote:
> I have an incoming call and the remote wants to receive the SRTP
> packets at port 40110 and rtpengine wants to receive the SRTP packets
> at port 42046. That is advertised in the SDP packets.
>
> From the rtpengine logs:
> RTPEngine sends SRTP from port 42046 to port 40110. Then it receives
> the first remote SRTP packet coming from port 44701. Therefore, it
> sends the next SRTP packets from port 42046 to port 44701.
>
> From the pcap (captured with tcpdump):
> RTPEngine sends SRTP from port 35957 to port 40110. Then it receives
> the first remote SRTP packet coming from port 40110 and sent to port
> 42046. Then RTPEngine send the SRTP now to from port 42046 to port 40110.

Are you sure that it's actually rtpengine sending from a different port?
That would be extremely unusual. More likely is that rtpengine is
sending from the correct port but some NAT in between is changing it.
Double check and confirm by running tcpdump on the rtpengine host itself.

Cheers

[AndreHeber]

Hi rfuchs,

I've made the capture with tcpdump on the rtpengine pod.

That is the thing:

- the rtpengine logs are telling me that the source port, from which rtpengine is sending, is correct, but the target port, from where the remote rtp is sent from, is wrong.

- the capture is telling me that rtpengine sends from a wrong port, but sends it to the correct port.

Here are the masked logs (attached) & capture:

Thank you very much!

[Richard Fuchs]

On 25/06/2024 13.05, 'AndreHeber' via Sipwise rtpengine wrote:
> Hi rfuchs,
>
> I've made the capture with tcpdump on the rtpengine pod.
> That is the thing:
> - the rtpengine logs are telling me that the source port, from which
> rtpengine is sending, is correct, but the target port, from where the
> remote rtp is sent from, is wrong.
> - the capture is telling me that rtpengine sends from a wrong port,
> but sends it to the correct port.

I don't buy it. RTP sockets are bound to specific ports. The code
doesn't just randomly open extra sockets on random ports. And the fact
that packet #16 was obviously received means that this socket was bound
to the correct port. Even the remote ports of received packets are
reported as different ones in the log: log says the remote port is 44701
but the pcap says it's sent to 40110. There's obviously some port or
address translation going on somewhere in the network.

Cheers