What an excellent response Richard!!! Thank you very much for that!! Best regards! Patrick
On Wed, Feb 15, 2017 at 5:23 AM, Richard Mudgett <rmudg...@digium.com> wrote: > > > On Tue, Feb 14, 2017 at 6:24 AM, Patrick Wakano <pwak...@gmail.com> wrote: > >> Hello Asterisk Users, >> >> Hope you all doing fine! >> I am working with a quite complex dialplan, and I've come to some >> situations where it makes some nasty use of pre-bridge handlers. >> The pre-bridge handlers wiki (https://wiki.asterisk.org/wik >> i/display/AST/Pre-Bridge+Handlers) doesn't have the big warning the >> pre-dial one has indicating it must return and must not put the >> caller/callee in other applications (https://wiki.asterisk.org/wik >> i/display/AST/Pre-Dial+Handlers). So apparently, looks like they >> wouldn't have this restriction... However I had the feeling this was not >> true, so after some research I found this issue >> https://issues.asterisk.org/jira/browse/ASTERISK-25690, that says "*Connected >> line subroutines are meant** to be fast and as a result there is an >> expectation that applications invoked will not consume frames*". I am >> assuming that connected lines subroutines are just different words for >> pre-bridge handlers, right? >> Anyway my question is, what happens if I do not return straight away from >> the pre-bridge handler? Or even worst, if I execute a Dial application for >> example? Will I fall in some "undefined behaviour"? >> >> Anyone has experienced something like this? >> > > There are several handler routines available and each handles situations > for the > different states of a call. It makes no sense to use the Hangup() > application in > any of them and you must return from all of them. Most of the handlers > operate > from within the Dial application. > > Pre-dial handlers > The purpose of these routines is to setup a channel to place a call. > The pre-dial > routines can be run on the calling and called channels. See the Dial > application > documentation. > > For the calling channel, you can do most anything to the calling channel > except > hangup because you are still within the Dial application's control. The > reason > for the ability to execute a pre-dial routine on the calling channel > instead of doing > all the setup before executing Dial is to eliminate a window of > opportunity when using > the Lock/Unlock applications with Dial. > > For the called channel, you can only setup the channel. At this point, > the channel > exists but is not connected to anything nor has the call been placed. > Do your > channel setup and return. > > Redirecting interception handlers > This routine normally executes on the calling channel because the called > channel > has indicated that the call is being diverted/forwarded/redirected to > somewhere > else. The purpose of this routine is to get the REDIRECTING party > information > setup as you want and then return. You do not have control of the media > nor should > you hangup. You also should be quick about it. > > Pre-bridge handlers > At this point the called channel has answered and all other called > channels that were > dialed have been hung up. The called channel is about to be bridged > with the calling > channel. > > The purpose of this routine is to give the called person an opportunity > to decide if > he even wants to talk to the caller. You have control of the media > stream to the called > party. You cannot hangup the channel in the routine because you must > return. If you > want to abort bridging the call with the channel you must set a return > value as > documented by the Dial application. You need to remember that the > caller is > waiting to be connected the entire time you are in this routine. > > Connected-line interception handlers > At this point the channels are bridged together and may have been > talking for awhile. > > The purpose of this routine is to get the CONNECTEDLINE party > information setup > as you want and then return. The bridged peer has changed identity > likely because > of a transfer. You do not have control of the media nor should you > hangup. You also > need be quick about it or you risk causing a noticeable interruption to > the media. > > Hangup handlers > At this point the channel is hungup and you should be gathering > information about > the call for further processing later. You should not be doing > extensive post call > analysis at this time because you are delaying the channel technology > hangup > sequence. You have the same restrictions with the h extension. > > Given what I have stated about pre-bridge handlers you should be able to > see that > doing a Dial in a pre-bridge handler (or any handler for that matter) is a > bad thing to > do and definitely falls into the "undefined behavior" category. > > Richard > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Check out the new Asterisk community forum at: https://community.asterisk. > org/ > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users