Summary: | ASTERISK-12521: False state in core show hints | ||
Reporter: | Marcin Kowalczyk (kowalma) | Labels: | |
Date Opened: | 2008-08-05 07:45:22 | Date Closed: | 2009-02-11 08:46:16.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/Subscriptions |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) 20090121__bug13238.diff.txt ( 1) channel.c_1.6.0_rc6_diff.txt | |
Description: | core show hint shows false value of dev state: asterisk-IBM*CLI> core show hint 1231 1231@hints : SIP/1231 State:InUse Watchers 0 1 hint matching extension 1231 asterisk-IBM:/usr/src# rasterisk -x "core show channels" | grep 1231 asterisk-IBM:/usr/src# asterisk-IBM:/usr/src# rasterisk -x "sip show channels" | grep 1231 SIP/1231 is asterisk 1.4.19, asterisk IBM (where I do core show hints) is 1.6.beta9 Restarting asterisk on 1231 does not solve the problem. | ||
Comments: | By: Marcin Kowalczyk (kowalma) 2008-08-05 08:02:04 One more thing: asterisk-IBM:/usr/src# rasterisk -x "sip show inuse" | grep 1231 1231 0 999 1231 -1/0/0 999 asterisk-IBM:/usr/src# By: Russell Bryant (russell) 2008-08-05 08:04:26 Can you nail down a sequence of things such that someone else can reproduce the issue? Otherwise, there isn't much we can do. By: Marcin Kowalczyk (kowalma) 2008-08-05 08:48:51 It happens very random and I don't know how to reproduce it yet. I have incomming queue and I use hint's to detect if agent is busy or not. I use following settings in sip.conf [general] limitonpeers=yes rtptimeout = 600 session-timers=accept session-expires=120 session-minse=90 session-refresher=uas rtptimeout=600 notifyringing = yes notifyhold = yes callcounter = yes allowsubscribe=yes subscribecontext = hints [1231] type=friend secret=XXXXX host=dynamic qualify=20 nat=no allow=all allow=ulaw context=form-cc usereqphone=yes callerid=1231 subscribecontext=hints [hints] contains: exten =>1231,hint,SIP/1231 Incomming calls to queues looks like that: [one] musicclass = one joinempty = yes strategy = leastrecent retry = 10 maxlen = 100 announce-holdtime = no wrapuptime=5 memberdelay = 5 memberdelay = 0 periodic-announce-frequency=30 periodic-announce = pls_wait dialplan to route calls to queue one exten => 116,1,Ringing() exten => 116,n,wait(6) exten => 116,n,Set(CHANNEL(musicclass)=one) exten => 116,n,GotoIfTime(7:00-21:00,mon-sat,*,*?open) exten => 116,n,GotoIfTime(9:00-20:00,sun,*,*?open) exten => 116,n,goto(closed) exten => 116,n(open),Set(QUEUE_PRIO=15) exten => 116,n,SipAddHeader(queue: ${EXTEN}) exten => 116,n,answer() exten => 116,n,wait(1) exten => 116,n,playback(welcome) exten => 116,n,Queue(one) exten => 116,n,hangup(16) exten => 116,n(closed),answer() exten => 116,n,wait(1) exten => 116,n,playback(closed) exten => 116,n,Voicemail(119@queue-vm,s) exten => 116,n,hangup(16) By: Tilghman Lesher (tilghman) 2008-08-05 09:03:17 If SIP/1231 transferred a call incoming from a queue somewhere else, and that call is still active, then this is expected behavior. Queued calls are associated with the channel to which they are originally delivered, even when the call is subsequently transferred (until the call is completed). By: Marcin Kowalczyk (kowalma) 2008-08-05 09:30:57 SIP/1231 has no possibilty to transfer call, so I don't think it's related to call-transfer By: Marcin Kowalczyk (kowalma) 2008-08-11 05:56:28 Today it happened again - I don't know if it's related but when I tried to do sip show history I did segmentatnion fault but asterisk did not crash. By: Marcin Kowalczyk (kowalma) 2008-11-24 02:55:57.000-0600 I think this can be corelated to this issue http://bugs.digium.com/view.php?id=13935 By: Enrico Maistro (emaistro) 2009-01-20 12:27:56.000-0600 I was able to reproduce the same bug in asterisk 1.6.0.1: - core show hints 101@hints : SIP/101&IAX2/101 State:InUse Watchers 1 - sip show inuse 101 -1/0/0 999 - core show channels Channel Location State Application(Data) 0 active channels 0 active calls 3 calls processed Here is how i was able to reliably reproduce it in 5 easy steps: I created 3 extensions (101, 102 and 300) 1) At asterisk startup everything is fine: - sip show inuse 101 0/0/0 999 300 0/0/0 999 102 0/0/0 999 - core show hints 102@hints : SIP/102&IAX2/102 State:Idle Watchers 0 101@hints : SIP/101&IAX2/101 State:Idle Watchers 1 300@hints : SIP/300&IAX2/300 State:Idle Watchers 0 2) 102 call 101 and 101 answer the call, everything is still working as expected - sip show inuse 101 1/0/0 999 300 0/0/0 999 102 1/0/0 999 - core show hints 102@hints : SIP/102&IAX2/102 State:InUse Watchers 0 101@hints : SIP/101&IAX2/101 State:InUse Watchers 1 300@hints : SIP/300&IAX2/300 State:Idle Watchers 0 3) while call between 101 and 102 is still active, 300 place a new call to 101. - sip show inuse 101 2/1/0 999 300 1/0/0 999 102 1/0/0 999 - core show hints 102@hints : SIP/102&IAX2/102 State:InUse Watchers 0 101@hints : SIP/101&IAX2/101 State:InUse&Ringing Watchers 1 300@hints : SIP/300&IAX2/300 State:InUse Watchers 0 4) While call between 101 and 102 is still active and before 101 answer call from 300, 300 cancel call. - sip show inuse 101 0/0/0 999 300 0/0/0 999 102 1/0/0 999 - core show hints 102@hints : SIP/102&IAX2/102 State:InUse Watchers 0 101@hints : SIP/101&IAX2/101 State:Idle Watchers 1 300@hints : SIP/300&IAX2/300 State:Idle Watchers 0 5) 101 hangup call. No more active channels. - sip show inuse 101 -1/0/0 999 300 0/0/0 999 102 0/0/0 999 - core show hints 102@hints : SIP/102&IAX2/102 State:Idle Watchers 0 101@hints : SIP/101&IAX2/101 State:InUse Watchers 1 300@hints : SIP/300&IAX2/300 State:Idle Watchers 0 In sip.conf i've got: allowsubscribe=yes subscribecontext = hints notifyringing = yes notifyhold = yes callcounter = yes counteronpeer = yes By: Tilghman Lesher (tilghman) 2009-01-20 15:23:12.000-0600 emaistro: we'd prefer if you could test this in the latest release of the 1.6.0 series. By: Enrico Maistro (emaistro) 2009-01-21 04:10:58.000-0600 1.6.0.3 have part of the problem. When call from 300 to 101 is cancelled, 101 is put in state Idle instead of back to InUse from InUse&Ringing. Inuse counter reporting -1 seems to have been fixed. By: Tilghman Lesher (tilghman) 2009-01-21 19:23:16.000-0600 Okay, this patch should fix your problem. Please test and give us feedback. By: Alec Davis (alecdavis) 2009-01-22 21:17:04.000-0600 I've had a similar problem, very infrequent, 3 times over ~3 months of use has it been brought to my attention. Today it just happened again. The problem being a Sip phone shows INUSE, when in fact it's not. Ringing from it to another extension didn't fix the state, but ringing it brought the state back to IDLE. Below is a sequence I went though, I didn't do the precursor work to debug it, as it came right too early. It was one of those 'I wonder what would happen if moments', and it came right. Asterisk 1.6.0rc6, (September 2008) so is not the latest. But is a production box so testing has to remain limited. ************************** Ring VoiceMail from 8514, the phone with the InUse hint ************************** **** 8514 rings Voice Mail notice the ‘new state’ Idle??? Should be InUse **** == Using SIP RTP CoS mark 5 == Extension Changed 8514[BLF_Group_1] new state Idle for Notify User GXP0001 == Extension Changed 8514[BLF_Group_1] new state Idle for Notify User GXP0002 -- Executing [8599@trusted:1] NoOp("SIP/8514-b7767c00", "8514") in new stack .... -- Executing [8599@trusted:7] VoiceMailMain("SIP/8514-b7767c00", "") in new stack -- <SIP/8514-b7767c00> Playing 'vm-login.gsm' (language 'en') .... -- <SIP/8514-b7767c00> Playing 'vm-message.gsm' (language 'en') -- <SIP/8514-b7767c00> Playing 'vm-onefor.gsm' (language 'en') == Spawn extension (trusted, 8599, 7) exited non-zero on 'SIP/8514-b7767c00' **** Hangup 8514 phone, ‘new state’ = Inuse ??? Should be Idle**** == Extension Changed 8514[BLF_Group_1] new state InUse for Notify User GXP0001 == Extension Changed 8514[BLF_Group_1] new state InUse for Notify User GXP0002 ************************** from another phone 8513, ring 8514 (the phone with the InUse hint) ************************** **** 8513 rings 8514 **** **** 8513 goes to ‘new state’ = InUse as expected **** == Using SIP RTP CoS mark 5 == Extension Changed 8513[BLF_Group_1] new state InUse for Notify User GXP0001 == Extension Changed 8513[BLF_Group_1] new state InUse for Notify User GXP0002 .... -- Executing [s@macro-procexten:24] Dial("SIP/GXP0003-b776fa28", "SIP/8514,20,r") in new stack == Using SIP RTP CoS mark 5 Called 8514 **** 8514 goes to ‘new state’ = InUse&Ringing, NOT quite as expected **** == Extension Changed 8514[BLF_Group_1] new state InUse&Ringing for Notify User GXP0001 == Extension Changed 8514[BLF_Group_1] new state InUse&Ringing for Notify User GXP0002 -- SIP/8514-08d2fbe8 is ringing **** 8513 Hangs up **** -- Executing [h@macro-procexten:1] NoOp("SIP/GXP0003-b776fa28", "== hangup dialstatus=CANCEL ==") in new stack -- Executing [h@macro-procexten:2] Goto("SIP/GXP0003-b776fa28", "h-CANCEL,1") in new stack -- Goto (macro-procexten,h-CANCEL,1) -- Executing [h-CANCEL@macro-procexten:1] Goto("SIP/GXP0003-b776fa28", "h-CLEANUP,1") in new stack -- Goto (macro-procexten,h-CLEANUP,1) ..... **** 8513 goes to ‘new state’ = Idle as expected **** == Extension Changed 8513[BLF_Group_1] new state Idle for Notify User GXP0001 == Extension Changed 8513[BLF_Group_1] new state Idle for Notify User GXP0002 ****8514 phone goes to ‘new state’ = InUse, NOT expected == Extension Changed 8514[BLF_Group_1] new state InUse for Notify User GXP0001 == Extension Changed 8514[BLF_Group_1] new state InUse for Notify User GXP0002 ****8514 then immediately goes to ‘new state’ = Idle, and is now fixed == Extension Changed 8514[BLF_Group_1] new state Idle for Notify User GXP0001 == Extension Changed 8514[BLF_Group_1] new state Idle for Notify User GXP0002 By: Tilghman Lesher (tilghman) 2009-01-25 17:15:42.000-0600 alecdavis: please try the patch attached and report back. By: Alec Davis (alecdavis) 2009-01-26 02:14:39.000-0600 Uploaded channel.c_1.6.0_rc6_diff.txt to fix asterisk 1.6.0_rc6. I should have said when I added my previous note, I went to apply the original patch '20090121__bug13238.diff.txt' but it failed, there are no occurances of ast_devstate_changed_literal anywhere in channel.c only 2 occurances of 'ast_device_state_changed_literal(name);' the ASTERISK_FILE_VERSION of channel.c is 141950 After reviewing the trunk version of channel.c and the 20090121__bug13238.diff.txt patch I changed the 2 places I found 'ast_device_state_changed_literal(name);' to 'ast_devstate_changed_literal(AST_DEVICE_UNKNOWN, name);' Seems to be working, but time and perhaps lots of it will tell. By: Tilghman Lesher (tilghman) 2009-01-26 16:58:38.000-0600 alecdavis: actually, the patch shouldn't do anything for you on 1.6.0-rc6, but there have been many other changes to devicestates in the most current version of 1.6.0, as compared to that release candidate. I would highly recommend that you upgrade. By: Enrico Maistro (emaistro) 2009-02-04 06:23:52.000-0600 I've managed to try the 20090121__bug13238.diff.txt patch on 1.6.1-RC1 but it behave exactly like unpatched 1.6.0.3 By: Digium Subversion (svnbot) 2009-02-10 09:37:08.000-0600 Repository: asterisk Revision: 174543 U trunk/channels/chan_sip.c ------------------------------------------------------------------------ r174543 | file | 2009-02-10 09:37:07 -0600 (Tue, 10 Feb 2009) | 6 lines Make the logic for inuse and inringing manipluation match that of 1.4. The old broken logic would reset the values back to 0 during certain scenarios causing the wrong state to be reported. (closes issue ASTERISK-13510) Reported by: caspy (issue ASTERISK-12521) Reported by: kowalma ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174543 By: Digium Subversion (svnbot) 2009-02-10 09:39:01.000-0600 Repository: asterisk Revision: 174544 _U branches/1.6.0/ U branches/1.6.0/channels/chan_sip.c ------------------------------------------------------------------------ r174544 | file | 2009-02-10 09:39:01 -0600 (Tue, 10 Feb 2009) | 13 lines Merged revisions 174543 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r174543 | file | 2009-02-10 11:37:07 -0400 (Tue, 10 Feb 2009) | 6 lines Make the logic for inuse and inringing manipluation match that of 1.4. The old broken logic would reset the values back to 0 during certain scenarios causing the wrong state to be reported. (closes issue ASTERISK-13510) Reported by: caspy (issue ASTERISK-12521) Reported by: kowalma ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174544 By: Digium Subversion (svnbot) 2009-02-10 09:39:54.000-0600 Repository: asterisk Revision: 174545 _U branches/1.6.1/ U branches/1.6.1/channels/chan_sip.c ------------------------------------------------------------------------ r174545 | file | 2009-02-10 09:39:54 -0600 (Tue, 10 Feb 2009) | 13 lines Merged revisions 174543 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r174543 | file | 2009-02-10 11:37:07 -0400 (Tue, 10 Feb 2009) | 6 lines Make the logic for inuse and inringing manipluation match that of 1.4. The old broken logic would reset the values back to 0 during certain scenarios causing the wrong state to be reported. (closes issue ASTERISK-13510) Reported by: caspy (issue ASTERISK-12521) Reported by: kowalma ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174545 By: Joshua C. Colp (jcolp) 2009-02-10 09:41:53.000-0600 I just spent some time labbing this up and testing. I believe the original issue has been fixed for a bit and that you have been bitten by an additional issue that I just put a fix in for. I tested the scenario you previously gave before the fix and it did indeed break. After the fix, however, it worked perfectly fine. Please use either 1.6.0 or 1.6.1 from subversion and test. Thanks. By: Alec Davis (alecdavis) 2009-02-10 14:12:09.000-0600 As I only upgraded to trunk yesterday, and no patches uploaded, I've just manually applied the changes, from viewing diffs from http://svn.digium.com/view/asterisk?view=rev&revision=174543 Shouldn't the same checking be applied to the following, to only allow decrementing of inringing if it's positive. line 5315 of chan_sip.c case DEC_CALL_RINGING: if (inringing) { sip_pvt_lock(fup); ao2_lock(p); if (ast_test_flag(&fup->flags[0], SIP_INC_RINGING)) { (*inringing)--; ast_clear_flag(&fup->flags[0], SIP_INC_RINGING); } ao2_unlock(p); sip_pvt_unlock(fup); } By: Digium Subversion (svnbot) 2009-02-10 14:15:44.000-0600 Repository: asterisk Revision: 174710 U trunk/channels/chan_sip.c ------------------------------------------------------------------------ r174710 | file | 2009-02-10 14:15:43 -0600 (Tue, 10 Feb 2009) | 4 lines Only decrease inringing count if above zero. (issue ASTERISK-12521) Reported by: kowalma ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174710 By: Digium Subversion (svnbot) 2009-02-10 14:16:58.000-0600 Repository: asterisk Revision: 174711 _U branches/1.6.0/ U branches/1.6.0/channels/chan_sip.c ------------------------------------------------------------------------ r174711 | file | 2009-02-10 14:16:58 -0600 (Tue, 10 Feb 2009) | 11 lines Merged revisions 174710 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r174710 | file | 2009-02-10 16:15:43 -0400 (Tue, 10 Feb 2009) | 4 lines Only decrease inringing count if above zero. (issue ASTERISK-12521) Reported by: kowalma ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174711 By: Digium Subversion (svnbot) 2009-02-10 14:17:46.000-0600 Repository: asterisk Revision: 174714 _U branches/1.6.1/ U branches/1.6.1/channels/chan_sip.c ------------------------------------------------------------------------ r174714 | file | 2009-02-10 14:17:45 -0600 (Tue, 10 Feb 2009) | 11 lines Merged revisions 174710 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r174710 | file | 2009-02-10 16:15:43 -0400 (Tue, 10 Feb 2009) | 4 lines Only decrease inringing count if above zero. (issue ASTERISK-12521) Reported by: kowalma ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174714 By: Joshua C. Colp (jcolp) 2009-02-10 14:18:14.000-0600 Good catch. I've made that change, thanks. By: Alec Davis (alecdavis) 2009-02-10 15:01:16.000-0600 file: The inuse counts don't seem to go negative anymore. There still seems to be a problem, if a second call is made to an already active sip channel, status changes to inuse&ringing, then if that 2nd attempted call is cancelled, the status changes to IDLE, then for some reason 5-6 seconds later back to INUSE. We use Grandstream GXP2000 BLF buttons to monitor other stations InUse or not. some console output. ... ############# Setup 1st Call to GXP0001 ########## -- Executing [s@macro-procexten:24] Dial("DAHDI/2-1", "SIP/GXP0001,10,r") in new stack == Using SIP RTP CoS mark 5 -- Called GXP0001 == Extension Changed 8512[BLF_Group_1] new state Ringing for Notify User GXP0002 == Extension Changed 8512[BLF_Group_1] new state Ringing for Notify User GXP0001 -- SIP/GXP0001-0910fba0 is ringing -- SIP/GXP0001-0910fba0 answered DAHDI/2-1 == Extension Changed 8512[BLF_Group_1] new state InUse for Notify User GXP0002 == Extension Changed 8512[BLF_Group_1] new state InUse for Notify User GXP0001 == Using SIP RTP CoS mark 5 ... ############# Setup 2nd Call to GXP0001 ########## -- Executing [s@macro-procexten:24] Dial("SIP/8512-0912c9b8", "SIP/GXP0001,10,r") in new stack == Using SIP RTP CoS mark 5 == Extension Changed 8512[BLF_Group_1] new state InUse&Ringing for Notify User GXP0002 == Extension Changed 8512[BLF_Group_1] new state InUse&Ringing for Notify User GXP0001 -- Called GXP0001 -- SIP/GXP0001-b76ad6b0 is ringing ... ############# Cancel 2nd Call to GXP0001, Note 1st call to GXP0001 still active ########## == Extension Changed 8512[BLF_Group_1] new state InUse for Notify User GXP0002 == Extension Changed 8512[BLF_Group_1] new state InUse for Notify User GXP0001 == Spawn extension (macro-procexten, s, 24) exited non-zero on 'SIP/8512-0912c9b8' in macro 'procexten' == Spawn extension (trusted, 8512, 1) exited non-zero on 'SIP/8512-0912c9b8' == Extension Changed 8512[BLF_Group_1] new state Idle for Notify User GXP0002 (queued) == Extension Changed 8512[BLF_Group_1] new state Idle for Notify User GXP0001 (queued) == Extension Changed 8512[BLF_Group_1] new state Idle for Notify User GXP0002 == Extension Changed 8512[BLF_Group_1] new state Idle for Notify User GXP0001 It seemed to have it right, after the call was cancel, went to INUSE, then for some reason IDLE (queued), then IDLE sip show inuse showed * Peer name In use Limit ... GXP0001 1/0/0 10 ... By: Joshua C. Colp (jcolp) 2009-02-10 15:03:54.000-0600 What does sip show inuse show during that time though? The correct value at the correct times? By: Alec Davis (alecdavis) 2009-02-10 16:13:46.000-0600 sip show inuse is correct ... GXP0001 1/0/0 10 So, hints notification is another issue? core show hints show idle and should show InUse 8512@BLF_Group_1 : SIP/GXP0001 State:Idle Watchers 5 By: Alec Davis (alecdavis) 2009-02-10 17:23:20.000-0600 I hadn't applied 20090121__bug13238.diff.txt, which fixes the hints issue. This was required as well as the changes made to trunk chan_sip.c today. I made about 50 calls, and every time the BLF on the grandstream was correct. The console output was correct, GXP0001 never went to Idle. Some console output below, with some debug. [Feb 11 12:15:53] NOTICE[14606]: chan_sip.c:5294 update_call_counter: INC_CALL_RINGING name=GXP0001 inringing=1 [Feb 11 12:15:53] NOTICE[14606]: chan_sip.c:5305 update_call_counter: INC_CALL_RINGING name=GXP0001 inuse=2 -- Called GXP0001 == Extension Changed 8512[BLF_Group_1] new state InUse&Ringing for Notify User GXP0003 == Extension Changed 8512[BLF_Group_1] new state InUse&Ringing for Notify User GXP0002 == Extension Changed 8512[BLF_Group_1] new state InUse&Ringing for Notify User GXP0004 == Extension Changed 8512[BLF_Group_1] new state InUse&Ringing for Notify User GXP0001 == Extension Changed 8512[BLF_Group_1] new state InUse&Ringing for Notify User GXP0005 -- SIP/GXP0001-088e90a0 is ringing [Feb 11 12:15:55] NOTICE[14512]: chan_sip.c:5236 update_call_counter: DEC_CALL_LIMIT name=8512 inuse=0 [Feb 11 12:15:55] NOTICE[14606]: chan_sip.c:5236 update_call_counter: DEC_CALL_LIMIT name=GXP0001 inuse=1 [Feb 11 12:15:55] NOTICE[14606]: chan_sip.c:5253 update_call_counter: DEC_CALL_LIMIT name=GXP0001 inringing=0 == Spawn extension (macro-procexten, s, 24) exited non-zero on 'SIP/8512-b6d8af30' in macro 'procexten' == Spawn extension (trusted, 8512, 1) exited non-zero on 'SIP/8512-b6d8af30' == Extension Changed 8512[BLF_Group_1] new state InUse for Notify User GXP0003 == Extension Changed 8512[BLF_Group_1] new state InUse for Notify User GXP0002 == Extension Changed 8512[BLF_Group_1] new state InUse for Notify User GXP0004 == Extension Changed 8512[BLF_Group_1] new state InUse for Notify User GXP0001 == Extension Changed 8512[BLF_Group_1] new state InUse for Notify User GXP0005 By: Digium Subversion (svnbot) 2009-02-11 08:44:48.000-0600 Repository: asterisk Revision: 174844 U trunk/main/channel.c ------------------------------------------------------------------------ r174844 | file | 2009-02-11 08:44:47 -0600 (Wed, 11 Feb 2009) | 10 lines Tell the device state core a change happened when a channel is freed but not a specific state. We need to do this because while we know that the freeing of the channel may cause something to become not in use we do not know this for sure. There may be another channel that is still up which would cause it to be in use. (closes issue ASTERISK-12521) Reported by: kowalma Patches: 20090121__bug13238.diff.txt uploaded by Corydon76 (license 14) Tested by: alecdavis ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174844 By: Digium Subversion (svnbot) 2009-02-11 08:45:24.000-0600 Repository: asterisk Revision: 174845 _U branches/1.6.0/ ------------------------------------------------------------------------ r174845 | file | 2009-02-11 08:45:24 -0600 (Wed, 11 Feb 2009) | 16 lines Blocked revisions 174844 via svnmerge ........ r174844 | file | 2009-02-11 10:44:47 -0400 (Wed, 11 Feb 2009) | 10 lines Tell the device state core a change happened when a channel is freed but not a specific state. We need to do this because while we know that the freeing of the channel may cause something to become not in use we do not know this for sure. There may be another channel that is still up which would cause it to be in use. (closes issue ASTERISK-12521) Reported by: kowalma Patches: 20090121__bug13238.diff.txt uploaded by Corydon76 (license 14) Tested by: alecdavis ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174845 By: Digium Subversion (svnbot) 2009-02-11 08:46:14.000-0600 Repository: asterisk Revision: 174846 _U branches/1.6.1/ U branches/1.6.1/main/channel.c ------------------------------------------------------------------------ r174846 | file | 2009-02-11 08:46:14 -0600 (Wed, 11 Feb 2009) | 17 lines Merged revisions 174844 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r174844 | file | 2009-02-11 10:44:47 -0400 (Wed, 11 Feb 2009) | 10 lines Tell the device state core a change happened when a channel is freed but not a specific state. We need to do this because while we know that the freeing of the channel may cause something to become not in use we do not know this for sure. There may be another channel that is still up which would cause it to be in use. (closes issue ASTERISK-12521) Reported by: kowalma Patches: 20090121__bug13238.diff.txt uploaded by Corydon76 (license 14) Tested by: alecdavis ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174846 |