[asterisk-bugs] [Asterisk 0012338]: There is no voice channel establishing between GoogleTalk and asterisk
noreply at bugs.digium.com
noreply at bugs.digium.com
Mon Mar 31 16:02:17 CDT 2008
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: 03-31-2008 16:02 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 - 03-31-08 16:02
----------------------------------------------------------------------
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 at gmail.com/asterisk6F80172B'
to='chodorenko at gmail.com/Talk.v932FDE815F' type='set' id='aaaac'><session
type='transport-accept' id='1787720173'
initiator='chodorenko at 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 at gmail.com/asterisk6F80172B'
to='chodorenko at gmail.com/Talk.v932FDE815F' type='set' id='aaaad'><session
type='transport-info' id='1787720173'
initiator='chodorenko at 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 at gmail.com/asterisk6F80172B" id="aaaad"
from="chodorenko at gmail.com/Talk.v932FDE815F"><session type="transport-info"
id="1787720173" initiator="chodorenko at 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 ?
Issue History
Date Modified Username Field Change
======================================================================
03-31-08 16:02 farlake Note Added: 0084810
======================================================================
More information about the asterisk-bugs
mailing list