Summary:	ASTERISK-08718: [patch] Asterisk to GoogleTalk client communications fail
Reporter:	phsultan (phsultan)	Labels:
Date Opened:	2007-02-02 10:15:20.000-0600	Date Closed:	2007-08-24 06:31:32
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_gtalk
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) branch-1.4-asterisk_to_gtalk_shutoff-1.diff ( 1) branch-1.4-asterisk_to_gtalk_shutoff-2.diff ( 2) trunk-asterisk_to_gtalk_shutoff-1.diff
Description:	Hi, Calling from a SIP phone an extension that opens a Gtalk channel causes either a deadlock issue or unexpected call teardown. In the first case (guest account is used in the gtalk.conf configuration file), some mutex is kept locked, and Asterisk dumps explicit error messages like : [Feb  2 16:51:55] ERROR[18298]: /home/sultan/src/asterisk/trunk/include/asterisk/lock.h:244 __ast_pthread_mutex_lock: chan_gtalk.c line 1530 (gtalk_parser): Deadlock? waited 155 sec for mutex '&((struct gtalk *) data)->_lock'? The second problem is caused by Asterisk not responding to a Gtalk IQ (Information Query) from the remote GoogleTalk client. This makes the GoogleTalk client close the call after some time. The attached patch corrects those issues, and possibly other observed failures in bug ASTERISK-7973. Philippe Sultan
Comments:	By: phsultan (phsultan) 2007-02-02 10:25:22.000-0600 The error message related to the locking issue was incomplete in my initial report , here is the complete version : [Feb 2 16:51:55] ERROR[18298]: /home/sultan/src/asterisk/trunk/include/asterisk/lock.h:244 __ast_pthread_mutex_lock: chan_gtalk.c line 1530 (gtalk_parser): Deadlock? waited 155 sec for mutex '&((struct gtalk *) data)->_lock'? [Feb  2 16:51:55] ERROR[18298]: /home/sultan/src/asterisk/trunk/include/asterisk/lock.h:247 __ast_pthread_mutex_lock: chan_gtalk.c line 285 (find_gtalk): '&((struct gtalk *) data)->_lock' was locked here. By: Olle Johansson (oej) 2007-02-11 12:43:48.000-0600 Is this a problem in 1.4 too - if so, can you please provide a patch for 1.4? By: phsultan (phsultan) 2007-02-12 07:37:17.000-0600 Yes it is Olle! Patch is attached. By: phsultan (phsultan) 2007-02-21 04:30:44.000-0600 Patch updated to latest revision. By: Jason Parker (jparker) 2007-02-21 14:31:44.000-0600 Fixed in 1.4 and trunk in revisions 55954 and 55955. 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). ........ ------------------------------------------------------------------------