[asterisk-users] Execution of pre-bridge handlers

Tue Feb 14 15:50:15 CST 2017

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 <rmudgett at digium.com>
wrote:

>
>
> On Tue, Feb 14, 2017 at 6:24 AM, Patrick Wakano <pwakano at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20170215/3c0183fd/attachment.html>