rtcp-mux changing on re-INVITE

[alexcme]

I'm testing standalone rtpengine with webRTC client (RTP/SAVPF) and legacy devices (RTP/AVP) and see a problem in the following scenario:

1. Offer from webRTC (RTP/SAVPF) client send to rtpengine with offer[rtcp-mux] = demux, offer[ICE] = remove, offer[transport-protocol] = RTP/AVP
2. SDP received from engine and sent to legacy client
3. Answer received from legacy client and sent to engine with answer[ICE]=force (optional), answer[transport-protocol]=RTP/SAVPF (optional), answer[rtcp-mux]=reject, offer
4. rtpengine return correct SDP for answer where the same port used for RTP and RTCP and with single candidate for that addres:port:

m=audio 30074 RTP/SAVPF 0
a=rtcp:30074
a=rtcp-mux
a=candidate ... 30074 typ host

Now, when I receive re-INVITE from legacy client (ie, the other side of the session) and send it to rtpengine as an offer with swapped from-tag and to-tag, engine return SDP with additional port allocated for RTPC and two candidates for RTP and RTCP each, ie:

m=audio 30074 RTP/SAVPF 0
a=rtcp:30075
a=rtcp-mux
a=candidate ... 30074 typ host
a=candidate ... 30075 typ host

I tried different parameters / no parameters for rtcp-mux without lack - result is always the same.

[rfuchs]

This is by design. When offering rtcp-mux, the SDP must contain fallback RTCP attributes in case the answering client doesn't understand rtcp-mux and/or wishes not to multiplex. Only in the answer these attributes may be omitted. See RFC 5761.

[alexcme]

Would have to agree, it did not break functionality, but, on session refresh it does looks like unfortunate to get an additional (unused) port allocated.

[rfuchs]

The port is "used" anyway, it gets allocated on the initial offer. It has to be, due to the mentioned fallback mechanism. Even if you were to deallocate it after it's confirmed to go unused, you couldn't use it for much else as it's an odd-numbered port. You could use it for another session only if there were some kind of "WebRTC only" or "rtcp-mux only" mode of operation, which doesn't exist.

[alexcme]

Ooops, found it, using query after everyoffer/answer transaction :) little bit confusing though, and helpful to know as I need to allocate / enable available ports range in advance, would be nice I think to comment it in description.