Re: [asterisk-users] Execution of pre-bridge handlers

[Patrick Wakano]

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 
wrote:

>
>
> On Tue, Feb 14, 2017 at 6:24 AM, Patrick Wakano  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 

Re: [asterisk-users] Execution of pre-bridge handlers

[Richard Mudgett]

On Tue, Feb 14, 2017 at 6:24 AM, Patrick Wakano  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/ji
> ra/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

[asterisk-users] Execution of pre-bridge handlers

[Patrick Wakano]

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
-- 
_
-- 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