[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.

Alright, can you please update your 3.0 branch from git and try with
this. The rtcp-mux default now is to go along with the client's choice,
which I believe should fix your use case.

On the other hand, it may break the usual WebRTC<>non-WebRTC bridging
case, depending on how picky the WebRTC client is. To accommodate for
this, there's a set of new flags within the control protocol to do
things like accepting rtcp-mux when the other client doesn't accept it,
removing an rtcp-mux offer from SDP, offering it when it wasn't offered,
offering it but rejecting it on the other side, and all kinds of other
scenarios (which may or may not collide with how ICE candidates are
handled). I'll see if I can get those implemented into the rtpproxy-ng
module soon for those who may need them.

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/20140224/295fb9d6/attachment.pgp>