Call issues with Firefox 34 beta on Mac

130 views
Skip to first unread message

capi...@gmail.com

unread,
Oct 27, 2014, 4:45:27 PM10/27/14
to sip...@googlegroups.com
We just recently tried the WebRTC portion of our application with Firefox 34-beta on Mac and after sending the invite call the library fires the 'accepted' event, but no audio is played in the browser. The audio is sent to the sever because other clients can hear the Mac client, but the Mac client can't hear anything coming back. Firefox 33 and Chrome 38 both work fine on the same machine. We've tested with different Macs on different networks and the problem is the same on all of them. The result was the same when testing with your demo-phone website (http://sipjs.com/demo-phone/) and I put in our server information.

A console log can be found here, http://pastebin.com/8JX3PwEP, from when I tested the call functionality with your demo-phone website. I cleaned the actual domain name from the log as it is a public server, but I can provide it in private if needed.

Chad

capi...@gmail.com

unread,
Oct 27, 2014, 5:18:38 PM10/27/14
to sip...@googlegroups.com, capi...@gmail.com
It looks like Firefox 34-beta doesn't work on Windows either. Other clients can hear the Firefox user, but the Firefox user can't hear anything coming back.

Here is a log from the Windows machine, http://pastebin.com/npRfk7Nx, while using the same demo-phone website.

Chad

Joseph Frazier

unread,
Oct 27, 2014, 5:27:29 PM10/27/14
to sip...@googlegroups.com, capi...@gmail.com
Hi Chad,

In both of those logs, a=recvonly appears in the audio section of the answer SDP, indicating that the server is not sending audio to Firefox. Perhaps your server is treating Firefox's offer differently than the other browsers? 

Joseph

capi...@gmail.com

unread,
Oct 27, 2014, 6:22:40 PM10/27/14
to sip...@googlegroups.com, capi...@gmail.com
Thanks for the help. I will look through the Freeswitch logs and see if anything sticks out.

lu...@eternite.org

unread,
Oct 28, 2014, 2:01:07 PM10/28/14
to sip...@googlegroups.com, capi...@gmail.com
Same problem here.

Did you find a way ?

capi...@gmail.com

unread,
Oct 28, 2014, 2:59:46 PM10/28/14
to sip...@googlegroups.com, capi...@gmail.com, lu...@eternite.org
I haven't been able to find a fix. I did notice something odd from the Freeswitch cli though. Freeswitch shows the remote SDP as "a=sendonly" and then Freeswitch shows "a=sendrecv" for the SDP that it sends back. I'm not too familiar with the signalling structure so it's possible that I'm reading the logs incorrectly.

The full Freeswitch log can be found here, http://pastebin.com/iMGFByS0.

Will Mitchell

unread,
Oct 28, 2014, 3:24:00 PM10/28/14
to sip...@googlegroups.com, capi...@gmail.com, lu...@eternite.org
It looks like Firefox is no longer specifying a valid IP address in the `c=` line in its SDP.  The c line specifies where the remote party should send media.  Leaving this as 0.0.0.0 *should* be okay, as ICE negotiation will take precedence.  Any IP address specified in the c line would serve as a fallback, I believe, in case the other endpoint doesn't support ICE.  FreeSWITCH (and I'm guessing other endpoints as well) sees this 0.0.0.0 IP address and assumes that Firefox doesn't want to receive any media.  Since FreeSWITCH does support ICE negotiation, I would count this as a FreeSWITCH bug.  It seems odd that Firefox would change this now, though.

In any case, looks like this calls for an addition to our Hacks file.  This is the second "a=sendrecv vs c=..." conflict we've had, so our behavior, browsers' behavior, and servers' behavior may be up for a full review.  In any case, we'll be sure to get this sorted ahead of Firefox Beta hitting production, likely in the form of a hackCLineIP parameter or something.

Stay tuned for updates...

-Will

Ludovic RATEAU

unread,
Oct 28, 2014, 4:11:18 PM10/28/14
to Will Mitchell, sip...@googlegroups.com, capi...@gmail.com
Thanks for the explanation. Good to know.

And Thanks for your work.

--
Ludovic RATEAU

capi...@gmail.com

unread,
Oct 28, 2014, 5:19:37 PM10/28/14
to sip...@googlegroups.com, capi...@gmail.com, lu...@eternite.org
I just posted a message to the freeswitch-users mailing list with the information about the changes to the "c" line in Firefox. Hopefully they can shed some light on the problem.

Firefox 34 isn't scheduled to be released until November 24th so it's possible it is a bug on their side and it will be fixed at some point.

Eric Green

unread,
Oct 28, 2014, 7:48:59 PM10/28/14
to sip...@googlegroups.com, capi...@gmail.com, lu...@eternite.org
Can you link to the thread? I am in the process of creating a bug report for them.

Thanks,
-Eric Green

Chad Pilkey

unread,
Oct 28, 2014, 7:59:34 PM10/28/14
to Eric Green, sip...@googlegroups.com, lu...@eternite.org
You can find the thread here, http://lists.freeswitch.org/pipermail/freeswitch-users/2014-October/108879.html. Anthony replied with a couple of things to try and Freeswitch is showing both read and write traffic for the session that isn't receiving audio. I also tried the suggestion in his second reply, but that didn't appear to make a difference. The only thing I didn't try was capturing packets with Wireshark to see if the data is reaching my local client.

Eric Green

unread,
Oct 30, 2014, 11:43:05 AM10/30/14
to sip...@googlegroups.com, eric....@onsip.com, lu...@eternite.org, capi...@gmail.com
You can track a bug report that I filed with FreeSWITCH: https://freeswitch.org/jira/browse/FS-6955

-Eric Green

Eric Green

unread,
Nov 24, 2014, 5:35:48 PM11/24/14
to sip...@googlegroups.com, eric....@onsip.com, lu...@eternite.org, capi...@gmail.com
To keep SIP.js compatibility and Firefox 34 releasing next week, I added a hack and we have release 0.6.4 to address this. Try grabbing tagged release 0.6.4 and see if it fixes your issue. I have tested it here and get 2 way audio with Firefox 34 Beta now.
Reply all
Reply to author
Forward
0 new messages