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

[Mihai Marin]

Hello Sirs, Sir Richard,
This is working perfect. I have tried the following test cases:
1. WS - WS in intranet; PASSED
2. WS - WS in different networks, both with restrictive firewalls: PASSED
3. WS - SIP Client (Boghe, Jitsi) in intranet: PASSED
4. WS - IMSDroid, both with restrictive firewalls: PASSED
5. WS - Linphone (intranet/internet): FAILED, video not receiving from WS
to Linphone (Linphone does not receive video)
6. Linphone - Linphone in different networks, both with restrictive
firewalls: PASSED

So, we have very good results. I'm loving it :)

I'll dig into the problem with Linphone to try to figure out what's the
problem. I'll be back with news but until now looks very good.

Thank you.

Best regards,
Mihai M



On Mon, Feb 24, 2014 at 9:39 PM, Richard Fuchs <rfuchs at sipwise.com> wrote:

> 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
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140226/a9b00c56/attachment.html>