[Home]

Summary:ASTERISK-07973: [patch] Asterisk to Gtalk audio shuts off after 30 seconds into call
Reporter:bungalow (bungalow)Labels:
Date Opened:2006-10-20 19:34:17Date Closed:2007-05-24 10:21:56
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_gtalk
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) branch-1.4-bug_8193-1.diff
( 1) gtalk_audio_off.log
( 2) gtalk_log_5
( 3) trunk-bug_8193-1.diff
Description:In a Gtalk to Asterisk call, the Gtalk -> Asterisk audio is shutting off after just about 30 seconds after the start of the call.  The Asterisk -> Gtalk audio remains.  Through a port cap and rtp debug, it appears that the forward and reverse RTP streams remain intact, even though audio has been shutoff.

On some connections there is no Gtalk -> Asterisk audio from the start of the call.

This appears to happen regardless of the application run on the channel.  Thus far I've tried Echotest and Dial SIP.

I've set core debug 9, full logging, and jabber debug on and have not seen any differences in the error messages.  I also checeked stun debug, in addition to rtp debug, and could not see any changes between the time when audio is on vs. off.

Attached is a log of the answered call...
Comments:By: Anthony LaMantia (alamantia) 2006-11-01 14:51:57.000-0600

there was just an addition to chan_gtalk in 1.4trunk and svn trunk which allows you to set bindaddr=<address>  in gtalk.conf .

setting that option has helped a few other people in the same situation. please try tnat and see if it helps you.
By: jmls (jmls) 2006-11-20 15:06:04.000-0600

bungalow: did you try alamantia's suggestion ?
By: jmls (jmls) 2006-11-20 15:06:05.000-0600

bungalow: did you try alamantia's suggestion ?
By: Vijay Amritraj (amritraj) 2006-11-22 06:49:05.000-0600

I am getting both ways audio. My asterisk is behind a NAT and I have tried with Gtalk clients behind differnt nats.

However, for the calls originating from Asterisk to Gtalk, the call terminates after 14-20 seconds of talk.

I am using latest svn revision.
By: Anton Sinelnikov (antal) 2006-11-26 17:00:03.000-0600

Have the same problem with last SVN...
Bind settings doesn't help...
Calls from gtalk to asterisk - no problem, Call from * to gtalk interrupted after 15-30 seconds...


By: Vijay Amritraj (amritraj) 2006-11-26 23:23:23.000-0600

As soon as the second RTCP packet is received, it disconnects. I will dig into the issue deep today, if you guys can give some more hints to where could be the problem, it would be a big help.
By: bungalow (bungalow) 2006-11-27 16:55:53.000-0600

jmls, sorry for being slow to respond. I was pulled away to tend to another project.

I did try the patch and setting the bindaddr, but Asterisk seg faulted.  I have not yet verified if this is repeatable.

I hope to get back to this shortly.
By: Joshua C. Colp (jcolp) 2006-12-18 21:09:46.000-0600

How about trying the latest 1.4? I put in some RTP code specific to google talk in regards to bridging, it may have solved the issue.
By: Vijay Amritraj (amritraj) 2006-12-20 10:56:33.000-0600

Oops !! It didn't help. Somehow, the gtalk is sending terminate signal to asterisk after 15 seconds of call.


<------------->
--- (11 headers 0 lines) ---
**** Received ACK (6) - Command in SIP ACK
setting state to INV_CONFIRMED

JABBER: gtalk_account INCOMING: <iq to="XXXXXXXXXX@gmail.com/TalkB7E9B2" type="set" id="120" from="me@gmail.com/Talk.v100497AA093"><session type="terminate" id="48daf12e6a" initiator="XXXXXXXXXXXX@gmail.com/TalkB7E9B2" xmlns="http://www.google.com/session"/></iq>
By: phsultan (phsultan) 2006-12-27 08:02:15.000-0600

bungalow: final 200 OK response from your SIP gateway is not present in the log file. Can you confirm you did not snipped it out?

Also, please provide info regarding your setup :
- attach the sip.conf section of your SIP gateway (and try to set canreinvite=no if not already done)?
- are the GoogleTalk client, Asterisk and your SIP gateway on the same LAN?
- which devices are behind NAT boxes?

Thanks in advance!
By: bungalow (bungalow) 2006-12-27 12:01:08.000-0600

host=GATEWAY_IP
disallow=all
allow=ulaw
dtmfmode=rfc2833
type=friend
context=inbound
rfc2833compensate=yes
nat=yes
canreinvite=no

The Gtalk client and the Asterisk box are not on the same LAN, and they are both behind iptables with 5060 and 5222 forwarded.  This same SIP setup has been used extensively for SIP/SIP calls.  The Gtalk client has also been used extensively for calls to other Gtalk clients without problems.
Early on, I tried turning off iptables in from of the Asterisk server, but noticed no difference.

I can't confirm whether or not I got a 200 OK as I'm away from the client machine I used.  I tried to replicate the problem from a Gtalk client on a different network and I'm not getting any audio output from Gtalk from the start of the call though I get audio output from the PSTN phone.  In this configuration I am receiving a 200 OK from the SIP gateway.
By: bungalow (bungalow) 2006-12-27 12:39:15.000-0600

On a different client machine, I was able to get audio both ways by removing the NAT in front of the Gtalk client.  I don't have access to the original client, but I'm assuming the result would be the same.  

In practice I won't have any control over the Gtalk client, so the question is what can I do to the server to compensate for the client-side NAT?
By: phsultan (phsultan) 2006-12-27 17:41:40.000-0600

bungalow: I noticed from your log file that RTP packets from the SIP gateway do not go through Asterisk (unlike those from the GoogleTalk client).

A debug output of the bridging procedure might help, this part is missing in the provided log file (most likely snipped out along with the SIP 200 OK response).

If the channels ever happen to be natively bridged, you'll might want to try the patch provided by mnicholson in ASTERISK-8417.
By: Ramaseshi Reddy Kolli (ramaseshi) 2007-01-11 01:10:53.000-0600

Hi everybody i am also having same problem. When i made a call from Asterisk to Google talk call ends after few secs.

I have tried so far discussed settings but did't work out.Can anybody help me?
Atleast can anybody tell me where is the problem so that i can also start debugging it ?.


By: phsultan (phsultan) 2007-01-11 05:31:07.000-0600

To avoid confusion, it might be useful to keep this bug open for the Gtalk -> Asterisk call configuration problem only, and open a new bug for an Asterisk -> Gtalk configuration problem, if any.

Also, file has just fixed a previously mentioned bug (ASTERISK-8417) related to NAT and bridging. So it might be worth try the latest revisions (eg. rev 50466 for 1.4 and 50467 for trunk).


By: bungalow (bungalow) 2007-01-12 00:03:56.000-0600

Using 1.4beta4 with the 8655 patch I got the same results.
See gtalk_log_5 for the full debug output of the bridging procedure...
By: Serge Vecher (serge-v) 2007-01-12 09:46:58.000-0600

might be worth a try with the release, instead of beta.
By: bungalow (bungalow) 2007-01-15 02:18:26.000-0600

I noticed today that audio is dropped on my Asterisk -> SIP Gateway -> PSTN Phone calls after 30 seconds replaced by comfort noise, as well.  The last configuration change I remember was the patch mentioned, and before that beta4.  Not sure if beta4 or the patch are the causes or something else that happened beyond my control.

I upgraded to the the latest 1.4 branch (50820) and the same problem exists.  Now instead of just the Gtalk problem as described above, I have this SIP problem. Yikes!
By: rdlang (rdlang) 2007-01-19 15:06:03.000-0600

I tried the suggested patch on the SVN-trunk-r51266M, did not work. Also i am experiencing the 30 seconds sip call drop nowadays.
By: phsultan (phsultan) 2007-01-19 15:40:30.000-0600

I was able to reproduce this bug under the following setup :
GTalk client (NAT) -> Asterisk -> SIP Gateway -> PSTN Phone

Only the GTalk client stays behind a NAT box. Audio flows correctly from the GTalk Client to the PSTN Phone, but no audio *at all* from the PSTN Phone to the GTalk client.

Strangely, a packet capture on the Gtalk client shows RTP packets coming from Asterisk (P2P bridge), which are discarded or ignored by the GTalk client. I finally figured out that although Asterisk correctly relays the RTP traffic, it sends STUN requests to the private IP address suggested by the GTalk client.

Those STUN requests are needed to trigger the RTP reception on my GTalk client.

The attached patch makes Asterisk send STUN requests to the remote RTP peer's IP address.

rdlang, bungalow : can you try it out? I tried SVN trunk 51337, but the patch also applies to SVN 1.4.
By: rdlang (rdlang) 2007-01-20 10:31:40.000-0600

Tried it out, made no difference at all.
By: bungalow (bungalow) 2007-01-20 12:46:38.000-0600

phsultan - the patch works for me! I applied it to beta4 (1.4 (Rev 50820) gave me a different bug unrelated to this patch).  Where did you see the IP of the stun request? through port capture?  

As far as having the same problem with SIP - it just went away by itself after a couple of days (well before I tried this patch).  I tried to peg that on the gateway provider but they are claiming nothing changed on their end.  This might warrant a separate bug report.

phsultan - great job!
By: phsultan (phsultan) 2007-01-21 05:15:24.000-0600

rdlang : can you detail your setup, and in particular spot the NATed elements? This issue is related to NAT.

bungalow : I'm glad to read it works ok now for you!

> Where did you see the IP of the stun request? through port capture?

Yes, a packet capture on the Gtalk client reveals that STUN requests from Asterisk are not received. At the same time, a packet capture on Asterisk shows STUN requests directly sent to the private IP of the Gtalk client. The IP gateway does not route the private IP destination, and therefore sends ICMP errors to Asterisk. This is clearly a NAT issue.

Note that STUN requests coming from the Gtalk client are correctly processed y Asterisk, which sends STUN responses to the correct (public) IP destination.

bungalow, you might be interested in checking this report, that provides code to make Asterisk a Gtalk gateway : http://bugs.digium.com/view.php?id=8659

Please give your feedback when you have some time to check it out :)

Fogot to mention, disclaimer sent.
By: rdlang (rdlang) 2007-01-26 14:57:52.000-0600

my situation: Tiscali Internet with Tiscali sip gateway <-> ADSL modem with 2 analogue ports <-> Linux pc with asterisk

The 2 analogue ports connect with the asterisk server (use internal ip's, so no NAT there)

Asterisk connects to the tiscali gateway for pstn call's.

I call asterisk extension 111 from an analogue phone , wich dials an gtalk user. The user can pick up the call and talk for some time shorter than 30 sec's, then we get disconnected.
By: phsultan (phsultan) 2007-01-27 04:28:00.000-0600

rdlang : I believe you're experiencing a different bug, also mentioned by ramaseshi (in note 0057607). The call configuration here is Gtalk -> Asterisk, your call configuration is Asterisk -> Gtalk. Also, bungalow and I put in evidence the relationship with NAT for the current bug.

As mentioned before (note 0057608), we should open another bug that matches your setup and start working on it, and close this one.
By: phsultan (phsultan) 2007-02-02 10:20:31.000-0600

rdlang: I was able to reproduce a bug that looks similar to yours. Please check bug ASTERISK-8718 : http://bugs.digium.com/view.php?id=8970
By: Olle Johansson (oej) 2007-02-11 13:00:59.000-0600

Philippe, seems like your patch ignores the "sin" address totally and sends stun somewhere else. This issue exists in 1.4 too, we need to focus patching on 1.4 and then upgrade to trunk.

Seems like the function gtalk_update_stun needs to be changed a bit more. If we don't need "sin" here, why do DNS lookup on the hostname?

Or are there cases when we need to send stun to the "sin" address?
By: phsultan (phsultan) 2007-02-12 07:34:50.000-0600

Hi Olle, new patch applies to branch 1.4, and sends STUN requests to the detected remote RTP peer's IP address, prefered over what was announced by the remote GoogleTalk client.

If no IP address could be learnt from Asterisk's RTP stack, then STUN requests are being sent to the IP announced by the remote GoogleTalk client.

This way, we can detect the case where the remote GoogleTalk client is behind a NAT box, and still behave properly if it is not.
By: Jason Parker (jparker) 2007-02-21 15:16:20.000-0600

There appear to have been changes in google talk which may affect this positively.  Can you please test with the latest gtalk client and latest svn branch 1.4?
By: phsultan (phsultan) 2007-02-22 04:40:26.000-0600

I just tested the latest SVN revision from branch 1.4, still no audio from Asterisk to Gtalk when setting up a call under the following configuration :
- Gtalk client-> Asterisk -> SIP/PSTN phone
- Gtalk client behind NAT

Latest patch still applies and fixes it.
By: Gregory Hinton Nietsky (irroot) 2007-03-31 11:11:07

hi there i was experiancing this and did a massive rework of the rtp i found the problem went away when i procesed and acknowlaged the accept message from the client.

see http://bugs.digium.com/view.php?id=9401 function gtalk_answer_call
By: phsultan (phsultan) 2007-04-06 11:54:33

Just to summarize things a little. There is a NAT issue here, which needs to be solved in any way. It was put in evidence in note ASTERISK-5540883 by bungalow and I was able to reproduce it (ASTERISK-5652036). Patch in branch-1.4-bug_8193-1.diff corrects this issue (at least for the reporter).

Other issues involving chan_gtalk should be handled under new bug reports, with a complete and accurate description.
By: zandbelt (zandbelt) 2007-05-04 14:14:36

I can confirm that phsultan's fix works and I would like to see it included. Please commit and the this bug report can be closed.
By: Ronald Chan (loloski) 2007-05-08 01:05:06

Yes, I can confirm this also, it isn't an issue anymore with phsultan fix what's really holding this? Thanks Philippe.


By: John Todd (jtodd) 2007-05-10 13:45:27

Tested patch "branch-1.4-bug" and works for my issues (which I incorrectly described as associated with ASTERISK-7488.)  Seems to work; no ill effects at this point.
By: Olle Johansson (oej) 2007-05-24 10:20:41

Philippe's fix committed to svn 1.4 rev 65892 and trunk. THanks!