[Home]

Summary:ASTERISK-12521: False state in core show hints
Reporter:Marcin Kowalczyk (kowalma)Labels:
Date Opened:2008-08-05 07:45:22Date Closed:2009-02-11 08:46:16.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents: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