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@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