[asterisk-users] duration limits in Dial() not being enforced at correct time

[Kingsley Tart]

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 at 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 at 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 at 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:     -- <DAHDI/i1/08451238347-3>AGI Script agi://127.0.0.1:4573/ServiceNTSV2 completed, returning 0
[Nov  2 16:47:39] VERBOSE[2029] pbx.c:     -- Executing [s at 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 at 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 at 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?

-- 
Cheers,
Kingsley.