[Home]

Summary:ASTERISK-11756: [patch] There is no voice channel establishing between GoogleTalk and asterisk
Reporter:Andrey Klimov (farlake)Labels:
Date Opened:2008-03-31 03:26:31Date Closed:2008-05-06 04:57:37
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Channels/chan_gtalk
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-gtalk.log
( 1) chan_gtalk.patch
Description:The issue is absolutelly stable and blocked for GT interconnecting since Asterisk 1.4 (at least, in case of connecting from Russia to talk.google.com)

This caused, because googletalk not understands the <transport> sequence from Asterisk:

JABBER: asterisk OUTGOING: <iq from='gigasim@gmail.com/Talk48CF2B75' to='anklimov@gmail.com/Talk.v105AFCCEA63' type='set' id='aaaby'><session type='transport-info' id='3244105671' initiator='anklimov@gmail.com/Talk.v105AFCCEA63' xmlns='http://www.google.com/session'>

<transport xmlns='http://www.google.com/transport/p2p'><candidate name='rtp' address='192.168.1.2' port='65510' username='696825c97cc875ff' password='5e3ea4ef2e33b38d' preference='1.00' protocol='udp' type='local' network='0' generation='0'/></transport></session></iq>


Google returns an error:

JABBER: asterisk INCOMING: <iq type="error" to="gigasim@gmail.com/Talk48CF2B75" id="aaabx" from="anklimov@gmail.com/Talk.v105AFCCEA63"><session type="transport-accept" id="3244105671" initiator="anklimov@gmail.com/Talk.v105AFCCEA63" xmlns="http://www.google.com/session"><transport xmlns="http://www.google.com/transport/p2p"/></session><error code="501" type="cancel"><feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>


According real traces, collected beetween two GT clients and GT Client diagnostic logs, the only
understandable way to send <candidates> toward googletalk is:

SEND >>>>>>>>>>>>>>>>>>>>>>>>> : Fri Mar 14 00:28:00 2008
<iq to="vklimova@gmail.com/Talk.v939F5BB7E6" type="set" id="113">
 <session xmlns="http://www.google.com/session" type="candidates" id="255815956" initiator="anklimov@gmail.com/Talk.v105AFCCEA63">
 <candidate name="rtp" address="192.168.1.10" port="3510" username="gaWVy+jKC/KQ+mIE" password="cfhluFa53hps9tq7" preference="1" protocol="udp" type="local" network="0" generation="0"/>
 </session>
 </iq>


This approach was tested with patch attached (see Additional Info). After patching, chan_gtalk is working acceptable.
chan_gtalk contain plenty another bugs, perhaps. It is not send in <candidates> external IP, that could causes unstable voice chanel establishing in case GT client connected via https tunnel, but it requeres additional investigation.
Now it just working.

****** ADDITIONAL INFORMATION ******

# diff -Naur chan_gtalk.c.original chan_gtalk.c.patched >chan_gtalk.patch
# cat chan_gtalk.patch
--- chan_gtalk.c.original       2008-01-09 19:59:09.000000000 +0300
+++ chan_gtalk.c.patched        2008-03-31 12:19:55.000000000 +0400
@@ -723,15 +723,14 @@
       struct sockaddr_in sin;
       struct sockaddr_in dest;
       struct in_addr us;
-       iks *iq, *gtalk, *candidate, *transport;
+       iks *iq, *gtalk, *candidate;
       char user[17], pass[17], preference[5], port[7];


       iq = iks_new("iq");
       gtalk = iks_new("session");
       candidate = iks_new("candidate");
-       transport = iks_new("transport");
-       if (!iq || !gtalk || !candidate || !transport) {
+       if (!iq || !gtalk || !candidate ) {
               ast_log(LOG_ERROR, "Memory allocation error\n");
               goto safeout;
       }
@@ -740,11 +739,8 @@
       if (!ours1 || !ours2)
               goto safeout;

-       iks_insert_attrib(transport, "xmlns","http://www.google.com/transport/p2p");
       iks_insert_node(iq, gtalk);
-       iks_insert_node(gtalk,transport);
-       iks_insert_node(transport, candidate);
-
+       iks_insert_node(gtalk,candidate);
       for (; p; p = p->next) {
               if (!strcasecmp(p->sid, sid))
                       break;
@@ -801,7 +797,7 @@
               iks_insert_attrib(iq, "type", "set");
               iks_insert_attrib(iq, "id", c->mid);
               ast_aji_increment_mid(c->mid);
-               iks_insert_attrib(gtalk, "type", "transport-info");
+               iks_insert_attrib(gtalk, "type", "candidates");
               iks_insert_attrib(gtalk, "id", sid);
               iks_insert_attrib(gtalk, "initiator", (p->initiator) ? to : from);
               iks_insert_attrib(gtalk, "xmlns", GOOGLE_NS);
@@ -838,8 +834,6 @@
               iks_delete(gtalk);
       if (candidate)
               iks_delete(candidate);
-       if(transport)
-               iks_delete(transport);
       return 1;
}

@@ -1160,6 +1154,8 @@
               sin.sin_port = htons(tmp->port);
               snprintf(username, sizeof(username), "%s%s", tmp->username,
                        p->ourcandidates->username);
+//             snprintf(username, sizeof(username), "%s", tmp->username);
+

               /* Find out the result of the STUN */
               ast_rtp_get_peer(p->rtp, &aux);



===================================
# cat jabber.conf
[general]
debug=yes                               ;;Turn on debugging by default.
autoprune=no                            ;;Auto remove users from buddy list.
autoregister=yes                        ;;Auto register users from buddy list.

[asterisk]                              ;;label
type=client                             ;;Client or Component connection
serverhost=72.14.253.125 ;;talk.google.com                      ;;Route to server for example,
                                       ;;      talk.google.com
username=gigasim@gmail.com/Talk         ;;Username with optional roster.
secret=xxxxxxx                                ;;Password
port=5222                               ;;Port to use defaults to 5222
usetls=yes                              ;;Use tls or not
usesasl=yes                             ;;Use sasl or not
buddy=ank@gmail.com                ;;Manual addition of buddy to list.
statusmessage="My home PABX"            ;;Have custom status message for
                                       ;;Asterisk.
timeout=100                             ;;Timeout on the message stack.

==============

# cat gtalk.conf
[general]
bindaddr=192.168.1.2
context=google-in               ;;Context to dump call into
allowguest=yes                  ;;Allow calls from people not in
                               ;;list of peers
;
[guest]                 ;;special account for options on guest account
disallow=all
allow=ulaw
context=google-in
;

[asterisk]
username=gigasim@gmail.com

disallow=all
allow=ulaw
context=google-in
connection=asterisk             ;;client or component in jabber.conf
                               ;;for the call to leave on.
Comments:By: phsultan (phsultan) 2008-03-31 08:44:01

Wrapping 'candidates' tags in 'transport' is valid with my GoogleTalk client version (1.0.0.104).

It looks like you're running an older localized version of the GoogleTalk client. Please install the latest english version, see http://bugs.digium.com/view.php?id=10512 , thanks!

--- edit : wrong HTTP link


By: Andrey Klimov (farlake) 2008-03-31 16:02:16

Tryed to install latest available version (1.0) before. English as well. No results :(

Possible, the bug depends from the region due some Google's distributed architecture. Really spent days to recognize the root of problem.
Additionally, the google server is parsing incoming XMLs before pass it to client.
In my case, Client was not received <candidate> at all, if it wrapped by <transport>
I have a traces/logfiles from both sides to confirm this.
Can send/attach if you interested

By the way,  pls. examine logs, allached to report 10512.
It is very similar.

ABBER: asterisk OUTGOING: <iq from='user_my_by@gmail.com/asterisk6F80172B' to='chodorenko@gmail.com/Talk.v932FDE815F' type='set' id='aaaac'><session type='transport-accept' id='1787720173' initiator='chodorenko@gmail.com/Talk.v932FDE815F' xmlns='http://www.google.com/session'><transport [^] xmlns='http://www.google.com/transport/p2p'/></session></iq> [^]

JABBER: asterisk OUTGOING: <iq from='user_my_by@gmail.com/asterisk6F80172B' to='chodorenko@gmail.com/Talk.v932FDE815F' type='set' id='aaaad'><session type='transport-info' id='1787720173' initiator='chodorenko@gmail.com/Talk.v932FDE815F' xmlns='http://www.google.com/session'><transport [^] xmlns='http://www.google.com/transport/p2p'><candidate [^] name='rtp' address='111.111.111.111' port='17168' username='50a3900934bba2d0' password='0457b8f66466c3e5' preference='1.00' protocol='udp' type='local' network='0' generation='0'/></transport></session></iq>

==============

ABBER: asterisk INCOMING: <iq type="error" to="user_my_by@gmail.com/asterisk6F80172B" id="aaaad" from="chodorenko@gmail.com/Talk.v932FDE815F"><session type="transport-info" id="1787720173" initiator="chodorenko@gmail.com/Talk.v932FDE815F" xmlns="http://www.google.com/session"><transport [^] xmlns="http://www.google.com/transport/p2p"><candidate [^] name="rtp" address="111.111.111.111" port="17168" username="50a3900934bba2d0" password="0457b8f66466c3e5" preference="1.00" protocol="udp" type="local" network="0" generation="0"/></transport></session><error code="501" type="cancel"><feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>

Therefore, google is not understand <transport> and throw an error on it.
As result, google Client refuses STUN stream from asterisk, because the Asterisk's Username not known by G Client.

Could you share the asterisk logs in normal call completion scenario?

in any cases - avoidance of <transport> helps to solve problem and makes the solution to more tolerant against different GTalk stuff.

That about implement it configurable in chan_gtalk ?
By: phsultan (phsultan) 2008-04-01 04:08:54

> Possible, the bug depends from the region due some Google's distributed
> architecture. Really spent days to recognize the root of problem.

I doubt it, I modified my jabber.conf to connect to the server you're connected to (eg. 72.14.253.125), and I could place calls from Asterisk to the GoogleTalk client.

> Additionally, the google server is parsing incoming XMLs before pass it to
> client.
> In my case, Client was not received <candidate> at all, if it wrapped by
> <transport>
> I have a traces/logfiles from both sides to confirm this.
> Can send/attach if you interested

That's odd, please attach a log file.

> By the way, pls. examine logs, allached to report 10512.
> It is very similar.

Indeed, this is why I pointed you to this bug report :). You can see that upgrading to the English version of Gtalk Client version 1.0.0.104 solved the problem.

> Could you share the asterisk logs in normal call completion scenario?

There you go, check the attached file. The 'candidates' tag is wrapped in a 'transport' tag, and the GoogleTalk client interprets it without problem.

> in any cases - avoidance of <transport> helps to solve problem and makes the
> solution to more tolerant against different GTalk stuff.
> That about implement it configurable in chan_gtalk ?

The 'transport' tag makes the implementation closer to the Jingle specification, this is why Google introduced it in its latest GoogleTalk client (and possibly in the spec as well). We don't need Asterisk to handle older versions of the GoogleTalk/Jingle protocol.
By: Andrey Klimov (farlake) 2008-04-01 15:12:54

>> Additionally, the google server is parsing incoming XMLs before pass it to
>> client.
>> In my case, Client was not received <candidate> at all, if it wrapped by
>> <transport>
>> I have a traces/logfiles from both sides to confirm this.
>> Can send/attach if you interested

>That's odd, please attach a log file.


I've doublechecked the logs together with Ethereal snoops.  I was wrong - the <transport> element coming toward GTclient, but GT client not wrote it to logs due not recognized.

In couple of days I will rollback my Asterisk changes and try newest GT Client (I find out that newer version available now, than I used at start point of my investigation).

Now, patched Asterisk working perfectly with latest English version and with 0.9x as well (not all my correspondents have GT client up to date). I sure, that newer  Google clients will keep backward compatibility with 0.9x clients long time and (*) will be working with both versions of client. Possible, I'll prefer to re-apply attached patch later just to achieve compatibility with wider range of client versions.

It would be perfectly to implement some autodetecting  of opponent's client version, for example, based on address suffix (atter @gmail.com/Talk)

from="anklimov@gmail.com/Talk.v105AFCCEA63"

in this example, client version something like 1.0.5
But it is not clear now, what client version required to allow client working with (*) smoothly- Russian 1.0.5 client still not working. English client good for me, but could be not good enough for all my friends and family.
By: phsultan (phsultan) 2008-04-02 03:48:20

Can you point me to the link where you downloaded your client? I was able to find a GoogleTalk client referenced 1.0.0.105 on the web, but it seems to be a JavaScript based version of GoogleTalk, which I doubt can have voice capabilities.

Thanks!
By: Andrey Klimov (farlake) 2008-04-02 04:33:19

From my registry:
AvailableURL http://dl.google.com/googletalk/googletalk-setup-upgrade-ru.exe
Installed Version: 1.0.0.105
By: phsultan (phsultan) 2008-04-02 09:50:52

Can't install this one, an error message pops up, which I obviously can't understand (written in cyrillic characters). It looks like it's an upgrade program.

I tried to reinstall GoogleTalk on my laptop and had version 1.0.0.104 installed. I can't find any information referring to version 1.0.0.105 on Google's site.

I understand your concern regarding the localized version of the GoogleTalk client, but it can be solved by moving to the latest English version (just like Mikhail Chodorenko did in bug ASTERISK-10133). Therefore, we should not bother being compatible with older releases, as they don't work with Asterisk for a long time now, if they ever interoperated.

Please report back your after your new testing, thanks!
By: phsultan (phsultan) 2008-04-17 08:58:02

Hi farlake,

did you have any chance to rollback your changes and check that your Asterisk server works with GoogleTalk 1.0.0.104?

Also, do you have more info regarding GoogleTalk 1.0.0.105? Is it a localized version of 1.0.0.104? I'm curious about this release I can't find on their website.

Thanks!
By: phsultan (phsultan) 2008-05-06 04:57:34

I'm closing this bug since a similar one was solved by using the english version of the GoogleTalk client (ASTERISK-10133). We can't afford to support multiple versions of the Gooogle's Jingle protocol depending on their client's versions.