Summary:	ASTERISK-10131: channel appear as UP before call being picked up (and wrong indication in CDR)
Reporter:	keepitcool (keepitcool)	Labels:
Date Opened:	2007-08-21 03:55:24	Date Closed:	2007-08-24 06:31:32
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_gtalk
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) branch-1.4-10509-1.diff
Description:	Hello, First of all, nice work on the xmpp/gtalk support as a first approach to support jingle. My first bug report here, so if something is missing (or wrong) please let me know. In all my testing scenarios with established calls everything seems to be working ok - including the audio (but  I tested only with the gsm codec). The problems I detected seem to be more related to signaling when the call do not go through because one party ends the call before it being picked up. Please read bellow a detailed description: 1) PROBLEM: Channel appear as UP before call being picked up (and wrong indication in CDR) Testing components: - Fedora core 3 + Asterisk server 1.4.10 (no zaptel, no libpri) + iksemel 1.3 (also tested with 1.2) - 1 google talk credentials for asterisk server connection - 3 clients on different PC’s for testing: 1 zoiper iax client (IAX_CLIENT), 2 google talk clients (GTALK_CLIENT_1, GTALK_CLIENT_2) Testing Flow: Clients trying to call each other (once at a time) and one of the parties ending the call before the call being picked up. In the next points I will detail the problems according to the direction of establishment of the call: 1.a) IAX_CLIENT -> GTALK_CLIENT_1 In both the following situations: - call is disconnected by the IAX_CLIENT before the GTALK_CLIENT_1 pick it up - or call being rejected by the GTALK_CLIENT_1 the channels appear always as UP (“show channels”) and in the CDR (in the end of the call attempt) appears as “ANSWERED”. This is not correct. 1.b) GTALK_CLIENT_1 -> GTALK_CLIENT_2 In both the following situations: - call is disconnected by the GTALK_CLIENT_1 before the GTALK_CLIENT_2 pick it up - or call being rejected by the GTALK_CLIENT_2 the channels appear always as UP (“show channels”) and in the CDR (in the end of the call attempt) appears as “ANSWERED”. This is not correct. 1.c) GTALK_CLIENT_1 -> IAX_CLIENT In both situations: - Call is disconnected by the GTALK_CLIENT_1 before the IAX_CLIENT pick it up - or call being rejected by the IAX_CLIENT the channels appear only as Ringing/Ring (“show channels”) and in the CDR (in the end of the call attempt) appears as “NO ANSWER”. So, in these situation everything seems to be OK! The problem in this last scenario is that when it is the IAX_CLIENT that rejects the call the GTALK_CLIENT_1 keeps ringing until it goes to the google voice mail. (It seems not to be notified about the call end) When the call is rejected by the IAX_CLIENT in the asterisk CLI appears: [Aug  9 17:34:08] NOTICE[21377]: chan_gtalk.c:1371 gtalk_indicate: Don't know how to indicate condition '-1'  == Auto fallthrough, channel 'Gtalk/rpinto-12d3' status is 'CHANUNAVAIL' [Aug  9 17:34:08] NOTICE[21377]: chan_gtalk.c:1371 gtalk_indicate: Don't know how to indicate condition '8'
Comments:	By: phsultan (phsultan) 2007-08-21 12:01:54 You're right there's a bug here, we're answering the call upon reception of a 'transport-accept' iq packet, which is wrong. However, we still need to acknowledge this packet so that the remote GoogleTalk client does not close the call, see bug ASTERISK-8718. Please try the attached patch and give your feedback. By: phsultan (phsultan) 2007-08-21 12:04:10 And thanks for the detailed and accurate report, keep it cool :) By: keepitcool (keepitcool) 2007-08-23 07:33:43 Thank you for the fast answer. Just tested your patch (using asterisk 1.4.10.1) and all the same configuration and testing scenario described before. Regarding the channels appearing as "UP" before the calls being picked up, that was solved, so also the CDR issues are solved and it now appear always a "NO ANSWER" record. But (why is there always a but ?! :)) there are still some scenarios where one side keeps ringing even after the call being ended or rejected: (Note: Do not forget that in any scenario the calls aren't picked up, they are always ended by one side) 1.a) IAX_CLIENT -> GTALK_CLIENT_1 When the call is rejected by the GTALK_CLIENT_1 the IAX_CLIENT keeps ringing and the channel is in the state "Busy". When the call is ended by the IAX_CLIENT everything is ok. 1.b) GTALK_CLIENT_1 -> GTALK_CLIENT_2 When the call is rejected by the GTALK_CLIENT_2 the GTALK_CLIENT_1 keeps ringing and the channel is in the state "Busy". When the call is disconnected by the GTALK_CLIENT_1 everything is Ok. 1.c) GTALK_CLIENT_1 -> IAX_CLIENT When the call is rejected by the IAX_CLIENT the GTALK_CLIENT_1 keeps ringing and the channel is in the state "Busy". When the Call is disconnected by the GTALK_CLIENT_1 everyhing is Ok. So, the common in the previous 3 scenarios is that the problem seems to exist only when the receiving party (gtalk or iax) reject the call. Hope this will help. By: phsultan (phsultan) 2007-08-23 09:40:33 Well as long as the *called* party is rejecting the call, having the call closed and marked with a BUSY state looks fine to me. I tested it in a SIP to IAX call configuration and observed the same results. But the call should stop ringing on the calling side too... does the corresponding section of your extensions.conf file end with a Hangup() statement? By: keepitcool (keepitcool) 2007-08-23 11:03:10 Once again thank you for your fast answers! You are right, it was missing the Hangup(). It was commented, sorry! Now, everything seems pretty good! I'm noticing some strange issues on other areas (more jabber presence related), but when I'm able to reproduce the issues and I have more detail, if necessary I will open a new bug. Meanwhile, do you happen to know were I can get more detailed information about the gtalk/jabber configuration options in asterisk, so I can test it further and be more certain about using all the correct configuration options? By: keepitcool (keepitcool) 2007-08-23 11:33:47 And if you can tell me where can I ask a few questions before deciding if it is a bug or not, please let me know. Questions, like for example: 1) Why the cli "gtalk show channels" command say always "no gtalk channels in use" even when there are established gtalk calls ? 2) Does the chan_gtalk already supports other codecs besides gsm ? What codecs? 3) Is it possible to have the same gtalk user configured in more then one asterisk server? By: keepitcool (keepitcool) 2007-08-23 12:03:43 ahhh... another question :) How do I know if this correction of yours is included in the next asterisk release? By: phsultan (phsultan) 2007-08-24 03:14:49 Hi keepitcool, > I'm noticing some strange issues on other areas (more jabber presence > related), but when I'm able to reproduce the issues and I have more detail, > if necessary I will open a new bug. Recent fixes have been added to the 1.4.11 release, related to presence handling, see ASTERISK-9860. > Meanwhile, do you happen to know were I can get more detailed information > about the gtalk/jabber configuration options in asterisk, so I can test it > further and be more certain about using all the correct configuration options? Well, you probably already visited this URL, which I found useful :  http://www.voip-info.org/wiki/view/Asterisk+Google+Talk This page is regularly updated, but do not hesitate to provide corrections/updates! > 1) Why the cli "gtalk show channels" command say always > "no gtalk channels in use" even when there are established gtalk calls ? That looks like a bug, please open a bug report with all the details you have. > 2) Does the chan_gtalk already supports other codecs besides gsm ? > What codecs? Codec resources are common to all channels that do RTP in Asterisk. > 3) Is it possible to have the same gtalk user configured in more > then one asterisk server? Well I guess that is possible, not sure though. I think Google's jabber server uses unique resource strings, valid for the time of a session in order to distinguish between JIDs. > How do I know if this correction of yours is included in the next > asterisk release? Now you have confirmed your problem is fixed, I will commit the patch soon in both SVN trunk and 1.4 branch. Thanks for thouroughly testing and reporting on this bug! By: keepitcool (keepitcool) 2007-08-24 03:51:12 It's me that have to thank you for all your quick answers and fixes! Great work! I will open the "gtalk show channels" bug. See you. By: Digium Subversion (svnbot) 2007-08-24 06:24:45 Repository: asterisk Revision: 80661 ------------------------------------------------------------------------ r80661 | phsultan | 2007-08-24 06:24:43 -0500 (Fri, 24 Aug 2007) | 9 lines Closes issue ASTERISK-10131 Googletalk calls are answered too early, which results in CDRs wrongly stating that a call was ANSWERED when the calling party cancelled a call before before being established. We must not answer the call upon reception of a 'transport-accept' iq packet, but this packet still needs to be acknowledged, otherwise the remote peer would close the call (like in ASTERISK-8718). ------------------------------------------------------------------------ By: Digium Subversion (svnbot) 2007-08-24 06:31:32 Repository: asterisk Revision: 80662 ------------------------------------------------------------------------ r80662 | phsultan | 2007-08-24 06:31:32 -0500 (Fri, 24 Aug 2007) | 17 lines Merged revisions 80661 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r80661 | phsultan | 2007-08-24 13:42:46 +0200 (Fri, 24 Aug 2007) | 9 lines Closes issue ASTERISK-10131 Googletalk calls are answered too early, which results in CDRs wrongly stating that a call was ANSWERED when the calling party cancelled a call before before being established. We must not answer the call upon reception of a 'transport-accept' iq packet, but this packet still needs to be acknowledged, otherwise the remote peer would close the call (like in ASTERISK-8718). ........ ------------------------------------------------------------------------