[SR-Users] kamailio with mediaproxy-ng, 488 Not Acceptable Here

[Richard Fuchs]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140222/a9df7e19/attachment.pgp>