One way audio due to media is sent from different src port after receiving SDP with different IP address

[eugenio-patrev]

Hello,

we faced an issue with unexpected and silent changing of a source port used for sending media. And it is crucial for us as the sip operator this media is intended for doesn't use rtp learning. Thus, it leads to one-way audio.

We use RTPEngine mr9.5.1.4 (5aa5c98) and Kamailio. Debug log with level 7 is attached.

Call flow (can be seen on the screenshot):

1. We sent INVITE, m=audio 35302.
2. The operator responded with SIP/183 ( 35.156.111.10:10266), we could hear early media.
3. Comfort noise was sent by our side using source port 35302.
4. The operator sent SIP/183 with a different IP/port in SDP: 80.84.31.129:23484. The caller could hear early media.
5. Comfort noise (and further media after the call is answered) was sent by our side using another source port 35350.
6. The operator answered the call, the caller could hear the callee, but not vice versa (the media stream from the operator side is not shown in the screenshot, but it is just sngrep issue, media stream exists: 80.84.31.129:23484 -> our port 35302). Our media was being sent from port 35350 that wasn't present in SDP, so the operator rejected the stream.

rtpengine_debug.log

[rfuchs]

You can use the port-latching option to prevent RTP port changes during a re-offer/answer.

[eugenio-patrev]

Unfortunately, it didn't help

rtpengine_debug2.log

[rfuchs]

That's because the second answer is using a different to-tag and so rtpengine opens a new set of ports. This use case (multiple provisional responses with SDPs with different to-tags) is not currently supported.

[rfuchs]

Same as #1330