- Added development section (backtrace.tex)
- Correct filesystem path formating
- Replace all "|" argument separator to ","
- Endless count of spaces at the end of line
- Using astlisting to make listings do not take so much place
- Take back ASTRISKVERSION on first page
- Make localchannel.tex readable by inserting extra end of lines
(closes issue #10962)
Reported by: IgorG
Patches:
texdoc-85177-1.patch uploaded by IgorG (license 20)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@85519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan\_local is a pseudo-channel. Use of this channel simply loops calls back into the dialplan in a different context. Useful for recursive routing.
chan\_local is a pseudo-channel. Use of this channel simply loops calls back
into the dialplan in a different context. Useful for recursive routing.
\subsection{Syntax}
\subsection{Syntax}
\begin{verbatim}
\begin{verbatim}
Local/extension@context[/n]
Local/extension@context[/n]
\end{verbatim}
\end{verbatim}
Adding "/n" at the end of the string will make the Local channel not do a native transfer (the "n" stands for "n"o release) upon the remote end answering the line. This is an esoteric, but important feature if you expect the Local channel to handle calls exactly like a normal channel. If you do not have the "no release" feature set, then as soon as the destination (inside of the Local channel) answers the line, the variables and dial plan will revert back to that of the original call, and the Local channel will become a zombie and be removed from the active channels list. This is desirable in some circumstances, but can result in unexpected dialplan behavior if you are doing fancy things with variables in your call handling.
Adding "/n" at the end of the string will make the Local channel not do a
native transfer (the "n" stands for "n"o release) upon the remote end answering
There is another option that can be used with local channels, which is the "j" option. The "j" option must be used with the "n" option to make sure that the local channel does not get optimized out of the call. This option will enable a jitterbuffer on the local channel. The jitterbuffer will be used to de-jitter audio that it receives from the channel that called the local channel. This is especially in the case of putting chan\_local in between an incoming SIP call and Asterisk applications, so that the incoming audio will be de-jittered.
the line. This is an esoteric, but important feature if you expect the Local
channel to handle calls exactly like a normal channel. If you do not have the
"no release" feature set, then as soon as the destination (inside of the Local
channel) answers the line, the variables and dial plan will revert back to that
of the original call, and the Local channel will become a zombie and be removed
from the active channels list. This is desirable in some circumstances, but can
result in unexpected dialplan behavior if you are doing fancy things with
variables in your call handling.
There is another option that can be used with local channels, which is the "j"
option. The "j" option must be used with the "n" option to make sure that the
local channel does not get optimized out of the call. This option will enable
a jitterbuffer on the local channel. The jitterbuffer will be used to de-jitter
audio that it receives from the channel that called the local channel. This is
especially in the case of putting chan\_local in between an incoming SIP call
and Asterisk applications, so that the incoming audio will be de-jittered.
\subsection{Purpose}
\subsection{Purpose}
The Local channel construct can be used to establish dialing into any part of the dialplan.
The Local channel construct can be used to establish dialing into any part of
the dialplan.
Imagine you have a TE410P in your box. You want to do something for which you must use a Dial statement (for instance when dropping files in /var/spool/outgoing) but you do want to be able to use your dialplans least-cost-routes or other intelligent stuff. What you could do before we had chan\_local was create a cross-link between two ports of the TE410P and then Dial out one port and in the other. This way you could control where the call was going.
Imagine you have a TE410P in your box. You want to do something for which you
must use a Dial statement (for instance when dropping files in
\path{/var/spool/outgoing}) but you do want to be able to use your dialplans
least-cost-routes or other intelligent stuff. What you could do before we had
chan\_local was create a cross-link between two ports of the TE410P and then
Dial out one port and in the other. This way you could control where the call
was going.
Of course, this was a nasty hack, and to make it more sensible, chan\_local was built.
Of course, this was a nasty hack, and to make it more sensible, chan\_local was
built.
The "Local" channel driver allows you to convert an arbitrary extension into a channel. It is used in a variety of places, including agents, etc.
The "Local" channel driver allows you to convert an arbitrary extension into a
channel. It is used in a variety of places, including agents, etc.
This also allows us to hop to contexts like a GoSub routine; See examples below.
This also allows us to hop to contexts like a GoSub routine; See examples below.
If you use chan\_local from a call-file and you want to pass channel variables into your context, make sure you append the '/n', because otherwise chan\_local will 'optimize' itself out of the call-path, and the variables will get lost. i.e.
If you use chan\_local from a call-file and you want to pass channel variables
into your context, make sure you append the '/n', because otherwise
chan\_local will 'optimize' itself out of the call-path, and the variables will
Russell Bryant
18 years ago