rtcp-mux changing on re-INVITE about rtpengine HOT 4 CLOSED

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.

from rtpengine.

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.

from rtpengine.

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.

from rtpengine.

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.

from rtpengine.