Re: [asterisk-users] 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).
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Kingsley Tart
Sent: Thursday, November 03, 2011 5:11 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] 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:3: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 = 3
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,un
iqueIDB=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?
--
Cheers,
Kingsley.
--
_
-- 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://list
Re: [asterisk-users] duration limits in Dial() not being enforced at correct time
On Thu, Nov 3, 2011 at 18:44, Danny Nicholas wrote:
> 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).
>
> -Original Message-
> From: asterisk-users-boun...@lists.digium.com
> [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Kingsley
> Tart
> Sent: Thursday, November 03, 2011 5:11 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: [asterisk-users] 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:3: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 = 3
> 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,un
> iqueIDB=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?
>
> --
> Cheers,
> Kingsley.
>
>
> --
> _
>
Re: [asterisk-users] duration limits in Dial() not being enforced 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
From: "amit anand"
Sent: Thursday, November 03, 2011 9:18 AM
To: "Asterisk Users Mailing List - Non-Commercial Discussion"
Subject: Re: [asterisk-users] duration limits in Dial() not being enforced
at correct time
On Thu, Nov 3, 2011 at 18:44, Danny Nicholas wrote:
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).
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Kingsley
Tart
Sent: Thursday, November 03, 2011 5:11 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] 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:3: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 =
3
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,un
iqueIDB=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
Re: [asterisk-users] duration limits in Dial() not being enforced at correct time
+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?) ).
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Bryant
Zimmerman
Sent: Thursday, November 03, 2011 8:25 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] duration limits in Dial() not being enforced
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
_
From: "amit anand"
Sent: Thursday, November 03, 2011 9:18 AM
To: "Asterisk Users Mailing List - Non-Commercial Discussion"
Subject: Re: [asterisk-users] duration limits in Dial() not being enforced
at correct time
On Thu, Nov 3, 2011 at 18:44, Danny Nicholas wrote:
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).
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Kingsley Tart
Sent: Thursday, November 03, 2011 5:11 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] 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:3: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 = 3
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,un
<http://127.0.0.1:4573/ServiceNTSV2,mode=answered,uniqueID=1320252457.17_1,u
niqueIDB=1320252457.18,ddi=08451238347,Goto=agiOK1>
iqueIDB=1320252457.18,ddi=08451238347,Goto=agiOK1") in new stack
[Nov 2 16:47:39] VERBOSE[2029] res_agi.c: -- AGI Sc
Re: [asterisk-users] duration limits in Dial() not being enforced at correct time
On Thu, 2011-11-03 at 18:50 +0530, amit anand wrote: > Hi you can use Absoulte timeout to set the time limit feature for the channel 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. -- Cheers, Kingsley. -- _ -- 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
Re: [asterisk-users] duration limits in Dial() not being enforced at correct time
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.
On Thu, 2011-11-03 at 08:14 -0500, Danny Nicholas wrote:
> 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).
>
> -Original Message-
> From: asterisk-users-boun...@lists.digium.com
> [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Kingsley Tart
> Sent: Thursday, November 03, 2011 5:11 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: [asterisk-users] 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:3: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 = 3
> 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,un
> iqueIDB=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
>
>
