[Home]

Summary:ASTERISK-10200: Codec options in gtalk.conf not respected
Reporter:keepitcool (keepitcool)Labels:
Date Opened:2007-08-30 08:00:54Date Closed:2008-04-04 12:38:16
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_gtalk
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) branch-1.4-10604-1.diff
( 1) branch-1.4-10604-2.diff
Description:When you have in gtalk.conf the following configuration:
[buddy]
disallow=all
allow=gsm
...

The gtalk connection is established even if the gtalk client do not support the GSM codec, and the connection/channel appears established with a different codec that it is not allowed (like for example the slin codec).

On the other side, a similar configuration with IAX works as it is supposed to.
When I have a configuration like this on my iax.conf :
disallow=all
allow=gsm
...

And when my remote client do not have GSM as one of the possible codecs, the connect attempt is rejected and I receive the following message in my zoiper iax client : “bearercapability notavail”

And on the asterisk server side I have the following message:
[Aug 30 11:40:50] NOTICE[1358]: chan_iax2.c:7645 socket_process: Rejected connect attempt from XX.XX.XX.XX, requested/capability 0x200/0x60c incompatible with our capability 0xe002.

Isn’t it suppose to work the same way with the gtalk ?

Testing components:
- Fedora core 3 + Asterisk server 1.4.11 (no zaptel, no libpri) + iksemel 1.3
- Google Talk client 1.0.0.104
- With the following patchs applied:
http://bugs.digium.com/view.php?id=10509
http://bugs.digium.com/view.php?id=10548 (branch-1.4-10548-3.diff)
Comments:By: phsultan (phsultan) 2007-10-04 04:55:43

Hi keepitcool, can you please try the attached patch?

Thanks!
By: keepitcool (keepitcool) 2007-10-04 05:49:06

Hi Phsultan,

Nice to ear again from you.
I need your help because I'm a little bit confused.

Some time have passed, and there's now a new version of asterisk (1.4.12).
In my tests I always try to use the latest versions to avoid finding bugs that are already solved.

But with all these versions, the previous patches you have made and now this new patch, I'm a little bit lost.

How can I know if the new asterisk version already have the previous patchs?
Can I just use the latest asterisk version and add all previous patchs plus this new one ?

Please let me know, so I can continue the tests.
Thanks!
By: phsultan (phsultan) 2007-10-04 06:12:51

The patches made out of your previous bug reports have all been included in Asterisk 1.4.12. So you can download this new version, and fix it with this new patch only.

Thank you very much for your patience and help!
By: keepitcool (keepitcool) 2007-10-04 14:16:25

Testing components:
- Fedora core 3 + Asterisk server 1.4.12 (no zaptel, no libpri) + iksemel 1.3
- Google Talk client 1.0.0.104
- With the this new patch applied:

The gtalk.conf options are still not respected. I have:
[buddy]
...
disallow=all
allow=ulaw
...

and when the connection is established in the gtalk side the codec used is "slin".

So, it seems the problem reported still exists.

Unfortunately I noticed other problem: The audio do not pass in the direction gtalk client -> iax client, but it passes ok in the opposite direction (iax->gtalk).

To check if it was from your patch I changed to version 1.4.11 with all the previous patchs from the bugs I reported (indicated above), and the audio problem is there also! (and everything used to work very well)

I have also tested a simple echo test using only the gtalk client and it do not work.

I haven't made tests with gtalk since I open this bug, so some changes might have happen on the Google side. Do you notice this audio problem also?

Please let me know how can I help you and if I should open a separate bug for the audio problem (if it is a bug).
By: keepitcool (keepitcool) 2007-10-04 14:30:25

Some other things:
Is there any place to discuss about certain issues before opening bugs or feature requests?

I would like to help test the codec compatibilities between gtalk and asterisk (iax/sip) clients,but I would like to know what people already know and have done on that area.

And I would like also to know if it is possible to have rtp data pass directly between iax/sip clients and gtalk clients (not passing in the asterisk server).

and some other things...

Is there a place where people discuss these things more actively?
By: phsultan (phsultan) 2007-10-04 15:54:08

How are you placing the call? GoogleTalk -> Asterisk -> IAX or the opposite way? Please try both call configurations.

Also, an console debug output (along with an 'rtp debug' output) will help solve the half way audio problem you're experiencing. I am not able to reproduce it, thanks!

I'll try to answer your other questions :
- it is currently not possible to have the audio streams bypass Asterisk when a GoogleTalk client is involved in the call ;
- the best places to start discussions about new features or configuration issues are the Asterisk user/developer mailing lists, and the IRC channel.
By: phsultan (phsultan) 2007-10-04 15:55:52

Please also restrict the codec set to GSM in your gtalk.conf file :
disallow=all
allow=gsm
By: phsultan (phsultan) 2007-10-05 08:54:46

Ok I rewent through testing, and realized the previous patch did not work properly, as you mentioned it. Can you please try this new version?
By: keepitcool (keepitcool) 2007-10-05 10:14:53

Thank you for your answers.

Initially I was placing the call: IAX -> Asterisk -> Gtalk
But now I tried in both directions and have the same results.
I have restricted my tests to gsm only (gtalk.conf: disallow=all allow=gsm)
The gtalk.conf configs are not respected. (gtalk show channels always indicated that the codec being used is slin)

Please find bellow the debug information you requested. I have done a full search and replace of certain parameters just to avoid having some information posted here at a public place, but if you prefer to have the original data, I may send you through a more private channel. (email?)

I have tried with no active firewalls on both sides (server and clients) and I have also configured additional rtp ports in rtp.conf ->from 1650 to 53000. Initially it was only from 1650 to 4650 but it seemed from the debug that now higher ports are being used.
But the audio still doesn't work from the gtalk client to the iax. (but ok from iax to gtalk).
I have also seen the connection monitor on the gtalk client and there are only received Bytes (recvB), no sent Bytes (sentB = 0).
In the asterisk debug output it seems there are also only rtp packets from asterisk to the gtalk client (confirmed with a iptables logging)

Really strange this one way audio problem...
Is it just a simple thing I'm not seeing? :-)

Asterisk debug output :
(note: for these tests I sticked with the 1.4.12 + this new patch)
--------------------------------------------------
MY_MACHINE*CLI>
   -- Accepting AUTHENTICATED call from MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):
      > requested format = gsm,
      > requested prefs = (),
      > actual format = gsm,
      > host prefs = (),
      > priority = mine
   -- Executing [200@MY_CONTEXT:1] Dial("IAX2/MY_IAX_USER-3", "GTALK/gtalk_account/MY_GTALK_CLIENT") in new stack
MY_MACHINE*CLI>
JABBER: gtalk_account OUTGOING: <iq type='set' to='MY_GTALK_CLIENT/Talk.v104EBC9D3E1' from='MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B' id='aaaak'><session xmlns='http://www.google.com/session' type='initiate' initiator='MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B' id='510b3bc22527311a'><description xmlns='http://www.google.com/session/phone' xml:lang='en'><payload-type id='106' name='telephone-event' clockrate='8000'/></description><transport xmlns='http://www.google.com/transport/p2p'/></session></iq>
MY_MACHINE*CLI>
JABBER: gtalk_account OUTGOING: <iq from='MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B' to='MY_GTALK_CLIENT/Talk.v104EBC9D3E1' type='set' id='aaaal'><session type='transport-info' id='510b3bc22527311a' initiator='MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B' xmlns='http://www.google.com/session'><transport xmlns='http://www.google.com/transport/p2p'><candidate name='rtp' address='MY_ASTERISK_SERVER_IP_ADRESS(NO_NAT)' port='7708' username='4b976c22175e85af' password='4fab089a4432f86a' preference='1.00' protocol='udp' type='local' network='0' generation='0'/></transport></session></iq>
   -- Called gtalk_account/MY_GTALK_CLIENT
MY_MACHINE*CLI>
JABBER: gtalk_account INCOMING: <iq to="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" id="aaaak" type="result" from="MY_GTALK_CLIENT/Talk.v104EBC9D3E1"/>
   -- Gtalk/MY_GTALK_CLIENT-80c1 is ringing
MY_MACHINE*CLI>
JABBER: gtalk_account INCOMING: <iq to="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" type="set" id="415" from="MY_GTALK_CLIENT/Talk.v104EBC9D3E1"><session type="transport-accept" id="510b3bc22527311a" initiator="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" xmlns="http://www.google.com/session"><transport xmlns="http://www.google.com/transport/p2p"/></session></iq>
MY_MACHINE*CLI>
JABBER: gtalk_account OUTGOING: <iq type='result' from='MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B' to='MY_GTALK_CLIENT/Talk.v104EBC9D3E1' id='415'/>
MY_MACHINE*CLI>
JABBER: gtalk_account INCOMING: <iq to="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" id="aaaal" type="result" from="MY_GTALK_CLIENT/Talk.v104EBC9D3E1"/>
MY_MACHINE*CLI>
JABBER: gtalk_account INCOMING: <iq to="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" type="set" id="417" from="MY_GTALK_CLIENT/Talk.v104EBC9D3E1"><session type="transport-info" id="510b3bc22527311a" initiator="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" xmlns="http://www.google.com/session"><transport xmlns="http://www.google.com/transport/p2p"><candidate name="rtp" address="192.168.1.66" port="2838" preference="1" username="lsEgUT0n7sC2mh/m" protocol="udp" generation="0" password="az5ipAqJDCwUPZ95" type="local" network="0"/></transport></session></iq>

JABBER: gtalk_account OUTGOING: <iq type='result' from='MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B' to='MY_GTALK_CLIENT/Talk.v104EBC9D3E1' id='417'/>
MY_MACHINE*CLI>
JABBER: gtalk_account INCOMING: <iq to="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" type="set" id="418" from="MY_GTALK_CLIENT/Talk.v104EBC9D3E1"><session type="transport-info" id="510b3bc22527311a" initiator="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" xmlns="http://www.google.com/session"><transport xmlns="http://www.google.com/transport/p2p"><candidate name="rtp" address="MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT)" port="54350" preference="0.9" username="6KQPPHkyJxnplbtG" protocol="udp" generation="0" password="6RmONYNag4j9M4cn" type="stun" network="0"/></transport></session></iq>

JABBER: gtalk_account OUTGOING: <iq type='result' from='MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B' to='MY_GTALK_CLIENT/Talk.v104EBC9D3E1' id='418'/>
MY_MACHINE*CLI>
JABBER: gtalk_account INCOMING: <iq to="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" type="set" id="420" from="MY_GTALK_CLIENT/Talk.v104EBC9D3E1"><session type="accept" id="510b3bc22527311a" initiator="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" xmlns="http://www.google.com/session"><description xml:lang="en" xmlns="http://www.google.com/session/phone"><payload-type id="106" name="telephone-event" clockrate="8000"/></description></session></iq>
   -- Gtalk/MY_GTALK_CLIENT-80c1 answered IAX2/MY_IAX_USER-3

JABBER: gtalk_account OUTGOING: <iq type='result' from='MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B' to='MY_GTALK_CLIENT/Talk.v104EBC9D3E1' id='420'/>
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013901, ts 000160, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013902, ts 000320, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013903, ts 000480, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013904, ts 000640, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013905, ts 000800, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013906, ts 000960, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013907, ts 001120, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013908, ts 001280, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013909, ts 001440, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013910, ts 001600, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013911, ts 001760, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013912, ts 001920, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013913, ts 002080, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013914, ts 002240, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013915, ts 002400, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013916, ts 002560, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013917, ts 002720, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013918, ts 002880, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013919, ts 003040, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013920, ts 003200, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013921, ts 003360, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013922, ts 003520, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013923, ts 003680, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013924, ts 003840, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013925, ts 004000, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013926, ts 004160, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013927, ts 004320, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013928, ts 004480, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013929, ts 004640, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013930, ts 004800, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013931, ts 004960, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013932, ts 005120, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013933, ts 005280, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013934, ts 005440, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013935, ts 005600, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013936, ts 005760, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013937, ts 005920, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013938, ts 006080, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013939, ts 006240, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013940, ts 006400, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013941, ts 006560, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013942, ts 006720, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013943, ts 006880, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013944, ts 007040, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013945, ts 007200, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013946, ts 007360, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013947, ts 007520, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013948, ts 007680, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013949, ts 007840, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013950, ts 008000, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013951, ts 008160, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013952, ts 008320, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013953, ts 008480, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013954, ts 008640, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013955, ts 008800, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013956, ts 008960, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013957, ts 009120, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013958, ts 009280, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013959, ts 009440, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013960, ts 009600, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013961, ts 009760, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013962, ts 009920, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013963, ts 010080, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013964, ts 010240, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013965, ts 010400, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013966, ts 010560, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013967, ts 010720, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013968, ts 010880, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013969, ts 011040, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013970, ts 011200, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013971, ts 011360, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013972, ts 011520, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013973, ts 011680, len 000160)
Sent RTP packet to      MY_CLIENTS_PUBLIC_IP_ADDRESS(BEHIND_NAT):54351 (type 00, seq 013974, ts 011840, len 000160)
MY_MACHINE*CLI>
JABBER: gtalk_account INCOMING: <iq to="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" type="set" id="421" from="MY_GTALK_CLIENT/Talk.v104EBC9D3E1"><session type="terminate" id="510b3bc22527311a" initiator="MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B" xmlns="http://www.google.com/session"/></iq>
 == Spawn extension (MY_CONTEXT, 200, 1) exited non-zero on 'IAX2/MY_IAX_USER-3'
   -- Hungup 'IAX2/MY_IAX_USER-3'
MY_MACHINE*CLI>
JABBER: gtalk_account OUTGOING: <iq type='result' from='MY_GTALK_USER_FOR_ASTERISK_SERVER0D40182B' to='MY_GTALK_CLIENT/Talk.v104EBC9D3E1' id='421'/>

--------------------------------------------------
By: keepitcool (keepitcool) 2007-10-05 10:19:01

I only noticed that you have updated the bug, after posting the test results from what I have been working with.

This new patch you are providing doesn't have anything to do with my one way audio problem, right?
It is only related with the gtalk.conf options not being respected, right?

I may test it, but maybe I should be able to have audio working in both directions first.
What do you think?
By: phsultan (phsultan) 2007-10-09 08:35:13

Hi keepitcool,

your console debug output shows that your GoogleTalk client agreed to setup a DTMF *only* session with Asterisk. No audio has been negociated because of capabilities mismatch (GSM not being supported by the GoogleTalk client).

I tried to address this issue in the new patch, can you please give it a try?

Thanks!
By: keepitcool (keepitcool) 2007-11-01 07:39:04

Hi Phsultan,

First of all I’m sorry for taking so much time to get back to you.
I had some issues that made me take longer to test your patch.

Not much changed in my testing scenario, just the fact that I’m now using the last version of asterisk (1.4.13) and I have applied only your last patch (branch-1.4-10604-2.diff).

Regarding the tests the results were:
Trying to place the call
GTALK_CLIENT_1-> asterisk -> GTALK_CLIENT_2
or
IAX->asterisk->GTALK_CLIENT_1

And although I already have done a lot of tests, I can’t extract concrete results because I’m having some strange behaviors.

First it seems to me that when I do a reload in the asterisk CLI the gtalk.conf is not reloaded. But I notice that if I restart the asterisk the changes in the gtalk.conf are reflected. Is this possible?!

Second, sometimes the call is not even established (for a already working configuration in gtalk.conf like : disallow=all allow=ulaw) and the only strange message I notice is:

JABBER: gtalk_account INCOMING: <iq to="MY_GTALK_USER_FOR_ASTERISK_SERVER854290B3" id="aaaam" type="error" from="GTALK_CLIENT_2/Talk.v104F1CA8805"><session type="transport-info" id="5d801e1134d82854" initiator="MY_GTALK_USER_FOR_ASTERISK_SERVER854290B3" xmlns="http://www.google.com/session"><transport xmlns="http://www.google.com/transport/p2p"><candidate name="rtp" address="MY_ASTERISK_SERVER_IP_ADDRESS" port="2294" username="0942369b4289016c" password="7d22a1085d2ff566" 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">unknown session</sta:text></error></iq>


Your patch seems to have improved and now I notice that the connection is not established if in the gtalk.conf I’m forcing a codec (f.ex: gsm) not supported by gtalk.
But with such an unstable behavior is really difficult to test completely the patch.
And no, I’m not changing the configurations like crazy, just the codec options in the gtalk.conf file. No changes to the already working extensions.conf, etc.

Do you know if anything has changed lately? Do you notice the problems 1 and 2 I reported above?
By: phsultan (phsultan) 2007-12-07 10:01:09.000-0600

Hi keepitcool, sorry for this late answer, I've been quite busy the last month.

You're right the 'gtalk reload' CLI function does nothing. Please open another bug report (assign it directly to me), I'll work on a fix for this problem.

I was not able to reproduce the instability problems you're experiencing with IAX + Gtalk. I'm running an Asterisk 1.4 branch at the latest SVN revision (91735).

Can you post your gtalk.conf, jabber.conf, along with the relevant part of your extensions.ael file?

Thanks!
By: Jason Parker (jparker) 2008-03-28 16:06:47

This issue seems to have morphed into something else.  If the patch fixes the original codec issue, I think this should be committed and closed.
By: phsultan (phsultan) 2008-03-31 06:59:07

Yep, I'll work back on this one.
By: Digium Subversion (svnbot) 2008-04-04 12:12:27

Repository: asterisk
Revision: 112766

U   branches/1.4/channels/chan_gtalk.c

------------------------------------------------------------------------
r112766 | phsultan | 2008-04-04 12:12:25 -0500 (Fri, 04 Apr 2008) | 7 lines

Prevent call connections when codecs don't match.

(closes issue ASTERISK-10200)
Reported by: keepitcool
Patches:
     branch-1.4-10604-2.diff uploaded by phsultan (license 73)
Tested by: phsultan
------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=112766
By: Digium Subversion (svnbot) 2008-04-04 12:28:08

Repository: asterisk
Revision: 112785

_U  trunk/
U   trunk/channels/chan_gtalk.c

------------------------------------------------------------------------
r112785 | phsultan | 2008-04-04 12:28:07 -0500 (Fri, 04 Apr 2008) | 15 lines

Merged revisions 112766 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r112766 | phsultan | 2008-04-04 19:16:59 +0200 (Fri, 04 Apr 2008) | 7 lines

Prevent call connections when codecs don't match.

(closes issue ASTERISK-10200)
Reported by: keepitcool
Patches:
     branch-1.4-10604-2.diff uploaded by phsultan (license 73)
Tested by: phsultan
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=112785
By: Digium Subversion (svnbot) 2008-04-04 12:38:16

Repository: asterisk
Revision: 112786

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

------------------------------------------------------------------------
r112786 | phsultan | 2008-04-04 12:38:15 -0500 (Fri, 04 Apr 2008) | 23 lines

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

................
r112785 | phsultan | 2008-04-04 19:32:46 +0200 (Fri, 04 Apr 2008) | 15 lines

Merged revisions 112766 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r112766 | phsultan | 2008-04-04 19:16:59 +0200 (Fri, 04 Apr 2008) | 7 lines

Prevent call connections when codecs don't match.

(closes issue ASTERISK-10200)
Reported by: keepitcool
Patches:
     branch-1.4-10604-2.diff uploaded by phsultan (license 73)
Tested by: phsultan
........

................

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

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