[asterisk-bugs] [Asterisk 0012338]: There is no voice channel establishing between GoogleTalk and asterisk

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12338 
====================================================================== 
Reported By:                farlake
Assigned To:                phsultan
====================================================================== 
Project:                    Asterisk
Issue ID:                   12338
Category:                   Channels/chan_gtalk
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.0-beta4 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             03-31-2008 03:26 CDT
Last Modified:              04-01-2008 15:12 CDT
====================================================================== 
Summary:                    There is no voice channel establishing between
GoogleTalk and asterisk
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 at gmail.com/Talk48CF2B75'
to='anklimov at gmail.com/Talk.v105AFCCEA63' type='set' id='aaaby'><session
type='transport-info' id='3244105671'
initiator='anklimov at 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 at gmail.com/Talk48CF2B75" id="aaabx"
from="anklimov at gmail.com/Talk.v105AFCCEA63"><session
type="transport-accept" id="3244105671"
initiator="anklimov at 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 at gmail.com/Talk.v939F5BB7E6" type="set" id="113">
  <session xmlns="http://www.google.com/session" type="candidates"
id="255815956" initiator="anklimov at 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.
====================================================================== 

---------------------------------------------------------------------- 
 farlake - 04-01-08 15:12  
---------------------------------------------------------------------- 
>> 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 at 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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
04-01-08 15:12  farlake        Note Added: 0084892                          
======================================================================