Call issues with Firefox 34 beta on Mac

[capi...@gmail.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]

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]

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]

Thanks for the help. I will look through the Freeswitch logs and see if anything sticks out.

[lu...@eternite.org]

Same problem here.

Did you find a way ?

[capi...@gmail.com]

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]

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]

Thanks for the explanation. Good to know.

And Thanks for your work.

--

Ludovic RATEAU

[capi...@gmail.com]

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]

Can you link to the thread? I am in the process of creating a bug report for them.

Thanks,

-Eric Green

[Chad Pilkey]

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]

You can track a bug report that I filed with FreeSWITCH: https://freeswitch.org/jira/browse/FS-6955

-Eric Green

[Eric Green]

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.