asterisk users - Sep 2022 - Problems detecting hangup after hold / resume

Hi.

I have a dialplan which accepts an inbound call and dials out to another 
number, automatically bridging the channels together when the second call is 
answered.

I then have a facility for the caller to put the call on hold (which uses 
ChannelRedirect() in the dialplan to play music on hold to the callee, and 
some beeps to the caller), and resume it again (which uses Bridge() in the 
dialplan to re-join the two channels).

This works fine.

If the calleR hangs up (after resuming the call again, so the channels are 
bridged) the dialplan somewhat unexpectedly (to me) goes to the h at Hold 
extension (where Hold is the context I use to do the ChannelRedirect()s on the 
two legs of the call).

I can cope with this; at least it tells me the call has been hung up and 
allows the dialplan to do some "end of call" processing.

However, if the calleE hangs up instead, no hangup extension is called at all, 
so my dialplan cannot tell that the call has ended (which is important, 
because it has to send data to another application at both call start and call 
end).

The only thing I do see is the h at Hold extension being activated, but at the 
time when the channels are bridged back together again to resume the call, and 
the channel name which is passed to h at Hold is a Surrogate/... channel.

I guess it's correct that when hold music stops and the channels are re-
bridged, the Surrogate channel has in fact hung up, but the timing of this is 
nothing to do with the actual end of the call.

What do I need to do to get dialplan control passed to somewhere or other when 
the "real" callee channel hangs up?


Incidentally, if the call comes in, gets answered, and then the callee hangs 
up, without the channels ever having been put on hold, the dialplan does go to 
the h at DialOn extension (where DialOn is the context in which the second call 
is dialled out to the callee).  This doesn't happen if the channels have
been
redirected and then bridged back together again, though.


I know there is an F() parameter to the Dial() command which can pass the 
callee to a context/extension when the caller hangs up, but I don't see any 
equivalent for when the callee hangs up.


Does anyone have some helpful ideas on how to detect callee hangup in this 
situation?


Thanks,


Antony.

-- 
Software development can be quick, high quality, or low cost.

The customer gets to pick any two out of three.

                                                   Please reply to the list;
                                                         please *don't* CC
me.

On Tue, Sep 13, 2022 at 11:49 AM Antony Stone <
Antony.Stone at asterisk.open.source.it> wrote:
> Hi.
>
> I have a dialplan which accepts an inbound call and dials out to another
> number, automatically bridging the channels together when the second call
> is
> answered.
>
> I then have a facility for the caller to put the call on hold (which uses
> ChannelRedirect() in the dialplan to play music on hold to the callee, and
> some beeps to the caller), and resume it again (which uses Bridge() in the
> dialplan to re-join the two channels).
>
> This works fine.
>
> If the calleR hangs up (after resuming the call again, so the channels are
> bridged) the dialplan somewhat unexpectedly (to me) goes to the h at Hold
> extension (where Hold is the context I use to do the ChannelRedirect()s on
> the
> two legs of the call).
>
> I can cope with this; at least it tells me the call has been hung up and
> allows the dialplan to do some "end of call" processing.
>
> However, if the calleE hangs up instead, no hangup extension is called at
> all,
> so my dialplan cannot tell that the call has ended (which is important,
> because it has to send data to another application at both call start and
> call
> end).
>
> The only thing I do see is the h at Hold extension being activated, but at
> the
> time when the channels are bridged back together again to resume the call,
> and
> the channel name which is passed to h at Hold is a Surrogate/... channel.
>
> I guess it's correct that when hold music stops and the channels are
re-
> bridged, the Surrogate channel has in fact hung up, but the timing of this
> is
> nothing to do with the actual end of the call.
>
> What do I need to do to get dialplan control passed to somewhere or other
> when
> the "real" callee channel hangs up?
>
>
> Incidentally, if the call comes in, gets answered, and then the callee
> hangs
> up, without the channels ever having been put on hold, the dialplan does
> go to
> the h at DialOn extension (where DialOn is the context in which the second
> call
> is dialled out to the callee).  This doesn't happen if the channels
have
> been
> redirected and then bridged back together again, though.
>
>
> I know there is an F() parameter to the Dial() command which can pass the
> callee to a context/extension when the caller hangs up, but I don't see
> any
> equivalent for when the callee hangs up.
>
>
> Does anyone have some helpful ideas on how to detect callee hangup in this
> situation?
>
Do hangup handlers[1] work for the situation? They follow channels as
things move around, including masquerades and such.

[1] https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers

-- 
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20220913/82a787bb/attachment.html>