[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:              11-01-2007 07:39 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 - 11-01-07 07:39  
---------------------------------------------------------------------- 
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? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-01-07 07:39  keepitcool     Note Added: 0072879                          
======================================================================