Created attachment 20876 [details] gabble log I've tried to call someone using Empathy 2.25.2 and telepathy-gabble 0.7.16. The party at the other end is using the google web client. The connection is established successfully and I can hear him. However, he cannot hear me. But by looking at a network monitor, it appears that there is an outgoing audio stream. SIP echo tests work fine with Empathy, so it does not appear to be a local audio problem. He is behind NAT. I've tried with both public and private IP on my side, no difference. I'm attaching (redacted) logs.
Created attachment 20877 [details] stream engine log
Johan, could you please resend gabble log with LM_DEBUG=net (the XMPP data) included? The gabble logs you provided unfortunately don't tell us much :( From the stream log, I can't see why this would be happening. From log: ** (telepathy-stream-engine:12958): DEBUG: stream 1 (audio) cb_fs_state_changed: stream 0x1d9c320, state: connected, direction: none ** Message: Connected to ReadPacket ** Message: mutex is 0x1cf7890 (telepathy-stream-engine:12958): farsight-rtp-DEBUG: AUDIO - farsight_rtp_stream_transmitter_state_changed: Setting pipeline to PLAYING returned 2 (telepathy-stream-engine:12958): farsight-rtp-DEBUG: AUDIO - farsight_rtp_stream_set_playing: We are now trying to go PLAYING ** (telepathy-stream-engine:12958): DEBUG: stream 1 (audio) set_stream_sending: 1 (telepathy-stream-engine:12958): farsight-rtp-DEBUG: AUDIO - farsight_rtp_stream_set_sending: Setting sending to 1 ** (telepathy-stream-engine:12958): DEBUG: stream 1 (audio) cb_fs_state_changed: stream 0x1d9c320, state: connected, direction: send ** (telepathy-stream-engine:12958): DEBUG: stream 1 (audio) set_stream_playing: 1 ** (telepathy-stream-engine:12958): DEBUG: stream 1 (audio) set_stream_sending: 1 .. ** (telepathy-stream-engine:12958): DEBUG: stream 1 (audio) cb_fs_state_changed: stream 0x1d9c320, state: connected, direction: both So the media stream is connected, playing audio from peer, and sending audio to peer.
I have been able to reproduce the symptoms of the bug, and was able to "fix" the bug by disabling speex codec in my /etc/farsight/gstcodecs.conf (by setting id=-1 for speex). As the rest of the log seems fine, Johan please try this, and if it does work around the problem, then we can conclude the problem is in incompatible speex codecs between farsight/gstreamer and google.
I can confirm that deleting speex from gstcodecs.conf makes the audio work in both directions. Thank you for looking into this.
I think we've had problems with speex in the past. Adding the mailing list as QA contact in the hope that this is familiar to someone... perhaps there's a particular version of gstreamer-plugins-something that you need?
So, I just successfully made a call between Empathy and GMail (on a Mac), and verified that Speex was in use. So this issue seems to have gone away. I asked the internet's Olivier Crête and he doesn't recall an issue around Speex… so anyway, I'm going to resolve this WORKSFORME. If this is still an issue, please reopen.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.