16 May
2014
16 May
'14
8:30 p.m.
Hi Richard!
Just have tried an outgoing call to Chrome and Opera and it works fine.
Thank you for the clarification regarding ICE! Dump files and rtp logs
(Firefox, Chrome) I've sent to your email.
My little investigation brings the following :
- browsers (Firefox, Chrome and Opera) don't use "a=ice-lite" in their
SDP;
- Chrome and Opera take the role of ICE-CONTROLLING and provide
USE-CANDIDATE for the ICE-Lite peer (mediaproxy) for both "offer" and
"answer" cases;
- Firefox takes the role of ICE-CONTROLLING and provide USE-CANDIDATE in
case of the "offer" while it takes the role of ICE-CONTROLLED during the
"answer";
/means no media from WebRTC UA in the latter case/
Some other remarks.
During the call from Fire I saw a lot of "SRTP output wanted, but no crypto
suite was negotiated" messages from rtpengine. However DTLS is finally was
established. Is that one more issue of Firefox?
Looking in STUN section of the dump files I wonder why Chrome use more than
10 binding request (USE-CANDIDATE) for each candidate while Mozilla does
it just once.
regards,
Alexey
2014-05-16 14:53 GMT+04:00 Richard Fuchs <rfuchs(a)sipwise.com>om>:
There's nothing wrong with the SDP bodies that I can see. I recall that
Firefox had or still has a problem with ICE role switching when ice-lite
is offered. It never completes ICE negotiation (never sends an STUN
packet with "use candidate") and so never starts DTLS handshake.
You can confirm that by doing a packet capture including the RTP ports
and inspecting the STUN packets. Chrome shouldn't have that problem
though, perhaps do another test run with it? You can send those capture
files to me if you'd like me to have a look.