Summary: | ASTERISK-17201: [patch] Create a manager event when the app_dial creates a new call with a new unique id | ||
Reporter: | oelewapperke (oelewapperke) | Labels: | |
Date Opened: | 2011-01-04 08:37:59.000-0600 | Date Closed: | 2013-07-31 12:45:49 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Applications/app_dial |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) newuniqueidontransfer.patch ( 1) newuniqueidontransfer2.patch | |
Description: | The event contains both the old and the new unique id, allowing manager applications to track what's happening. The problem is that all manager events after a blind call transfer carry a new unique id, and there isn't any manager event that contains both the old and new unique ids, thereby making following the call impossible for any manager applications. This patch intends to remedy this situation. | ||
Comments: | By: oelewapperke (oelewapperke) 2011-01-04 08:39:31.000-0600 This patch works by sending a manager event after a new channel has been allocated and requested, only if the channel is successfully allocated. By: Leif Madsen (lmadsen) 2011-01-05 10:03:36.000-0600 Marked as Needs License until the license has been approved. By: oelewapperke (oelewapperke) 2011-01-05 11:07:02.000-0600 Licence has been updated and accepted. By: Matt Jordan (mjordan) 2013-07-31 12:45:16.503-0500 So... not that it's much fun to hear this two and a half years after you created this patch, but: In Asterisk 12, the next major version, this probably isn't needed any more. Channels no longer change their names or their unique IDs - ever. Particularly not during transfers. This is true during all stages of execution. As such, I'm going to go ahead and close this out. Thanks for the contribution anyway! By: Matt Jordan (mjordan) 2013-07-31 12:45:49.314-0500 Note that this is closed out as Fixed as the problem that this patch provided information for no longer occurs. |