similar to: Hangup-handler on failed calls

This has been super-helpful, Eric. However, the handleHangupByPeer priorities below are still not run when the peer hangs-up. The last line in the cli when the peer hangs-up is still: Strict RTP learning complete - Locking on source address (Although sometimes there is also: Retransmission timeout reached on transmission) same =>

Thanks, Eric. I just tried a hangup handler, but it's showing a similar problem: When the peer hangs-up, the hangup handler is not invoked and the caller channel remains open. same => n(callPeer),Set(GLOBAL(Peer${IndexIntoPeers}CurrentCallsCount)=$[${PeerCurrentCallsCount} + 1]) same => n,Set(CHANNEL(hangup_handler_push)=handleHangupByCallerOrPeer,doesntMatter,1(args)) same =>

2013/3/26 Richard Mudgett <rmudgett at digium.com> > > On 03/25/2013 05:17 PM, Olivier wrote: > > > Hello, > > > > > > I'm giving hangup-handlers a try on a new Asterisk 11.2.1 setup. > > > My plan is to use this handler to update my CDRs with values such > > > as > > > Asterish and Tech cause (see function HANGUP_CAUSE). >

On Wed, Aug 8, 2018 at 1:53 PM, Daniel Journo <dan at keshercommunications.com> wrote: > > Prior to a call entering a Queue, I set __DYNAMIC_FEATURES=NewRecordApp. > > AgentA answers and is able to use that feature code. > > If AgentA performs an attended transfer of a call from a queue to > AgentB, the > > feature code no longer works. > > > > It only

hi, I hope someone can help me:-) we’ve got a freepbx server. there are 2 special extensions (2001, 2002). if someone calls this extensions (or a call is forwarded to these extensions) and these extension hangup (not the caller party), then we’d like to put the calls back into a queue (1000) and wouldn’t like to hangup. I read your description about hangup hooks:

Hello, I've started to play with PJSIP and got stuck at the following problem. I need to retrieve SIP Call-ID associated with PJSIP channel. For inbound channel I can use ${PJSIP_HEADER(read,Call-ID)}, but that doesn't work for outbound channel even in pre-dial or hangup handler. Whatever I do PJSIP_HEADER seem to be unable to read headers for outbound channel. Here's what I do:

Last question for today, I promise! The problem: In order to disconnect calls after x minutes, I need to do this: [setup] exten => setup,1,Answer() same => n,Set(LIMIT_PLAYAUDIO_CALLER=yes) same => n,Set(LIMIT_WARNING_FILE=/var/lib/asterisk/sounds/en_GB_TNS/time_limit_reached) same => n,Dial(Local/s at root/n,3,L(3540000:60000)) same => n,Hangup() [root] exten

Hi, I have the following code that operates when a channel is hung-up: [record-hangupcause]exten => 1,n,Set(CDR(hangupcause)=${HANGUPCAUSE})exten => s,n,Return() Before the dial a hangup handler is registered: Set(CHANNEL(hangup_handler_push)=record-hangupcause,s,1) The routine is called and the variables are being set, however not on the channel's CDR which made the call. I believe this

It seems that what ever I set in my answer handler does not show up in the hangup handler. In order to do billing I can't rely on the g option where the caller hangs up the call. Looks like I can either use h or a hangup handler along with the shared function. On Tue, Dec 26, 2017 at 4:40 PM, Eric Wieling <ewieling at nyigc.com> wrote: > Don't use an 'h' extension, use

I'm looking for a way of detecting in my dialplan when a peer becomes non-responsive after answering. It seems that Asterisk knows when the peer becomes non-responsive because it logs "Remote UNIX connection disconnected" around the same time, and it seems that if there is no following "Remote UNIX connection" within a short time, then the peer can be considered

Hi, I think I've identified an issue and just want to check before completing a bug report. Prior to a call entering a Queue, I set __DYNAMIC_FEATURES=NewRecordApp. AgentA answers and is able to use that feature code. If AgentA performs an attended transfer of a call from a queue to AgentB, the feature code no longer works. Cases that do work are as follows... Calls using both Queue() and

This was always possible in the past, however does not work in the current release. I believe this is a bug. To: asterisk-users at lists.digium.com From: cervajs at fpf.slu.cz Date: Fri, 9 Oct 2015 10:04:47 +0200 Subject: Re: [asterisk-users] Storing HANGUPCAUSE in CDR search in archives save the records to another table like cdr_extended Dne

Please point me to samples of popping and wiping hangup handlers. I don't need to use the values returned; I just need to clear any handlers before I push a new one. It's not clear at https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers+Specification how to provide vars on the right-hand side. Cheers, David -------------- next part -------------- An HTML attachment was scrubbed...

Response below... On Fri, Dec 27, 2019 at 12:02 PM David P <davidswalkabout at gmail.com> wrote: > > > > > I'm looking for a way of detecting in my dialplan when a peer becomes > > non-responsive after answering. [deleted] Is there a way to configure > > a handler for this state? > > > > We use v14.7.6 and we dial the peer this way: > > >

Thanks, Anthony. I added both 'g' and 'F' options. Now, when the caller hangs-up, my cleanup code is run by both the caller channel and the peer channel, but I only want the caller channel to do that. Also, when the peer hangs-up, there is no execution of the priorities following the Dial. Finally, is there a way to reset all globals, maybe as a variant of "dialplan

I think HANGUPCAUSE is channel agnostic. See: core show function HANGUPCAUSE Some thing like this IIRC: Set(my_cause=${HANGUPCAUSE(${CHANNEL(name)},tech)}) Remember the incoming leg of the call and the outgoing leg of the call are different channels. Make sure you are giving HANGUPCAUSE the correct channel. On 06/09/2018 02:01 PM, Khalil Khamlichi wrote: > It seems very weird to me

Hello, I'm using Hanhup Handlers in a testing asterisk 11 system. Within one such handler, I'm setting CDR values. To me, it seems those changed CDR values are not saved in CDR back-end. Can you confirm ? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL:

2013/3/29 Julian Lyndon-Smith <asterisk at dotr.com> > check out the endbeforehexten option in cdr.conf > > this needs to set to "yes" > > Julian > Unfortunately, this doesn't help. Let's drop the hangup handler at the moment, and focus on the "saving to file" part. Then my issue is I can't update CDR value is hangup exten. Here is a

Hi, I have a dial plan where I need to notify an external system when a call was answered and when the call hung up. In both requests the start time needs to be the same. My Dialplan looks something like this: [outbound] Exten => _X.,1,Dial(SIP/${EXTEN}@1.1.1.1,,U(call-answer-from-carrier)) Exten => h,1,NoOp(ANSWERED_TIME: ${ANSWEREDTIME} >>> DIAL_TIME: ${DIALEDTIME}

I know that hangup handlers ( https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers) have to finish quickly. So it's no surprise that my speech to text agi which takes 8 seconds gets killed. However, can anyone think of a way round this? So, once the caller has hung up, I need to take one of the channel variables, and pass it to a python agi script which then does speech to text.