[Home]

Summary:ASTERISK-07488: [patch] no audio on calls from google talk to Asterisk
Reporter:pbd (pbd)Labels:
Date Opened:2006-08-08 13:21:45Date Closed:2007-05-24 10:06:43
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_jingle
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) jabber.conf
( 1) jingle.conf
( 2) trunk-force_P2P_bridge-1.diff
Description:Testing SVN Trunk.  Simple setup, mirroring suggested .conf.sample and voip-info. (jabber.conf and jingle.conf attached below).  Call completes- but no audio is passed.  Error message appears in the console log:
[Aug  8 12:42:41] NOTICE[11028]: chan_jingle.c:1176 jingle_indicate: Don't know how to indicate condition '-1'
[Aug  8 12:42:41] WARNING[11028]: rtp.c:2517 ast_rtp_bridge: Can't find native functions for channel 'Jingle/planac-09e3'

Not sure if they are relevant, but they are the only warnings that appear during call setup.
Comments:By: Serge Vecher (serge-v) 2006-08-08 13:51:40

please update to latest revision of trunk, which is currently at r39380
By: pbd (pbd) 2006-08-08 13:54:51

Actually, I am at latest, per report by 'make update'.  The number reported I got from 'show version' at the CLI, which is quite obviously wrong..  perhaps time for another bug report..
(confirmed also with 'svn info')


By: pbd (pbd) 2006-08-08 14:37:11

A few technical details:
Both the Google Talk client and Asterisk test box are NATted, both are on the same  physical subnet.
Jabber messages appear to work correctly.
The problem has existed for several weeks in trunk- I've pestered Mog a few times on it, and I've heard tell of a few others out there with this problem- but according to Mog, we're in the minority.  I suspect configuration, or possibly library/compiler differences, as it seems to affect the minority.  I've inspected the code quite a bit- and found nothing relevant (my jedi skills are still immature).
By: Matt O'Gorman (mogorman) 2006-08-08 14:40:21

im sorry if i have appeared apathetic to your cause.  I am finishing up my other large project here and will begin working non stop again on jingle, esp in my free time after work, I should be around today after digium closes as well as this weekend to help trouble shoot, these problems.
By: pbd (pbd) 2006-08-08 14:43:44

No worries- I'm just putting it here so others can look at it and maybe understand how many are actually affected.  It'd be nice to resolve this as 'update this library', and let you get on about the business of fixing other stuff.
By: Matt Riddell (zx81) 2006-08-10 20:45:26

just adding a me3 here.  No audio.  I'm behind NAT but the server is not.  Obviously messaging is working and my bot is happy to text me, but it would be nice if she called me every now and then!

:)
By: Clod Patry (junky) 2006-08-10 23:42:51

audio isnt working if:
you * is behind a nat.
your google talk client is behind a nat.
By: pbd (pbd) 2006-08-14 09:46:40

Hmm.  Has anyone been able to confirm if it matters which end is not NATted?  I've  held many google talk conversations between two google talk clients that are both NATted, so the protocol would appear to support it- since the packet counts are exactly zero in each direction, I'm thinking the problem would be removed if Asterisk were de-NATted.  (not that that's extremely prudent or practical, but it's more clues).  This would point towards a relatively (?) simple protocol issue to resolve- if you watch the xml go by, you can see all the pertinent IP addresses- this just means we're plucking the wrong one to pass to the gtalk server.  Something like the 'externip/externhost' stuff from SIP.CONF might be useful here.
By: Matt Riddell (zx81) 2006-08-15 05:03:23

You can see from my post that my server is not behind NAT
By: Serge Vecher (serge-v) 2006-09-06 11:02:58

ok, is this an issue with latest trunk (r> 42000). There've been quite a few updates and now there is chan_talk ...
By: Serge Vecher (serge-v) 2006-09-27 13:54:57

no response from op or zx81. If this is still an issue in 1.4-betaX or trunk, please reopen the issue indication what revision you are seeing this on ...
By: Clod Patry (junky) 2006-09-30 21:34:44

I still have no audio with 1.4.0-beta2, if * is behind a NAT.
By: Marcelo M. Sosa Lugones (marsosa) 2006-10-02 08:48:54

I'm having the same problem, gtalk is behind nat, * is not, i've reported it to mogorman at least 2 months ago. Tcpdump says there is rtp traffic arriving to gtalk client but gtalk isn't reproducing it, so i stopped trying to solve it. If anyone wants to debug it some more, you can find me in gtalk with this username.
By: Matt O'Gorman (mogorman) 2006-10-04 10:43:44

this bug is directly related to the stunning proccess, we are not using information we recieve back to send data to correct end point always.  It is more likely to happen when multiple interfaces are exposed.  I am working on it.
By: Terry Wilson (twilson) 2006-10-10 20:53:45

I also have the no audio problem.  Asterisk is on a machine that has two interfaces, public and private.  My google talk client is running from the private subnet.  Looking at the negotiation with jabber and rtp debug on, it looks like the google talk and chan_gtalk think that the best way to communicate would be via 127.0.0.1 even though they are on different machines.  chan_gtalk happily sends RTP to and from itself.  127.0.0.1 has preference 1.0 for asterisk and google talk, the private ip (for google talk) and public ip (for asterisk) have preferences of 0.9.  I'm guessing that when the RTP is sent from Asterisk that it shouldn't respond to it's own RTP in this situation.
By: Morten Isaksen (misaksen) 2006-10-17 16:20:41

I have tested this a bit. All calls from gtalt to Asterisk.

First I got no audio at all. chan_gtalk decided to bind to 127.0.0.1

JABBER: asterisk OUTGOING: <iq from='asteriskatmisak@gmail.com/asterisk6721102B' to='misaksen@gmail.com/Talk.v985BB9B343' type='set' id='aaacf'><session type='transport-info' id='2666368611' initiator='misaksen@gmail.com/Talk.v985BB9B343' xmlns='http://www.google.com/session'><transport xmlns='http://www.google.com/transport/p2p'><candidate name='rtp' address='127.0.0.1' port='10054' username='7f8641d17d502c7f' password='3a07744b6ab5165c' preference='1.00' protocol='udp' type='local' network='0' generation='0'/></transport></session></iq>

and then the my gtalk progam responded

JABBER: asterisk INCOMING: <iq to="asteriskatmisak@gmail.com/asterisk6721102B" id="aaacf" type="error" from="misaksen@gmail.com/Talk.v985BB9B343"><session type="transport-info" id="2666368611" initiator="misaksen@gmail.com/Talk.v985BB9B343" xmlns="http://www.google.com/session"><transport xmlns="http://www.google.com/transport/p2p"><candidate name="rtp" address="127.0.0.1" port="10054" username="7f8641d17d502c7f" password="3a07744b6ab5165c" 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>

I then edited /etc/hosts and made sure that asterisk would not bind itself to the loopback address but my normal ip address. Now I have one way audio from gtalk to Asterisk.

Both gtalk and asterisk are on the same subnet. The jabber server is talk.google.com.

I will do some more tests later.
By: Andres Maduro (palillo) 2006-10-19 13:37:23

Hi,

I have been able to reproduce this behavior with:

* Behind NAT
Gtalk client behind NAT (on same network) as well as on an external (nated network)

Had to change /etc/hosts and map hostname to the eth0 address in order to be able to get one way audio.
By: Anthony LaMantia (alamantia) 2006-10-19 14:17:27

hi,

there is a workaround patch for this issue here. http://bugs.digium.com/view.php?id=8164

you can use this while we work around the problem which is causing this.

please try using this patch. in the meantime.
By: Morten Isaksen (misaksen) 2006-10-19 14:55:50

I discovered the source of my one way audio problem (from gtalk to Asterisk).

I have vmware player installed on my workstation and it has added 2 virtual interfaces. The gtalk client sends one "invite" for every local ip address on the workstation with preference 1.0 and one "invite" with my external ip address with preference 0.9. chan_gtalk just uses the last "invite" with preference 1.0 and in my case it was one of the virtual interfaces for vmware.

I got audio both wayes now when I disable all adapters but my LAN interface on the workstation.
By: Andres Maduro (palillo) 2006-10-20 08:52:03

Hi,

I applied the patch mentioned earlier but the one way audio problem persist.

I tried with:

1. Asterisk behind NAT and Nated google talk client on the same lan
2. Asterisk behind NAT and Nated google talk client on a different lan

Note.  I am using stock 1.4b3 downloaded from Digium website, should I use svn latest version ?

Regards
By: Ronald Chan (loloski) 2006-10-20 10:02:42

Same here no audio at all :) using Asterisk SVN-branch-1.4-r45741M with the patch mention above. setup gtalk client behind a nat and * is _NOT_ they are on the same net segments just like others.


Best regards,

Ronald
By: caspy (caspy) 2006-10-24 10:01:53

(chan_gtalk, res_jabber, asterisk-1.4-beta3)

I have the same one way audio trouble with client (native GTalk) behind the NAT.

With tcpdump i can see:
- packets to NAT server on the asterisk server,
- packets to client's internal IP on NAT server (freebsd/natd),
- packets arriving to windows machine.

But GTalk IM does not increment recv counter, thus providing no audio.
By: Daniel Cardin (mrhightech) 2006-10-26 08:50:35

my chan_gtalk gets both invites, for the internal address with 1.0 and the external with 0.9. Am I understanding correctly that chan_gtalk uses the 1.0 only ?

anyone else gets an unknown session error ? What does it mean?

JABBER: gtalk_account INCOMING: <iq to="netappsid@gmail.com/Talk484F9BF7" id="aaaae" type="error" from="Daniel.Cardin@gmail.com/Talk.v99B412FF2B"><session type="transport-accept" id="3401463686" initiator="Daniel.Cardin@gmail.com/Talk.v99B412FF2B" xmlns="http://www.google.com/session"><transport xmlns="http://www.google.com/transport/p2p"/></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">unknown session</sta:text></error></iq>
By: Anthony LaMantia (alamantia) 2006-11-01 14:25:58.000-0600

have either of you tired setting bindaddr=
in your gtalk.conf after using the patch from issue 8164, this is helped a number of people in the same situation.
By: Andres Maduro (palillo) 2006-11-01 17:04:28.000-0600

I have just upgraded to latest svn which already have the patch applied and added the binaddr to gtalk.conf

I don't have audio in either way and I am getting this messages about not being able to bridge the gtalk and sip channels.  With or without the binaddr there is no audio.  Before, I had audio in 1 way.

JABBER: asterisk INCOMING: <iq to="palillo@gmail.com/asterisk1C505549" id="aaaau" type="result" from="ricardo.maduro@gmail.com/Talk.v100F8AAB7F5"/>
[Nov  1 18:50:21] VERBOSE[23795] logger.c: --- set_address_from_contact host '192.168.0.192'
[Nov  1 18:50:21] VERBOSE[24850] logger.c:     -- SIP/101-08cc7a90 answered Gtalk/ricardo.maduro-ca75
[Nov  1 18:50:21] NOTICE[24850] chan_gtalk.c: Don't know how to indicate condition '-1'
[Nov  1 18:50:21] WARNING[24850] rtp.c: Can't find native functions for channel 'Gtalk/ricardo.maduro-ca75'
[Nov  1 18:50:21] VERBOSE[24850] logger.c:     -- Native bridging Gtalk/ricardo.maduro-ca75 and SIP/101-08cc7a90 ended

The local ethernet address of my server is 192.168.0.7 which I added to gtalk.conf with:

[general]
bindaddr=192.168.0.7
context=from-pstn               ;;Context to dump call into
allowguest=yes                  ;;Allow calls from people not in
                               ;;list of peers
By: phsultan (phsultan) 2007-01-22 09:29:51.000-0600

I believe the NAT part of this issue is related to bug ASTERISK-7973. Please check this bug report.

As for the native bridging problem, I suggest to force P2P bridging whenever a Gtalk channel is involved in the communication, as direct media connection not yet implemented.

Patch to SVN trunk is attached, disclaimer sent.
By: Farrukh Ahmed (f4fahmed) 2007-05-07 22:27:05

I have used following patch into my testing machine and found that 2 way audio from Gtalk -> Asterisk is working perfectly.

I am using SVN Revision: 63195
By: John Todd (jtodd) 2007-05-10 13:14:03

The P2P bridge patch may work in some circumstances, but apparently not in mine.   I have never had a successful call with Gtalk in a NAT environment (and due to my test configuration, this means I've never seen it work at all.)  Please see attached file (jtodd-gtalk-details) for more information and configuration notes.

Short summary: chan_gtalk is currently non-functional for the 85% of destinations that are behind NAT.  I'm very interested in helping to get it working; let me know if anyone has more debug ideas.

My configuration:
- Asterisk (SVN trunk, no mods except for P2P bridge patch in this bug)
- Asterisk box on public IP address
- only one interface on Asterisk system (eth0)
- Gtalk client (native Google client) on NAT'ed IP address
- SIP client works fine on the Asterisk system (canreinvite=no, also)
- SIP client and Gtalk client are behind the same NAT



Output on console from a call from a SIP extension (2208) to a Gtalk user (gtalknative).  The JabberSend works fine - the user 'gtalknative' gets the message that extension 2208 is calling.  The Gtalk client rings, and I "answer" on the Gtalk side.  Audio gets set up, but I can only hear audio from the Gtalk client -> SIP, but not the other way around.    The debug in the other direction is similar, where my Gtalk client (logged in under "gtalknative) calls "johnhtodd", which is associated with my Asterisk system.  The call goes through - I get the ring, I answer the SIP extension, and I can hear audio from the Gtalk side of the link.  However, audio from the SIP phone does not reach the Gtalk client - same symptoms as going the other direction.  The patch did not make a difference in this instance.  I am using SVN TRUNK r63730 for these tests.
By: phsultan (phsultan) 2007-05-10 13:24:10

Hi John,

the P2P patch won't correct your problem, it solves a native bridging issue. However, you might want to take a look a bug ASTERISK-7973, and test the proposed fix that addresses a NAT issue : http://bugs.digium.com/view.php?id=8193

Philippe
By: John Todd (jtodd) 2007-05-10 13:44:12

Sorry for the noise on this bug.  My problem does seem to have symptoms more closely related to http://bugs.digium.com/view.php?id=8193  and the patch in that bug solves the issues.  Deleted my attachment.
By: Olle Johansson (oej) 2007-05-24 10:05:34

phsultan's fix committed to 1.4 svn rev 65857 and trunk. Thanks.