On 02/22/14 07:07, Mihai Marin wrote:
Hello Sirs, Sir Richard, Thank you for your detailed explication. I'm still thinking on that but I would say to act as the caller and keep caller decision. If caller makes an offer with rtcp-mux , include separate ICE candidates for RTCP for media proxy too and forward as it is to alice. If callee accept it (or not) you will receive the OK with alice sdp, modify it (depending on her choices) and forward to bob. In this way, we cover all the cases. Eventually we can add another parameter to always ignore rtcp-mux offers.
What are the disadvantages on doing that? Is there any possibility that some SIP clients not to respond properly to an SDP with rtcp-mux and that's why you are removing it - or for '+' case where delay will be added?
Compatibility is exactly the reason. I don't have any exact numbers, but I'm sure that there's a large number of SIP/RTP clients out there (I'd say the vast majority) which don't support rtcp-mux at all. Some of them might start misbehaving if they receive an rtcp-mux offer (even though as per RFC, they shouldn't, but experience shows that RFC compliance is often just wishful thinking). Since from our point of view (always either '+' or '-') there's no disadvantage in always demuxing RTCP, this was what was implemented.
In any case, I'll see if I can get a solution implemented in the near future.
cheers