* You are viewing Posts Tagged ‘hangup’

Continue AGI after Dial() following caller hang up?

Hello,

We would like to continue a Perl AGI after a Dial() it has done completes
following caller hangup. We would like to do this in the same AGI, and not
using a new AGI from the ‘h’ extension. It works fine when the called party
hangs up and the ‘g’ option is used, but not for caller hangup.

Is this possible?

If not a confirmation that this is the case would be very helpful.

Thanks for any advice!

Dial Application / hangup with option h or H / featuremap / more than 1 valid key

duration limits in Dial() not being enforced at correct time

Hi,

We’re trying to time-limit some calls by specifying L(x:y:z) as an
option to the Dial command.

If we set the limit to a fairly short duration (eg 120 seconds) then
Asterisk seems to issue the hangup at about the right time.

However, for longish calls we’re seeing quite a bit of overspill. For
example we tried to limit one to 1338 seconds but Asterisk didn’t hang
up until 1384 seconds after the call was answered.

Also, the error is not always consistent – a second test call also
limited to 1338 seconds was hung up by Asterisk after 1347 seconds.

We saw this problem with Asterisk 1.6 but we’ve now tried on Asterisk
1.8.6.0 and are having the same problem.

Here’s a log from the Asterisk 1.8.6.0 box for the test call that should
have been limited to 1338 seconds but was actually ended after 1384
seconds. The server wasn’t carrying any other calls at the time or doing
anything else so the load would have been very low.

[Nov 2 16:47:37] VERBOSE[2029] pbx.c: — Executing [01476292501@service_nts_v2:57] Dial(“DAHDI/i2/7622323283-4″, “DAHDI/g1/08451238347,,L(1338000:30000:5000)M(service-nts-v2-register-answer)”) in new stack
[Nov 2 16:47:37] VERBOSE[2029] features.c: > Limit Data for this call:
[Nov 2 16:47:37] VERBOSE[2029] features.c: > timelimit = 1338000 ms (1338.000 s)
[Nov 2 16:47:37] VERBOSE[2029] features.c: > play_warning = 30000 ms (30.000 s)
[Nov 2 16:47:37] VERBOSE[2029] features.c: > play_to_caller = yes
[Nov 2 16:47:37] VERBOSE[2029] features.c: > play_to_callee = no
[Nov 2 16:47:37] VERBOSE[2029] features.c: > warning_freq = 5000 ms (5.000 s)
[Nov 2 16:47:37] VERBOSE[2029] features.c: > start_sound =
[Nov 2 16:47:37] VERBOSE[2029] features.c: > warning_sound = /var/lib/asterisk/sounds/bespoke/beep_200ms
[Nov 2 16:47:37] VERBOSE[2029] features.c: > end_sound =
[Nov 2 16:47:37] VERBOSE[2029] sig_pri.c: — Requested transfer capability: 0×00 – SPEECH
[Nov 2 16:47:37] VERBOSE[2029] app_dial.c: — Called DAHDI/g1/08451238347
[Nov 2 16:47:37] VERBOSE[2029] app_dial.c: — DAHDI/i1/08451238347-3 is proceeding passing it to DAHDI/i2/7622323283-4
[Nov 2 16:47:37] VERBOSE[2029] app_dial.c: — DAHDI/i1/08451238347-3 is ringing
[Nov 2 16:47:38] VERBOSE[2029] app_dial.c: — DAHDI/i1/08451238347-3 answered DAHDI/i2/7622323283-4
[Nov 2 16:47:38] VERBOSE[2029] pbx.c: — Executing [s@macro-service-nts-v2-register-answer:1] NoOp(“DAHDI/i1/08451238347-3″, “ANSWER MACRO”) in new stack
[Nov 2 16:47:38] VERBOSE[2029] pbx.c: — Executing [s@macro-service-nts-v2-register-answer:2] AGI(“DAHDI/i1/08451238347-3″, “agi://127.0.0.1:4573/ServiceNTSV2,mode=answered,uniqueID=1320252457.17_1,uniqueIDB=1320252457.18,ddi=08451238347,Goto=agiOK1″) in new stack
[Nov 2 16:47:39] VERBOSE[2029] res_agi.c: — AGI Script Executing Application: (Goto) Options: (agiOK1)
[Nov 2 16:47:39] VERBOSE[2029] pbx.c: — Goto (macro-service-nts-v2-register-answer,s,7)
[Nov 2 16:47:39] VERBOSE[2029] res_agi.c: — AGI Script agi://127.0.0.1:4573/ServiceNTSV2 completed, returning 0
[Nov 2 16:47:39] VERBOSE[2029] pbx.c: — Executing [s@macro-service-nts-v2-register-answer:7] GotoIf(“DAHDI/i1/08451238347-3″, “1?agiOK2″) in new stack
[Nov 2 16:47:39] VERBOSE[2029] pbx.c: — Goto (macro-service-nts-v2-register-answer,s,13)
[Nov 2 16:47:39] VERBOSE[2029] pbx.c: — Executing [s@macro-service-nts-v2-register-answer:13] NoOp(“DAHDI/i1/08451238347-3″, “register-answer macro finished”) in new stack
[Nov 2 16:47:39] VERBOSE[2029] chan_dahdi.c: — Native bridging DAHDI/i2/7622323283-4 and DAHDI/i1/08451238347-3
[Nov 2 17:10:42] VERBOSE[2029] pbx.c: — Executing [h@service_nts_v2:1] NoOp(“DAHDI/i2/7622323283-4″, “number HANGING UP … CHANNEL=DAHDI/i2/7622323283-4, channel1=1320252457.17_1, channel2=, HANGUPCAUSE=16, UNIQUEID=1320252457.17″) in new stack

Is this a known problem and are there any workarounds?

Problem with Atxfer for the calling party

Good morning,

I have not solved this problem yet, but, I found that the source of
the problem are my macros. For example, I have this context:

context ramais {
101 => &dial_sip(exten1);
102 => &dial_sip(exten2);
103 => &dial_sip(exten3);
};

All these extensions use the dial_sip macro, I have changed this context
to use the Dial application instead of dial_sip macro, it worked fine.
The problem is that when i use the macro, the current context is changed
to the dial_sip context, the dial_sip context is automatically created
by asterisk when i use any macro and of fact this context doesn’t have
the ramais context included. Is there some way to specify on which
context the macro will run?

On Mon, 2011-10-31 at 09:09 -0200, Antonio Modesto wrote:

> Good Morning,
>
> I have an asterisk18-1.8.7.1 running on a FreeBSD 8.2-STABLE, and it
> is working well so far, i’m just having some problems with atxfer.
>
> I have written this macro to dial sip extensions:
>
> macro dial_sip(exten) {
> Verbose(2,”==> Chamando a MACRO dial_sip – ponto 1 macros.ael
> < ==");
> Verbose(4,”====> Macro dial_sip iniciada.”);
> ChanIsAvail(SIP/${exten});
> Verbose(2,”==> ${AVAILORIGCHAN}”);
>
> if (“${AVAILORIGCHAN}” != “”)
> {
> Verbose(4,”====> SIP/${exten} parece estar disponivel,
> vou disca-lo agora.”);
> Set(FromExt=${CALLERID(num)});
> System(/bin/sh /var/spool/asterisk/calllog/log.sh
> SIP/${FromExt} SIP/${exten} SIP-TO-SIP);
> Verbose(4,”====> System status: ${SYSTEMSTATUS}”);
> Dial(SIP/${exten},${SIP_DIAL_TIMEOUT},Ttr);
> Hangup();
> }
> else
> {
> Verbose(2,”====> SIP/${exten} nao esta disponivel.”);
> Hangup();
> };
>
>
> NoOp(“From ${MACRO_EXTEN} to ${exten});
> System(${CALLLOGDIR}/log.sh ${exten});
>
> return;
> };
>
> It is working, but the calling party is not able to transfer the calls
> because asterisk doesn’t wait all the digits be typed, it tries to
> transfer the call when the first digit is pressed (We use 3 digits
> extensions):
>
> [Oct 31 09:04:01] WARNING[2926]: features.c:2315 builtin_atxfer:
> Extension ’1′ does not exist in context ‘dial_sip’
> == Spawn extension (dial_sip, ~~s~~, 11) exited non-zero on
> ‘SIP/modesto-0000000d’
> [Oct 31 09:04:03] WARNING[2926]: features.c:2319 builtin_atxfer: No
> digits dialed for atxfer.
>
> Does anyone have suggestions?
>
> Regards.
>
> –
> _____________________________________________________________________
> — Bandwidth and Colocation Provided by http://www.api-digital.com
> New to Asterisk? Join us for a live introductory webinar every Thurs:
> http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users

(no subject)

Karim Mardhani http://lists.digium.com/mailman/listinfo/asterisk-users> wrote:
>* Hi everyone,*>* *>* I am trying to get Meetme to return back to the context from where it*>* joined the meetme. For example a user uses the following context to join a*>* conference, once user hangs up I would like to continue executing the rest*>* of the dialplan. But when caller hangs up from the conference I see on CLI*>* that meetme exited with non-zero status but none of the rest of the*>* dialplan is executed. Please help. I am using asterisk 1.6.2.20*>* *>* [default]*>* exten => _XXXX,1,MeetMe(1000,1pdMX)*>* exten => _XXXX,n,noop(returned from meetme) ;After user hangs up should*>* come here*>* exten => _XXXX,n,SoftHangup(${ORIG_CALLER})*>* exten => _XXXX,n,SoftHangup(${CONF_CALLER})*>* exten => _XXXX,n,Hangup*>* exten => h,1,noop(default-end)*>* exten => h,n,SoftHangup(${ORIG_CALLER})*>* exten => h,n,SoftHangup(${CONF_CALLER})*>* exten => h,n,Hangup*
That’s not how Asterisk works. When the caller hangs up, execution of
the current dialplan extension stops, and control passes to the ‘h’
extension, if one exists in the current context.

Any processing you want to do when the caller hangs up must be done
in the ‘h’ extension. Cheers

Thanks Tony for the quick response. As you would see I have the h
extension defined but execution doesn’t go to that either.

Tony