[SR-Users] [rtpengine] No media from WebRTC UA

[Alexey Rybalko]

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 at sipwise.com>:

>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140517/5c1ff67d/attachment.html>