Execution Of Pre-bridge Handlers

Home » Asterisk Users » Execution Of Pre-bridge Handlers
Asterisk Users 2 Comments

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/
wiki/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/
wiki/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?

Many thanks, Cheers, Patrick

2 thoughts on - Execution Of Pre-bridge Handlers

  • 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

    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

    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.