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 <rfu...@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@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >
_______________________________________________ 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
