#248 Cannot voice call (Jingle) from Google web client to clients connected to a prosody server
Reporter
javitonino
Owner
MattJ
Created
Updated
Stars
★★ (3)
Tags
Status-CantFix
Type-Other
Interoperability
javitonino
on
When using the voice chat plugin inside Gmail, any call initiated from the web client to any user under a prosody server fails (the reverse works). The problem is that the web client is not standard compliant and sends the following stanza:
<iq id='D0E524EEBF8F17FA' type='set' to='---' from='---'>
<jingle xmlns='urn:xmpp:jingle:1' initiator='---' action='session-initiate' sid='c1595313078'>
[snip payload-type list]
</jingle>
<session id='c1595313078' type='initiate' xmlns='http://www.google.com/session' initiator='---'>
[snip payload-type list]
</session>
</iq>
Both tags (jingle & session) seem to contain mostly the same information encoded slightly different, so it probably does that for compatibility with older versions.
This is an IQ stanza with two children which contradicts RFC6120, Section 8.2.3:
5. An IQ stanza of type "get" or "set" MUST contain exactly one
child element, which specifies the semantics of the particular
request.
Prosody drops the message and sends an error result, which is correct but blocks jingle calls initiating from the google web client.
Maybe a workaround can be added for this? If not, documentation of the problem would be helpful.
MattJ
on
Ouch, that stanza is painful to see. I'll say straight up that there is no way any official version of Prosody will ever allow this kind of thing through. That an <iq> contains a single child element is an assumption throughout the codebase (because that's how iq's were designed to work).
Since this is a client<->client stanza though Prosody probably won't actually look at it (unless you have some plugin that you might intercept iq stanzas) so you may be able to get away with it in this instance without anything breaking. I've attached a patch against trunk that simply removes the validity check (completely untested).
I'll chase a few people and dig into this issue more, I'll leave it open in the meantime to keep folks updated, even though it clearly isn't a Prosody bug.
Patch tested and working. I've also reported the bug to Google, but meanwhile, this workaround can be used.
yanjun@yahoo.com
on
Looks like libjingle uses hybrid protocol by default, which will cause the client sending 2 xml elements in iq stanza. You can change line 845 of talk/p2p/base/session.cc from PROTOCOL_HYBRID to PROTOCOL_JINGLE.
MattJ
on
Closing this - it's not a Prosody bug, and I don't think it's on Google's roadmap to fix it now that they are moving everyone over to their 'Hangouts' clients.
When using the voice chat plugin inside Gmail, any call initiated from the web client to any user under a prosody server fails (the reverse works). The problem is that the web client is not standard compliant and sends the following stanza: <iq id='D0E524EEBF8F17FA' type='set' to='---' from='---'> <jingle xmlns='urn:xmpp:jingle:1' initiator='---' action='session-initiate' sid='c1595313078'> [snip payload-type list] </jingle> <session id='c1595313078' type='initiate' xmlns='http://www.google.com/session' initiator='---'> [snip payload-type list] </session> </iq> Both tags (jingle & session) seem to contain mostly the same information encoded slightly different, so it probably does that for compatibility with older versions. This is an IQ stanza with two children which contradicts RFC6120, Section 8.2.3: 5. An IQ stanza of type "get" or "set" MUST contain exactly one child element, which specifies the semantics of the particular request. Prosody drops the message and sends an error result, which is correct but blocks jingle calls initiating from the google web client. Maybe a workaround can be added for this? If not, documentation of the problem would be helpful.
Ouch, that stanza is painful to see. I'll say straight up that there is no way any official version of Prosody will ever allow this kind of thing through. That an <iq> contains a single child element is an assumption throughout the codebase (because that's how iq's were designed to work). Since this is a client<->client stanza though Prosody probably won't actually look at it (unless you have some plugin that you might intercept iq stanzas) so you may be able to get away with it in this instance without anything breaking. I've attached a patch against trunk that simply removes the validity check (completely untested). I'll chase a few people and dig into this issue more, I'll leave it open in the meantime to keep folks updated, even though it clearly isn't a Prosody bug.
Attachments- prosody-accept-invalid-iq.patch
ChangesPatch tested and working. I've also reported the bug to Google, but meanwhile, this workaround can be used.
Looks like libjingle uses hybrid protocol by default, which will cause the client sending 2 xml elements in iq stanza. You can change line 845 of talk/p2p/base/session.cc from PROTOCOL_HYBRID to PROTOCOL_JINGLE.
Closing this - it's not a Prosody bug, and I don't think it's on Google's roadmap to fix it now that they are moving everyone over to their 'Hangouts' clients.
Changes