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

Andreas Granig agranig at sipwise.com
Sat May 17 13:42:28 CEST 2014


Hi,

There finally was some progress on the ice-lite issue in Firefox over
the last week or two (after the bug report got stuck for months), so I'd
expect Firefox nightly to properly work with ice-lice in a couple of
days or so.

Andreas

On 05/17/2014 02:30 AM, Alexey Rybalko wrote:
> 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
> <mailto: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.
> 
> 
> 
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> 



More information about the sr-users mailing list