[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 04:08 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.
====================================================================== 

---------------------------------------------------------------------- 
 phsultan - 04-01-08 04:08  
---------------------------------------------------------------------- 
> 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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
04-01-08 04:08  phsultan       Note Added: 0084832                          
======================================================================