26 Feb
2014
26 Feb
'14
11:22 a.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users