VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
guido.hecken at gwsnet...
Guest
|
 Posted: Tue Mar 25, 2008 8:48 am Post subject: [asterisk-users] Asterisk parking hold and transferdigittime |
 |
|
Hi,
anyone out there with the same problems and a possible solution to the
following?
The functions callparking and hold use the same transferdigittimeout in
features.conf.
While I think 3 to 5 seconds are enough to let the user "find" their keys on
the phone,
the double ammount of time ( 2 x 5 secs) you have to wait before a call is
parked and
the parkposition is announced, is really too long.
Did I miss something in the documentation?
We are using SVN-branch-1.4-r96449.
Regards,
Guido Hecken
gwsNetTech
Guido Hecken
Quirrenbacher Str. 36
53639 K?nigswinter
Germany
fon +49(2244) 870663
fax +49(2244) 870664
mobil +49(179) 1267353
web http://www.gwsnettech.de
mailto:guido.hecken at gwsnettech.de |
|
| Back to top |
|
 |
Guest
|
| Posted: Tue Mar 25, 2008 5:22 pm Post subject: [asterisk-users] Asterisk parking hold and transferdigittime |
|
|
Guido Hecken wrote:
| Quote: | Hi,
anyone out there with the same problems and a possible solution to the
following?
The functions callparking and hold use the same transferdigittimeout in
features.conf.
While I think 3 to 5 seconds are enough to let the user "find" their keys on
the phone,
the double ammount of time ( 2 x 5 secs) you have to wait before a call is
parked and
the parkposition is announced, is really too long.
Did I miss something in the documentation?
We are using SVN-branch-1.4-r96449.
Regards,
Guido Hecken
gwsNetTech
Guido Hecken
Quirrenbacher Str. 36
53639 K?nigswinter
Germany
fon +49(2244) 870663
fax +49(2244) 870664
mobil +49(179) 1267353
web http://www.gwsnettech.de
mailto:guido.hecken at gwsnettech.de
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
|
It seems that the dialplan comes into play. If your parking lot is 700,
and you have any extension patterns that COULD begin with that, then
asterisk will wait to make SURE you're not typing 700xxxx:
Let's say that 700 is my parking lot extension.
exten => _NXXNXXXXXX,1,blahblahblah
This could match 7005551212, so asterisk waits around to make sure I'm
not trying to find any more buttons before it accepts that I meant 700.
As an example, if your parking lot extension was **, then asterisk could
be pretty darn sure that that won't match anything else, and will accept
it directly as a number to transfer too. |
|
| Back to top |
|
|
jsmith at digium.com
Guest
|
| Posted: Wed Mar 26, 2008 7:01 am Post subject: [asterisk-users] Asterisk parking hold and transferdigittime |
|
|
On Wed, 2008-03-26 at 12:30 +0100, Guido Hecken wrote:
| Quote: | Now, what happens:
Call for 9556230 reaches capi-in, is redirected through include statement to
capi-in-sub and executed.
So far so fine, expected behaviour.
Call for 95562315 reaches capi-in and is executed direct, the include
directive isn't executed at all!
Why?
Through the include statement, asterisk has to look first in capi-in-sub,
there it should
find this extension:
exten => 95562315,1,DoSomethingAnybodyWouldExpect()
...
and follow the dialplan under capi-in-sub since a valid extension was found.
What's wrong, any ideas?
|
This is a very popular misconception regarding include statements, so
let me try to reiterate how includes work.
When a call comes into a particular context, Asterisk looks for the
following items:
1) Exact matches in the current context. If a match is found, Asterisk
will not continue searching.
2) Pattern matches in the current context. If at least one pattern
match is found that matches the dialed extension, Asterisk will not
continue searching (even if a better match is included .
3) Any "switch =>" statements. These can be used for remote dialplan
lookups, realtime dialplan lookups, DUNDi, etc. If Asterisk finds at
least one match, it will not continue searching.
4) Any included contexts. These will be followed in order, and for each
included context, this same list will be applied.
In your example above, you somehow assumed that the included context
would be searched, even though Asterisk already found a match in the
current context.
--
Jared Smith
Community Relations Manager
Digium, Inc. |
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
