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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
