mirror of
https://github.com/asterisk/asterisk.git
synced 2026-07-19 01:45:25 -07:00
Update new Local channel documentation.
The original reporter, Kobaz, of an issue with a Local channel that inspired the Local channel documentation provided some tweaks to the documentation after testing what I had written. Hopefully anything that was vague or unclear has been cleaned up by these changes. (closes issue #16963) Reported by: kobaz Patches: localchannel-2.txt uploaded by kobaz (license 834) Tested by: kobaz, lmadsen git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@253252 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
+55
-34
@@ -306,6 +306,22 @@ and then a NOTICE stating the call was completed.
|
||||
Understanding When To Use /n
|
||||
============================
|
||||
|
||||
Lets take a look at an example that demonstrates when the use of the /n
|
||||
directive is necessary. If we spawn a Local channel which does a Dial()
|
||||
to a SIP channel, but we use the L() option (which is used to limit the
|
||||
amount of time a call can be active, along with warning tones when the
|
||||
time is nearly up), it will be associated with the Local channel,
|
||||
which is then optimized out of the call path, and thus won't perform
|
||||
as expected.
|
||||
|
||||
This following dialplan will not perform as expected.
|
||||
|
||||
[services]
|
||||
exten => 2,1,Dial(SIP/PHONE_B,,L(60000:45000:15000))
|
||||
|
||||
[internal]
|
||||
exten => 4,1,Dial(Local/2@services);
|
||||
|
||||
By default, the Local channel will try to optimize itself out of the call path.
|
||||
This means that once the Local channel has established the call between the
|
||||
destination and Asterisk, the Local channel will get out of the way and let
|
||||
@@ -323,65 +339,70 @@ directive. By adding /n to the end of the channel definition, we can keep the
|
||||
Local channel in the call path, along with any channel variables, or other
|
||||
channel specific information.
|
||||
|
||||
For example, if we were calling a Local channel from the Dial() application, we
|
||||
could change:
|
||||
In order to make this behave as we expect (limiting the call), we would change:
|
||||
|
||||
Dial(Local/201@devices)
|
||||
[internal]
|
||||
exten => 4,1,Dial(Local/2@services);
|
||||
|
||||
...into the following line:
|
||||
...into the following:
|
||||
|
||||
[internal]
|
||||
exten => 4,1,Dial(Local/2@services/n);
|
||||
|
||||
Dial(Local/201@devices/n)
|
||||
|
||||
By adding /n to the end, our Local channel will now stay in the call path and
|
||||
not go away.
|
||||
|
||||
Lets take a look at an example that demonstrates when the use of the /n
|
||||
directive is necessary. If we spawn a Local channel which then performs another
|
||||
Dial() to a SIP channel, but we use the L() option (which is used to limit the
|
||||
amount of time a call can be active, along with warning tones when the time is
|
||||
nearly up), it will be associated with the Local channel, which is then
|
||||
optimized out of the call path, and thus won't perform as expected.
|
||||
|
||||
Here is an overview of our call flow, and the information associated with the
|
||||
channels:
|
||||
Why does adding the /n option all of a suddon make the 'L' option work? First
|
||||
we need to show an overview of the call flow that doesn't work properly, and
|
||||
discuss the information associated with the channels:
|
||||
|
||||
1) SIP device PHONE_A calls Asterisk via a SIP INVITE
|
||||
|
||||
2) Asterisk accepts the INVITE and then starts processing dialplan logic
|
||||
2) Asterisk accepts the INVITE and then starts processing dialplan logic in
|
||||
the [internal] context.
|
||||
|
||||
3) Our dialplan calls Dial(Local/2@services) <-- notice no /n
|
||||
3) Our dialplan calls Dial(Local/2@services); <-- notice no /n
|
||||
|
||||
4) The Local channel then executes dialplan at extension 2 within the services
|
||||
context
|
||||
4) The Local channel then executes dialplan at extension 2 within the [services]
|
||||
context.
|
||||
|
||||
5) Extension 2 within [services] then performs another Dial() to a SIP channel
|
||||
with the line: Dial(SIP/PHONE_B,,L(60000:450000:15000))
|
||||
5) Extension 2 within [services] then performs Dial() to PHONE_B
|
||||
with the line: Dial(SIP/PHONE_B,,L(60000:45000:15000))
|
||||
|
||||
6) The call is then placed to SIP/PHONE_B which then answers the call.
|
||||
6) SIP/PHONE_B then answers the call.
|
||||
|
||||
7) The Local channel containing the information for tracking the time allowance
|
||||
of the call is then optimized out of the call path, losing all information
|
||||
about when to terminate the call.
|
||||
7) Even though the L option was given when dialing the SIP device, the L
|
||||
information is stored in channel that is doing the dial... which is the local
|
||||
channel, and not the endpoint SIP channel.
|
||||
|
||||
8) SIP/PHONE_A and SIP/PHONE_B then continue talking indefinitely.
|
||||
8) The Local channel in the middle, containing the information for tracking the
|
||||
time allowance of the call is then optimized out of the call path, losing all
|
||||
information about when to terminate the call.
|
||||
|
||||
Now, if we were to modify our dialplan at step three (3) then we would force the
|
||||
9) SIP/PHONE_A and SIP/PHONE_B then continue talking indefinitely.
|
||||
|
||||
Now, if we were to add /n to our dialplan at step three (3) then we would force the
|
||||
Local channel to stay in the call path, and the L() option associated with the
|
||||
Dial() from the Local channel would remain, and our warning sounds and timing
|
||||
would work as expected.
|
||||
|
||||
There are two workarounds for the above described scenario:
|
||||
|
||||
1) Use Dial(Local/2@services/n) to cause the Local channel to remain in the call
|
||||
path so that the L() option used inside the Local channel is not discarded
|
||||
when optimization is performed.
|
||||
1) Use what we just described, Dial(Local/2@services/n) to cause the Local
|
||||
channel to remain in the call path so that the L() option used inside the
|
||||
Local channel is not discarded when optimization is performed.
|
||||
|
||||
2) Place the L() option outside of the Local channel so that when it is
|
||||
optimized out of the call path, the information required to make L() work is
|
||||
associated with the outside channel. For example:
|
||||
|
||||
Dial(Local/2@services,,L(60000:45000:15000))
|
||||
2) Place the L() option at the outermost part of the path so that when the middle
|
||||
is optimized out of the call path, the information required to make L() work
|
||||
is associated with the outside channel. The L information will then be stored
|
||||
on the calling channel, which is PHONE_A. For example:
|
||||
|
||||
[services]
|
||||
exten => 2,1,Dial(SIP/PHONE_B)
|
||||
|
||||
[internal]
|
||||
exten => 4,1,Dial(Local/2@services,,L(60000:45000:15000));
|
||||
|
||||
Local channel modifiers
|
||||
=======================
|
||||
|
||||
Reference in New Issue
Block a user