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

Home » Asterisk Users » duration limits in Dial() not being enforced at correct time
Asterisk Users 7 Comments

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: 0x00 – 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?

7 thoughts on - duration limits in Dial() not being enforced at correct time

  • Please elaborate on your “flavor” of DAHDI and LIBPRI and what type of DAHDI
    service you are using (PSTN, T1, etc). Speaking from a POTS line point of
    view, there can easily be a 7-10 second delay in the processing of DAHDI
    information (which would make your 1347 second call within tolerance).

  • If you dial to a Local/Context and use your time limits on that and then do
    your dial to your DAHDI device inside that context does that have any
    effect on the time limits working. We have used time limits with
    Local/Context dials and had them work with out any known issues.

    Thanks

    Bryant Zimmerman

  • +1 Bryant – by using the Local/Context you are introducing some overhead to
    the process, but eliminating the dependence on DAHDI timing (not that
    there’s anything wrong with that per se, but you can’t control the Space
    Shuttle with a Bearcat Scanner (or can you?) ).

    [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Bryant
    Zimmerman
    Sent: Thursday, November 03, 2011 8:25 AM
    at correct time

    If you dial to a Local/Context and use your time limits on that and then do
    your dial to your DAHDI device inside that context does that have any effect
    on the time limits working. We have used time limits with Local/Context
    dials and had them work with out any known issues.

    Thanks

    Bryant Zimmerman

    _____

    Sent: Thursday, November 03, 2011 9:18 AM

    at correct time

    Please elaborate on your “flavor” of DAHDI and LIBPRI and what type of DAHDI
    service you are using (PSTN, T1, etc). Speaking from a POTS line point of
    view, there can easily be a 7-10 second delay in the processing of DAHDI
    information (which would make your 1347 second call within tolerance).

  • Hi,

    Thanks for the suggestion. It’s good to know that absolute timeout
    exists (I’d not noticed that before). However, it won’t help here
    because we’re setting up the time limit to play a warning beep to the
    caller every 5 seconds for the last 30 seconds of the call.

  • Hi,

    DAHDI and LIBPRI are the standard versions from the Asterisk web site.
    The Asterisk server has a Sangoma E1 card in it and the line is regular
    ISDN30.

    Cheers,
    Kingsley.

  • Hi,

    Thanks. We’ve tried this and the first test call we did correctly
    limited itself to 1755 seconds, so it looks like this is a workaround we
    could use. We’ll do a few more tests before assuming it’s going to be
    consistent but for now it looks encouraging.

    Thanks once again.

    Cheers,
    Kingsley.