|Summary:||ASTERISK-07182: [patch][post-1.4] app_redirect|
|Reporter:||Tim Kelly (timkelly1980)||Labels:|
|Date Opened:||2006-06-15 18:54:10||Date Closed:||2011-06-07 14:02:44|
|Environment:||Attachments:||( 0) app_redirect.c|
( 1) app_redirect.c.fix1
|Description:||Similar to app_channelredirect but:|
* allows you to specify a device to redirect rather than an exact channel
* allows you to specify two Technology/resources (bridged) and redirect them to two seperate priorities. (essentially unbridging them)
Technology/resource1 is redirected to priority1
Technology/resource2 is redirected to priority2
a - redirects all channels on specified device instead of single resource.
****** ADDITIONAL INFORMATION ******
Disclaimer in progress.
This is the first time I have done any coding with asterisk or any open-source project:
Wasn't sure what the asterisk file revision should be set
Wasn't sure whether I should put Mark Spencer as co-author as used app_softhangup.c
Sorry if i have done anything wrong! please feel free tell me off!
|Comments:||By: Tim Kelly (timkelly1980) 2006-06-15 19:02:06|
One of the most useful things I could think of for this application is for a manager to take a pair of bridged calls, redirect them both to a meetme room and then join the meetme room themself.
However when I try this I encounter a bug, I get a thread locking error. I also tried it with the application already in trunk (app_channelredirect) and have exactly the same error, always reproducable (should I report this as a bug for that app??):
exten => 123,1,Milliwatt
exten => 456,1,Redirect(SIP/10001||123|meetme|1|1|a)
exten => 456,1,MeetMe(1001,dM)
exten => 123,1,MeetMe(1001,dM)
Ok Sip/10001 dials into extension 123 and gets Milliwatt
Manager dials into 456 which redirects Sip/10001 into meetme room 1001
Manager then enters meetme room 1001
But I get:
Jun 16 01:52:09 WARNING: channel.c:1470 ast_hangup: Hard hangup called by
thread 393239 on Zap/pseudo-353743279, while fd is blocked by thread 426009 in
procedure ast_waitfor_nandfds! Expect a failure
The redirect works fine and the manager can talk to the Sip/10001 but when both clients disconnect I get a crash.
By: Tim Kelly (timkelly1980) 2006-06-16 04:47:12
Sorry version should relate to SVN trunk, it won't let me change.
It would be way cooler if you didn't need to specify the 2nd channel and instead look up what the specified channel is currently bridged to. Could have an option (redirect both/hangup other end). Maybe call this app: app_unbridge ??
By: Tim Kelly (timkelly1980) 2006-06-16 04:58:16
app_redirect.c.fix1 -> Fixes problem that only the first channel was redirected if option a was not set.
By: Tim Kelly (timkelly1980) 2006-06-16 07:46:19
RE: Disclaimer on file> Fax now sent.
By: Serge Vecher (serge-v) 2006-06-16 09:57:38
timkelly: thanks for contributing and filing a disclaimer. Please review the CODING GUIDELINES file and fix up the app accordingly. Also, new features like these will go into trunk, not 1.2.x once the 1.4 beta branch is forked from the trunk (in the upcoming weeks). Thanks.
By: Tim Kelly (timkelly1980) 2006-06-17 08:48:28
I am going on a long expedition to africa so won't be able to tidy this up for a few months. Will report the issue with app_channelredirect as a seperate bug as it is in trunk already and is serious crash.
By: jmls (jmls) 2006-10-31 11:50:17.000-0600
hope you're back from Africa - I would like to see this in trunk :)
By: jmls (jmls) 2006-11-20 14:27:47.000-0600
Have you returned from your overseas adventures yet ?
By: Tim Kelly (timkelly1980) 2006-11-22 17:28:30.000-0600
Hi yes I am back and will look at this again very soon. I think an app_unbridge would be very useful :)
Please can you direct me to coding guidelines, also i really need to track the bug I mentioned and had trouble finding out exactly how to build asterisk in a form suitable to provide debugging info for some1 more experience to look at.
By: Sergey Basmanov (sb) 2006-11-25 06:03:40.000-0600
Regarding channelredirect. This app is works fine under conditions described here:
In this case, it redirects unbridged channel that is not running anything.
I think that trying to redirect channel which is running some app causes crash.
May be we need to check if channel can be redirected before doing something?
By: Tilghman Lesher (tilghman) 2006-12-30 23:33:46.000-0600
I'm feeling a bit of argument overload, and I think we can address this by using some of the standard argument parsing functions to better group the functions. I would suggest something like the following syntax:
where label is an argument that could be passed to ast_parseable_goto(). This clarifies quite a bit as to where the first channel will go, where the second channel will go, and also increases the versatility, in that the channels need not even be redirected to the same extension, let alone context.
You can see the example in app_skel.c for how to use the standard argument parsing tools.
By: Serge Vecher (serge-v) 2007-03-20 14:39:58
timkelly1980: where do we stand with this issue?
By: jmls (jmls) 2007-05-28 03:35:54
timkelly1980: ping. housekeeping
By: Jason Parker (jparker) 2007-08-29 18:03:12
I really don't want to do this, but there hasn't been any response here in about 9 months...
Suspending until somebody is able to work on this.
If anybody would like to take on this project, please feel free to either reopen this report, or request a bug marshal to reopen it. I really like the idea of this, and I don't want to see it just die.