| Summary: | ASTERISK-10854: [patch] Allow channel unique IDs when searching for channels by name | ||
| Reporter: | Michael FIG (michael-fig) | Labels: | |
| Date Opened: | 2007-11-21 14:08:13.000-0600 | Date Closed: | 2008-01-03 15:24:18.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/NewFeature |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 20071203__bug11340.diff.txt ( 1) asterisk-1.4.13-channel-uniqueid.diff ( 2) asterisk-1.4.14-channel-uniqueid.diff | |
| Description: | This patch allows the use of UniqueIDs in applications and the manager API anytime a channel name would be specified. ****** ADDITIONAL INFORMATION ****** This is needed to fix a race condition in dialplans that try to do ChannelRedirect on a channel that might be undergoing masquerading. | ||
| Comments: | By: Michael FIG (michael-fig) 2007-11-28 20:15:39.000-0600 The second patch (...-1.4.14-...) updates "core show channels concise" to report the uniqueids instead of the mutable channel name, so that manager API users can use it. It also modifies the masquerading code so that AsyncGoto's don't change an existing uniqueid. By: Tilghman Lesher (tilghman) 2007-12-02 03:47:15.000-0600 If you need this to fix a race condition, please fix that race condition at the same time. As far as the CLI is concerned, I'm afraid I'm going to have to reject that patch, as least as far as 1.4 is concerned. For trunk, we are deprecating the use of the CLI for automated tasks. If you want something like this, please create a native manager command to do that. By: Michael FIG (michael-fig) 2007-12-03 14:20:47.000-0600 The race condition appears when the dialplan is trying to redirect a channel that has just connected. The channel may be undergoing renaming due to an AsyncGoto or other masquerading operation. So, the only race is one introduced because the channel doesn't have a stable name. The patch fixes that, by making the uniqueid into a stable name, so that AMI applications using the uniqueid for their work won't have the channel renamed out from under them. By: Olle Johansson (oej) 2007-12-16 04:02:43.000-0600 Don't you get a rename event in manager to be able to follow the channel? By: Michael FIG (michael-fig) 2007-12-17 11:46:39.000-0600 I was trying to use the rename event, which is how I found this race condition. Basically, very shortly after a connect, I'm trying to do a ChannelRedirect. If I get the channel before or after its masquerading happens, everything is fine. If I follow the rename events, then it sometimes fails. This is because there is a race between the manager actually receiving the rename events and sending the ChannelRedirect, and the masquerading code continuing to rename the channel. By the time Asterisk receives the ChannelRedirect, the masquerading code has further renamed the channel, and the channel in the ChannelRedirect doesn't exist. Does this make more sense now? By: Digium Subversion (svnbot) 2008-01-03 15:24:18.000-0600 Repository: asterisk Revision: 96301 U trunk/main/channel.c ------------------------------------------------------------------------ r96301 | tilghman | 2008-01-03 15:24:17 -0600 (Thu, 03 Jan 2008) | 4 lines Allow the uniqueid to be used for searching for a channel in the list. Reported and initially patched by: michael-fig (Closes issue ASTERISK-10854) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=96301 | ||