| Summary: | ASTERISK-08979: Channel variables are not available in 'h' extension if channel goes zombie | ||
| Reporter: | hristo (hristo) | Labels: | |
| Date Opened: | 2007-03-09 09:01:11.000-0600 | Date Closed: | 2007-06-19 13:31:27 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/Configuration |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 9246.diff | |
| Description: | Once a channel becomes zombie, all variable associated with this channel are lost. I have tested this with DumpChan() in the 'h' extension. A zombie channel can still traverse the dial plan in the 'h' extension and any variable reference will not work in this case. I have inheritable variables that are set in the dial plan and also in sip.conf, but all of them are lost once the channel becomes zombie. While it makes sense to actually destroy all these variables once the channel becomes zombie, they should at least be available for as long as any dial plan logic (incl. 'h' logic) is still to be executed/evaluated. ****** ADDITIONAL INFORMATION ****** In my case this happens after a call transfer, if the tansferee is still in the ringing state when the transfer is completed. In this case the transferring channel becomes zombie all all vars are lost. If the transferee picks up the phone before the transfer is complete (destination channel is no longer in "ringing" state), all vars are available. Note, that in this case I do not have "ZOMBIE" appended to the channel name as well. I need the variables associated with zombie channels to clear some states. | ||
| Comments: | By: Steve Murphy (murf) 2007-06-08 19:01:29 hristo-- I've attached a patch, called 9246.diff; please apply it to your 1.4 code and see if the problem goes away. By: hristo (hristo) 2007-06-19 11:34:28 The patch fixes the problem (tested with patched 1.4-r69944). Sorry for my late reply to your request...I was out of the office for the last 10 days. Thanks! By: Steve Murphy (murf) 2007-06-19 13:31:27 The fix has been applied to 1.2 via 70053. to 1.4 via 70062. and to trunk via 70063. | ||