Video call from jitsi over XMPP always fails

[xuhdev]

Any video call from Jitsi over XMPP always fail.

To reproduce, just make a video call from Jitsi, and click accept on Pidgin. After accepting the call, Pidgin pops up the video chatting dialog and disappears after 1 sec. The Jitsi dialog prompts "Error: Remote party sent an invalid Jingle answer."

A log is attached. Unrelavant account information has been purged. The call is from test AT topbug.net (on Jitsi) to hong AT topbug.net (on Pidgin).

[mazhe]

Hello, I've stumbled on this issue which I encountered recently. One of the roots of this problem is that when Pidgin send the initial jingle negociation stanza, it describe a few audio codecs having zero channels, like :

<payload-type name='PCMU' id='0' clockrate='8000' channels='0'/>
<payload-type name='PCMA' id='8' clockrate='8000' channels='0'/>

If you try something crude and horrible like the following:

--- libpurple/protocols/jabber/jingle/rtp.c.orig    2016-01-06 18:07:20.250617000 +0100
+++ libpurple/protocols/jabber/jingle/rtp.c 2016-01-06 18:12:02.832399000 +0100
@@ -750,7 +750,7 @@
        xmlnode_set_attrib(payload, "name", name);
        xmlnode_set_attrib(payload, "id", id);
        xmlnode_set_attrib(payload, "clockrate", clockrate);
-       xmlnode_set_attrib(payload, "channels", channels);
+       if (channels != 0) xmlnode_set_attrib(payload, "channels", channels);

        g_free(channels);
        g_free(clockrate);

Audio will work. The real fix would be to understand where this information is coming from: maybe some NULL pointer or default value to describe "1 channel"? I did not go far enough to see whether it was from gstreamer or farstream/farsight...

As for video, after that, I ran into more issues... But beware that you need some h264 codecs for gstreamer as jitsi only use this format for video!