[Home]

Summary:ASTERISK-16955: chan_gtalk does not respect the rtp port range configured in rtp.conf
Reporter:Jeremy Kister (jkister)Labels:
Date Opened:2010-11-14 00:44:07.000-0600Date Closed:2015-02-26 09:29:46.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_gtalk Resources/res_jabber
Versions:1.8.4 1.8.5.0 1.8.6.0 1.8.7.0 1.8.8.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) jabber.txt
Description:{code}
# grep ^rtp /etc/asterisk/rtp.conf
rtpstart=20000
rtpend=20101
{code}
{code}
# grep iptables /var/log/messages | tail -2
iptables IN=eth0 OUT= SRC=75.101.138.128 DST=10.9.1.3 LEN=116 TOS=0x00 PREC=0x00 TTL=48 ID=49625 DF PROTO=UDP SPT=3478 DPT=37843 LEN=96
iptables IN=eth0 OUT= SRC=75.101.138.128 DST=10.9.1.3 LEN=116 TOS=0x00 PREC=0x00 TTL=49 ID=6825 DF PROTO=UDP SPT=3478 DPT=48659 LEN=96

# the interesting things there are the DPT (Destination Port) =37843 and =48659
# clearly outside of the 20000-20101 range
{code}

as soon as I opened up the rules to allow this host to access all unprivileged UDP ports, audio started working right away.
Comments:By: Leif Madsen (lmadsen) 2010-12-06 13:08:16.000-0600

I think it would be useful to have console debug information (debug level logging per logger.conf). Please attach as a text file to this issue. Thanks!
By: Jeremy Kister (jkister) 2011-06-08 14:57:55.093-0500

I would say this is more severe than 'minor' because there is no easy workaround.  Me saying i could open the firewall is only a *temporary* workaround because google changes the ip addresses that send me traffic.  So far I am up to seven, and only find them by trial-and-error (meaning when my google talk breaks, i have to tcpdump to find the new ip address).  

The only "workaround" would be to [basically] completely disable the firewall, which isnt a workaround at all.
By: Malcolm Davenport (mdavenport) 2015-02-26 09:29:46.773-0600

Unfortunately, this issue wasn't addressed during the bug-fix lifetime of Asterisk 1.8.  The good news is that Asterisk 11 and greater have chan_motif and res_xmpp, which are a rewrite of XMPP support within Asterisk, and are supported.

We'd encourage you to try that out instead and see if that clears things up for you.