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


_______________________________________________
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