<div dir="ltr">Hello Sirs, Sir Richard,<div>This is working perfect. I have tried the following test cases:</div><div>1. WS - WS in intranet; PASSED</div><div>2. WS - WS in different networks, both with restrictive firewalls: PASSED</div>
<div>3. WS - SIP Client (Boghe, Jitsi) in intranet: PASSED</div><div>4. WS - IMSDroid, both with restrictive firewalls: PASSED</div><div>5. WS - Linphone (intranet/internet): FAILED, video not receiving from WS to Linphone (Linphone does not receive video)</div>
<div>6. Linphone - Linphone in different networks, both with restrictive firewalls: PASSED</div><div><br></div><div>So, we have very good results. I'm loving it :)</div><div><br></div><div>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.</div>
<div><br></div><div>Thank you.</div><div><br></div><div>Best regards,</div><div>Mihai M</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 24, 2014 at 9:39 PM, Richard Fuchs <span dir="ltr"><<a href="mailto:rfuchs@sipwise.com" target="_blank">rfuchs@sipwise.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 02/22/14 07:07, Mihai Marin wrote:<br>
> Hello Sirs, Sir Richard,<br>
</div><div class="">> Thank you for your detailed explication.<br>
> I'm still thinking on that but I would say to act as the caller and keep<br>
> caller decision. If caller makes an offer with rtcp-mux ,<br>
> include separate ICE candidates for RTCP for media proxy too and forward<br>
> as it is to alice. If callee accept it (or not) you will receive the OK<br>
> with alice sdp, modify it (depending on her choices) and forward to bob.<br>
> In this way, we cover all the cases. Eventually we can add another<br>
> parameter to always ignore rtcp-mux offers.<br>
<br>
</div>Alright, can you please update your 3.0 branch from git and try with<br>
this. The rtcp-mux default now is to go along with the client's choice,<br>
which I believe should fix your use case.<br>
<br>
On the other hand, it may break the usual WebRTC<>non-WebRTC bridging<br>
case, depending on how picky the WebRTC client is. To accommodate for<br>
this, there's a set of new flags within the control protocol to do<br>
things like accepting rtcp-mux when the other client doesn't accept it,<br>
removing an rtcp-mux offer from SDP, offering it when it wasn't offered,<br>
offering it but rejecting it on the other side, and all kinds of other<br>
scenarios (which may or may not collide with how ICE candidates are<br>
handled). I'll see if I can get those implemented into the rtpproxy-ng<br>
module soon for those who may need them.<br>
<br>
cheers<br>
<br>
<br>_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br></blockquote></div><br></div>