[asterisk-bugs] [Asterisk 0010604]: Codec options in gtalk.conf not respected

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10604 
====================================================================== 
Reported By:                keepitcool
Assigned To:                phsultan
====================================================================== 
Project:                    Asterisk
Issue ID:                   10604
Category:                   Channels/chan_gtalk
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-30-2007 08:00 CDT
Last Modified:              10-04-2007 14:16 CDT
====================================================================== 
Summary:                    Codec options in gtalk.conf not respected
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)

====================================================================== 

---------------------------------------------------------------------- 
 keepitcool - 10-04-07 14:16  
---------------------------------------------------------------------- 
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). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-04-07 14:16  keepitcool     Note Added: 0071472                          
======================================================================