[Home]

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-0600Date Closed:2013-07-31 12:45:49
Priority:MajorRegression?No
Status:Closed/CompleteComponents: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.