Summary:	ASTERISK-10159: cli command "gtalk show channels" output always "No gtalk channels in use"
Reporter:	keepitcool (keepitcool)	Labels:
Date Opened:	2007-08-24 04:35:36	Date Closed:	2007-08-31 12:30:16
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_gtalk
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) branch-1.4-10548-1.diff ( 1) branch-1.4-10548-2.diff ( 2) branch-1.4-10548-3.diff
Description:	Even when there are established Gtalk calls (with other Gtalk or IAX)the cli command "gtalk show channels" output always "No gtalk channels in use". Using the cli command "core show channels" its possible to see that there are Gtalk channels active. Testing components: - Fedora core 3 + Asterisk server 1.4.11 (no zaptel, no libpri) + iksemel 1.3 - With the following patch applied (http://bugs.digium.com/view.php?id=10509) And everything else seems to be working ok - audio, call setup and establishment, etc.
Comments:	By: phsultan (phsultan) 2007-08-27 09:02:24 Hi keepitcool, please try this patch. By: keepitcool (keepitcool) 2007-08-27 16:31:42 Hi Phsultan, Just finished testing your patch. Now the cli command is showing some information. ;-) Is there any defined criteria you are following for the output information of these cli command, or is up to you to decide what to output ? I’m asking because some additional information it would be nice to have would be: - Channel name (different from Jabber id for multiple channels isn't it?!) - Format of the codec being used (gsm,...) Please tell me also what represent the fields you have added. The “Read format” and “Write format” are both showing “0x40 (slin)” and I don't understand what they mean. Thank you! By: phsultan (phsultan) 2007-08-28 09:02:12 Well, I thought you would get codec used in the read/write modes. Please try this new version :) The channel name is displayed by the 'core show channels' command, do you think it's worth including it also in 'gtalk show channels'? By: keepitcool (keepitcool) 2007-08-28 16:18:31 In the “Read format” and “Write format” it appears now “slin”, instead of “gsm” (the codec I’m using). The name of the channel appears also in other commands like for example the “iax2 show channels”. The idea of having the channel name in the “gtalk show channels” is to be able for example to see what codec is associated with each gtalk channel. And in the case of having more than one channel with the same jabber id the channel name would be the way to distinguish two different connections. By: phsultan (phsultan) 2007-08-29 04:42:30 >  In the “Read format” and “Write format” it appears now “slin”, instead of > “gsm” (the codec I’m using). Are your sure that GSM is actually used? I'm asking because my GoogleTalk client does not propose this codec. What does the 'rtp debug' command says? > The idea of having the channel name in the “gtalk show channels” is to be able > for example to see what codec is associated with each gtalk channel. And in the > case of having more than one channel with the same jabber id the channel name > would be the way to distinguish two different connections. Yep, new version displays the channel name. By: keepitcool (keepitcool) 2007-08-29 15:20:52 I believed the codec was gsm because in the gtalk.conf I have: [buddy] disallow=all allow=gsm ... But the previous config's seems not to be respected. New bug or am I doing something wrong? In respect to this bug, the cli command "gtalk show channels" is now showing an output with relevant and accurate information. Thank you once again for your quick fixes! By: phsultan (phsultan) 2007-08-30 03:57:33 You cannot force the use of GSM, you can only 'suggest' it to the remote peer during the codec negociation procedure. However, both Asterisk and GoogleTalk seem to have codec related problems : http://www.voip-info.org/wiki/view/Asterisk+Google+Talk#Bugsampknownissues Having your feedback on that would be nice. Do not hesitate to post report here if you find any bug. Will commit the patch soon, thanks for your quick feedback and suggestions! By: keepitcool (keepitcool) 2007-08-30 06:53:17 From my understanding you do not ‘force’ the use of the GSM, you ‘suggest’ it but if it’s the only option and it is not followed by the remote peer the connect attempt should be rejected. A nice way to force by suggesting :-) At least is seems to me that it is what happens with for example IAX clients. 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 ? If the gtalk client doesn’t support one codec type (for example GSM) and I have in gtalk.conf the: disallow=all allow=gsm the connection shouldn’t be established also. What do you think ? This possible issue is related with establishing or not the connections based on the peers capabilities (and asterisk server options). But as you requested I will try also to test different codec options to see if I can help in any way with the existing gtalk-asterisk codec problems you pointed out. By: phsultan (phsultan) 2007-08-30 07:09:54 You are right, please open a new bug report :) By: phsultan (phsultan) 2007-08-31 12:30:16 Committed to revision 81410 in 1.4, 81411 in trunk, thanks!