[Home]

Summary:ASTERISK-13134: No audio on outgoing Gtalk calls if /etc/hosts has Centos default; work-around provided
Reporter:John Covert (jcovert)Labels:
Date Opened:2008-11-28 10:41:34.000-0600Date Closed:2009-09-15 16:54:42
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_gtalk
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If /etc/hosts includes the name of the host in addition to "localhost", e.g.

127.0.0.1   blade14.on-state.com  blade14 localhost.localdomain localhost

chan_gtalk tries to set up the rtp audio channel on 127.0.0.1, which obviously fails (see protocol exchange below).

Now, _I_ personally would never set up /etc/hosts that way, but this seems to be a religious issue, and according to the IT guy who built the Linux system for me to install Asterisk on, the Centos default is to include the host name.

As soon as I changed the line to just

127.0.0.1 localhost.localdomain localhost

Gtalk calls worked just fine.

It would, however, be desirable for Gtalk to work without having to modify /etc/hosts from the default, so it would work regardless of your religious position on this issue.  I categorized this as "minor" since the workaround is simple, but it's "major" for anyone of the "we must put the real host-name in here" party.

/john

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

-- Executing [8466onstategtalktest*gmail.com@onstate:1] Set("SIP/cgate.covert.org-09abc7f0", "goog=onstategtalktest*gmail.com") in new stack
-- Executing [8466onstategtalktest*gmail.com@onstate:2] Goto("SIP/cgate.covert.org-09abc7f0", "googletalk,s,1") in new stack
-- Goto (googletalk,s,1)
-- Executing [s@googletalk:1] Set("SIP/cgate.covert.org-09abc7f0", "user=onstategtalktest") in new stack
-- Executing [s@googletalk:2] Set("SIP/cgate.covert.org-09abc7f0", "dom=gmail.com") in new stack
-- Executing [s@googletalk:3] JabberSend("SIP/cgate.covert.org-09abc7f0", "onstate,onstategtalktest@gmail.com,Call from "Snom 28" <28>") in new stack
blade14*CLI>
JABBER: onstate OUTGOING: <message type='chat' to='onstategtalktest@gmail.com' from='gateway1@on-state.com/Talk47658726'><body>Call from "Snom 28" <28></body></message>
-- Executing [s@googletalk:4] Dial("SIP/cgate.covert.org-09abc7f0", "gtalk/onstate/onstategtalktest@gmail.com,120") in new stack
blade14*CLI>
JABBER: onstate OUTGOING: <iq type='set' to='onstategtalktest@gmail.com/Talk.v10496F5B39E' from='gateway1@on-state.com/Talk47658726' id='aaaal'><session xmlns='http://www.google.com/session' type='initiate' initiator='gateway1@on-state.com/Talk47658726' id='178a0d15040324a8'><description xmlns='http://www.google.com/session/phone' xml:lang='en'><payload-type id='0' name='PCMU' clockrate='8000' bitrate='64000'/><payload-type id='100' name='EG711U' clockrate='8000' bitrate='64000'/><payload-type id='106' name='telephone-event' clockrate='8000'/></description><transport xmlns='http://www.google.com/transport/p2p'/></session></iq>
blade14*CLI>

Note that Asterisk, in the next message, says "contact me on 127.0.0.1".  Ooops!

JABBER: onstate OUTGOING: <iq from='gateway1@on-state.com/Talk47658726' to='onstategtalktest@gmail.com/Talk.v10496F5B39E' type='set' id='aaaam'><session type='transport-info' id='178a0d15040324a8' initiator='gateway1@on-state.com/Talk47658726' xmlns='http://www.google.com/session'><transport xmlns='http://www.google.com/transport/p2p'><candidate name='rtp' address='127.0.0.1' port='18012' username='7d15598039a2cf06' password='---' preference='1.00' protocol='udp' type='local' network='0' generation='0'/></transport></session></iq>
-- Called onstate/onstategtalktest@gmail.com
blade14*CLI>
JABBER: onstate INCOMING: <iq to="gateway1@on-state.com/Talk47658726" id="aaaal" type="result" from="OnStateGTalkTest@gmail.com/Talk.v10496F5B39E"/>
-- Gtalk/onstategtalktest@gmail.com-ecea is ringing
blade14*CLI>
JABBER: onstate INCOMING: <iq to="gateway1@on-state.com/Talk47658726" type="set" id="196" from="OnStateGTalkTest@gmail.com/Talk.v10496F5B39E"><session type="transport-accept" id="178a0d15040324a8" initiator="gateway1@on-state.com/Talk47658726" xmlns="http://www.google.com/session"><transport xmlns="http://www.google.com/transport/p2p"/></session></iq>
blade14*CLI>
JABBER: onstate OUTGOING: <iq type='result' from='gateway1@on-state.com/Talk47658726' to='OnStateGTalkTest@gmail.com/Talk.v10496F5B39E' id='196'/>
blade14*CLI>

And here, Gtalk says, "wt?, candidate has local IP address".  So no audio path ever gets set up.

JABBER: onstate INCOMING: <iq to="gateway1@on-state.com/Talk47658726" id="aaaam" type="error" from="OnStateGTalkTest@gmail.com/Talk.v10496F5B39E"><session type="transport-info" id="178a0d15040324a8" initiator="gateway1@on-state.com/Talk47658726" xmlns="http://www.google.com/session"><transport xmlns="http://www.google.com/transport/p2p"><candidate name="rtp" address="127.0.0.1" port="18012" username="7d15598039a2cf06" password="---" preference="1.00" protocol="udp" type="local" network="0" generation="0"/></transport></session><error type="modify"><sta:bad-request xmlns:sta="urn:ietf:params:xml:ns:xmpp-stanzas"/><sta:text xml:lang="en" xmlns:sta="urn:ietf:params:xml:ns:xmpp-stanzas">candidate has local IP address</sta:text></error></iq>
[Nov 27 18:53:04] NOTICE[6110]: chan_gtalk.c:1720 gtalk_parser: Remote peer reported an error, trying to establish the call anyway
blade14*CLI>
JABBER: onstate INCOMING: <iq to="gateway1@on-state.com/Talk47658726" type="set" id="198" from="OnStateGTalkTest@gmail.com/Talk.v10496F5B39E"><session type="transport-info" id="178a0d15040324a8" initiator="gateway1@on-state.com/Talk47658726" xmlns="http://www.google.com/session"><transport xmlns="http://www.google.com/transport/p2p"><candidate name="rtp" address="192.168.10.122" port="2852" preference="1" username="+fB5ttJQZRnaQuA2" protocol="udp" generation="0" password="---" type="local" network="0"/></transport></session></iq>

JABBER: onstate OUTGOING: <iq type='result' from='gateway1@on-state.com/Talk47658726' to='OnStateGTalkTest@gmail.com/Talk.v10496F5B39E' id='198'/>
blade14*CLI>
JABBER: onstate INCOMING: <iq to="gateway1@on-state.com/Talk47658726" type="set" id="199" from="OnStateGTalkTest@gmail.com/Talk.v10496F5B39E"><session type="transport-info" id="178a0d15040324a8" initiator="gateway1@on-state.com/Talk47658726" xmlns="http://www.google.com/session"><transport xmlns="http://www.google.com/transport/p2p"><candidate name="rtp" address="72.93.205.51" port="2853" preference="0.9" username="6qgfsXSgk+tcL2/3" protocol="udp" generation="0" password="---" type="stun" network="0"/></transport></session></iq>

JABBER: onstate OUTGOING: <iq type='result' from='gateway1@on-state.com/Talk47658726' to='OnStateGTalkTest@gmail.com/Talk.v10496F5B39E' id='199'/>
blade14*CLI>
JABBER: onstate INCOMING: <iq to="gateway1@on-state.com/Talk47658726" type="set" id="201" from="OnStateGTalkTest@gmail.com/Talk.v10496F5B39E"><session type="accept" id="178a0d15040324a8" initiator="gateway1@on-state.com/Talk47658726" xmlns="http://www.google.com/session"><description xml:lang="en" xmlns="http://www.google.com/session/phone"><payload-type id="0" name="PCMU" clockrate="8000" bitrate="64000"/><payload-type id="100" name="EG711U" clockrate="8000" bitrate="64000"/><payload-type id="106" name="telephone-event" clockrate="8000"/></description></session></iq>

JABBER: onstate OUTGOING: <iq type='result' from='gateway1@on-state.com/Talk47658726' to='OnStateGTalkTest@gmail.com/Talk.v10496F5B39E' id='201'/>
-- Gtalk/onstategtalktest@gmail.com-ecea answered SIP/cgate.covert.org-09abc7f0
[Nov 27 18:53:15] NOTICE[6152]: chan_gtalk.c:1454 gtalk_indicate: Don't know how to indicate condition '20'
-- Packet2Packet bridging SIP/cgate.covert.org-09abc7f0 and Gtalk/onstategtalktest@gmail.com-ecea

But no packets flow.
Comments:By: phsultan (phsultan) 2009-01-09 09:35:39.000-0600

Hi John,

Did you try to set the bindaddr attribute value explicitly in gtalk.conf under the [general] section?
By: John Covert (jcovert) 2009-01-09 12:52:16.000-0600

No, I didn't, because that's just another workaround for the basic problem.

If you make the bindaddr non-zero, then only that interface will be used, rather than all of them, and you can't use the current DHCP-assigned interface if you're on a dynamic host.

Your suggestion made me see what's wrong with the code.  I read the code in routine ast_find_ourip, and I see that it gets the IP address to use for the RTP session either from the bindaddr if specified, or by doing a lookup of the local host name and then converting that to an address, which fails if the CentOS default of translating your own host name to 127.0.0.1 is taken.  Ugh.

Just like SIP, this is a problem with using separate sessions.  In this case what we want is the address of the interface that is going to be used to communicate with the remote party (which will vary depending on what the remote party's IP address is), not some random interface turned up by doing a DNS lookup of our local hostname.

If you do a DNS lookup of the local hostname, then you need to get all of the possible results, not just the first, and use all of them as "candidates", and probably only bother to use 127.0.0.1 if it's the only one that comes back.

Since I consider the CentOS default of putting your local host name into /etc/hosts as 127.0.0.1 to be bogus, if you want to close this as "too hard to fix properly", I wouldn't object.
By: Digium Subversion (svnbot) 2009-02-12 08:25:20.000-0600

Repository: asterisk
Revision: 175089

U   trunk/channels/chan_gtalk.c

------------------------------------------------------------------------
r175089 | phsultan | 2009-02-12 08:25:19 -0600 (Thu, 12 Feb 2009) | 6 lines

Issue a warning message if our candidate's IP is the loopback address.

(closes issue ASTERISK-13134)
Reported by: jcovert
Tested by: phsultan

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=175089
By: Digium Subversion (svnbot) 2009-02-12 08:28:00.000-0600

Repository: asterisk
Revision: 175090

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_gtalk.c

------------------------------------------------------------------------
r175090 | phsultan | 2009-02-12 08:27:59 -0600 (Thu, 12 Feb 2009) | 14 lines

Merged revisions 175089 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r175089 | phsultan | 2009-02-12 15:25:03 +0100 (Thu, 12 Feb 2009) | 6 lines

Issue a warning message if our candidate's IP is the loopback address.

(closes issue ASTERISK-13134)
Reported by: jcovert
Tested by: phsultan

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=175090
By: Digium Subversion (svnbot) 2009-09-15 16:54:42

Repository: asterisk
Revision: 218727

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_gtalk.c

------------------------------------------------------------------------
r218727 | tilghman | 2009-09-15 16:54:41 -0500 (Tue, 15 Sep 2009) | 44 lines

Merged revisions 139281,175058,175089 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
(closes issue ASTERISK-13134)

................
 r139281 | phsultan | 2008-08-21 04:55:31 -0500 (Thu, 21 Aug 2008) | 5 lines
 
 Fix two memory leaks in chan_gtalk, thanks Eliel!
 (closes issue ASTERISK-12586)
 Reported by: eliel
 Patches:
       chan_gtalk.c.patch uploaded by eliel (license 64)
................
 r175058 | phsultan | 2009-02-12 04:31:36 -0600 (Thu, 12 Feb 2009) | 20 lines
 
 Merged revisions 175029 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
 r175029 | phsultan | 2009-02-12 11:16:21 +0100 (Thu, 12 Feb 2009) | 12 lines
 
 Set the initiator attribute to lowercase in our replies when receiving calls.
 
 This attribute contains a JID that identifies the initiator of the GoogleTalk
 voice session. The GoogleTalk client discards Asterisk's replies if the
 initiator attribute contains uppercase characters.
 
 (closes issue ASTERISK-13133)
 Reported by: jcovert
 Patches:
       chan_gtalk.2.patch uploaded by jcovert (license 551)
 Tested by: jcovert
 
 ........
................
 r175089 | phsultan | 2009-02-12 08:25:03 -0600 (Thu, 12 Feb 2009) | 6 lines
 
 Issue a warning message if our candidate's IP is the loopback address.
 
 (closes issue ASTERISK-13134)
 Reported by: jcovert
 Tested by: phsultan
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=218727