@cat sounds/sounds.xml >> $@
@echo "</menu>" >> $@
-pdf: asterisk.pdf
-asterisk.pdf:
- $(MAKE) -C doc/tex asterisk.pdf
-
-txt: asterisk.txt
-asterisk.txt:
- $(MAKE) -C doc/tex asterisk.txt
-
.PHONY: menuselect
.PHONY: main
.PHONY: sounds
.PHONY: uninstall
.PHONY: _uninstall
.PHONY: uninstall-all
-.PHONY: pdf
.PHONY: dont-optimize
.PHONY: badshell
.PHONY: installdirs
make -C sounds MENUSELECT_CORE_SOUNDS=CORE-SOUNDS-EN-GSM MENUSELECT_MOH=MOH-OPSOUND-WAV WGET=wget DOWNLOAD=wget all
make AWK=awk GREP=grep menuselect-tree
-make_tex_docs() {
- # make backup of asterisk.tex because we are going to alter it
- cp asterisk.tex asterisk.tex.orig
- sed -e "s/ASTERISKVERSION/${VERSION}/" asterisk.tex > asterisk_local.tex
- mv asterisk_local.tex asterisk.tex
- rubber --pdf asterisk.tex
- latex2html asterisk.tex
- latex asterisk.tex
- catdvi -e 1 -U asterisk.dvi | sed -re "s/\[U\+2022\]/*/g" | sed -re "s/\[U\+02C6\]/^/g" | sed -re "s/([^^[:space:]])\s+/\1 /g" > asterisk.txt
- # restore backup of asterisk.tex
- mv asterisk.tex.orig asterisk.tex
-}
-
-VERSION=`cat .version`
-cd doc/tex && make_tex_docs
+cd doc
+echo "Exporting Asterisk wiki to a PDF (this will take a minute) ..."
+wikiexport.py
+echo "Converting wiki export PDF to plain text ..."
+pdftotext AST.pdf
+++ /dev/null
- --------------------------------------
- == Asterisk Coding Guidelines ==
- --------------------------------------
-
-This document gives some basic indication on how the asterisk code
-is structured. The first part covers the structure and style of
-individual files. The second part (TO BE COMPLETED) covers the
-overall code structure and the build architecture.
-
-Please read it to the end to understand in detail how the asterisk
-code is organized, and to know how to extend asterisk or contribute
-new code.
-
-We are looking forward to your contributions to Asterisk - the
-Open Source PBX! As Asterisk is a large and in some parts very
-time-sensitive application, the code base needs to conform to
-a common set of coding rules so that many developers can enhance
-and maintain the code. Code also needs to be reviewed and tested
-so that it works and follows the general architecture and guide-
-lines, and is well documented.
-
-Asterisk is published under a dual-licensing scheme by Digium.
-To be accepted into the codebase, all non-trivial changes must be
-licensed to Digium. For more information, see the electronic license
-agreement on https://issues.asterisk.org/.
-
-Patches should be in the form of a unified (-u) diff, made from a checkout
-from subversion.
-
-/usr/src/asterisk$ svn diff > mypatch
-
-If you would like to only include changes to certain files in the patch, you
-can list them in the "svn diff" command:
-
-/usr/src/asterisk$ svn diff somefile.c someotherfile.c > mypatch
-
- -----------------------------------
- == PART ONE: CODING GUIDELINES ==
- -----------------------------------
-
-* General rules
----------------
-
-- Indent code using tabs, not spaces.
-
-- All code, filenames, function names and comments must be in ENGLISH.
-
-- Don't annotate your changes with comments like "/* JMG 4/20/04 */";
- Comments should explain what the code does, not when something was changed
- or who changed it. If you have done a larger contribution, make sure
- that you are added to the CREDITS file.
-
-- Don't make unnecessary whitespace changes throughout the code.
- If you make changes, submit them to the tracker as separate patches
- that only include whitespace and formatting changes.
-
-- Don't use C++ type (//) comments.
-
-- Try to match the existing formatting of the file you are working on.
-
-- Use spaces instead of tabs when aligning in-line comments or #defines (this makes
- your comments aligned even if the code is viewed with another tabsize)
-
-* File structure and header inclusion
--------------------------------------
-
-Every C source file should start with a proper copyright
-and a brief description of the content of the file.
-Following that, you should immediately put the following lines:
-
-#include "asterisk.h"
-ASTERISK_FILE_VERSION(__FILE__, "$Revision$")
-
-"asterisk.h" resolves OS and compiler dependencies for the basic
-set of unix functions (data types, system calls, basic I/O
-libraries) and the basic Asterisk APIs.
-ASTERISK_FILE_VERSION() stores in the executable information
-about the file.
-
-Next, you should #include extra headers according to the functionality
-that your file uses or implements. For each group of functions that
-you use there is a common header, which covers OS header dependencies
-and defines the 'external' API of those functions (the equivalent
-of 'public' members of a class). As an example:
-
- asterisk/module.h
- if you are implementing a module, this should be included in one
- of the files that are linked with the module.
-
- asterisk/io.h
- access to extra file I/O functions (stat, fstat, playing with
- directories etc)
-
- asterisk/network.h
- basic network I/O - all of the socket library, select/poll,
- and asterisk-specific (usually either thread-safe or reentrant
- or both) functions to play with socket addresses.
-
- asterisk/app.h
- parsing of application arguments
-
- asterisk/channel.h
- struct ast_channel and functions to manipulate it
-
-For more information look at the headers in include/asterisk/ .
-These files are usually self-sufficient, i.e. they recursively #include
-all the extra headers they need.
-
-The equivalent of 'private' members of a class are either directly in
-the C source file, or in files named asterisk/mod_*.h to make it clear
-that they are not for inclusion by generic code.
-
-Keep the number of header files small by not including them unnecessarily.
-Don't cut&paste list of header files from other sources, but only include
-those you really need. Apart from obvious cases (e.g. module.h which
-is almost always necessary) write a short comment next to each #include to
-explain why you need it.
-
-* Declaration of functions and variables
-----------------------------------------
-
-- Do not declare variables mid-block (e.g. like recent GNU compilers support)
- since it is harder to read and not portable to GCC 2.95 and others.
-
-- Functions and variables that are not intended to be used outside the module
- must be declared static. If you are compiling on a Linux platform that has the
- 'dwarves' package available, you can use the 'pglobal' tool from that package
- to check for unintended global variables or functions being exposed in your
- object files. Usage is very simple:
-
- $ pglobal -vf <path to .o file>
-
-- When reading integer numeric input with scanf (or variants), do _NOT_ use '%i'
- unless you specifically want to allow non-base-10 input; '%d' is always a better
- choice, since it will not silently turn numbers with leading zeros into base-8.
-
-- Strings that are coming from input should not be used as the format argument to
- any printf-style function.
-
-* Structure alignment and padding
----------------------------------
-
-On many platforms, structure fields (in structures that are not marked 'packed')
-will be laid out by the compiler with gaps (padding) between them, in order to
-satisfy alignment requirements. As a simple example:
-
-struct foo {
- int bar;
- void *xyz;
-}
-
-On nearly every 64-bit platform, this will result in 4 bytes of dead space between
-'bar' and 'xyz', because pointers on 64-bit platforms must be aligned on 8-byte
-boundaries. Once you have your code written and tested, it may be worthwhile to review
-your structure definitions to look for problems of this nature. If you are on a Linux
-platform with the 'dwarves' package available, the 'pahole' tool from that package
-can be used to both check for padding issues of this type and also propose reorganized
-structure definitions to eliminate it. Usage is quite simple; for a structure named 'foo',
-the command would look something like this:
-
-$ pahole --reorganize --show_reorg_steps -C foo <path to module>
-
-The 'pahole' tool has many other modes available, including some that will list all the
-structures declared in the module and the amount of padding in each one that could possibly
-be recovered.
-
-* Use the internal API
-----------------------
-
-- Make sure you are aware of the string and data handling functions that exist
- within Asterisk to enhance portability and in some cases to produce more
- secure and thread-safe code. Check utils.c/utils.h for these.
-
-- If you need to create a detached thread, use the ast_pthread_create_detached()
- normally or ast_pthread_create_detached_background() for a thread with a smaller
- stack size. This reduces the replication of the code to handle the pthread_attr_t
- structure.
-
-* Code formatting
------------------
-
-Roughly, Asterisk code formatting guidelines are generally equivalent to the
-following:
-
-# indent -i4 -ts4 -br -brs -cdw -lp -ce -nbfda -npcs -nprs -npsl -nbbo -saf -sai -saw -cs -l90 foo.c
-
-this means in verbose:
- -i4: indent level 4
- -ts4: tab size 4
- -br: braces on if line
- -brs: braces on struct decl line
- -cdw: cuddle do while
- -lp: line up continuation below parenthesis
- -ce: cuddle else
- -nbfda: dont break function decl args
- -npcs: no space after function call names
- -nprs: no space after parentheses
- -npsl: dont break procedure type
- -saf: space after for
- -sai: space after if
- -saw: space after while
- -cs: space after cast
- -l90: line length 90 columns
-
-Function calls and arguments should be spaced in a consistent way across
-the codebase.
- GOOD: foo(arg1, arg2);
- BAD: foo(arg1,arg2);
- BAD: foo (arg1, arg2);
- BAD: foo( arg1, arg2 );
- BAD: foo(arg1, arg2,arg3);
-
-Don't treat keywords (if, while, do, return) as if they were functions;
-leave space between the keyword and the expression used (if any). For 'return',
-don't even put parentheses around the expression, since they are not
-required.
-
-There is no shortage of whitespace characters :-) Use them when they make
-the code easier to read. For example:
-
- for (str=foo;str;str=str->next)
-
-is harder to read than
-
- for (str = foo; str; str = str->next)
-
-Following are examples of how code should be formatted.
-
-- Functions:
-int foo(int a, char *s)
-{
- return 0;
-}
-
-- If statements:
-if (foo) {
- bar();
-} else {
- blah();
-}
-
-- Case statements:
-switch (foo) {
-case BAR:
- blah();
- break;
-case OTHER:
- other();
- break;
-}
-
-- No nested statements without braces, e.g.:
-
-for (x = 0; x < 5; x++)
- if (foo)
- if (bar)
- baz();
-
-instead do:
-for (x = 0; x < 5; x++) {
- if (foo) {
- if (bar) {
- baz();
- }
- }
-}
-
-- Always use braces around the statements following an if/for/while construct,
-even if not strictly necessary, as it reduces future possible problems.
-
-- Don't build code like this:
-
-if (foo) {
- /* .... 50 lines of code ... */
-} else {
- result = 0;
- return;
-}
-
-Instead, try to minimize the number of lines of code that need to be
-indented, by only indenting the shortest case of the 'if'
-statement, like so:
-
-if (!foo) {
- result = 0;
- return;
-}
-
-.... 50 lines of code ....
-
-When this technique is used properly, it makes functions much easier to read
-and follow, especially those with more than one or two 'setup' operations
-that must succeed for the rest of the function to be able to execute.
-
-- Labels/goto are acceptable
-Proper use of this technique may occasionally result in the need for a
-label/goto combination so that error/failure conditions can exit the
-function while still performing proper cleanup. This is not a bad thing!
-Use of goto in this situation is encouraged, since it removes the need
-for excess code indenting without requiring duplication of cleanup code.
-
-- Never use an uninitialized variable
-Make sure you never use an uninitialized variable. The compiler will
-usually warn you if you do so. However, do not go too far the other way,
-and needlessly initialize variables that do not require it. If the first
-time you use a variable in a function is to store a value there, then
-initializing it at declaration is pointless, and will generate extra
-object code and data in the resulting binary with no purpose. When in doubt,
-trust the compiler to tell you when you need to initialize a variable;
-if it does not warn you, initialization is not needed.
-
-- Do not cast 'void *'
-Do not explicitly cast 'void *' into any other type, nor should you cast any
-other type into 'void *'. Implicit casts to/from 'void *' are explicitly
-allowed by the C specification. This means the results of malloc(), calloc(),
-alloca(), and similar functions do not _ever_ need to be cast to a specific
-type, and when you are passing a pointer to (for example) a callback function
-that accepts a 'void *' you do not need to cast into that type.
-
-* Function naming
------------------
-
-All public functions (those not marked 'static'), must be named "ast_<something>"
-and have a descriptive name.
-
-As an example, suppose you wanted to take a local function "find_feature", defined
-as static in a file, and used only in that file, and make it public, and use it
-in other files. You will have to remove the "static" declaration and define a
-prototype in an appropriate header file (usually in include/asterisk). A more
-specific name should be given, such as "ast_find_call_feature".
-
-* Variable function argument parsing
-------------------------------------
-
-Functions with a variable amount of arguments need a 'sentinel' when called.
-Newer GNU C compilers are fine if you use NULL for this. Older versions (pre 4)
-don't like this.
-You should use the constant SENTINEL.
-This one is defined in include/asterisk/compiler.h
-
-* Variable naming
------------------
-
-- Global variables
-Name global variables (or local variables when you have a lot of them or
-are in a long function) something that will make sense to aliens who
-find your code in 100 years. All variable names should be in lower
-case, except when following external APIs or specifications that normally
-use upper- or mixed-case variable names; in that situation, it is
-preferable to follow the external API/specification for ease of
-understanding.
-
-Make some indication in the name of global variables which represent
-options that they are in fact intended to be global.
- e.g.: static char global_something[80]
-
-- Don't use unnecessary typedef's
-Don't use 'typedef' just to shorten the amount of typing; there is no substantial
-benefit in this:
-struct foo { int bar; }; typedef struct foo foo_t;
-
-In fact, don't use 'variable type' suffixes at all; it's much preferable to
-just type 'struct foo' rather than 'foo_s'.
-
-- Use enums instead of #define where possible
-Use enums rather than long lists of #define-d numeric constants when possible;
-this allows structure members, local variables and function arguments to
-be declared as using the enum's type. For example:
-
-enum option {
- OPT_FOO = 1,
- OPT_BAR = 2,
- OPT_BAZ = 4,
-};
-
-static enum option global_option;
-
-static handle_option(const enum option opt)
-{
- ...
-}
-
-Note: The compiler will _not_ force you to pass an entry from the enum
-as an argument to this function; this recommendation serves only to make
-the code clearer and somewhat self-documenting. In addition, when using
-switch/case blocks that switch on enum values, the compiler will warn
-you if you forget to handle one or more of the enum values, which can be
-handy.
-
-* String handling
------------------
-
-Don't use strncpy for copying whole strings; it does not guarantee that the
-output buffer will be null-terminated. Use ast_copy_string instead, which
-is also slightly more efficient (and allows passing the actual buffer
-size, which makes the code clearer).
-
-Don't use ast_copy_string (or any length-limited copy function) for copying
-fixed (known at compile time) strings into buffers, if the buffer is something
-that has been allocated in the function doing the copying. In that case, you
-know at the time you are writing the code whether the buffer is large enough
-for the fixed string or not, and if it's not, your code won't work anyway!
-Use strcpy() for this operation, or directly set the first two characters
-of the buffer if you are just trying to store a one character string in the
-buffer. If you are trying to 'empty' the buffer, just store a single
-NULL character ('\0') in the first byte of the buffer; nothing else is
-needed, and any other method is wasteful.
-
-In addition, if the previous operations in the function have already
-determined that the buffer in use is adequately sized to hold the string
-you wish to put into it (even if you did not allocate the buffer yourself),
-use a direct strcpy(), as it can be inlined and optimized to simple
-processor operations, unlike ast_copy_string().
-
-* String conversions
---------------------
-
-When converting from strings to integers or floats, use the sscanf function
-in preference to the atoi and atof family of functions, as sscanf detects
-errors. Always check the return value of sscanf to verify that your numeric
-variables successfully scanned before using them. Also, to avoid a potential
-libc bug, always specify a maximum width for each conversion specifier,
-including integers and floats. A good length for both integers and floats is
-30, as this is more than generous, even if you're using doubles or long
-integers.
-
-* Use of functions
-------------------
-
-For the sake of uclibc, do not use index, bcopy or bzero; use strchr(), memset(),
-and memmove() instead. uclibc can be configured to supply these functions, but
-we can save these users time and consternation if we abstain from using these
-functions.
-
-When making applications, always ast_strdupa(data) to a local pointer if you
-intend to parse the incoming data string.
-
- if (data) {
- mydata = ast_strdupa(data);
- }
-
-- Use the argument parsing macros to declare arguments and parse them, i.e.:
-
- AST_DECLARE_APP_ARGS(args,
- AST_APP_ARG(arg1);
- AST_APP_ARG(arg2);
- AST_APP_ARG(arg3);
- );
- parse = ast_strdupa(data);
- AST_STANDARD_APP_ARGS(args, parse);
-
-- Create generic code!
-If you do the same or a similar operation more than one time, make it a
-function or macro.
-
-Make sure you are not duplicating any functionality already found in an
-API call somewhere. If you are duplicating functionality found in
-another static function, consider the value of creating a new API call
-which can be shared.
-
-* Handling of pointers and allocations
---------------------------------------
-
-- Dereference or localize pointers
-Always dereference or localize pointers to things that are not yours like
-channel members in a channel that is not associated with the current
-thread and for which you do not have a lock.
- channame = ast_strdupa(otherchan->name);
-
-- Use const on pointer arguments if possible
-Use const on pointer arguments which your function will not be modifying, as this
-allows the compiler to make certain optimizations. In general, use 'const'
-on any argument that you have no direct intention of modifying, as it can
-catch logic/typing errors in your code when you use the argument variable
-in a way that you did not intend.
-
-- Do not create your own linked list code - reuse!
-As a common example of this point, make an effort to use the lockable
-linked-list macros found in include/asterisk/linkedlists.h. They are
-efficient, easy to use and provide every operation that should be
-necessary for managing a singly-linked list (if something is missing,
-let us know!). Just because you see other open-coded list implementations
-in the source tree is no reason to continue making new copies of
-that code... There are also a number of common string manipulation
-and timeval manipulation functions in asterisk/strings.h and asterisk/time.h;
-use them when possible.
-
-- Avoid needless allocations!
-Avoid needless malloc(), strdup() calls. If you only need the value in
-the scope of your function try ast_strdupa() or declare structs on the
-stack and pass a pointer to them. However, be careful to _never_ call
-alloca(), ast_strdupa() or similar functions in the argument list
-of a function you are calling; this can cause very strange stack
-arrangements and produce unexpected behavior.
-
-- Allocations for structures
-When allocating/zeroing memory for a structure, use code like this:
-
-struct foo *tmp;
-
-...
-
-tmp = ast_calloc(1, sizeof(*tmp));
-
-Avoid the combination of ast_malloc() and memset(). Instead, always use
-ast_calloc(). This will allocate and zero the memory in a single operation.
-In the case that uninitialized memory is acceptable, there should be a comment
-in the code that states why this is the case.
-
-Using sizeof(*tmp) instead of sizeof(struct foo) eliminates duplication of the
-'struct foo' identifier, which makes the code easier to read and also ensures
-that if it is copy-and-pasted it won't require as much editing.
-
-The ast_* family of functions for memory allocation are functionally the same.
-They just add an Asterisk log error message in the case that the allocation
-fails for some reason. This eliminates the need to generate custom messages
-throughout the code to log that this has occurred.
-
-- String Duplications
-
-The functions strdup and strndup can *not* accept a NULL argument. This results
-in having code like this:
-
- if (str) {
- newstr = strdup(str);
- } else {
- newstr = NULL;
- }
-
-However, the ast_strdup and ast_strdupa functions will happily accept a NULL
-argument without generating an error. The same code can be written as:
-
- newstr = ast_strdup(str);
-
-Furthermore, it is unnecessary to have code that malloc/calloc's for the length
-of a string (+1 for the terminating '\0') and then using strncpy to copy the
-copy the string into the resulting buffer. This is the exact same thing as
-using ast_strdup.
-
-* CLI Commands
---------------
-
-New CLI commands should be named using the module's name, followed by a verb
-and then any parameters that the command needs. For example:
-
-*CLI> iax2 show peer <peername>
-
-not
-
-*CLI> show iax2 peer <peername>
-
-* New dialplan applications/functions
--------------------------------------
-
-There are two methods of adding functionality to the Asterisk
-dialplan: applications and functions. Applications (found generally in
-the apps/ directory) should be collections of code that interact with
-a channel and/or user in some significant way. Functions (which can be
-provided by any type of module) are used when the provided
-functionality is simple... getting/retrieving a value, for
-example. Functions should also be used when the operation is in no way
-related to a channel (a computation or string operation, for example).
-
-Applications are registered and invoked using the
-ast_register_application function; see the apps/app_skel.c file for an
-example.
-
-Functions are registered using 'struct ast_custom_function'
-structures and the ast_custom_function_register function.
-
-* Doxygen API Documentation Guidelines
---------------------------------------
-
-When writing Asterisk API documentation the following format should be
-followed. Do not use the javadoc style.
-
-/*!
- * \brief Do interesting stuff.
- *
- * \param thing1 interesting parameter 1.
- * \param thing2 interesting parameter 2.
- *
- * This function does some interesting stuff.
- *
- * \retval zero on success
- * \retval -1 on error.
- */
-int ast_interesting_stuff(int thing1, int thing2)
-{
- return 0;
-}
-
-Notice the use of the \param, \brief, and \return constructs. These should be
-used to describe the corresponding pieces of the function being documented.
-Also notice the blank line after the last \param directive. All doxygen
-comments must be in one /*! */ block. If the function or struct does not need
-an extended description it can be left out.
-
-Please make sure to review the doxygen manual and make liberal use of the \a,
-\code, \c, \b, \note, \li and \e modifiers as appropriate.
-
-When documenting a 'static' function or an internal structure in a module,
-use the \internal modifier to ensure that the resulting documentation
-explicitly says 'for internal use only'.
-
-When adding new API you should also attach a \since note because this will
-indicate to developers that this API did not exist before this version. It
-also has the benefit of making the resulting HTML documentation to group
-the changes for a single version.
-
-Structures should be documented as follows.
-
-/*!
- * \brief A very interesting structure.
- */
-struct interesting_struct
-{
- /*! \brief A data member. */
- int member1;
-
- int member2; /*!< \brief Another data member. */
-}
-
-Note that /*! */ blocks document the construct immediately following them
-unless they are written, /*!< */, in which case they document the construct
-preceding them.
-
-It is very much preferred that documentation is not done inline, as done in
-the previous example for member2. The first reason for this is that it tends
-to encourage extremely brief, and often pointless, documentation since people
-try to keep the comment from making the line extremely long. However, if you
-insist on using inline comments, please indent the documentation with spaces!
-That way, all of the comments are properly aligned, regardless of what tab
-size is being used for viewing the code.
-
-* Finishing up before you submit your code
-------------------------------------------
-
-- Look at the code once more
-When you achieve your desired functionality, make another few refactor
-passes over the code to optimize it.
-
-- Read the patch
-Before submitting a patch, *read* the actual patch file to be sure that
-all the changes you expect to be there are, and that there are no
-surprising changes you did not expect. During your development, that
-part of Asterisk may have changed, so make sure you compare with the
-latest SVN.
-
-- Listen to advice
-If you are asked to make changes to your patch, there is a good chance
-the changes will introduce bugs, check it even more at this stage.
-Also remember that the bug marshal or co-developer that adds comments
-is only human, they may be in error :-)
-
-- Optimize, optimize, optimize
-If you are going to reuse a computed value, save it in a variable
-instead of recomputing it over and over. This can prevent you from
-making a mistake in subsequent computations, making it easier to correct
-if the formula has an error and may or may not help optimization but
-will at least help readability.
-
-Just an example (so don't over analyze it, that'd be a shame):
-
-const char *prefix = "pre";
-const char *postfix = "post";
-char *newname;
-char *name = "data";
-
-if (name && (newname = alloca(strlen(name) + strlen(prefix) + strlen(postfix) + 3))) {
- snprintf(newname, strlen(name) + strlen(prefix) + strlen(postfix) + 3, "%s/%s/%s", prefix, name, postfix);
-|
-
-...vs this alternative:
-
-const char *prefix = "pre";
-const char *postfix = "post";
-char *newname;
-char *name = "data";
-int len = 0;
-
-if (name && (len = strlen(name) + strlen(prefix) + strlen(postfix) + 3) && (newname = alloca(len))) {
- snprintf(newname, len, "%s/%s/%s", prefix, name, postfix);
-}
-
-* Creating new manager events?
-------------------------------
-If you create new AMI events, please read manager.txt. Do not re-use
-existing headers for new purposes, but please re-use existing headers
-for the same type of data.
-
-Manager events that signal a status are required to have one
-event name, with a status header that shows the status.
-The old style, with one event named "ThisEventOn" and another named
-"ThisEventOff", is no longer approved.
-
-Check manager.txt for more information on manager and existing
-headers. Please update this file if you add new headers.
-
-* Locking in Asterisk
------------------------------
-
-A) Locking Fundamentals
-
-Asterisk is a heavily multithreaded application. It makes extensive
-use of locking to ensure safe access to shared resources between
-different threads.
-
-When more that one lock is involved in a given code path, there is the
-potential for deadlocks. A deadlock occurs when a thread is stuck
-waiting for a resource that it will never acquire. Here is a classic
-example of a deadlock:
-
- Thread 1 Thread 2
- ------------ ------------
- Holds Lock A Holds Lock B
- Waiting for Lock B Waiting for Lock A
-
-In this case, there is a deadlock between threads 1 and 2.
-This deadlock would have been avoided if both threads had
-agreed that one must acquire Lock A before Lock B.
-
-In general, the fundamental rule for dealing with multiple locks is
-
- an order _must_ be established to acquire locks, and then all threads
- must respect that order when acquiring locks.
-
-
-A.1) Establishing a locking order
-
-Because any ordering for acquiring locks is ok, one could establish
-the rule arbitrarily, e.g. ordering by address, or by some other criterion.
-The main issue, though, is defining an order that
- i) is easy to check at runtime;
- ii) reflects the order in which the code executes.
-As an example, if a data structure B is only accessible through a
-data structure A, and both require locking, then the natural order
-is locking first A and then B.
-As another example, if we have some unrelated data structures to
-be locked in pairs, then a possible order can be based on the address
-of the data structures themselves.
-
-B) Minding the boundary between channel drivers and the Asterisk core
-
-The #1 cause of deadlocks in Asterisk is by not properly following the
-locking rules that exist at the boundary between Channel Drivers and
-the Asterisk core. The Asterisk core allocates an ast_channel, and
-Channel Drivers allocate "technology specific private data" (PVT) that is
-associated with an ast_channel. Typically, both the ast_channel and
-PVT have their own lock. There are _many_
-code paths that require both objects to be locked.
-
-The locking order in this situation is the following:
-
- 1) ast_channel
- 2) PVT
-
-Channel Drivers implement the ast_channel_tech interface to provide a
-channel implementation for Asterisk. Most of the channel_tech
-interface callbacks are called with the associated ast_channel
-locked. When accessing technology specific data, the PVT can be locked
-directly because the locking order is respected.
-
-C) Preventing lock ordering reversals.
-
-There are some code paths which make it extremely difficult to
-respect the locking order.
-Consider for example the following situation:
-
- 1) A message comes in over the "network"
- 2) The Channel Driver (CD) monitor thread receives the message
- 3) The CD associates the message with a PVT and locks the PVT
- 4) While processing the message, the CD must do something that requires
- locking the ast_channel associated to the PVT
-
-This is the point that must be handled carefully.
-The following psuedo-code
-
- unlock(pvt);
- lock(ast_channel);
- lock(pvt);
-
-is _not_ correct for two reasons:
-
-i) first and foremost, unlocking the PVT means that other threads
- can acquire the lock and believe it is safe to modify the
- associated data. When reacquiring the lock, the original thread
- might find unexpected changes in the protected data structures.
- This essentially means that the original thread must behave as if
- the lock on the pvt was not held, in which case it could have
- released it itself altogether;
-
-ii) Asterisk uses the so called "recursive" locks, which allow a thread
- to issue a lock() call multiple times on the same lock. Recursive
- locks count the number of calls, and they require an equivalent
- number of unlock() to be actually released.
-
- For this reason, just calling unlock() once does not guarantee that the
- lock is actually released -- it all depends on how many times lock()
- was called before.
-
-An alternative, but still incorrect, construct is widely used in
-the asterisk code to try and improve the situation:
-
- while (trylock(ast_channel) == FAILURE) {
- unlock(pvt);
- usleep(1); /* yield to other threads */
- lock(pvt);
- }
-
-Here the trylock() is non blocking, so we do not deadlock if the ast_channel
-is already locked by someone else: in this case, we try to unlock the PVT
-(which happens only if the PVT lock counter is 1), yield the CPU to
-give other threads a chance to run, and then acquire the lock again.
-
-This code is not correct for two reasons:
- i) same as in the previous example, it releases the lock when the thread
- probably did not expect it;
- ii) if the PVT lock counter is greater than 1 we will not
- really release the lock on the PVT. We might be lucky and have the
- other contender actually release the lock itself, and so we will "win"
- the race, but if both contenders have their lock counts > 1 then
- they will loop forever (basically replacing deadlock with livelock).
-
-Another variant of this code is the following:
-
- if (trylock(ast_channel) == FAILURE) {
- unlock(pvt);
- lock(ast_channel);
- lock(pvt);
- }
-
-which has the same issues as the while(trylock...) code, but just
-deadlocks instead of looping forever in case of lock counts > 1.
-
-The deadlock/livelock could be in principle spared if one had an
-unlock_all() function that calls unlock as many times as needed to
-actually release the lock, and reports the count. Then we could do:
-
- if (trylock(ast_channel) == FAILURE) {
- n = unlock_all(pvt);
- lock(ast_channel)
- while (n-- > 0) lock(pvt);
- }
-
-The issue with unexpected unlocks remains, though.
-
-C) Locking multiple channels.
-
-The next situation to consider is what to do when you need a lock on
-multiple ast_channels (or multiple unrelated data structures).
-
-If we are sure that we do not hold any of these locks, then the
-following construct is sufficient:
-
- lock(MIN(chan1, chan2));
- lock(MAX(chan1, chan2));
-
-That type of code would follow an established locking order of always
-locking the channel that has a lower address first. Also keep in mind
-that to use this construct for channel locking, one would have to go
-through the entire codebase to ensure that when two channels are locked,
-this locking order is used.
- However, if we enter the above section of code with some lock held
-(which would be incorrect using non-recursive locks, but is completely
-legal using recursive mutexes) then the locking order is not guaranteed
-anymore because it depends on which locks we already hold. So we have
-to go through the same tricks used for the channel+PVT case.
-
-D) Recommendations
-
-As you can see from the above discussion, getting locking right is all
-but easy. So please follow these recommendations when using locks:
-
-*) Use locks only when really necessary
- Please try to use locks only when strictly necessary, and only for
- the minimum amount of time required to run critical sections of code.
- A common use of locks in the current code is to protect a data structure
- from being released while you use it.
- With the use of reference-counted objects (astobj2) this should not be
- necessary anymore.
-
-*) Do not sleep while holding a lock
- If possible, do not run any blocking code while holding a lock,
- because you will also block other threads trying to access the same
- lock. In many cases, you can hold a reference to the object to avoid
- that it is deleted while you sleep, perhaps set a flag in the object
- itself to report other threads that you have some pending work to
- complete, then release and acquire the lock around the blocking path,
- checking the status of the object after you acquire the lock to make
- sure that you can still perform the operation you wanted to.
-
-*) Try not to exploit the 'recursive' feature of locks.
- Recursive locks are very convenient when coding, as you don't have to
- worry, when entering a section of code, whether or not you already
- hold the lock -- you can just protect the section with a lock/unlock
- pair and let the lock counter track things for you.
- But as you have seen, exploiting the features of recursive locks
- make it a lot harder to implement proper deadlock avoidance strategies.
- So please try to analyse your code and determine statically whether you
- already hold a lock when entering a section of code.
- If you need to call some function foo() with and without a lock held,
- you could define two function as below:
- foo_locked(...) {
- ... do something, assume lock held
- }
-
- foo(...) {
- lock(xyz)
- ret = foo_locked(...)
- unlock(xyz)
- return ret;
- }
- and call them according to the needs.
-
-*) Document locking rules.
- Please document the locking order rules are documented for every
- lock introduced into Asterisk. This is done almost nowhere in the
- existing code. However, it will be expected to be there for newly
- introduced code. Over time, this information should be added for
- all of the existing lock usage.
-
------------------------------------------------------------------------
-
-
- ------------------------------------
- == PART TWO: BUILD ARCHITECTURE ==
- ------------------------------------
-
-The asterisk build architecture relies on autoconf to detect the
-system configuration, and on a locally developed tool (menuselect) to
-select build options and modules list, and on gmake to do the build.
-
-The first step, usually to be done soon after a checkout, is running
-"./configure", which will store its findings in two files:
-
- + include/asterisk/autoconfig.h
- contains C macros, normally #define HAVE_FOO or HAVE_FOO_H ,
- for all functions and headers that have been detected at build time.
- These are meant to be used by C or C++ source files.
-
- + makeopts
- contains variables that can be used by Makefiles.
- In addition to the usual CC, LD, ... variables pointing to
- the various build tools, and prefix, includedir ... which are
- useful for generic compiler flags, there are variables
- for each package detected.
- These are normally of the form FOO_INCLUDE=... FOO_LIB=...
- FOO_DIR=... indicating, for each package, the useful libraries
- and header files.
-
-The next step is to run "make menuselect", to extract the dependencies existing
-between files and modules, and to store build options.
-menuselect produces two files, both to be read by the Makefile:
-
- + menuselect.makeopts
- Contains for each subdirectory a list of modules that must be
- excluded from the build, plus some additional informatiom.
- + menuselect.makedeps
- Contains, for each module, a list of packages it depends on.
- For each of these packages, we can collect the relevant INCLUDE
- and LIB files from makeopts. This file is based on information
- in the .c source code files for each module.
-
-The top level Makefile is in charge of setting up the build environment,
-creating header files with build options, and recursively invoking the
-subdir Makefiles to produce modules and the main executable.
-
-The sources are split in multiple directories, more or less divided by
-module type (apps/ channels/ funcs/ res/ ...) or by function, for the main
-binary (main/ pbx/).
-
-
-TO BE COMPLETED
-
-
------------------------------------------------
-Welcome to the Asterisk development community!
-Meet you on the asterisk-dev mailing list.
-Subscribe at http://lists.digium.com!
-
--- The Asterisk.org Development Team
+++ /dev/null
-===============================================================================
-===
-=== HowTo: Collect Debug Information for the Asterisk Issue Tracker
-===
-=== Written by: Paul Belanger
-=== Last updated: 2010-04-12
-===============================================================================
-
-This document will provide instructions on how to collect debugging logs from an
-Asterisk machine, for the purpose of helping bug marshals troubleshoot an issue
-on https://issues.asterisk.org
--------------------------------------------------------------------------------
---- PREREQUISITES
--------------------------------------------------------------------------------
-
-- Asterisk 1.4.30 or greater.
-
--------------------------------------------------------------------------------
---- STEPS
--------------------------------------------------------------------------------
-
-1. Edit the logger.conf file to enable debug output to your filesystem.
-
- Add the following line. The word "myDebugLog" can be changed to anything you
- want, as that is the filename the logging will be written to. A good example
- might be something like: issue_12345_full_log
-
- myDebugLog => notice,warning,error,debug,verbose,dtmf
-
-2. From the Asterisk CLI, restart the logger module:
-
- *CLI> core set verbose 15
- *CLI> core set debug 15
- *CLI> module reload logger
-
- Optionally, if you've used this file to record data previously, then rotate
- the logs:
-
- *CLI> logger rotate
-
-2.1. Depending on your issue, be sure to enable the channel driver logging.
-
- SIP (1.6.0 or higher)
-
- *CLI> sip set debug on
-
- SIP (1.4)
-
- *CLI> sip set debug
-
- IAX2 (1.6.0 or higher)
-
- *CLI> iax2 set debug on
-
- IAX2 (1.4)
-
- *CLI> iax2 set debug
-
-3. Reproduce your issue.
-
-4. Once finished, be sure to disable the extra debbuging:
-
- *CLI> core set verbose 0
- *CLI> core set debug 0
-
-4.1. Again, remember to disable any extra logging if you enabled it in the
- channel driver.
-
- SIP (1.4 or higher)
-
- *CLI> sip set debug off
-
- IAX2 (1.4 or higher)
-
- *CLI> iax2 set debug off
-
-5. Upload the file located in /var/log/asterisk/myDebugLog to the issue tracker.
-
- *** IMPORTANT ***
- Do NOT post the output of your file as a comment. This clutters the issue
- and will only result in your comment being deleted.
-
-6. Disable logging to the filesystem. Edit the logger.conf file and comment out
- or delete the line you added in step 1. Using a semi-colon as the first
- character on the line will comment out the line.
-
- Then reload the logger module like in step 2:
-
- *CLI> module reload logger
+++ /dev/null
-India finds itself in a unique situation (hopefully). It has several
-telephone line providers, and they are not all using the same CID
-signalling; and the CID signalling is not like other countries.
-
-In order to help those in India quickly find to the CID signalling
-system that their carrier uses (or range of them), and get the
-configs right with a minimal amount of experimentation, this file
-is provided. Not all carriers are covered, and not all mentioned
-below are complete. Those with updates to this table should post
-the new information on bug 6683 of the asterisk bug tracker.
-
-
----------------------------------------------------------
-Provider: Bharti (is this BSNL?)
-Config: cidstart=polarity_in
- cidsignalling=dtmf
-Results: ? (this should work), but needs to be tested?
-tested by:
---------------------------------------------------------
-
-Provider: VSNL
-Config:
-
-Results: ?
-tested by:
---------------------------------------------------------
-
-Provider: BSNL
-Config: cid_start=ring
- cid_signalling=dtmf
-
-Results: ?
-tested by: (abhi)
---------------------------------------------------------
-
-Provider: MTNL, old BSNL
-Config: cidsignalling = v23
- cidstart=ring
-
-Results: works
-tested by: (enterux)
---------------------------------------------------------
-
-Provider: MTNL (Delhi)
-Config: cidsignalling = v23
- cidstart = ring
-
-cidsignalling = dtmf
-cidstart = polarity_IN
-
-cidsignalling = dtmf
-cidstart = polarity
-
-Results: fails
-tested by: brealer
---------------------------------------------------------
-
-Provider: TATA
-Config: cidsignalling = dtmf
- cidstart=polarity_IN
-
-Results: works
-tested by: brealer
----------------------------------------------------------
-
-Asterisk still doesn't work with some of the CID scenarios in India.
-If you are in India, and not able to make CID work with any of the
-permutations of cidsignalling and cidstart, it could be that this
-particular situation is not covered by Asterisk. A good course of
-action would be to get in touch with the provider, and find out from
-them exactly how their CID signalling works. Describe this to us,
-and perhaps someone will be able to extend the code to cover their
-signalling.
-
-
+++ /dev/null
-\begin{verbatim}
-
- DIGIUM GENERAL PEERING AGREEMENT (TM)
- Version 1.0.0, September 2004
- Copyright (C) 2004 Digium, Inc.
- 445 Jan Davis Drive, Huntsville, AL 35806 USA
-
- Everyone is permitted to copy and distribute complete verbatim copies
- of this General Peering Agreement provided it is not modified in any
- manner.
-
- ------------------------------------------------------
-
- DIGIUM GENERAL PEERING AGREEMENT
-
- PREAMBLE
-
- For most of the history of telecommunications, the power of being able
-to locate and communicate with another person in a system, be it across
-a hall or around the world, has always centered around a centralized
-authority -- from a local PBX administrator to regional and national
-RBOCs, generally requiring fees, taxes or regulation. By contrast,
-DUNDi is a technology developed to provide users the freedom to
-communicate with each other without the necessity of any centralized
-authority. This General Peering Agreement ("GPA") is used by individual
-parties (each, a "Participant") to allow them to build the E164 trust
-group for the DUNDi protocol.
-
- To protect the usefulness of the E164 trust group for those who use
-it, while keeping the system wholly decentralized, it is necessary to
-replace many of the responsibilities generally afforded to a company or
-government agency, with a set of responsibilities implemented by the
-parties who use the system, themselves. It is the goal of this document
-to provide all the protections necessary to keep the DUNDi E164 trust
-group useful and reliable.
-
- The Participants wish to protect competition, promote innovation and
-value added services and make this service valuable both commercially
-and non-commercially. To that end, this GPA provides special terms and
-conditions outlining some permissible and non-permissible revenue
-sources.
-
- This GPA is independent of any software license or other license
-agreement for a program or technology employing the DUNDi protocol. For
-example, the implementation of DUNDi used by Asterisk is covered under a
-separate license. Each Participant is responsible for compliance with
-any licenses or other agreements governing use of such program or
-technology that they use to peer.
-
- You do not have to execute this GPA to use a program or technology
-employing the DUNDi protocol, however if you do not execute this GPA,
-you will not be able to peer using DUNDi and the E164 context with
-anyone who is a member of the trust group by virtue of their having
-executed this GPA with another member.
-
-The parties to this GPA agree as follows:
-
- 0. DEFINITIONS. As used herein, certain terms shall be defined as
-follows:
-
- (a) The term "DUNDi" means the DUNDi protocol as published by
- Digium, Inc. or its successor in interest with respect to the
- DUNDi protocol specification.
-
- (b) The terms "E.164" and "E164" mean ITU-T specification E.164 as
- published by the International Telecommunications Union (ITU) in
- May, 1997.
-
- (c) The term "Service" refers to any communication facility (e.g.,
- telephone, fax, modem, etc.), identified by an E.164-compatible
- number, and assigned by the appropriate authority in that
- jurisdiction.
-
- (d) The term "Egress Gateway" refers an Internet facility that
- provides a communications path to a Service or Services that may
- not be directly addressable via the Internet.
-
- (e) The term "Route" refers to an Internet address, policies, and
- other characteristics defined by the DUNDi protocol and
- associated with the Service, or the Egress Gateway which
- provides access to the specified Service.
-
- (f) The term "Propagate" means to accept or transmit Service and/or
- Egress Gateway Routes only using the DUNDi protocol and the
- DUNDi context "e164" without regard to case, and does not apply
- to the exchange of information using any other protocol or
- context.
-
- (g) The term "Peering System" means the network of systems that
- Propagate Routes.
-
- (h) The term "Subscriber" means the owner of, or someone who
- contracts to receive, the services identified by an E.164
- number.
-
- (i) The term "Authorizing Individual" means the Subscriber to a
- number who has authorized a Participant to provide Routes
- regarding their services via this Peering System.
-
- (j) The term "Route Authority" refers to a Participant that provides
- an original source of said Route within the Peering System.
- Routes are propagated from the Route Authorities through the
- Peering System and may be cached at intermediate points. There
- may be multiple Route Authorities for any Service.
-
- (k) The term "Participant" (introduced above) refers to any member
- of the Peering System.
-
- (l) The term "Service Provider" refers to the carrier (e.g.,
- exchange carrier, Internet Telephony Service Provider, or other
- reseller) that provides communication facilities for a
- particular Service to a Subscriber, Customer or other End User.
-
- (m) The term "Weight" refers to a numeric quality assigned to a
- Route as per the DUNDi protocol specification. The current
- Weight definitions are shown in Exhibit A.
-
- 1. PEERING. The undersigned Participants agree to Propagate Routes
-with each other and any other member of the Peering System and further
-agree not to Propagate DUNDi Routes with a third party unless they have
-first have executed this GPA (in its unmodified form) with such third
-party. The Participants further agree only to Propagate Routes with
-Participants whom they reasonably believe to be honoring the terms of
-the GPA. Participants may not insert, remove, amend, or otherwise
-modify any of the terms of the GPA.
-
- 2. ACCEPTABLE USE POLICY. The DUNDi protocol contains information
-that reflect a Subscriber's or Egress Gateway's decisions to receive
-calls. In addition to the terms and conditions set forth in this GPA,
-the Participants agree to honor the intent of restrictions encoded in
-the DUNDi protocol. To that end, Participants agree to the following:
-
- (a) A Participant may not utilize or permit the utilization of
- Routes for which the Subscriber or Egress Gateway provider has
- indicated that they do not wish to receive "Unsolicited Calls"
- for the purpose of making an unsolicited phone call on behalf of
- any party or organization.
-
- (b) A Participant may not utilize or permit the utilization of
- Routes which have indicated that they do not wish to receive
- "Unsolicited Commercial Calls" for the purpose of making an
- unsolicited phone call on behalf of a commercial organization.
-
- (c) A Participant may never utilize or permit the utilization of any
- DUNDi route for the purpose of making harassing phone calls.
-
- (d) A Party may not utilize or permit the utilization of DUNDi
- provided Routes for any systematic or random calling of numbers
- (e.g., for the purpose of locating facsimile, modem services, or
- systematic telemarketing).
-
- (e) Initial control signaling for all communication sessions that
- utilize Routes obtained from the Peering System must be sent
- from a member of the Peering System to the Service or Egress
- Gateway identified in the selected Route. For example, 'SIP
- INVITES' and IAX2 "NEW" commands must be sent from the
- requesting DUNDi node to the terminating Service.
-
- (f) A Participant may not disclose any specific Route, Service or
- Participant contact information obtained from the Peering System
- to any party outside of the Peering System except as a
- by-product of facilitating communication in accordance with
- section 2e (e.g., phone books or other databases may not be
- published, but the Internet addresses of the Egress Gateway or
- Service does not need to be obfuscated.)
-
- (g) The DUNDi Protocol requires that each Participant include valid
- contact information about itself (including information about
- nodes connected to each Participant). Participants may use or
- disclose the contact information only to ensure enforcement of
- legal furtherance of this Agreement.
-
- 3. ROUTES. The Participants shall only propagate valid Routes, as
-defined herein, through the Peering System, regardless of the original
-source. The Participants may only provide Routes as set forth below,
-and then only if such Participant has no good faith reason to believe
-such Route to be invalid or unauthorized.
-
- (a) A Participant may provide Routes if each Route has as its
- original source another member of the Peering System who has
- duly executed the GPA and such Routes are provided in accordance
- with this Agreement; provided that the Routes are not modified
- (e.g., with regards to existence, destination, technology or
- Weight); or
-
- (b) A Participant may provide Routes for Services with any Weight
- for which it is the Subscriber; or
-
- (c) A Participant may provide Routes for those Services whose
- Subscriber has authorized the Participant to do so, provided
- that the Participant is able to confirm that the Authorizing
- Individual is the Subscriber through:
-
- i. a written statement of ownership from the Authorizing
- Individual, which the Participant believes in good faith
- to be accurate (e.g., a phone bill with the name of the
- Authorizing Individual and the number in question); or
-
- ii. the Participant's own direct personal knowledge that the
- Authorizing Individual is the Subscriber.
-
- (d) A Participant may provide Routes for Services, with Weight in
- accordance with the Current DUNDi Specification, if it can in
- good faith provide an Egress Gateway to that Service on the
- traditional telephone network without cost to the calling party.
-
- 4. REVOCATION. A Participant must provide a free, easily accessible
-mechanism by which a Subscriber may revoke permission to act as a Route
-Authority for his Service. A Participant must stop acting as a Route
-Authority for that Service within 7 days after:
-
- (a) receipt of a revocation request;
-
- (b) receiving other notice that the Service is no longer valid; or
-
- (c) determination that the Subscriber's information is no longer
- accurate (including that the Subscriber is no longer the service
- owner or the service owner's authorized delegate).
-
- 5. SERVICE FEES. A Participant may charge a fee to act as a Route
-Authority for a Service, with any Weight, provided that no Participant
-may charge a fee to propagate the Route received through the Peering
-System.
-
- 6. TOLL SERVICES. No Participant may provide Routes for any Services
-that require payment from the calling party or their customer for
-communication with the Service. Nothing in this section shall prohibit
-a Participant from providing routes for Services where the calling party
-may later enter into a financial transaction with the called party
-(e.g., a Participant may provide Routes for calling cards services).
-
- 7. QUALITY. A Participant may not intentionally impair communication
-using a Route provided to the Peering System (e.g. by adding delay,
-advertisements, reduced quality). If for any reason a Participant is
-unable to deliver a call via a Route provided to the Peering System,
-that Participant shall return out-of-band Network Congestion
-notification (e.g. "503 Service Unavailable" with SIP protocol or
-"CONGESTION" with IAX protocol).
-
- 8. PROTOCOL COMPLIANCE. Participants agree to Propagate Routes in
-strict compliance with current DUNDi protocol specifications.
-
- 9. ADMINISTRATIVE FEES. A Participant may charge (but is not required
-to charge) another Participant a reasonable fee to cover administrative
-expenses incurred in the execution of this Agreement. A Participant may
-not charge any fee to continue the relationship or to provide Routes to
-another Participant in the Peering System.
-
- 10. CALLER IDENTIFICATION. A Participant will make a good faith effort
-to ensure the accuracy and appropriate nature of any caller
-identification that it transmits via any Route obtained from the Peering
-System. Caller identification shall at least be provided as a valid
-E.164 number.
-
- 11. COMPLIANCE WITH LAWS. The Participants are solely responsible for
-determining to what extent, if any, the obligations set forth in this
-GPA conflict with any laws or regulations their region. A Participant
-may not provide any service or otherwise use DUNDi under this GPA if
-doing so is prohibited by law or regulation, or if any law or regulation
-imposes requirements on the Participant that are inconsistent with the
-terms of this GPA or the Acceptable Use Policy.
-
- 12. WARRANTY. EACH PARTICIPANT WARRANTS TO THE OTHER PARTICIPANTS THAT
-IT MADE, AND WILL CONTINUE TO MAKE, A GOOD FAITH EFFORT TO AUTHENTICATE
-OTHERS IN THE PEERING SYSTEM AND TO PROVIDE ACCURATE INFORMATION IN
-ACCORDANCE WITH THE TERMS OF THIS GPA. THIS WARRANTY IS MADE BETWEEN
-THE PARTICIPANTS, AND THE PARTICIPANTS MAY NOT EXTEND THIS WARRANTY TO
-ANY NON-PARTICIPANT INCLUDING END-USERS.
-
- 13. DISCLAIMER OF WARRANTIES. THE PARTICIPANTS UNDERSTAND AND AGREE
-THAT ANY SERVICE PROVIDED AS A RESULT OF THIS GPA IS "AS IS." EXCEPT FOR
-THOSE WARRANTIES OTHERWISE EXPRESSLY SET FORTH HEREIN, THE PARTICIPANTS
-DISCLAIM ANY REPRESENTATIONS OR WARRANTIES OF ANY KIND OR NATURE,
-EXPRESS OR IMPLIED, AS TO THE CONDITION, VALUE OR QUALITIES OF THE
-SERVICES PROVIDED HEREUNDER, AND SPECIFICALLY DISCLAIM ANY
-REPRESENTATION OR WARRANTY OF MERCHANTABILITY, SUITABILITY OR FITNESS
-FOR A PARTICULAR PURPOSE OR AS TO THE CONDITION OR WORKMANSHIP THEREOF,
-OR THE ABSENCE OF ANY DEFECTS THEREIN, WHETHER LATENT OR PATENT,
-INCLUDING ANY WARRANTIES ARISING FROM A COURSE OF DEALING, USAGE OR
-TRADE PRACTICE. EXCEPT AS EXPRESSLY PROVIDED HEREIN, THE PARTICIPANTS
-EXPRESSLY DISCLAIM ANY REPRESENTATIONS OR WARRANTIES THAT THE PEERING
-SERVICE WILL BE CONTINUOUS, UNINTERRUPTED OR ERROR-FREE, THAT ANY DATA
-SHARED OR OTHERWISE MADE AVAILABLE WILL BE ACCURATE OR COMPLETE OR
-OTHERWISE COMPLETELY SECURE FROM UNAUTHORIZED ACCESS.
-
- 14. LIMITATION OF LIABILITIES. NO PARTICIPANT SHALL BE LIABLE TO ANY
-OTHER PARTICIPANT FOR INCIDENTAL, INDIRECT, CONSEQUENTIAL, SPECIAL,
-PUNITIVE OR EXEMPLARY DAMAGES OF ANY KIND (INCLUDING LOST REVENUES OR
-PROFITS, LOSS OF BUSINESS OR LOSS OF DATA) IN ANY WAY RELATED TO THIS
-GPA, WHETHER IN CONTRACT OR IN TORT, REGARDLESS OF WHETHER SUCH
-PARTICIPANT WAS ADVISED OF THE POSSIBILITY THEREOF.
-
- 15. END-USER AGREEMENTS. The Participants may independently enter
-into agreements with end-users to provide certain services (e.g., fees
-to a Subscriber to originate Routes for that Service). To the extent
-that provision of these services employs the Peering System, the Parties
-will include in their agreements with their end-users terms and
-conditions consistent with the terms of this GPA with respect to the
-exclusion of warranties, limitation of liability and Acceptable Use
-Policy. In no event may a Participant extend the warranty described in
-Section 12 in this GPA to any end-users.
-
- 16. INDEMNIFICATION. Each Participant agrees to defend, indemnify and
-hold harmless the other Participant or third-party beneficiaries to this
-GPA (including their affiliates, successors, assigns, agents and
-representatives and their respective officers, directors and employees)
-from and against any and all actions, suits, proceedings,
-investigations, demands, claims, judgments, liabilities, obligations,
-liens, losses, damages, expenses (including, without limitation,
-attorneys' fees) and any other fees arising out of or relating to (i)
-personal injury or property damage caused by that Participant, its
-employees, agents, servants, or other representatives; (ii) any act or
-omission by the Participant, its employees, agents, servants or other
-representatives, including, but not limited to, unauthorized
-representations or warranties made by the Participant; or (iii) any
-breach by the Participant of any of the terms or conditions of this GPA.
-
- 17. THIRD PARTY BENEFICIARIES. This GPA is intended to benefit those
-Participants who have executed the GPA and who are in the Peering
-System. It is the intent of the Parties to this GPA to give to those
-Participants who are in the Peering System standing to bring any
-necessary legal action to enforce the terms of this GPA.
-
- 18. TERMINATION. Any Participant may terminate this GPA at any time,
-with or without cause. A Participant that terminates must immediately
-cease to Propagate.
-
- 19. CHOICE OF LAW. This GPA and the rights and duties of the Parties
-hereto shall be construed and determined in accordance with the internal
-laws of the State of New York, United States of America, without regard
-to its conflict of laws principles and without application of the United
-Nations Convention on Contracts for the International Sale of Goods.
-
- 20. DISPUTE RESOLUTION. Unless otherwise agreed in writing, the
-exclusive procedure for handling disputes shall be as set forth herein.
-Notwithstanding such procedures, any Participant may, at any time, seek
-injunctive relief in addition to the process described below.
-
- (a) Prior to mediation or arbitration the disputing Participants
- shall seek informal resolution of disputes. The process shall be
- initiated with written notice of one Participant to the other
- describing the dispute with reasonable particularity followed
- with a written response within ten (10) days of receipt of
- notice. Each Participant shall promptly designate an executive
- with requisite authority to resolve the dispute. The informal
- procedure shall commence within ten (10) days of the date of
- response. All reasonable requests for non-privileged information
- reasonably related to the dispute shall be honored. If the
- dispute is not resolved within thirty (30) days of commencement
- of the procedure either Participant may proceed to mediation or
- arbitration pursuant to the rules set forth in (b) or (c) below.
-
- (b) If the dispute has not been resolved pursuant to (a) above or,
- if the disputing Participants fail to commence informal dispute
- resolution pursuant to (a) above, either Participant may, in
- writing and within twenty (20) days of the response date noted
- in (a) above, ask the other Participant to participate in a one
- (1) day mediation with an impartial mediator, and the other
- Participant shall do so. Each Participant will bear its own
- expenses and an equal share of the fees of the mediator. If the
- mediation is not successful the Participants may proceed with
- arbitration pursuant to (c) below.
-
- (c) If the dispute has not been resolved pursuant to (a) or (b)
- above, the dispute shall be promptly referred, no later than one
- (1) year from the date of original notice and subject to
- applicable statute of limitations, to binding arbitration in
- accordance with the UNCITRAL Arbitration Rules in effect on the
- date of this contract. The appointing authority shall be the
- International Centre for Dispute Resolution. The case shall be
- administered by the International Centre for Dispute Resolution
- under its Procedures for Cases under the UNCITRAL Arbitration
- Rules. Each Participant shall bear its own expenses and shall
- share equally in fees of the arbitrator. All arbitrators shall
- have substantial experience in information technology and/or in
- the telecommunications business and shall be selected by the
- disputing participants in accordance with UNCITRAL Arbitration
- Rules. If any arbitrator, once selected is unable or unwilling
- to continue for any reason, replacement shall be filled via the
- process described above and a re-hearing shall be conducted. The
- disputing Participants will provide each other with all
- requested documents and records reasonably related to the
- dispute in a manner that will minimize the expense and
- inconvenience of both parties. Discovery will not include
- depositions or interrogatories except as the arbitrators
- expressly allow upon a showing of need. If disputes arise
- concerning discovery requests, the arbitrators shall have sole
- and complete discretion to resolve the disputes. The parties and
- arbitrator shall be guided in resolving discovery disputes by
- the Federal Rules of Civil Procedure. The Participants agree
- that time of the essence principles shall guide the hearing and
- that the arbitrator shall have the right and authority to issue
- monetary sanctions in the event of unreasonable delay. The
- arbitrator shall deliver a written opinion setting forth
- findings of fact and the rationale for the award within thirty
- (30) days following conclusion of the hearing. The award of the
- arbitrator, which may include legal and equitable relief, but
- which may not include punitive damages, will be final and
- binding upon the disputing Participants, and judgment may be
- entered upon it in accordance with applicable law in any court
- having jurisdiction thereof. In addition to award the
- arbitrator shall have the discretion to award the prevailing
- Participant all or part of its attorneys' fees and costs,
- including fees associated with arbitrator, if the arbitrator
- determines that the positions taken by the other Participant on
- material issues of the dispute were without substantial
- foundation. Any conflict between the UNCITRAL Arbitration Rules
- and the provisions of this GPA shall be controlled by this GPA.
-
- 21. INTEGRATED AGREEMENT. This GPA, constitutes the complete
-integrated agreement between the parties concerning the subject matter
-hereof. All prior and contemporaneous agreements, understandings,
-negotiations or representations, whether oral or in writing, relating to
-the subject matter of this GPA are superseded and canceled in their
-entirety.
-
- 22. WAIVER. No waiver of any of the provisions of this GPA shall be
-deemed or shall constitute a waiver of any other provision of this GPA,
-whether or not similar, nor shall such waiver constitute a continuing
-waiver unless otherwise expressly so provided in writing. The failure
-of either party to enforce at any time any of the provisions of this
-GPA, or the failure to require at any time performance by either party
-of any of the provisions of this GPA, shall in no way be construed to be
-a present or future waiver of such provisions, nor in any way affect the
-ability of a Participant to enforce each and every such provision
-thereafter.
-
- 23. INDEPENDENT CONTRACTORS. Nothing in this GPA shall make the
-Parties partners, joint venturers, or otherwise associated in or with
-the business of the other. Parties are, and shall always remain,
-independent contractors. No Participant shall be liable for any debts,
-accounts, obligations, or other liabilities of the other Participant,
-its agents or employees. No party is authorized to incur debts or other
-obligations of any kind on the part of or as agent for the other. This
-GPA is not a franchise agreement and does not create a franchise
-relationship between the parties, and if any provision of this GPA is
-deemed to create a franchise between the parties, then this GPA shall
-automatically terminate.
-
- 24. CAPTIONS AND HEADINGS. The captions and headings used in this GPA
-are used for convenience only and are not to be given any legal effect.
-
- 25. EXECUTION. This GPA may be executed in counterparts, each of which
-so executed will be deemed to be an original and such counterparts
-together will constitute one and the same Agreement. The Parties shall
-transmit to each other a signed copy of the GPA by any means that
-faithfully reproduces the GPA along with the Signature. For purposes of
-this GPA, the term "signature" shall include digital signatures as
-defined by the jurisdiction of the Participant signing the GPA.
-
- Exhibit A
-
-Weight Range Requirements
-
-0-99 May only be used under authorization of Owner
-
-100-199 May only be used by the Owner's service
- provider, regardless of authorization.
-
-200-299 Reserved -- do not use for e164 context.
-
-300-399 May only be used by the owner of the code under
- which the Owner's number is a part of.
-
-400-499 May be used by any entity providing access via
- direct connectivity to the Public Switched
- Telephone Network.
-
-500-599 May be used by any entity providing access via
- indirect connectivity to the Public Switched
- Telephone Network (e.g. Via another VoIP
- provider)
-
-600- Reserved-- do not use for e164 context.
-
- Participant Participant
-
-Company:
-
-Address:
-
-Email:
-
-
- _________________________ _________________________
- Authorized Signature Authorized Signature
-
-Name:
-
-
-END OF GENERAL PEERING AGREEMENT
-
-------------------------------------------------
-
-How to Peer using this GPA If you wish to exchange routing information
-with parties using the e164 DUNDi context, all you must do is execute
-this GPA with any member of the Peering System and you will become a
-member of the Peering System and be able to make Routes available in
-accordance with this GPA.
-
-DUNDi, IAX, Asterisk and GPA are trademarks of Digium, Inc.
-
-\end{verbatim}
--- /dev/null
+The vast majority of the Asterisk project documentation has been moved to the
+project wiki:
+
+ http://wiki.asterisk.org/
+
+Asterisk release tarballs contain an export of the wiki in PDF and plain text
+form, which you can find in:
+
+ doc/AST.pdf
+ doc/AST.txt
+++ /dev/null
-================
-Advice of Charge
-================
-
-Written by: David Vossel
-Initial version: 04-19-2010
-Email: dvossel@digium.com
-
-This document is designed to give an overview of how to configure and
-generate Advice of Charge along with a detailed explanation of how each
-option works.
-
---------------------------------------
-| READ THIS FIRST |
---------------------------------------
-PLEASE REPORT ANY ISSUES ENCOUNTERED WHILE USING AOC. This feature
-has had very little community feedback so far. If you are using this
-feature please share with us any problems you are having and any
-improvements that could make this feature more useful. Thank you!
-
---------------------------------------
-| Terminology |
---------------------------------------
-AOC: Advice of Charge
-
-AOC-S: Advice of Charge message sent at the beginning of a call during
-call setup. This message contains a list of rates associated with the
-call.
-
-AOC-D: Advice of Charge message sent during the call. This message
-is typically used to update the endpoint with the current call charge.
-
-AOC-E: Advice of Charge message sent at the end of a call. This
-message is used to indicate to the endpoint the final call charge.
-
-AMI: Asterisk Manager Interface. This interface is used to generate
-AOC messages and listen for AOC events.
-
---------------------------------------
-| AOC in chan_dahdi |
---------------------------------------
------ LibPRI Support:
-ETSI, or euroisdn, is the only switchtype that LibPRI currently supports
-for AOC.
-
------ Enable AOC Pass-through in chan_dahdi
-To enable AOC pass-through between the ISDN and Asterisk use the
-'aoc_enable' config option. This option allows for any combination
-of AOC-S, AOC-D, and AOC-E to be enabled or disabled.
-
-For example:
-aoc_enable=s,d,e ; enables pass-through of AOC-S, AOC-D, and AOC-E
-
-aoc_enable=s,d ; enables pass-through of AOC-S and AOC-D. Rejects
- ; AOC-E and AOC-E request messages
-
-Since AOC messages are often transported on facility messages, the
-'facilityenable' option must be enabled as well to fully support AOC
-pass-through.
-
------ Handling AOC-E in chan_dahdi
-Whenever a dahdi channel receives an AOC-E message from Asterisk, it
-stores that message to deliver it at the appropriate time during call
-termination. This means that if two AOC-E messages are received on the
-same call, the last one will override the first one and only one AOC-E
-message will be sent during call termination.
-
-There are some tricky situations involving the final AOC-E message. During
-a bridged call, if the endpoint receiving the AOC messages terminates
-the call before the endpoint delivering the AOC does, the final AOC-E
-message sent by the sending side during termination will never make it to
-the receiving end because Asterisk will have already torn down that channel.
-This is where the chan_dahdi.conf 'aoce_delayhangup' option comes into play.
-
-By enabling 'aoce_delayhangup', anytime a hangup is initiated by the
-ISDN side of an Asterisk channel, instead of hanging up the channel,
-the channel sends a unique internal AOC-E termination request to its bridge
-channel. This indicates it is about to hangup and wishes to receive the
-final AOC-E message from the bridged channel before completely tearing
-down. If the bridged channel knows what to do with this AOC-E termination
-request, it will do whatever is necessary to indicate to its endpoint that
-the call is being terminated without actually hanging up the Asterisk channel.
-This allows the final AOC-E message to come in and be sent across the bridge
-while both channels are still up. If the channel delaying its hangup for
-the final AOC-E message times out, the call will be torn down just as it
-normally would. In chan_dahdi the timeout period is 1/2 the T305 timer
-which by default is 15 seconds.
-
-'aoce_delayhangup' currently only works when both bridged channels are
-dahdi_channels. If a SIP channel receives an AOC-E termination request, it
-just responds by immediately hanging up the channel. Using this option when
-bridged to any channel technology besides SIP or DAHDI will result in the
-15 second timeout period before tearing down the call completely.
-
------ Requesting AOC services
-AOC can be requested on a call by call basis using the DAHDI dialstring
-option, A(). The A() option takes in 's', 'd', and 'e' parameters which
-represent the three types of AOC messages, AOC-S, AOC-D, and AOC-E. By using
-this option Asterisk will indicate to the endpoint during call setup that it
-wishes to receive the specified forms of AOC during the call.
-
-Example Usage in extensions.conf
-exten => 1111,1,Dial(DAHDI/g1/1112/A(s,d,e) ; requests AOC-S, AOC-D, and AOC-E on
- ; call setup
-exten => 1111,1,Dial(DAHDI/g1/1112/A(d,e) ; requests only AOC-D, and AOC-E on
- ; call setup
-
---------------------------------------
-| AOC in chan_sip |
---------------------------------------
-Asterisk supports a very basic way of sending AOC on a SIP channel to Snom
-phones using an AOC specification designed by Snom. This support is limited
-to the sending of AOC-D and AOC-E pass-through messages. No support for
-AOC-E on call termination is present, so if the Snom endpoint receiving the
-AOC messages from Asterisk terminates the call, the channel will be torn
-down before the phone can receive the final AOC-E message.
-
-To enable passthrough of AOC messages via the snom specification, use
-the 'snom_aoc_enabled' option in sip.conf.
-
---------------------------------------
-| Generate AOC Messages via AMI |
---------------------------------------
-Asterisk supports a way to generate AOC messages on a channel via
-the AMI action AOCMessage. At the moment the AOCMessage action is limited
-to AOC-D and AOC-E message generation. There are some limitations
-involved with delivering the final AOC-E message as well. The AOCMessage
-action has its own detailed parameter documentation so this discussion will
-focus on higher level use. When generating AOC messages on a Dahdi channel
-first make sure the appropriate chan_dahdi.conf options are enabled. Without
-enabling 'aoc_enable' correctly for pass-through the AOC messages will never
-make it out the pri. The same goes with SIP, the 'snom_aoc_enabled' option
-must be configured before messages can successfully be set to the endpoint.
-
------ AOC-D Message Generation
-AOC-D message generation can happen anytime throughout the call. This
-message type is very straight forward.
-
-Example: AOCMessage action generating AOC-D currency message with Success
-response.
-
-Action: AOCMessage
-Channel: DAHDI/i1/1111-1
-MsgType: d
-ChargeType: Currency
-CurrencyAmount: 16
-CurrencyName: USD
-CurrencyMultiplier: OneThousandth
-AOCBillingId: Normal
-ActionID: 1234
-
-Response: Success
-ActionID: 1234
-Message: AOC Message successfully queued on channel
-
------ AOC-E Message Generation
-AOC-E messages are sent during call termination and represent the final charge
-total for the call. Since Asterisk call termination results in the channel
-being destroyed, it is currently not possible for the AOCMessage AMI action to
-be used to send the final AOC-E message on call hangup. There is however a
-work around for this issue that can be used for Dahdi channels. By default
-chan_dahdi saves any AOC-E message it receives from Asterisk during a call and
-waits to deliver that message during call termination. If multiple AOC-E messages
-are received from Asterisk on the same Dahdi channel, only the last message received
-is stored for delivery. This means that each new AOC-E message received on the
-channel overrides the previous one. Knowing this the final AOC-E message can be
-continually updated on a Dahdi channel until call termination occurs allowing
-the last update to be sent on hangup. This method is only as accurate as the
-intervals in which it is updated, but allows some form of AOC-E to be generated.
-
-Example: AOCMessage action generating AOC-E unit message with Success response.
-
-Action: AOCMessage
-Channel: DAHDI/i1/1111-1
-MsgType: e
-ChargeType: Unit
-UnitAmount(0): 111
-UnitType(0): 6
-UnitAmount(1): 222
-UnitType(1): 5
-UnitAmount(2): 333
-UnitType(3): 4
-UnitAmount(4): 444
-AOCBillingId: Normal
-ActionID: 1234
-
-Response: Success
-ActionID: 1234
-Message: AOC Message successfully queued on channel
+++ /dev/null
-ASTERISK-MIB DEFINITIONS ::= BEGIN
-
-IMPORTS
- OBJECT-TYPE, MODULE-IDENTITY, Integer32, Counter32, TimeTicks,
- Unsigned32, Gauge32
- FROM SNMPv2-SMI
-
- TEXTUAL-CONVENTION, DisplayString, TruthValue
- FROM SNMPv2-TC
-
- digium
- FROM DIGIUM-MIB;
-
-asterisk MODULE-IDENTITY
- LAST-UPDATED "200806202025Z"
- ORGANIZATION "Digium, Inc."
- CONTACT-INFO
- "Mark A. Spencer
- Postal: Digium, Inc.
- 445 Jan Davis Drive
- Huntsville, AL 35806
- USA
- Tel: +1 256 428 6000
- Email: markster@digium.com
-
- Thorsten Lockert
- Postal: Voop AS
- Boehmergaten 42
- NO-5057 Bergen
- Norway
- Tel: +47 5598 7200
- Email: tholo@voop.no"
- DESCRIPTION
- "Asterisk is an Open Source PBX. This MIB defined
- objects for managing Asterisk instances."
- REVISION "200806202025Z"
- DESCRIPTION
- "smilint police --
- Add missing imports; fix initial capitalization
- of enumeration elements; add missing range
- restrictions for Integer32 indices, correct
- spelling of astChanCidANI in its definition.
- Addresses bug 12905. - jeffg@opennms.org"
- REVISION "200708211450Z"
- DESCRIPTION
- "Add total and current call counter statistics."
- REVISION "200603061840Z"
- DESCRIPTION
- "Change audio codec identification from 3kAudio to
- Audio3k to conform better with specification.
-
- Expand on contact information."
- REVISION "200602041900Z"
- DESCRIPTION
- "Initial published revision."
- ::= { digium 1 }
-
-asteriskVersion OBJECT IDENTIFIER ::= { asterisk 1 }
-asteriskConfiguration OBJECT IDENTIFIER ::= { asterisk 2 }
-asteriskModules OBJECT IDENTIFIER ::= { asterisk 3 }
-asteriskIndications OBJECT IDENTIFIER ::= { asterisk 4 }
-asteriskChannels OBJECT IDENTIFIER ::= { asterisk 5 }
-
--- asteriskVersion
-
-astVersionString OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Text version string of the version of Asterisk that
- the SNMP Agent was compiled to run against."
- ::= { asteriskVersion 1 }
-
-astVersionTag OBJECT-TYPE
- SYNTAX Unsigned32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "SubVersion revision of the version of Asterisk that
- the SNMP Agent was compiled to run against -- this is
- typically 0 for release-versions of Asterisk."
- ::= { asteriskVersion 2 }
-
--- asteriskConfiguration
-
-astConfigUpTime OBJECT-TYPE
- SYNTAX TimeTicks
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Time ticks since Asterisk was started."
- ::= { asteriskConfiguration 1 }
-
-astConfigReloadTime OBJECT-TYPE
- SYNTAX TimeTicks
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Time ticks since Asterisk was last reloaded."
- ::= { asteriskConfiguration 2 }
-
-astConfigPid OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The process id of the running Asterisk process."
- ::= { asteriskConfiguration 3 }
-
-astConfigSocket OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The control socket for giving Asterisk commands."
- ::= { asteriskConfiguration 4 }
-
-astConfigCallsActive OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of calls currently active on the Asterisk PBX."
- ::= { asteriskConfiguration 5 }
-
-astConfigCallsProcessed OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of calls processed through the Asterisk PBX since last
- restart."
- ::= { asteriskConfiguration 6 }
-
--- asteriskModules
-
-astNumModules OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of modules currently loaded into Asterisk."
- ::= { asteriskModules 1 }
-
--- asteriskIndications
-
-astNumIndications OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of indications currently defined in Asterisk."
- ::= { asteriskIndications 1 }
-
-astCurrentIndication OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Default indication zone to use."
- ::= { asteriskIndications 2 }
-
-astIndicationsTable OBJECT-TYPE
- SYNTAX SEQUENCE OF AstIndicationsEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table with all the indication zones currently know to
- the running Asterisk instance."
- ::= { asteriskIndications 3 }
-
-astIndicationsEntry OBJECT-TYPE
- SYNTAX AstIndicationsEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Information about a single indication zone."
- INDEX { astIndIndex }
- ::= { astIndicationsTable 1 }
-
-AstIndicationsEntry ::= SEQUENCE {
- astIndIndex Integer32,
- astIndCountry DisplayString,
- astIndAlias DisplayString,
- astIndDescription DisplayString
-}
-
-astIndIndex OBJECT-TYPE
- SYNTAX Integer32 (1 .. 2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Numerical index into the table of indication zones."
- ::= { astIndicationsEntry 1 }
-
-astIndCountry OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Country for which the indication zone is valid,
- typically this is the ISO 2-letter code of the country."
- ::= { astIndicationsEntry 2 }
-
-astIndAlias OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- ""
- ::= { astIndicationsEntry 3 }
-
-astIndDescription OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Description of the indication zone, usually the full
- name of the country it is valid for."
- ::= { astIndicationsEntry 4 }
-
--- asteriskChannels
-
-astNumChannels OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Current number of active channels."
- ::= { asteriskChannels 1 }
-
-astChanTable OBJECT-TYPE
- SYNTAX SEQUENCE OF AstChanEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table with details of the currently active channels
- in the Asterisk instance."
- ::= { asteriskChannels 2 }
-
-astChanEntry OBJECT-TYPE
- SYNTAX AstChanEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Details of a single channel."
- INDEX { astChanIndex }
- ::= { astChanTable 1 }
-
-AstChanEntry ::= SEQUENCE {
- astChanIndex Integer32,
- astChanName DisplayString,
- astChanLanguage DisplayString,
- astChanType DisplayString,
- astChanMusicClass DisplayString,
- astChanBridge DisplayString,
- astChanMasq DisplayString,
- astChanMasqr DisplayString,
- astChanWhenHangup TimeTicks,
- astChanApp DisplayString,
- astChanData DisplayString,
- astChanContext DisplayString,
- astChanMacroContext DisplayString,
- astChanMacroExten DisplayString,
- astChanMacroPri Integer32,
- astChanExten DisplayString,
- astChanPri Integer32,
- astChanAccountCode DisplayString,
- astChanForwardTo DisplayString,
- astChanUniqueId DisplayString,
- astChanCallGroup Unsigned32,
- astChanPickupGroup Unsigned32,
- astChanState INTEGER,
- astChanMuted TruthValue,
- astChanRings Integer32,
- astChanCidDNID DisplayString,
- astChanCidNum DisplayString,
- astChanCidName DisplayString,
- astChanCidANI DisplayString,
- astChanCidRDNIS DisplayString,
- astChanCidPresentation DisplayString,
- astChanCidANI2 Integer32,
- astChanCidTON Integer32,
- astChanCidTNS Integer32,
- astChanAMAFlags INTEGER,
- astChanADSI INTEGER,
- astChanToneZone DisplayString,
- astChanHangupCause INTEGER,
- astChanVariables DisplayString,
- astChanFlags BITS,
- astChanTransferCap INTEGER
-}
-
-astChanIndex OBJECT-TYPE
- SYNTAX Integer32 (1 .. 2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Index into the channel table."
- ::= { astChanEntry 1 }
-
-astChanName OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Name of the current channel."
- ::= { astChanEntry 2 }
-
-astChanLanguage OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Which language the current channel is configured to
- use -- used mainly for prompts."
- ::= { astChanEntry 3 }
-
-astChanType OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Underlying technology for the current channel."
- ::= { astChanEntry 4 }
-
-astChanMusicClass OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Music class to be used for Music on Hold for this
- channel."
- ::= { astChanEntry 5 }
-
-astChanBridge OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Which channel this channel is currently bridged (in a
- conversation) with."
- ::= { astChanEntry 6 }
-
-astChanMasq OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Channel masquerading for us."
- ::= { astChanEntry 7 }
-
-astChanMasqr OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Channel we are masquerading for."
- ::= { astChanEntry 8 }
-
-astChanWhenHangup OBJECT-TYPE
- SYNTAX TimeTicks
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "How long until this channel will be hung up."
- ::= { astChanEntry 9 }
-
-astChanApp OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Current application for the channel."
- ::= { astChanEntry 10 }
-
-astChanData OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Arguments passed to the current application."
- ::= { astChanEntry 11 }
-
-astChanContext OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Current extension context."
- ::= { astChanEntry 12 }
-
-astChanMacroContext OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Current macro context."
- ::= { astChanEntry 13 }
-
-astChanMacroExten OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Current macro extension."
- ::= { astChanEntry 14 }
-
-astChanMacroPri OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Current macro priority."
- ::= { astChanEntry 15 }
-
-astChanExten OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Current extension."
- ::= { astChanEntry 16 }
-
-astChanPri OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Current priority."
- ::= { astChanEntry 17 }
-
-astChanAccountCode OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Account Code for billing."
- ::= { astChanEntry 18 }
-
-astChanForwardTo OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Where to forward to if asked to dial on this
- interface."
- ::= { astChanEntry 19 }
-
-astChanUniqueId OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Unique Channel Identifier."
- ::= { astChanEntry 20 }
-
-astChanCallGroup OBJECT-TYPE
- SYNTAX Unsigned32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Call Group."
- ::= { astChanEntry 21 }
-
-astChanPickupGroup OBJECT-TYPE
- SYNTAX Unsigned32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Pickup Group."
- ::= { astChanEntry 22 }
-
-astChanState OBJECT-TYPE
- SYNTAX INTEGER {
- stateDown(0),
- stateReserved(1),
- stateOffHook(2),
- stateDialing(3),
- stateRing(4),
- stateRinging(5),
- stateUp(6),
- stateBusy(7),
- stateDialingOffHook(8),
- statePreRing(9)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Channel state."
- ::= { astChanEntry 23 }
-
-astChanMuted OBJECT-TYPE
- SYNTAX TruthValue
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Transmission of voice data has been muted."
- ::= { astChanEntry 24 }
-
-astChanRings OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of rings so far."
- ::= { astChanEntry 25 }
-
-astChanCidDNID OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Dialled Number ID."
- ::= { astChanEntry 26 }
-
-astChanCidNum OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Caller Number."
- ::= { astChanEntry 27 }
-
-astChanCidName OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Caller Name."
- ::= { astChanEntry 28 }
-
-astChanCidANI OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "ANI"
- ::= { astChanEntry 29 }
-
-astChanCidRDNIS OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Redirected Dialled Number Service."
- ::= { astChanEntry 30 }
-
-astChanCidPresentation OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number Presentation/Screening."
- ::= { astChanEntry 31 }
-
-astChanCidANI2 OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "ANI 2 (info digit)."
- ::= { astChanEntry 32 }
-
-astChanCidTON OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Type of Number."
- ::= { astChanEntry 33 }
-
-astChanCidTNS OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Transit Network Select."
- ::= { astChanEntry 34 }
-
-astChanAMAFlags OBJECT-TYPE
- SYNTAX INTEGER {
- default(0),
- omit(1),
- billing(2),
- documentation(3)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "AMA Flags."
- ::= { astChanEntry 35 }
-
-astChanADSI OBJECT-TYPE
- SYNTAX INTEGER {
- unknown(0),
- available(1),
- unavailable(2),
- offHookOnly(3)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Whether or not ADSI is detected on CPE."
- ::= { astChanEntry 36 }
-
-astChanToneZone OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Indication zone to use for channel."
- ::= { astChanEntry 37 }
-
-astChanHangupCause OBJECT-TYPE
- SYNTAX INTEGER {
- notDefined(0),
- unregistered(3),
- normal(16),
- busy(17),
- noAnswer(19),
- congestion(34),
- failure(38),
- noSuchDriver(66)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Why is the channel hung up."
- ::= { astChanEntry 38 }
-
-astChanVariables OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Channel Variables defined for this channel."
- ::= { astChanEntry 39 }
-
-astChanFlags OBJECT-TYPE
- SYNTAX BITS {
- wantsJitter(0),
- deferDTMF(1),
- writeInterrupt(2),
- blocking(3),
- zombie(4),
- exception(5),
- musicOnHold(6),
- spying(7),
- nativeBridge(8),
- autoIncrementingLoop(9)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Flags set on this channel."
- ::= { astChanEntry 40 }
-
-astChanTransferCap OBJECT-TYPE
- SYNTAX INTEGER {
- speech(0),
- digital(8),
- restrictedDigital(9),
- audio3k(16),
- digitalWithTones(17),
- video(24)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Transfer Capabilities for this channel."
- ::= { astChanEntry 41 }
-
-astNumChanTypes OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of channel types (technologies) supported."
- ::= { asteriskChannels 3 }
-
-astChanTypeTable OBJECT-TYPE
- SYNTAX SEQUENCE OF AstChanTypeEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table with details of the supported channel types."
- ::= { asteriskChannels 4 }
-
-astChanTypeEntry OBJECT-TYPE
- SYNTAX AstChanTypeEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Information about a technology we support, including
- how many channels are currently using this technology."
- INDEX { astChanTypeIndex }
- ::= { astChanTypeTable 1 }
-
-AstChanTypeEntry ::= SEQUENCE {
- astChanTypeIndex Integer32,
- astChanTypeName DisplayString,
- astChanTypeDesc DisplayString,
- astChanTypeDeviceState Integer32,
- astChanTypeIndications Integer32,
- astChanTypeTransfer Integer32,
- astChanTypeChannels Gauge32
-}
-
-astChanTypeIndex OBJECT-TYPE
- SYNTAX Integer32 (1 .. 2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Index into the table of channel types."
- ::= { astChanTypeEntry 1 }
-
-astChanTypeName OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Unique name of the technology we are describing."
- ::= { astChanTypeEntry 2 }
-
-astChanTypeDesc OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Description of the channel type (technology)."
- ::= { astChanTypeEntry 3 }
-
-astChanTypeDeviceState OBJECT-TYPE
- SYNTAX TruthValue
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Whether the current technology can hold device states."
- ::= { astChanTypeEntry 4 }
-
-astChanTypeIndications OBJECT-TYPE
- SYNTAX TruthValue
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Whether the current technology supports progress indication."
- ::= { astChanTypeEntry 5 }
-
-astChanTypeTransfer OBJECT-TYPE
- SYNTAX TruthValue
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Whether the current technology supports transfers, where
- Asterisk can get out from inbetween two bridged channels."
- ::= { astChanTypeEntry 6 }
-
-astChanTypeChannels OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of active channels using the current technology."
- ::= { astChanTypeEntry 7 }
-
-astChanScalars OBJECT IDENTIFIER ::= { asteriskChannels 5 }
-
-astNumChanBridge OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Number of channels currently in a bridged state."
- ::= { astChanScalars 1 }
-
-END
+++ /dev/null
-===============================================================================
-===
-=== Collecting Backtrace Information
-===
-=== Last updated: 2010-04-12
-===============================================================================
-
-This document is intended to provide information on how to obtain the
-backtraces required on the asterisk bug tracker, available at
-https://issues.asterisk.org.
-
--------------------------------------------------------------------------------
---- Overview
--------------------------------------------------------------------------------
-
-The backtrace information is required by developers to help fix problem with
-bugs of any kind. Backtraces provide information about what was wrong when a
-program crashed; in our case, Asterisk.
-
--------------------------------------------------------------------------------
---- Preparing Asterisk To Produce Core Files On Crash
--------------------------------------------------------------------------------
-
-First of all, when you start Asterisk, you MUST start it with option
--g. This tells Asterisk to produce a core file if it crashes.
-
-If you start Asterisk with the safe_asterisk script, it automatically
-starts using the option -g.
-
-If you're not sure if Asterisk is running with the -g option, type the
-following command in your shell:
-
-debian:/tmp# ps aux | grep asterisk
-root 17832 0.0 1.2 2348 788 pts/1 S Aug12 0:00 /bin/sh /usr/sbin/safe_asterisk
-root 26686 0.0 2.8 15544 1744 pts/1 S Aug13 0:02 asterisk -vvvg -c
-[...]
-
-The interesting information is located in the last column.
-
-Second, your copy of Asterisk must have been built without
-optimization or the backtrace will be (nearly) unusable. This can be
-done by selecting the 'DONT_OPTIMIZE' option in the Compiler Flags
-submenu in the 'make menuselect' tree before building Asterisk.
-
-Running a production server with DONT_OPTIMIZE is generally safe.
-You'll notice the binary files may be a bit larger, but in terms of
-Asterisk performance, and impact should be negligible.
-
-After Asterisk crashes, a core file will be "dumped" in your /tmp/
-directory. To make sure it's really there, you can just type the
-following command in your shell:
-
-debian:/tmp# ls -l /tmp/core.*
--rw------- 1 root root 10592256 Aug 12 19:40 /tmp/core.26252
--rw------- 1 root root 9924608 Aug 12 20:12 /tmp/core.26340
--rw------- 1 root root 10862592 Aug 12 20:14 /tmp/core.26374
--rw------- 1 root root 9105408 Aug 12 20:19 /tmp/core.26426
--rw------- 1 root root 9441280 Aug 12 20:20 /tmp/core.26462
--rw------- 1 root root 8331264 Aug 13 00:32 /tmp/core.26647
-debian:/tmp#
-
-In the event that there are multiple core files present (as in the
-above example), it is important to look at the file timestamps in
-order to determine which one you really intend to look at.
-
--------------------------------------------------------------------------------
---- Getting Information After A Crash
--------------------------------------------------------------------------------
-
-There are two kind of backtraces (aka 'bt') which are useful: bt and bt full.
-
-Now that we've verified the core file has been written to disk, the final part
-is to extract 'bt' from the core file. Core files are pretty big, don't be
-scared, it's normal.
-
-******************************************************************************
-*** NOTE: Don't attach core files on the bug tracker as they are only useful *
-*** on the machine they were generated on. We only need the output of *
-*** the 'bt' and 'bt full.' *
-******************************************************************************
-
-For extraction, we use a really nice tool, called gdb. To verify that
-you have gdb installed on your system:
-
-debian:/tmp# gdb -v
-GNU gdb 6.3-debian
-Copyright 2004 Free Software Foundation, Inc.
-GDB is free software, covered by the GNU General Public License, and you are
-welcome to change it and/or distribute copies of it under certain conditions.
-Type "show copying" to see the conditions.
-There is absolutely no warranty for GDB. Type "show warranty" for details.
-This GDB was configured as "i386-linux".
-debian:/tmp#
-
-If you don't have gdb installed, go install gdb. You should be able to install
-using something like: apt-get install gdb --or-- yum install gdb
-
-Now load the core file in gdb with the following command. This will also save
-the output of gdb to the /tmp/backtract.txt file.
-
-# gdb -se "asterisk" -c /tmp/core.26252 | tee /tmp/backtrace.txt
-
-******************************************************************************
-*** TIP!
-*** Just run the following command to get the output into the
-*** backtrace.txt file, ready for uploading to the issue tracker. Be sure
-*** to change the name of the core file to your actual core dump file:
-***
-*** gdb -se "asterisk" -ex "bt full" -ex "thread apply all bt" --batch -c /tmp/core.26252 > /tmp/backtrace.txt
-***
-******************************************************************************
-
-
-[...]
-(You would see a lot of output here.)
-[...]
-Reading symbols from /usr/lib/asterisk/modules/app_externalivr.so...done.
-Loaded symbols for /usr/lib/asterisk/modules/app_externalivr.so
-#0 0x29b45d7e in ?? ()
-(gdb)
-
-In order to make extracting the gdb output easier, you may wish to
-turn on logging using "set logging on". This command will save all
-output to the default file of gdb.txt, which in the end can be
-uploaded as an attachment to the bug tracker.
-
-Now at the gdb prompt, type: bt
-You would see output similar to:
-
-(gdb) bt
-#0 0x29b45d7e in ?? ()
-#1 0x08180bf8 in ?? ()
-#2 0xbcdffa58 in ?? ()
-#3 0x08180bf8 in ?? ()
-#4 0xbcdffa60 in ?? ()
-#5 0x08180bf8 in ?? ()
-#6 0x180bf894 in ?? ()
-#7 0x0bf80008 in ?? ()
-#8 0x180b0818 in ?? ()
-#9 0x08068008 in ast_stopstream (tmp=0x40758d38) at file.c:180
-#10 0x000000a0 in ?? ()
-#11 0x000000a0 in ?? ()
-#12 0x00000000 in ?? ()
-#13 0x407513c3 in confcall_careful_stream (conf=0x8180bf8, filename=0x8181de8 "DAHDI/pseudo-1324221520") at app_meetme.c:262
-#14 0x40751332 in streamconfthread (args=0x8180bf8) at app_meetme.c:1965
-#15 0xbcdffbe0 in ?? ()
-#16 0x40028e51 in pthread_start_thread () from /lib/libpthread.so.0
-#17 0x401ec92a in clone () from /lib/libc.so.6
-(gdb)
-
-
-The bt's output is the information that we need on the bug tracker.
-
-Now do a bt full as follows:
-
-(gdb) bt full
-#0 0x29b45d7e in ?? ()
-No symbol table info available.
-#1 0x08180bf8 in ?? ()
-No symbol table info available.
-#2 0xbcdffa58 in ?? ()
-No symbol table info available.
-#3 0x08180bf8 in ?? ()
-No symbol table info available.
-#4 0xbcdffa60 in ?? ()
-No symbol table info available.
-#5 0x08180bf8 in ?? ()
-No symbol table info available.
-#6 0x180bf894 in ?? ()
-No symbol table info available.
-#7 0x0bf80008 in ?? ()
-No symbol table info available.
-#8 0x180b0818 in ?? ()
-No symbol table info available.
-#9 0x08068008 in ast_stopstream (tmp=0x40758d38) at file.c:180
-No locals.
-#10 0x000000a0 in ?? ()
-No symbol table info available.
-#11 0x000000a0 in ?? ()
-No symbol table info available.
-#12 0x00000000 in ?? ()
-No symbol table info available.
-#13 0x407513c3 in confcall_careful_stream (conf=0x8180bf8, filename=0x8181de8 "DAHDI/pseudo-1324221520") at app_meetme.c:262
- f = (struct ast_frame *) 0x8180bf8
- trans = (struct ast_trans_pvt *) 0x0
-#14 0x40751332 in streamconfthread (args=0x8180bf8) at app_meetme.c:1965
-No locals.
-#15 0xbcdffbe0 in ?? ()
-No symbol table info available.
-#16 0x40028e51 in pthread_start_thread () from /lib/libpthread.so.0
-No symbol table info available.
-#17 0x401ec92a in clone () from /lib/libc.so.6
-No symbol table info available.
-(gdb)
-
-The final "extraction" would be to know all traces by all threads. Even if
-Asterisk runs on the same thread for each call, it could have created some new
-threads.
-
-To make sure we have the correct information, just do:
-(gdb) thread apply all bt
-
-Thread 1 (process 26252):
-#0 0x29b45d7e in ?? ()
-#1 0x08180bf8 in ?? ()
-#2 0xbcdffa58 in ?? ()
-#3 0x08180bf8 in ?? ()
-#4 0xbcdffa60 in ?? ()
-#5 0x08180bf8 in ?? ()
-#6 0x180bf894 in ?? ()
-#7 0x0bf80008 in ?? ()
-#8 0x180b0818 in ?? ()
-#9 0x08068008 in ast_stopstream (tmp=0x40758d38) at file.c:180
-#10 0x000000a0 in ?? ()
-#11 0x000000a0 in ?? ()
-#12 0x00000000 in ?? ()
-#13 0x407513c3 in confcall_careful_stream (conf=0x8180bf8, filename=0x8181de8 "DAHDI/pseudo-1324221520") at app_meetme.c:262
-#14 0x40751332 in streamconfthread (args=0x8180bf8) at app_meetme.c:1965
-#15 0xbcdffbe0 in ?? ()
-#16 0x40028e51 in pthread_start_thread () from /lib/libpthread.so.0
-#17 0x401ec92a in clone () from /lib/libc.so.6
-(gdb)
-
-
-That output tells us crucial information about each thread.
-
--------------------------------------------------------------------------------
---- Getting Information For A Deadlock
--------------------------------------------------------------------------------
-
-Whenever supplying information about a deadlock (i.e. when you run the
-'core show locks' command on the Asterisk console), it is useful to also have
-additional information about the threads. We can generate this information by
-attaching to a running Asterisk process and gathering that information.
-
-You can easily attach to a running Asterisk process, gather the output required
-and then detach from the process all in a single step. Execute the following
-command and upload the resulting backtrace-threads.txt file to the Asterisk
-issue tracker:
-
- gdb -ex "thread apply all bt" --batch /usr/sbin/asterisk `pidof asterisk` > /tmp/backtrace-threads.txt
-
-Note that this gathers information from the running Asterisk process, so you
-want to make sure you run this command immediately before or after gathering
-the output of 'core show locks'. You can gather that information by running the
-following command:
-
- asterisk -rx "core show locks" > /tmp/core-show-locks.txt
-
--------------------------------------------------------------------------------
---- Verify Your Backtraces
--------------------------------------------------------------------------------
-
-Before uploading your backtraces to the issue tracker, you should double check
-to make sure the data you have is of use to the developers. Check your
-backtrace files to make sure you're not seeing several of the following:
-
- <value optimized out>
-
-If you are, then you likely haven't compiled with DONT_OPTIMIZE. The impact of
-DONT_OPTIMIZE is negligible on most systems. Be sure you've enabled the
-DONT_OPTIMIZE flag within the Compiler Flags section of menuselect. After
-doing so, be sure to run 'make install' and restart Asterisk.
-
--------------------------------------------------------------------------------
---- Uploading Your Information To The Issue Tracker
--------------------------------------------------------------------------------
-
-You're now ready to upload your files to the Asterisk issue tracker (located at
-https://issues.asterisk.org).
-
-******************************************************************************
-*** NOTE: Please ATTACH your output! DO NOT paste it as a note! *
-******************************************************************************
-
-If you have questions or comments regarding this documentation, feel free to
-pass by the #asterisk-bugs channel on irc.freenode.net.
+++ /dev/null
-=================
- Building Queues
-=================
-
-Written by: Leif Madsen
-Initial version: 2010-01-14
-
-In this article, we'll look at setting up a pair of queues in Asterisk called
-'sales' and 'support'. These queues can be logged into by queue members, and
-those members will also have the ability to pause and unpause themselves.
-
-All configuration will be done in flat files on the system in order to maintain
-simplicity in configuration.
-
-Note that this documentation is based on Asterisk 1.6.2, and this is just one
-approach to creating queues and the dialplan logic. You may create a better way,
-and in that case, I would encourage you to submit it to the Asterisk issue
-tracker at http://issues.asterisk.org for inclusion in Asterisk.
-
--------------------------------------
-| Adding SIP Devices to Your Server |
--------------------------------------
-
-The first thing we want to do is register a couple of SIP devices to our server.
-These devices will be our agents that can login and out of the queues we'll
-create later. Our naming convention will be to use MAC addresses as we want to
-abstract the concepts of user (agent), device, and extension from each other.
-
-In sip.conf, we add the following to the bottom of our file:
-
-sip.conf
---------
-
-[std-device](!)
-type=peer
-context=devices
-host=dynamic
-secret=s3CuR#p@s5
-dtmfmode=rfc2833
-disallow=all
-allow=ulaw
-
-[0004f2040001](std-device)
-
-[0004f2040002](std-device)
-
-
-
-What we're doing here is creating a [std-device] template and applying it to
-a pair of peers that we'll register as 0004f2040001 and 0004f2040002; our
-devices.
-
-Then our devices can register to Asterisk. In my case I have a hard phone and
-a soft phone registered. I can verify their connectivity by running 'sip show
-peers'.
-
-*CLI> sip show peers
-Name/username Host Dyn Nat ACL Port Status
-0004f2040001/0004f2040001 192.168.128.145 D 5060 Unmonitored
-0004f2040002/0004f2040002 192.168.128.126 D 5060 Unmonitored
-2 sip peers [Monitored: 0 online, 0 offline Unmonitored: 2 online, 0 offline]
-
-
-
-----------------------------
-| Configuring Device State |
-----------------------------
-
-Next, we need to configure our system to track the state of the devices. We do
-this by defining a 'hint' in the dialplan which creates the ability for a device
-subscription to be retained in memory. By default we can see there are no hints
-registered in our system by running the 'core show hints' command.
-
-*CLI> core show hints
-There are no registered dialplan hint
-
-
-We need to add the devices we're going to track to the extensions.conf file
-under the [default] context which is the default configuration in sip.conf,
-however we can change this to any context we want with the 'subscribecontext'
-option.
-
-Add the following lines to extensions.conf:
-
-[default]
-exten => 0004f2040001,hint,SIP/0004f2040001
-exten => 0004f2040002,hint,SIP/0004f2040002
-
-Then perform a 'dialplan reload' in order to reload the dialplan.
-
-After reloading our dialplan, you can see the status of the devices with 'core
-show hints' again.
-
-
-*CLI> core show hints
-
- -= Registered Asterisk Dial Plan Hints =-
- 0004f2040002@default : SIP/0004f2040002 State:Idle Watchers 0
- 0004f2040001@default : SIP/0004f2040001 State:Idle Watchers 0
-----------------
-- 2 hints registered
-
-
-At this point, create an extension that you can dial that will play a prompt
-that is long enough for you to go back to the Asterisk console to check the
-state of your device while it is in use.
-
-To do this, add the 555 extension to the [devices] context and make it playback
-the tt-monkeys file.
-
-
-extensions.conf
----------------
-
-[devices]
-exten => 555,1,Playback(tt-monkeys)
-
-
-Dial that extension and then check the state of your device on the console.
-
-*CLI> == Using SIP RTP CoS mark 5
- -- Executing [555@devices:1] Playback("SIP/0004f2040001-00000001", "tt-monkeys") in new stack
- -- <SIP/0004f2040001-00000001> Playing 'tt-monkeys.slin' (language 'en')
-
-*CLI> core show hints
-
- -= Registered Asterisk Dial Plan Hints =-
- 0004f2040002@default : SIP/0004f2040002 State:Idle Watchers 0
- 0004f2040001@default : SIP/0004f2040001 State:Idle Watchers 0
-----------------
-- 2 hints registered
-
-Aha, we're not getting the device state correctly. There must be something else
-we need to configure.
-
-In sip.conf, we need to enable 'callcounter' in order to activate the ability
-for Asterisk to monitor whether the device is in use or not. In versions prior
-to 1.6.0 we needed to use 'call-limit' for this functionality, but call-limit
-is now deprecated and is no longer necessary.
-
-So, in sip.conf, in our [std-device] template, we need to add the callcounter
-option.
-
-sip.conf
---------
-
-[std-device](!)
-type=peer
-context=devices
-host=dynamic
-secret=s3CuR#p@s5
-dtmfmode=rfc2833
-disallow=all
-allow=ulaw
-callcounter=yes ; <-- add this
-
-
-Then reload chan_sip with 'sip reload' and perform our 555 test again. Dial 555
-and then check the device state with 'core show hints'.
-
-*CLI> == Using SIP RTP CoS mark 5
- -- Executing [555@devices:1] Playback("SIP/0004f2040001-00000002", "tt-monkeys") in new stack
- -- <SIP/0004f2040001-00000002> Playing 'tt-monkeys.slin' (language 'en')
-
-*CLI> core show hints
-
- -= Registered Asterisk Dial Plan Hints =-
- 0004f2040002@default : SIP/0004f2040002 State:Idle Watchers 0
- 0004f2040001@default : SIP/0004f2040001 State:InUse Watchers 0
-----------------
-- 2 hints registered
-
-
-Note that now we have the correct device state when extension 555 is dialed,
-showing that our device is InUse after dialing extension 555. This is important
-when creating queues, otherwise our queue members would get multiple calls from
-the queues.
-
------------------------------
-| Adding Queues to Asterisk |
------------------------------
-
-The next step is to add a couple of queues to Asterisk that we can assign queue
-members into. For now we'll work with two queues; sales and support. Lets create
-those queues now in queues.conf.
-
-We'll leave the default settings that are shipped with queues.conf.sample in the
-[general] section of queues.conf. See the queues.conf.sample file for more
-information about each of the available options.
-
-queues.conf
------------
-
-[general]
-persistantmembers=yes
-autofill=yes
-monitor-type=MixMonitor
-shared_lastcall=no
-
-
-We can then define a [queue_template] that we'll assign to each of the queues
-we create. These definitions can be overridden by each queue individually if you
-reassign them under the [sales] or [support] headers. So under the [general]
-section of your queues.conf file, add the following.
-
-
-queues.conf
-----------
-
-[queue_template](!)
-musicclass=default ; play [default] music
-strategy=rrmemory ; use the Round Robin Memory strategy
-joinempty=yes ; join the queue when no members available
-leavewhenempty=no ; don't leave the queue no members available
-ringinuse=no ; don't ring members when already InUse
-
-[sales](queue_template)
-; Sales queue
-
-[support](queue_template)
-; Support queue
-
-
-
-After defining our queues, lets reload our app_queue.so module.
-
-
-*CLI> module reload app_queue.so
- -- Reloading module 'app_queue.so' (True Call Queueing)
-
- == Parsing '/etc/asterisk/queues.conf': == Found
-
-
-Then verify our queues loaded with 'queue show'.
-
-
-*CLI> queue show
-support has 0 calls (max unlimited) in 'rrmemory' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
- No Members
- No Callers
-
-sales has 0 calls (max unlimited) in 'rrmemory' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
- No Members
- No Callers
-
-
-
-------------------------
-| Adding Queue Members |
-------------------------
-
-You'll notice that we have no queue members available to take calls from the
-queues. We can add queue members from the Asterisk CLI with the 'queue add
-member' command.
-
-This is the format of the 'queue add member' command:
-
-Usage: queue add member <channel> to <queue> [[[penalty <penalty>] as <membername>] state_interface <interface>]
- Add a channel to a queue with optionally: a penalty, membername and a state_interface
-
-The penalty, membername, and state_interface are all optional values. Special
-attention should be brought to the 'state_interface' option for a member though.
-The reason for state_interface is that if you're using a channel that does not
-have device state itself (for example, if you were using the Local channel to
-deliver a call to an end point) then you could assign the device state of a SIP
-device to the pseudo channel. This allows the state of a SIP device to be
-applied to the Local channel for correct device state information.
-
-Lets add our device located at SIP/0004f2040001
-
-*CLI> queue add member SIP/0004f2040001 to sales
-Added interface 'SIP/0004f2040001' to queue 'sales'
-
-Then lets verify our member was indeed added.
-
-*CLI> queue show sales
-sales has 0 calls (max unlimited) in 'rrmemory' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
- Members:
- SIP/0004f2040001 (dynamic) (Not in use) has taken no calls yet
- No Callers
-
-Now, if we dial our 555 extension, we should see that our member becomes InUse
-within the queue.
-
-*CLI> == Using SIP RTP CoS mark 5
- -- Executing [555@devices:1] Playback("SIP/0004f2040001-00000001", "tt-monkeys") in new stack
- -- <SIP/0004f2040001-00000001> Playing 'tt-monkeys.slin' (language 'en')
-
-
-*CLI> queue show sales
-sales has 0 calls (max unlimited) in 'rrmemory' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
- Members:
- SIP/0004f2040001 (dynamic) (In use) has taken no calls yet
- No Callers
-
-We can also remove our members from the queue using the 'queue remove' CLI
-command.
-
-*CLI> queue remove member SIP/0004f2040001 from sales
-Removed interface 'SIP/0004f2040001' from queue 'sales'
-
-Because we don't want to have to add queue members manually from the CLI, we
-should create a method that allows queue members to login and out from their
-devices. We'll do that in the next section.
-
-But first, lets add an extension to our dialplan in order to permit people to
-dial into our queues so calls can be delivered to our queue members.
-
-extensions.conf
----------------
-
-[devices]
-exten => 555,1,Playback(tt-monkeys)
-
-exten => 100,1,Queue(sales)
-
-exten => 101,1,Queue(support)
-
-
-Then reload the dialplan, and try calling extension 100 from SIP/0004f2040002,
-which is the device we have not logged into the queue.
-
-*CLI> dialplan reload
-
-And now we call the queue at extension 100 which will ring our device at
-SIP/0004f2040001.
-
-*CLI> == Using SIP RTP CoS mark 5
- -- Executing [100@devices:1] Queue("SIP/0004f2040002-00000005", "sales") in new stack
- -- Started music on hold, class 'default', on SIP/0004f2040002-00000005
- == Using SIP RTP CoS mark 5
- -- SIP/0004f2040001-00000006 is ringing
-
-
-We can see the device state has changed to Ringing while the device is ringing.
-
-*CLI> queue show sales
-sales has 1 calls (max unlimited) in 'rrmemory' strategy (2s holdtime, 3s talktime), W:0, C:1, A:1, SL:0.0% within 0s
- Members:
- SIP/0004f2040001 (dynamic) (Ringing) has taken 1 calls (last was 14 secs ago)
- Callers:
- 1. SIP/0004f2040002-00000005 (wait: 0:03, prio: 0)
-
-
-Our queue member then answers the phone.
-
-*CLI> -- SIP/0004f2040001-00000006 answered SIP/0004f2040002-00000005
- -- Stopped music on hold on SIP/0004f2040002-00000005
- -- Native bridging SIP/0004f2040002-00000005 and SIP/0004f2040001-00000006
-
-
-And we can see the queue member is now in use.
-
-*CLI> queue show sales
-sales has 0 calls (max unlimited) in 'rrmemory' strategy (3s holdtime, 3s talktime), W:0, C:1, A:1, SL:0.0% within 0s
- Members:
- SIP/0004f2040001 (dynamic) (In use) has taken 1 calls (last was 22 secs ago)
- No Callers
-
-
-Then the call is hung up.
-
-*CLI> == Spawn extension (devices, 100, 1) exited non-zero on 'SIP/0004f2040002-00000005'
-
-
-And we see that our queue member is available to take another call.
-
-*CLI> queue show sales
-sales has 0 calls (max unlimited) in 'rrmemory' strategy (3s holdtime, 4s talktime), W:0, C:2, A:1, SL:0.0% within 0s
- Members:
- SIP/0004f2040001 (dynamic) (Not in use) has taken 2 calls (last was 6 secs ago)
- No Callers
-
---------------------------------
-| Logging In and Out of Queues |
---------------------------------
-
-In this section we'll show how to use the AddQueueMember() and
-RemoveQueueMember() dialplan applications to login and out of queues. For more
-information about the available options to AddQueueMember() and
-RemoveQueueMember() use the 'core show application <app>' command from the CLI.
-
-The following bit of dialplan is a bit long, but stick with it, and you'll see
-that it isn't really all that bad. The gist of the dialplan is that it will
-check to see if the active user (the device that is dialing the extension) is
-currently logged into the queue extension that has been requested, and if logged
-in, then will log them out; if not logged in, then they will be logged into the
-queue.
-
-We've updated the two lines we added in the previous section that allowed us to
-dial the sales and support queues. We've abstracted this out a bit in order to
-make it easier to add new queues in the future. This is done by adding the queue
-names to a global variable, then utilizing the extension number dialed to look
-up the queue name.
-
-So we replace extension 100 and 101 with the following dialplan.
-
-; Call any of the queues we've defined in the [globals] section.
-exten => _1XX,1,Verbose(2,Call queue as configured in the QUEUE_${EXTEN} global variable)
-exten => _1XX,n,Set(thisQueue=${GLOBAL(QUEUE_${EXTEN})})
-exten => _1XX,n,GotoIf($["${thisQueue}" = ""]?invalid_queue,1)
-exten => _1XX,n,Verbose(2, --> Entering the ${thisQueue} queue)
-exten => _1XX,n,Queue(${thisQueue})
-exten => _1XX,n,Hangup()
-
-exten => invalid_queue,1,Verbose(2,Attempted to enter invalid queue)
-exten => invalid_queue,n,Playback(silence/1&invalid)
-exten => invalid_queue,n,Hangup()
-
-The [globals] section contains the following two global variables.
-
-[globals]
-QUEUE_100=sales
-QUEUE_101=support
-
-So when we dial extension 100, it matches our pattern _1XX. The number we dialed
-(100) is then retrievable via ${EXTEN} and we can get the name of queue 100
-(sales) from the global variable QUEUE_100. We then assign it to the channel
-variable thisQueue so it is easier to work with in our dialplan.
-
-exten => _1XX,n,Set(thisQueue=${GLOBAL(QUEUE_${EXTEN})})
-
-We then check to see if we've gotten a value back from the global variable which
-would indicate whether the queue was valid or not.
-
-exten => _1XX,n,GotoIf($["${thisQueue}" = ""]?invalid_queue,1)
-
-If ${thisQueue} returns nothing, then we Goto the invalid_queue extension and
-playback the 'invalid' file.
-
-We could alternatively limit our pattern match to only extension 100 and 101
-with the _10[0-1] pattern instead.
-
-Lets move into the nitty-gritty section and show how we can login and logout our
-devices to the pair of queues we've created.
-
-First, we create a pattern match that takes star (*) plus the queue number
-that we want to login or logout of. So to login/out of the sales queue (100) we
-would dial *100. We use the same extension for logging in and out.
-
-; Extension *100 or *101 will login/logout a queue member from sales or support queues respectively.
-exten => _*10[0-1],1,Set(xtn=${EXTEN:1}) ; save ${EXTEN} with * chopped off to ${xtn}
-exten => _*10[0-1],n,Goto(queueLoginLogout,member_check,1) ; check if already logged into a queue
-
-We save the value of ${EXTEN:1} to the 'xtn' channel variable so we don't need
-to keep typing the complicated pattern match.
-
-Now we move into the meat of our login/out dialplan inside the
-[queueLoginLogout] context.
-
-The first section is initializing some variables that we need throughout the
-member_check extension such as the name of the queue, the members currently
-logged into the queue, and the current device peer name (i.e. SIP/0004f2040001).
-
-
-
-; ### Login or Logout a Queue Member
-[queueLoginLogout]
-exten => member_check,1,Verbose(2,Logging queue member in or out of the request queue)
-exten => member_check,n,Set(thisQueue=${GLOBAL(QUEUE_${xtn})}) ; assign queue name to a variable
-exten => member_check,n,Set(queueMembers=${QUEUE_MEMBER_LIST(${thisQueue})}) ; assign list of logged in members of thisQueue to
- ; a variable (comma separated)
-exten => member_check,n,Set(thisActiveMember=SIP/${CHANNEL(peername)}) ; initialize 'thisActiveMember' as current device
-
-exten => member_check,n,GotoIf($["${queueMembers}" = ""]?q_login,1) ; short circuit to logging in if we don't have
- ; any members logged into this queue
-
-
-
-At this point if there are no members currently logged into our sales queue,
-we then short-circuit our dialplan to go to the 'q_login' extension since there
-is no point in wasting cycles searching to see if we're already logged in.
-
-The next step is to finish initializing some values we need within the While()
-loop that we'll use to check if we're already logged into the queue. We set
-our ${field} variable to 1, which will be used as the field number offset in
-the CUT() function.
-
-
-; Initialize some values we'll use in the While() loop
-exten => member_check,n,Set(field=1) ; start our field counter at one
-exten => member_check,n,Set(logged_in=0) ; initialize 'logged_in' to "not logged in"
-exten => member_check,n,Set(thisQueueMember=${CUT(queueMembers,\,,${field})}) ; initialize 'thisQueueMember' with the value in the
- ; first field of the comma-separated list
-
-
-Now we get to enter our While() loop to determine if we're already logged in.
-
-
-; Enter our loop to check if our member is already logged into this queue
-exten => member_check,n,While($[${EXISTS(${thisQueueMember})}]) ; while we have a queue member...
-
-
-This is where we check to see if the member at this position of the list is the
-same as the device we're calling from. If it doesn't match, then we go to the
-'check_next' priority label (where we increase our ${field} counter variable).
-If it does match, then we continue on in the dialplan.
-
-exten => member_check,n,GotoIf($["${thisQueueMember}" != "${thisActiveMember}"]?check_next) ; if 'thisQueueMember' is not the
- ; same as our active peer, then
- ; check the next in the list of
- ; logged in queue members
-
-If we continued on in the dialplan, then we set the ${logged_in} channel
-variable to '1' which represents we're already logged into this queue. We then
-exit the While() loop with the ExitWhile() dialplan application.
-
-exten => member_check,n,Set(logged_in=1) ; if we got here, set as logged in
-exten => member_check,n,ExitWhile() ; then exit our loop
-
-
-
-If we didn't match this peer name in the list, then we increase our ${field}
-counter variable by one, update the ${thisQueueMember} channel variable and then
-move back to the top of the loop for another round of checks.
-
-exten => member_check,n(check_next),Set(field=$[${field} + 1]) ; if we got here, increase counter
-exten => member_check,n,Set(thisQueueMember=${CUT(queueMembers,\,,${field})}) ; get next member in the list
-exten => member_check,n,EndWhile() ; ...end of our loop
-
-
-And once we exit our loop, we determine whether we need to log our device in
-or out of the queue.
-
-; if not logged in, then login to this queue, otherwise, logout
-exten => member_check,n,GotoIf($[${logged_in} = 0]?q_login,1:q_logout,1) ; if not logged in, then login, otherwise, logout
-
-
-
-The following two extensions are used to either log the device in or out of the
-queue. We use the AddQueueMember() and RemovQueueMember() applications to login
-or logout the device from the queue.
-
-The first two arguments for AddQueueMember() and RemoveQueueMember() are 'queue'
-and 'device'. There are additional arguments we can pass, and you can check
-those out with 'core show application AddQueueMember' and 'core show
-application RemoveQueueMember()'.
-
-; ### Login queue member ###
-exten => q_login,1,Verbose(2,Logging ${thisActiveMember} into the ${thisQueue} queue)
-exten => q_login,n,AddQueueMember(${thisQueue},${thisActiveMember}) ; login our active device to the queue
- ; requested
-exten => q_login,n,Playback(silence/1) ; answer the channel by playing one second of silence
-
-; If the member was added to the queue successfully, then playback "Agent logged in", otherwise, state an error occurred
-exten => q_login,n,ExecIf($["${AQMSTATUS}" = "ADDED"]?Playback(agent-loginok):Playback(an-error-has-occurred))
-exten => q_login,n,Hangup()
-
-
-; ### Logout queue member ###
-exten => q_logout,1,Verbose(2,Logging ${thisActiveMember} out of ${thisQueue} queue)
-exten => q_logout,n,RemoveQueueMember(${thisQueue},${thisActiveMember})
-exten => q_logout,n,Playback(silence/1)
-exten => q_logout,n,ExecIf($["${RQMSTATUS}" = "REMOVED"]?Playback(agent-loggedoff):Playback(an-error-has-occurred))
-exten => q_logout,n,Hangup()
-
-
-And that's it! Give it a shot and you should see console output similar to the
-following which will login and logout your queue members to the queues you've
-configured.
-
-You can see there are already a couple of queue members logged into the sales
-queue.
-
-*CLI> queue show sales
-sales has 0 calls (max unlimited) in 'rrmemory' strategy (3s holdtime, 4s talktime), W:0, C:2, A:1, SL:0.0% within 0s
- Members:
- SIP/0004f2040001 (dynamic) (Not in use) has taken no calls yet
- SIP/0004f2040002 (dynamic) (Not in use) has taken no calls yet
- No Callers
-
-
-Then we dial *100 to logout the active device from the sales queue.
-
-*CLI> == Using SIP RTP CoS mark 5
- -- Executing [*100@devices:1] Set("SIP/0004f2040001-00000012", "xtn=100") in new stack
- -- Executing [*100@devices:2] Goto("SIP/0004f2040001-00000012", "queueLoginLogout,member_check,1") in new stack
- -- Goto (queueLoginLogout,member_check,1)
- -- Executing [member_check@queueLoginLogout:1] Verbose("SIP/0004f2040001-00000012", "2,Logging queue member in or out of the request queue") in new stack
- == Logging queue member in or out of the request queue
- -- Executing [member_check@queueLoginLogout:2] Set("SIP/0004f2040001-00000012", "thisQueue=sales") in new stack
- -- Executing [member_check@queueLoginLogout:3] Set("SIP/0004f2040001-00000012", "queueMembers=SIP/0004f2040001,SIP/0004f2040002") in new stack
- -- Executing [member_check@queueLoginLogout:4] Set("SIP/0004f2040001-00000012", "thisActiveMember=SIP/0004f2040001") in new stack
- -- Executing [member_check@queueLoginLogout:5] GotoIf("SIP/0004f2040001-00000012", "0?q_login,1") in new stack
- -- Executing [member_check@queueLoginLogout:6] Set("SIP/0004f2040001-00000012", "field=1") in new stack
- -- Executing [member_check@queueLoginLogout:7] Set("SIP/0004f2040001-00000012", "logged_in=0") in new stack
- -- Executing [member_check@queueLoginLogout:8] Set("SIP/0004f2040001-00000012", "thisQueueMember=SIP/0004f2040001") in new stack
- -- Executing [member_check@queueLoginLogout:9] While("SIP/0004f2040001-00000012", "1") in new stack
- -- Executing [member_check@queueLoginLogout:10] GotoIf("SIP/0004f2040001-00000012", "0?check_next") in new stack
- -- Executing [member_check@queueLoginLogout:11] Set("SIP/0004f2040001-00000012", "logged_in=1") in new stack
- -- Executing [member_check@queueLoginLogout:12] ExitWhile("SIP/0004f2040001-00000012", "") in new stack
- -- Jumping to priority 15
- -- Executing [member_check@queueLoginLogout:16] GotoIf("SIP/0004f2040001-00000012", "0?q_login,1:q_logout,1") in new stack
- -- Goto (queueLoginLogout,q_logout,1)
- -- Executing [q_logout@queueLoginLogout:1] Verbose("SIP/0004f2040001-00000012", "2,Logging SIP/0004f2040001 out of sales queue") in new stack
- == Logging SIP/0004f2040001 out of sales queue
- -- Executing [q_logout@queueLoginLogout:2] RemoveQueueMember("SIP/0004f2040001-00000012", "sales,SIP/0004f2040001") in new stack
-[Nov 12 12:08:51] NOTICE[11582]: app_queue.c:4842 rqm_exec: Removed interface 'SIP/0004f2040001' from queue 'sales'
- -- Executing [q_logout@queueLoginLogout:3] Playback("SIP/0004f2040001-00000012", "silence/1") in new stack
- -- <SIP/0004f2040001-00000012> Playing 'silence/1.slin' (language 'en')
- -- Executing [q_logout@queueLoginLogout:4] ExecIf("SIP/0004f2040001-00000012", "1?Playback(agent-loggedoff):Playback(an-error-has-occurred)") in new stack
- -- <SIP/0004f2040001-00000012> Playing 'agent-loggedoff.slin' (language 'en')
- -- Executing [q_logout@queueLoginLogout:5] Hangup("SIP/0004f2040001-00000012", "") in new stack
- == Spawn extension (queueLoginLogout, q_logout, 5) exited non-zero on 'SIP/0004f2040001-00000012'
-
-
-And we can see that the device we loggd out by running 'queue show sales'.
-
-*CLI> queue show sales
-sales has 0 calls (max unlimited) in 'rrmemory' strategy (3s holdtime, 4s talktime), W:0, C:2, A:1, SL:0.0% within 0s
- Members:
- SIP/0004f2040002 (dynamic) (Not in use) has taken no calls yet
- No Callers
-
-
--------------------------------------------
-| Pausing and Unpausing Members of Queues |
--------------------------------------------
-
-Once we have our queue members logged in, it is inevitable that they will want
-to pause themselves during breaks, and other short periods of inactivity. To do
-this we can utilize the 'queue pause' and 'queue unpause' CLI commands.
-
-We have two devices logged into the sales queue as we can see with the 'queue
-show sales' CLI command.
-
-*CLI> queue show sales
-sales has 0 calls (max unlimited) in 'rrmemory' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
- Members:
- SIP/0004f2040002 (dynamic) (Not in use) has taken no calls yet
- SIP/0004f2040001 (dynamic) (Not in use) has taken no calls yet
- No Callers
-
-
-We can then pause our devices with 'queue pause' which has the following format.
-
-Usage: queue {pause|unpause} member <member> [queue <queue> [reason <reason>]]
- Pause or unpause a queue member. Not specifying a particular queue
- will pause or unpause a member across all queues to which the member
- belongs.
-
-Lets pause device 0004f2040001 in the sales queue by executing the following.
-
-*CLI> queue pause member SIP/0004f2040001 queue sales
-paused interface 'SIP/0004f2040001' in queue 'sales' for reason 'lunch'
-
-
-And we can see they are paused with 'queue show sales'.
-
-*CLI> queue show sales
-sales has 0 calls (max unlimited) in 'rrmemory' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
- Members:
- SIP/0004f2040002 (dynamic) (Not in use) has taken no calls yet
- SIP/0004f2040001 (dynamic) (paused) (Not in use) has taken no calls yet
- No Callers
-
-At this point the queue member will no longer receive calls from the system. We
-can unpause them with the CLI command 'queue unpause member'.
-
-*CLI> queue unpause member SIP/0004f2040001 queue sales
-unpaused interface 'SIP/0004f2040001' in queue 'sales'
-
-And if you don't specify a queue, it will pause or unpause from all queues.
-
-*CLI> queue pause member SIP/0004f2040001
-paused interface 'SIP/0004f2040001'
-
-
-Of course we want to allow the agents to pause and unpause themselves from their
-devices, so we need to create an extension and some dialplan logic for that to
-happen.
-
-Below we've created the pattern patch _*0[01]! which will match on *00 and *01,
-and will *also* match with zero or more digits following it, such as the queue
-extension number.
-
-So if we want to pause ourselves in all queues, we can dial *00; unpausing can
-be done with *01. But if our agents just need to pause or unpause themselves
-from a single queue, then we will also accept *00100 to pause in queue 100
-(sales), or we can unpause ourselves from sales with *01100.
-
-
-extensions.conf
----------------
-
-; Allow queue members to pause and unpause themselves from all queues, or an individual queue.
-;
-; _*0[01]! pattern match will match on *00 and *01 plus 0 or more digits.
-exten => _*0[01]!,1,Verbose(2,Pausing or unpausing queue member from one or more queues)
-exten => _*0[01]!,n,Set(xtn=${EXTEN:3}) ; save the queue extension to 'xtn'
-exten => _*0[01]!,n,Set(thisQueue=${GLOBAL(QUEUE_${xtn})}) ; get the queue name if available
-exten => _*0[01]!,n,GotoIf($[${ISNULL(${thisQueue})} & ${EXISTS(${xtn})}]?invalid_queue,1) ; if 'thisQueue' is blank and the
- ; the agent dialed a queue exten,
- ; we will tell them it's invalid
-
-The following line will determine if we're trying to pause or unpause. This is
-done by taking the value dialed (e.g. *00100) and chopping off the first 2
-digits which leaves us with 0100, and then the :1 will return the next digit,
-which in this case is '0' that we're using to signify that the queue member
-wants to be paused (in queue 100).
-
-So we're doing the following with our EXTEN variable.
-
- ${EXTEN:2:1}
-offset ^ ^ length
-
-
-Which causes the following.
-
- *00100
- ^^ offset these characters
-
- *00100
- ^ then return a digit length of one, which is digit 0
-
-
-exten => _*0[01]!,n,GotoIf($[${EXTEN:2:1} = 0]?pause,1:unpause,1) ; determine if they wanted to pause
- ; or to unpause.
-
-
-The following two extensions, pause & unpause, are used for pausing and
-unpausing our extension from the queue(s). We use the PauseQueueMember() and
-UnpauseQueueMember() dialplan applications which accept the queue name
-(optional) and the queue member name. If the queue name is not provided, then it
-is assumed we want to pause or unpause from all logged in queues.
-
-; Unpause ourselves from one or more queues
-exten => unpause,1,NoOp()
-exten => unpause,n,UnpauseQueueMember(${thisQueue},SIP/${CHANNEL(peername)}) ; if 'thisQueue' is populated we'll pause in
- ; that queue, otherwise, we'll unpause in
- ; in all queues
-
-
-Once we've unpaused ourselves, we use GoSub() to perform some common dialplan
-logic that is used for pausing and unpausing. We pass three arguments to the
-subroutine:
-
- * variable name that contains the result of our operation
- * the value we're expecting to get back if successful
- * the filename to play
-
-exten => unpause,n,GoSub(changePauseStatus,start,1(UPQMSTATUS,UNPAUSED,available)) ; use the changePauseStatus subroutine and
- ; pass the values for: variable to check,
- ; value to check for, and file to play
-exten => unpause,n,Hangup()
-
-
-And the same method is done for pausing.
-
-; Pause ourselves in one or more queues
-exten => pause,1,NoOp()
-exten => pause,n,PauseQueueMember(${thisQueue},SIP/${CHANNEL(peername)})
-exten => pause,n,GoSub(changePauseStatus,start,1(PQMSTATUS,PAUSED,unavailable))
-exten => pause,n,Hangup()
-
-
-Lets explore what happens in the subroutine we're using for pausing and
-unpausing.
-
-
-; ### Subroutine we use to check pausing and unpausing status ###
-[changePauseStatus]
-; ARG1: variable name to check, such as PQMSTATUS and UPQMSTATUS (PauseQueueMemberStatus / UnpauseQueueMemberStatus)
-; ARG2: value to check for, such as PAUSED or UNPAUSED
-; ARG3: file to play back if our variable value matched the value to check for
-;
-exten => start,1,NoOp()
-exten => start,n,Playback(silence/1) ; answer line with silence
-
-The following line is probably the most complex. We're using the IF() function
-inside the Playback() application which determines which file to playback
-to the user.
-
-Those three values we passed in from the pause and unpause extensions could have
-been something like:
-
- * ARG1 -- PQMSTATUS
- * ARG2 -- PAUSED
- * ARG3 -- unavailable
-
-So when expanded, we'd end up with the following inside the IF() function.
-
- $["${PQMSTATUS}" = "PAUSED"]?unavailable:not-yet-connected
-
-${PQMSTATUS} would then be expanded further to contain the status of our
-PauseQueueMember() dialplan application, which could either be PAUSED or
-NOTFOUND. So if ${PQMSTATUS} returned PAUSED, then it would match what we're
-looking to match on, and we'd then return 'unavailable' to Playback() that would
-tell the user they are now unavailable.
-
-Otherwise, we'd get back a message saying "not yet connected" to indicate they
-are likely not logged into the queue they are attempting to change status in.
-
-
-; Please note that ${ARG1} is wrapped in ${ } in order to expand the value of ${ARG1} into
-; the variable we want to retrieve the value from, i.e. ${${ARG1}} turns into ${PQMSTATUS}
-exten => start,n,Playback(${IF($["${${ARG1}}" = "${ARG2}"]?${ARG3}:not-yet-connected)}) ; check if value of variable
- ; matches the value we're looking
- ; for and playback the file we want
- ; to play if it does
-
-If ${xtn} is null, then we just go to the end of the subroutine, but if it isn't
-then we will play back "in the queue" followed by the queue extension number
-indicating which queue they were (un)paused from.
-
-exten => start,n,GotoIf($[${ISNULL(${xtn})}]?end) ; if ${xtn} is null, then just Return()
-exten => start,n,Playback(in-the-queue) ; if not null, then playback "in the queue"
-exten => start,n,SayNumber(${xtn}) ; and the queue number that we (un)paused from
-exten => start,n(end),Return() ; return from were we came
-
---------------
-| Conclusion |
---------------
-
-You should now have a simple system that permits you to login and out of queues
-you create in queues.conf, and to allow queue members to pause themselves within
-one or more queues. There are a lot of dialplan concepts utilized in this
-article, so you are encouraged to seek out additional documentation if any of
-these concepts are a bit fuzzy for you.
-
-A good start is the doc/ subdirectory of the Asterisk sources, or the various
-configuration samples files located in the configs/ subdirectory of your
-Asterisk source code.
+++ /dev/null
-Asterisk call files
-===================
-
-Asterisk has the ability to initiate a call from outside of the normal
-methods such as the dialplan, manager interface, or spooling interface.
-
-Using the call file method, you must give Asterisk the following information:
-
-* How to perform the call, similar to the Dial() application
-* What to do when the call is answered
-
-With call files you submit this information simply by creating a file with
-the required syntax and placing it in the outgoing spooling directory, located
-by default in /var/spool/asterisk/outgoing/ (configurable in asterisk.conf).
-
-The pbx_spool module aggressively examines the directory contents every second,
-creating a new call for every call file it finds. Do NOT write or create
-the call file directly in the outgoing directory, but always create the file
-in another directory of the same filesystem and then move the file to the
-/var/spool/asterisk/outgoing directory, or Asterisk may read just a partial
-file.
-
-
-The call file syntax
-====================
-
-The call file consists of <Key>: <value> pairs; one per line.
-
-Comments are indicated by a '#' character that begins a line, or follows a space
-or tab character. To be consistent with the configuration files in Asterisk,
-comments can also be indicated by a semicolon. However, the multiline comments
-(;-- --;) used in Asterisk configuration files are not supported. Semicolons can
-be escaped by a backslash.
-
-
-The following keys-value pairs are used to specify how setup a call:
-
-Channel: <channel> the channel to use for the new call, in the form
- technology/resource as in the Dial application. This
- value is required.
-
-Callerid: <callerid> the caller id to use.
-
-WaitTime: <number> how many seconds to wait for an answer before the call
- fails (ring cycle). Default 45 seconds.
-
-Maxretries: <number> number of retries before failing, not including the
- initial attempt. Default = 0 e.g. don't retry if fails.
-
-RetryTime: <number> how many seconds to wait before retry. The default is
- 300 (5 minutes).
-
-Account: <account> the account code for the call. This value will be
- assigned to CDR(accountcode)
-
-
-
-When the call answers there are two choices:
-* Execute a single application, or
-* Execute the dialplan at the specified context/extension/priority.
-
-
-To execute an application:
---------------------------
-
-Application: <appname> the application to execute
-
-Data: <args> the application arguments
-
-
-To start executing applications in the dialplan:
-------------------------------------------------
-
-Context: <context> the context in the dialplan
-
-Extension: <exten> the extension in the specified context
-
-Priority: <priority> the priority of the specified extension
- (numeric or label)
-
-
-
-Setvar: <var=value> you may also assign values to variables that will be
- available to the channel, as if you had performed a
- Set(var=value) in the dialplan. More than one Setvar:
- maybe specified.
-
-
-The processing of the call file ends when the call is answered and terminated; when
-the call was not answered in the initial attempt and subsequent retries; or if
-the call file can't be successfully read and parsed.
-
-To specify what to do with the call file at the end of processing:
-
-Archive: <yes|no> if "no" the call file is deleted. If set to "yes" the
- call file is moved to the "outgoing_done" subdirectory
- of the Asterisk spool directory. The default is to
- delete the call file.
-
-
-If the call file is archived, Asterisk will append to the call file:
-
-Status: <exitstatus> can be "Expired", "Completed" or "Failed"
-
-
-
-Other lines generated by Asterisk:
-
-Asterisk keep track of how many retries the call has already attempted,
-appending to the call file the following key-pairs in the form:
-
-StartRetry: <pid> <retrycount> (<time>)
-EndRetry: <pid> <retrycount> (<time>)
-
-With the main process ID (pid) of the Asterisk process, the retry number, and
-the attempts start and end times in time_t format.
-
-
-
-Directory locations
-===================
-
-<astspooldir>/outgoing the outgoing dir, where call files are put
- for processing
-
-<astspooldir>/outgoing_done the archive dir
-
-
-<astspooldir> is specified in asterisk.conf, usually /var/spool/asterisk
-
-
-
-How to schedule a call
-======================
-
-Call files that have the time of the last modification in the future are ignored
-by Asterisk. This makes it possible to modify the time of a call file to the
-wanted time, move to the outgoing directory, and Asterisk will attempt to
-create the call at that time.
+++ /dev/null
-Measuring the SIP channel driver's Performance
-==============================================
-
-This file documents the methods I used to measure
-the performance of the SIP channel driver, in
-terms of maximum simultaneous calls and how quickly
-it could handle incoming calls.
-
-Knowing these limitations can be valuable to those
-implementing PBX's in 'large' environments. Will your
-installation handle expected call volume?
-
-Quoting these numbers can be totally useless for other
-installations. Minor changes like the amount of RAM
-in a system, the speed of the ethernet, the amount of
-cache in the CPU, the CPU clock speed, whether or not
-you log CDR's, etc. can affect the numbers greatly.
-
-In my set up, I had a dedicated test machine running Asterisk,
-and another machine which ran sipp, connected together with
-ethernet.
-
-The version of sipp that I used was sipp-2.0.1; however,
-I have reason to believe that other versions would work
-just as well.
-
-On the asterisk machine, I included the following in my
-extensions.ael file:
-
-context test11
-{
- s => {
- Answer();
- while (1) {
- Background(demo-instruct);
- }
- Hangup();
- }
- _X. => {
- Answer();
- while (1) {
- Background(demo-instruct);
- }
- Hangup();
- }
-}
-
-Basically, incoming SIP calls are answered, and
-the demo-instruct sound file is played endlessly
-to the caller. This test depends on the calling
-party to hang up, thus allowing sipp to determine
-the length of a call.
-
-The sip.conf file has this entry:
-
-[asterisk02]
-type=friend
-context=test11
-host=192.168.134.240 ;; the address of the host you will be running sipp on
-user=sipp
-directmedia=no
-disallow=all
-allow=ulaw
-
-Note that it's pretty simplistic; no authentication beyond the host ip,
-and it uses ulaw, which is pretty efficient, low-cpu-intensive codec.
-
-
-To measure the impact of incoming call traffic on the Asterisk
-machine, I run vmstat. It gives me an idea of the cpu usage by
-Asterisk. The most common failure mode of Asterisk at high call volumes,
-is that the CPU reaches 100% utilization, and then cannot keep up with
-the workload, resulting in timeouts and other failures, which swiftly
-compound and cascade, until gross failure ensues. Watch the CPU Idle %
-numbers.
-
-I learned to split the testing into two modes: one for just call call processing
-power, in the which we had relatively few simultaneous calls in place,
-and another where we allow the the number of simultaneous calls to quickly
-reach a set maximum, and then rerun sipp, looking for the maximum.
-
-Call processing power is measured with extremely short duration calls:
-
- ./sipp -sn uac 192.168.134.252 -s 12 -d 100 -l 256
-
-The above tells sipp to call your asterisk test machine (192.168.134.252)
-at extension 12, each call lasts just .1 second, with a limit of 256 simultaneous
-calls. The simultaneous calls will be the rate/sec of incoming calls times the call length,
-so 1 simultaneous call at 10 calls/sec, and 45 at 450 calls/sec. Setting the limit
-to 256 implies you do not intend to test above 2560 calls/sec.
-
-Sipp starts at 10 calls/sec, and you can slowly increase the speed by hitting '*' or '+'.
-Watch your cpu utilization on the asterisk server. When you approach 100%, you have found
-your limit.
-
-
-Simultaneous calls can be measured with very long duration calls:
-
-./sipp -sn uac 192.168.134.252 -s 12 -d 100000 -l 270
-
-This will place 100 sec duration calls to Asterisk. The number of simultaneous
-calls will increase until the maximum of 270 is reached. If Asterisk survives
-this number and is not at 100% cpu utilization, you can stop sipp and run it again
-with a higher -l argument.
-
-
-By changing one Asterisk parameter at a time, you can get a feel for how much that change
-will affect performance.
-
-
+++ /dev/null
-In addition to being the console for Asterisk, the CLI also sports several
-features that make it very helpful to use for obtaining information and
-affecting system configuration. The console can also be seen by starting
-a remote console, which connects to the running daemon and shows much of
-the same information as if using the daemon in foreground mode.
-
-Connecting a remote console is as easy as using the -r or -R flags. The only
-difference between these flags is that the uppercase variation (-R) will
-automatically reconnect to the daemon (or at least retry) if the daemon
-restarts. To exit a remote console, simply type 'quit' or 'exit'. Please note
-that you can differentiate between a remote console and the Asterisk console,
-as 'quit' or 'exit' will not function on the main console, which prevents an
-accidental shutdown of the daemon. If you would like to shutdown the Asterisk
-daemon, you can use the 'stop' set of commands, such as 'stop now',
-'stop gracefully', or 'stop when convenient'.
-
-Once on the console, the 'help' command may be used to see a list of commands
-available for use. Note that in addition to the 'help' command, the Asterisk
-CLI sports tab command line completion on all commands, including many
-arguments. To use tab command line completion, simply press the <Tab> key at
-any time while entering the beginning of any command. If the command can be
-completed unambiguously, it will do so, otherwise it will complete as much of
-the command as possible. Additionally, Asterisk will print a list of all
-possible matches, if possible.
-
-The 'help' command may also be used to obtain more detailed information on
-how to use a particular command. For example, if you type 'help core show',
-Asterisk will respond with a list of all commands that start with that string.
-If you type 'help core show version', specifying a complete command, Asterisk
-will respond with a usage message which describes how to use that command. As
-with other commands on the Asterisk console, the help command also responds to
-tab command line completion.
-
+++ /dev/null
-CODEC BIT EXPANSION
--------------------
-
-The code base up to and including Asterisk 1.6.2 has a basic limit of 32 codecs
-recognizable, due to the use of a 32-bit integer for the codec bitmask. We
-have expanded the number of available codecs from 32 to 64, through the use of
-an immutable type, called format_t. This should make future expansion to even
-more bits more easily done.
-
-The design of this expansion has made some changes to the architecture of codecs
-in order to accomplish this task. I will attempt to enumerate them here.
-
-The initial set of 32-bits were allocated as the first 16 to audio codecs, the
-next 8 to video codecs, and the remaining to text codecs (which are used for
-fax capabilities). Initially, there is an assumption in the code that all
-audio codecs are contiguous, followed by a contiguous set of video codecs.
-After the conversion, this assumption will no longer be true. The codec bits
-for the existing codecs will continue to be allocated as-is, and the additional
-codec bits should be allocated on an as-needed basis, with audio codecs
-occupying slots 32-47 and video codecs occupying slots 48-62 (with a 0-based
-offset). Slot 63 is reserved and should not be allocated; it is used in code
-as an end condition for iterating through the entire set of codecs.
-
-The frame structure has been altered. Initially, the subclass held an integer
-whose meaning was specified by the frametype. If the frametype was
-AST_FRAME_VOICE, the subclass specified the audio codec. If the frametype was
-AST_FRAME_VIDEO, the subclass specified the video codec, with the 0-bit set to
-specify a key frame. This was done with a union on the subclass, where the
-"integer" union member specifies the traditional 32-bit subclass and the "codec"
-union member specifies the new 64-bit codec bitmask. This additionally
-guarantees that code compiled under the old scheme will need to be altered to
-compile under the new scheme, which helps avoid incorrect assumptions about the
-state of code which might otherwise compile without errors.
-
-The IAX2 code initially used a 32-bit integer IE to specify both the codec as
-well as the preferred format. An additional IE has been added, which specifies
-a single byte version number as the initial part of the data. This version
-number is initially specified as 00 and requires 8 bytes to follow, specifying
-the 64-bit codec bitmask, in network-byte order. This schema should allow
-further codec expansion in the future without allocation of any additional IEs.
-
-Little changes are required to support further codec expansion in the future,
-though the majority of the work has already been accomplished. Specifically,
-the bitwise operations that are immutable operations in the gcc compiler will
-need to be altered to handle larger bitmasks. Additionally, the constants that
-define specific codecs will need to be changed from integers to structures.
-
+++ /dev/null
-As of 1.6.2, Asterisk now supports doing database transactions from the
-dialplan. A number of new applications and functions have been introduced
-for this purpose and this document should hopefully familiarize you with
-all of them.
-
-First, the ODBC() function has been added which is used to set up all new
-database transactions. Simply write the name of the transaction to this
-function, along with the arguments of "transaction" and the database name,
-e.g. Set(ODBC(transaction,postgres-asterisk)=foo). In this example, the
-name of the transaction is "foo". The name doesn't really matter, unless
-you're manipulating multiple transactions within the same dialplan, at the
-same time. Then, you use the transaction name to change which transaction
-is active for the next dialplan function.
-
-The ODBC() function is also used to turn on a mode known as forcecommit.
-For most cases, you won't need to use this, but it's there. It simply
-causes a transaction to be committed, when the channel hangs up. The other
-property which may be set is the isolation property. Please consult with
-your database vendor as to which values are supported by their ODBC driver.
-Asterisk supports setting all standard ODBC values, but many databases do
-not support the entire complement.
-
-Finally, when you have run multiple statements on your transaction and you
-wish to complete the transaction, use the ODBC_Commit and ODBC_Rollback
-applications, along with the transaction ID (in the example above, "foo")
-to commit or rollback the transaction. Please note that if you do not
-explicitly commit the transaction or if forcecommit is not turned on, the
-transaction will be automatically rolled back at channel destruction (after
-hangup) and all related database resources released back to the pool.
+++ /dev/null
-Asterisk Channel Data Stores
-============================
-
-* What is a data store?
-
-A data store is a way of storing complex data (such as a structure) on a channel
-so it can be retrieved at a later time by another application, or the same application.
-
-If the data store is not freed by said application though, a callback to a destroy function
-occurs which frees the memory used by the data in the data store so no memory loss occurs.
-
-* A datastore info structure
-static const struct example_datastore {
- .type = "example",
- .destroy = callback_destroy
-};
-
-This is a needed structure that contains information about a datastore, it's used by many API calls.
-
-* How do you create a data store?
-
-1. Use ast_datastore_alloc function to return a pre-allocated structure
- Ex: datastore = ast_datastore_alloc(&example_datastore, "uid");
- This function takes two arguments: (datastore info structure, uid)
-2. Attach data to pre-allocated structure.
- Ex: datastore->data = mysillydata;
-3. Add datastore to the channel
- Ex: ast_channel_datastore_add(chan, datastore);
- This function takes two arguments: (pointer to channel, pointer to data store)
-
-Full Example:
-
-void callback_destroy(void *data)
-{
- ast_free(data);
-}
-
-struct ast_datastore *datastore = NULL;
-datastore = ast_datastore_alloc(&example_datastore, NULL);
-datastore->data = mysillydata;
-ast_channel_datastore_add(chan, datastore);
-
-NOTE: Because you're passing a pointer to a function in your module, you'll want to include
-this in your use count. When allocated increment, when destroyed decrement.
-
-* How do you remove a data store?
-
-1. Find the data store
- Ex: datastore = ast_channel_datastore_find(chan, &example_datastore, NULL);
- This function takes three arguments: (pointer to channel, datastore info structure, uid)
-2. Remove the data store from the channel
- Ex: ast_channel_datastore_remove(chan, datastore);
- This function takes two arguments: (pointer to channel, pointer to data store)
-3. If we want to now do stuff to the data on the data store
-4. Free the data store (this will call the destroy call back)
- Ex: ast_channel_datastore_free(datastore);
- This function takes one argument: (pointer to data store)
-
-* How do you find a data store?
-
-1. Find the data store
- Ex: datastore = ast_channel_datastore_find(chan, &example_datastore, NULL);
- This function takes three arguments: (pointer to channel, datastore info structure, uid)
+++ /dev/null
-DIGIUM-MIB DEFINITIONS ::= BEGIN
-
-IMPORTS
- enterprises, MODULE-IDENTITY
- FROM SNMPv2-SMI;
-
-digium MODULE-IDENTITY
- LAST-UPDATED "200806202000Z"
- ORGANIZATION "Digium, Inc."
- CONTACT-INFO
- "Mark Spencer
- Email: markster@digium.com"
- DESCRIPTION
- "The Digium private-enterprise MIB"
- REVISION "200806202000Z"
- DESCRIPTION
- "Corrected imports and missing revision for last update.
- Addresses bug 12905. - jeffg@opennms.org"
- REVISION "200602041900Z"
- DESCRIPTION
- "Initial revision."
- ::= { enterprises 22736 }
-
-END
+++ /dev/null
-===============================================================================
-===
-=== XMPP PubSub Distributed Device State
-===
-=== Copyright (C) 2010, Digium, Inc.
-=== Leif Madsen <lmadsen@digium.com>
-===
-===============================================================================
-
--------------------------------------------------------------------------------
---- INTRODUCTION
--------------------------------------------------------------------------------
-
-This document describes installing and utilizing XMPP PubSub events to
-distribute device state and message waiting indication (MWI) events between
-servers. The difference between this method and OpenAIS (see
-distributed_devstate.txt) is that OpenAIS can only be used in low latency
-networks; meaning only on the LAN, and not across the internet.
-
-If you plan on distributing device state or MWI across the internet, then you
-will require the use of XMPP PubSub events.
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Tigase Installation
--------------------------------------------------------------------------------
-
--- Description --
-
-Currently the only server supported for XMPP PubSub events is the Tigase open
-source XMPP/Jabber environment. This is the server that the various Asterisk
-servers will connect to in order to distribute the events. The Tigase server can
-even be clustered in order to provide high availability for your device state;
-however, that is beyond the scope of this document.
-
-For more information about Tigase, visit their web site:
-
- http://www.tigase.org
-
--- Download --
-
-To download the Tigase environment, get the latest version at:
-
- http://www.tigase.org/en/filebrowser/tigase-server
-
--- Install --
-
-The Tigase server requires a working Java environment, including both a JRE
-(Java Runtime Environment) and a JDK (Java Development Kit), currently at least
-version 1.6.
-
-For more information about how to install Tigase, see the web site:
-
- http://www.tigase.org/en/content/quick-start
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Tigase Configuration
--------------------------------------------------------------------------------
-
-While installing Tigase, be sure you enable the PubSub module. Without it, the
-PubSub events won't be accepted by the server, and your device state will not be
-distributed.
-
-There are a couple of things you need to configure in Tigase before you start it
-in order for Asterisk to connect. The first thing we need to do is generate the
-self-signed certificate. To do this we use the keytool application. More
-information can be found here:
-
- http://www.tigase.org/en/content/server-certificate
-
--- Generating the keystore file --
-
-Generally, we need to run the following commands to generate a new keystore
-file.
-
-# cd /opt/Tigase-4.3.1-b1858/certs
-
-Be sure to change the 'yourdomain' to your domain.
-
-# keytool -genkey -alias yourdomain -keystore rsa-keystore \
- -keyalg RSA -sigalg MD5withRSA
-
-The keytool application will then ask you for a password. Use the password
-'keystore' as this is the default password that Tigase will use to load the
-keystore file.
-
-You then need to specify your domain as the first value to be entered in the
-security certificate.
-
-What is your first and last name?
- [Unknown]: asterisk.mydomain.tld
-What is the name of your organizational unit?
- [Unknown]:
-What is the name of your organization?
- [Unknown]:
-What is the name of your City or Locality?
- [Unknown]:
-What is the name of your State or Province?
- [Unknown]:
-What is the two-letter country code for this unit?
- [Unknown]:
-Is CN=asterisk.mydomain.tld, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct?
- [no]: yes
-
-You will then be asked for another password, in which case you must just press
-enter for the same password as Tigase will not work without them being the same.
-
-Enter key password for <mykey>
- (RETURN if same as keystore password):
-
-
--- Configuring init.properties --
-
-The next step is to configure the init.properties file which is used by Tigase
-to generate the tigase.xml file. Whenever you change the init.properties file
-because sure to remove the current tigase.xml file so that it will be
-regenerated at start up.
-
-# cd /opt/Tigase-4.3.1-b1858/etc
-
-Then edit the init.properties file and add the following:
-
-config-type=--gen-config-def
---admins=admin@asterisk.mydomain.tld
---virt-hosts=asterisk.mydomain.tld
---debug=server
---user-db=derby
---user-db-uri=jdbc:derby:/opt/Tigase-4.3.1-b1858
---comp-name-1=pubsub
---comp-class-1=tigase.pubsub.PubSubComponent
-
-Be sure to change the domain in the --admin and --virt-hosts options. The most
-important lines are --comp-name-1 and --comp-class-1 which tell Tigase to load
-the PubSub module.
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Running Tigase
--------------------------------------------------------------------------------
-
-You can then start the Tigase server with the tigase.sh script.
-
-# cd /opt/Tigase-4.3.1-b1858
-# ./scripts/tigase.sh start etc/tigase.conf
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Adding Buddies to Tigase
--------------------------------------------------------------------------------
-
-At this time, Asterisk is not able to automatically register your peers for you,
-so you'll need to use an external application to do the initial registration.
-
-Pidgin is an excellent multi-protocol instant messenger application which
-supports XMPP. It runs on Linux, Windows, and OSX, and is open source. You can
-get Pidgin from http://www.pidgin.im
-
-Then add the two buddies we'll use in Asterisk with Pidgin by connecting to
-the Tigase server. For more information about how to register new buddies, see
-the Pidgin documentation.
-
-Once the initial registration is done and loaded into Tigase, you no longer need
-to worry about using Pidgin. Asterisk will then be able to load the peers into
-memory at start up.
-
-The example peers we've used in the following documentation for our two nodes
-are:
-
-server1@asterisk.mydomain.tld/astvoip1
-server2@asterisk.mydomain.tld/astvoip2
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Installing Asterisk
--------------------------------------------------------------------------------
-
-Install Asterisk as usual. However, you'll need to make sure you have the
-res_jabber module compiled, which requires the iksemel development library.
-Additionally, be sure you have the OpenSSL development library installed so you
-can connect securly to the Tigase server.
-
-Make sure you check menuselect that res_jabber is selected so that it will
-compile.
-
-# cd asterisk-source
-# ./configure
-
-# make menuselect
- ---> Resource Modules
-
-If you don't have jabber.conf in your existing configuration, because sure to
-copy the sample configuration file there.
-
-# cd configs
-# cp jabber.conf.sample /etc/asterisk/jabber.conf
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Configuring Asterisk
--------------------------------------------------------------------------------
-
-We then need to configure our servers to communicate with the Tigase server. We
-need to modify the jabber.conf file on the servers. The configurations below are
-for a 2 server setup, but could be expanded for additional servers easily.
-
-The key note here is to note that the pubsub_node option needs to start with
-pubsub, so for example, pubsub.asterisk.mydomain.tld. Without the 'pubsub' your
-Asterisk system will not be able to distribute events.
-
-Additionally, you will need to specify each of the servers you need to connec to
-using the 'buddy' option.
-
-
--- Asterisk Server 1 --
-
-[general]
-debug=no ;;Turn on debugging by default.
-;autoprune=yes ;;Auto remove users from buddy list. Depending on your
- ;;setup (ie, using your personal Gtalk account for a test)
- ;;you might lose your contacts list. Default is 'no'.
-autoregister=yes ;;Auto register users from buddy list.
-;collection_nodes=yes ;;Enable support for XEP-0248 for use with
- ;;distributed device state. Default is 'no'.
-;pubsub_autocreate=yes ;;Whether or not the PubSub server supports/is using
- ;;auto-create for nodes. If it is, we have to
- ;;explicitly pre-create nodes before publishing them.
- ;;Default is 'no'.
-
-[asterisk]
-type=client
-serverhost=asterisk.mydomain.tld
-pubsub_node=pubsub.asterisk.mydomain.tld
-username=server1@asterisk.mydomain.tld/astvoip1
-secret=welcome
-distribute_events=yes
-status=available
-usetls=no
-usesasl=yes
-buddy=server2@asterisk.mydomain.tld/astvoip2
-
-
--- Asterisk Server 2 --
-
-[general]
-debug=yes ;;Turn on debugging by default.
-;autoprune=yes ;;Auto remove users from buddy list. Depending on your
- ;;setup (ie, using your personal Gtalk account for a test)
- ;;you might lose your contacts list. Default is 'no'.
-autoregister=yes ;;Auto register users from buddy list.
-;collection_nodes=yes ;;Enable support for XEP-0248 for use with
- ;;distributed device state. Default is 'no'.
-;pubsub_autocreate=yes ;;Whether or not the PubSub server supports/is using
- ;;auto-create for nodes. If it is, we have to
- ;;explicitly pre-create nodes before publishing them.
- ;;Default is 'no'.
-
-[asterisk]
-type=client
-serverhost=asterisk.mydomain.tld
-pubsub_node=pubsub.asterisk.mydomain.tld
-username=server2@asterisk.mydomain.tld/astvoip2
-secret=welcome
-distribute_events=yes
-status=available
-usetls=no
-usesasl=yes
-buddy=server1@asterisk.mydomain.tld/astvoip1
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Basic Testing of Asterisk with XMPP PubSub
--------------------------------------------------------------------------------
-
-Once you have Asterisk installed with XMPP PubSub, it is time to test it out.
-
-We need to start up our first server and make sure we get connected to the XMPP
-server. We can verify this with an Asterisk console command to determine if
-we're connected.
-
-On Asterisk 1 we can run 'jabber show connected' to verify we're connected to
-the XMPP server.
-
-*CLI> jabber show connected
-Jabber Users and their status:
- User: server1@asterisk.mydomain.tld/astvoip1 - Connected
-----
- Number of users: 1
-
-The command above has given us output which verifies we've connected our first
-server.
-
-We can then check the state of our buddies with the 'jabber show buddies' CLI
-command.
-
-*CLI> jabber show buddies
-Jabber buddy lists
-Client: server1@asterisk.mydomain.tld/astvoip1
- Buddy: server2@asterisk.mydomain.tld
- Resource: None
- Buddy: server2@asterisk.mydomain.tld/astvoip2
- Resource: None
-
-The output above tells us we're not connected to any buddies, and thus we're not
-distributing state to anyone (or getting it from anyone). That makes sense since
-we haven't yet started our other server.
-
-Now, let's start the other server and verify the servers are able to establish
-a connection between each other.
-
-On Asterisk 2, again we run the 'jabber show connected' command to make sure
-we've connected successfully to the XMPP server.
-
-*CLI> jabber show connected
-Jabber Users and their status:
- User: server2@asterisk.mydomain.tld/astvoip2 - Connected
-----
- Number of users: 1
-
-And now we can check the status of our buddies.
-
-*CLI> jabber show buddies
-Jabber buddy lists
-Client: server2@scooter/astvoip2
- Buddy: server1@asterisk.mydomain.tld
- Resource: astvoip1
- node: http://www.asterisk.org/xmpp/client/caps
- version: asterisk-xmpp
- Jingle capable: yes
- Status: 1
- Priority: 0
- Buddy: server1@asterisk.mydomain.tld/astvoip1
- Resource: None
-
-Excellent! So we're connected to the buddy on Asterisk 1, and we could run the
-same command on Asterisk 1 to verify the buddy on Asterisk 2 is seen.
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Testing Distributed Device State
--------------------------------------------------------------------------------
-
-The easiest way to test distributed device state is to use the DEVICE_STATE()
-diaplan function. For example, you could have the following piece of dialplan
-on every server:
-
-[devstate_test]
-
-exten => 1234,hint,Custom:mystate
-
-exten => set_inuse,1,Set(DEVICE_STATE(Custom:mystate)=INUSE)
-exten => set_not_inuse,1,Set(DEVICE_STATE(Custom:mystate)=NOT_INUSE)
-
-exten => check,1,NoOp(Custom:mystate is ${DEVICE_STATE(Custom:mystate)})
-
-
-Now, you can test that the cluster-wide state of "Custom:mystate" is what
-you would expect after going to the CLI of each server and adjusting the state.
-
-server1*CLI> console dial set_inuse@devstate_test
- ...
-
-server2*CLI> console dial check@devstate_test
- -- Executing [check@devstate_test:1] NoOp("OSS/dsp", "Custom:mystate is INUSE") in new stack
-
-Various combinations of setting and checking the state on different servers can
-be used to verify that it works as expected. Also, you can see the status of
-the hint on each server, as well, to see how extension state would reflect the
-state change with distributed device state:
-
-server2*CLI> core show hints
- -= Registered Asterisk Dial Plan Hints =-
- 1234@devstate_test : Custom:mystate State:InUse Watchers 0
-
-
-One other helpful thing here during testing and debugging is to enable debug
-logging. To do so, enable debug on the console in /etc/asterisk/logger.conf.
-Also, enable debug at the Asterisk CLI.
-
-*CLI> core set debug 1
-
-When you have this debug enabled, you will see output during the processing of
-every device state change. The important thing to look for is where the known
-state of the device for each server is added together to determine the overall
-state.
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Notes On Large Installations
--------------------------------------------------------------------------------
-
-On larger installations where you want a fully meshed network of buddies (i.e.
-all servers have all the buddies of the remote servers), you may want some
-method of distributing those buddies automatically so you don't need to modify
-all servers (N+1) every time you add a new server to the cluster.
-
-The problem there is that you're confined by what's allowed in XEP-0060, and
-unfortunately that means modifying affiliations by individual JID (as opposed to
-the various subscription access models, which are more flexible).
-
-See here for details:
-http://xmpp.org/extensions/xep-0060.html#owner-affiliations
-
-One method for making this slightly easier is to utilize the #exec functionality
-in configuration files, and dynamically generate the buddies via script that
-pulls the information from a database, or to #include a file which is
-automatically generated on all the servers when you add a new node to the
-cluster.
-
-Unfortunately this still requires a reload of res_jabber.so on all the servers,
-but this could also be solved through the use of the Asterisk Manager Interface
-(AMI).
-
-So while this is not the ideal situation, it is programmatically solvable with
-existing technologies and features found in Asterisk today.
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Questions, Comments, and Bug Reports
--------------------------------------------------------------------------------
-
-Please utilize the Asterisk issue tracker for all bug reports at
-https://issues.asterisk.org
+++ /dev/null
-===============================================================================
-===
-=== Distributed Device State
-===
-=== Copyright (C) 2007-2008, Digium, Inc.
-=== Russell Bryant <russell@digium.com>
-===
-===============================================================================
-
--------------------------------------------------------------------------------
---- IMPORTANT NOTE
--------------------------------------------------------------------------------
-
-This document includes some information about using the res_ais module for
-distributed events. However, it is important to note that res_ais is still
-considered experimental, as the module exposes the binary format of events
-over the network between servers. This format is still subject to change
-between 1.6.X releases.
-
--------------------------------------------------------------------------------
---- INTRODUCTION
--------------------------------------------------------------------------------
-
-Various changes have been made related to "event handling" in Asterisk.
-One of the most important things included in these changes is the ability
-to share certain events between servers. The two types of events that can
-currently be shared between servers are:
-
- 1) MWI - Message Waiting Indication
- - This gives you a high performance option for letting servers in a
- cluster be aware of changes in the state of a mailbox. Instead of
- having each server have to poll an ODBC database, this lets the server
- that actually made the change to the mailbox generate an event which
- will get distributed to the other servers that have subscribed to this
- information.
-
- 2) Device State
- - This lets servers in a local cluster inform each other about changes in
- the state of a device on that particular server. When the state of a
- device changes on any server, the overall state of that device across
- the cluster will get recalculated. So, any subscriptions to the state
- of a device, such as hints in the dialplan or an application like
- Queue() which reads device state, will then reflect the state of a
- device across a cluster.
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- OpenAIS Installation
--------------------------------------------------------------------------------
-
---- Description ---
-
-The current solution for providing distributed events with Asterisk is done by
-using the AIS (Application Interface Specification), which provides an API for
-a distributed event service. While this API is standardized, this code has
-been developed exclusively against the open source implementation of AIS called
-OpenAIS.
-
-For more information about OpenAIS, visit their web site:
-
- http://www.openais.org/
-
---- Download ---
-
-To quickly downlaod OpenAIS, just check it out of svn:
-
-$ svn co http://svn.osdl.org/openais/trunk openais-trunk
-
---- Compile ---
-
-$ cd openais-trunk
-$ make PREFIX=/usr
-
---- Install ---
-
-By default, the current Makefile installs the libraries into /usr/lib/openais/,
-which is a little bit inconvenient. So, open up the Makefile, find the lines
-that start with "LIBDIR=" to define the lib installation directory, and remove
-the trailing "openais" so it just gets installed in /usr/lib/.
-
-$ sudo make install PREFIX=/usr
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- OpenAIS Configuration
--------------------------------------------------------------------------------
-
-Basic OpenAIS configuration to get this working is actually pretty easy. When
-you install it, it will put some default configuration files into /etc/ais/.
-Edit openais.conf ...
-
-$ ${EDITOR:-vim} /etc/ais/openais.conf
-
-The only section that you should need to change is the totem - interface
-section.
-
-totem {
- ...
- interface {
- interface {
- ringnumber: 0
- bindnetaddr: 10.19.0.0
- mcastaddr: 226.94.1.1
- mcastport: 5405
- }
-}
-
-The default mcastaddr and mcastport is probably fine. But, you need to change
-the bindnetaddr to match the network address that the nodes of your cluster
-will communicate on.
-
-The one other thing that you need to do is create a user called "ais".
-
-$ sudo adduser ais
-
-See the OpenAIS QUICKSTART file for more information on installing,
-configuring, and testing OpenAIS.
-
-$ cd openais-trunk
-$ less QUICKSTART
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Running OpenAIS
--------------------------------------------------------------------------------
-
-While testing, I would recommend starting the aisexec application in the
-foreground so that you can see debug messages that verify that the nodes have
-discovered each other and joined the cluster.
-
-$ sudo aisexec -f
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Installing Asterisk
--------------------------------------------------------------------------------
-
-Install Asterisk as usual. Just make sure that you run the configure script
-after OpenAIS gets installed. That way, it will find the AIS header files and
-will let you build the res_ais module. Check menuselect to make sure that
-res_ais is going to get compiled and installed.
-
-$ cd asterisk-source
-$ ./configure
-
-$ make menuselect
- ---> Resource Modules
-
-If you have existing configuration on the system being used for testing, just
-be sure to install the addition configuration file needed for res_ais.
-
-$ sudo cp configs/ais.conf.sample /etc/asterisk/ais.conf
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Configuring Asterisk
--------------------------------------------------------------------------------
-
-First, ensure that you have a unique "entity ID" set for each server.
-
-*CLI> core show settings
- ...
- Entity ID: 01:23:45:67:89:ab
-
-The code will attempt to generate a unique entity ID for you by reading
-MAC addresses off of a network interface. However, you can also set it
-manually in the [options] section of asterisk.conf.
-
-$ sudo ${EDITOR:-vim} /etc/asterisk/asterisk.conf
-
-[options]
-...
-entity_id=01:23:45:67:89:ab
-
-
-Edit the Asterisk ais.conf to enable distributed events. For example, if you
-would like to enable distributed device state, you should add the following
-section to the file:
-
-$ sudo ${EDITOR:-vim} /etc/asterisk/ais.conf
-
-[device_state]
-type=event_channel
-publish_event=device_state
-subscribe_event=device_state
-
-For more information on the contents and available options in this configuration
-file, please see the sample configuration file:
-
-$ cd asterisk-source
-$ less configs/ais.conf.sample
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Basic Testing of Asterisk with OpenAIS
--------------------------------------------------------------------------------
-
-If you have OpenAIS successfully installed and running, as well as Asterisk
-with OpenAIS support successfully installed, configured, and running, then you
-are ready to test out some of the AIS functionality in Asterisk.
-
-The first thing to test is to verify that all of the nodes that you think should
-be in your cluster are actually there. There is an Asterisk CLI command which
-will list the current cluster members using the AIS Cluster Membership Service
-(CLM).
-
-*CLI> ais clm show members
-
-=============================================================
-=== Cluster Members =========================================
-=============================================================
-===
-=== ---------------------------------------------------------
-=== Node Name: 10.19.2.255
-=== ==> ID: 0xa1302ff
-=== ==> Address: 10.19.2.255
-=== ==> Member: Yes
-=== ---------------------------------------------------------
-===
-=== ---------------------------------------------------------
-=== Node Name: 10.19.6.187
-=== ==> ID: 0xa1306bb
-=== ==> Address: 10.19.6.187
-=== ==> Member: Yes
-=== ---------------------------------------------------------
-===
-=============================================================
-
-
-The next thing to do is to verify that you have successfully configured some
-event channels in the Asterisk ais.conf file. This command is related to the
-event service (EVT), so like the previous command, uses the syntax:
-"ais <service name> <command>".
-
-*CLI> ais evt show event channels
-
-=============================================================
-=== Event Channels ==========================================
-=============================================================
-===
-=== ---------------------------------------------------------
-=== Event Channel Name: mwi
-=== ==> Publishing Event Type: mwi
-=== ==> Subscribing to Event Type: mwi
-=== ---------------------------------------------------------
-===
-=== ---------------------------------------------------------
-=== Event Channel Name: device_state
-=== ==> Publishing Event Type: device_state
-=== ==> Subscribing to Event Type: device_state
-=== ---------------------------------------------------------
-===
-=============================================================
-
--------------------------------------------------------------------------------
-
--------------------------------------------------------------------------------
---- Testing Distributed Device State
--------------------------------------------------------------------------------
-
-The easiest way to test distributed device state is to use the DEVICE_STATE()
-diaplan function. For example, you could have the following piece of dialplan
-on every server:
-
-[devstate_test]
-
-exten => 1234,hint,Custom:mystate
-
-exten => set_inuse,1,Set(DEVICE_STATE(Custom:mystate)=INUSE)
-exten => set_not_inuse,1,Set(DEVICE_STATE(Custom:mystate)=NOT_INUSE)
-
-exten => check,1,NoOp(Custom:mystate is ${DEVICE_STATE(Custom:mystate)})
-
-
-Now, you can test that the cluster-wide state of "Custom:mystate" is what
-you would expect after going to the CLI of each server and adjusting the state.
-
-server1*CLI> console dial set_inuse@devstate_test
- ...
-
-server2*CLI> console dial check@devstate_test
- -- Executing [check@devstate_test:1] NoOp("OSS/dsp", "Custom:mystate is INUSE") in new stack
-
-Various combinations of setting and checking the state on different servers can
-be used to verify that it works as expected. Also, you can see the status of
-the hint on each server, as well, to see how extension state would reflect the
-state change with distributed device state:
-
-server2*CLI> core show hints
- -= Registered Asterisk Dial Plan Hints =-
- 1234@devstate_test : Custom:mystate State:InUse Watchers 0
-
-
-One other helpful thing here during testing and debugging is to enable debug
-logging. To do so, enable debug on the console in /etc/asterisk/logger.conf.
-Also, enable debug at the Asterisk CLI.
-
-*CLI> core set debug 1
-
-When you have this debug enabled, you will see output during the processing of
-every device state change. The important thing to look for is where the known
-state of the device for each server is added together to determine the overall
-state.
-
--------------------------------------------------------------------------------
-
-
--------------------------------------------------------------------------------
---- Question, Comments, and Bug Reports
--------------------------------------------------------------------------------
-
-For now, please direct all feedback to Russell Bryant <russell@digium.com>.
-
--------------------------------------------------------------------------------
+++ /dev/null
-Asterisk External IVR Interface
--------------------------------
-
-If you load app_externalivr.so in your Asterisk instance, you will
-have an ExternalIVR() application available in your dialplan. This
-application implements a simple protocol for bidirectional
-communication with an external process, while simultaneous playing
-audio files to the connected channel (without interruption or
-blocking).
-
-There are two ways to use ExternalIVR(); you can execute an
-application on the local system or you can establish a socket
-connection to a TCP/IP socket server.
-
-To execute a local application use the form:
-ExternalIVR(/full/path/to/applcation[(arguments)],options)
-
-The arguments are optional, however if they exist they must be
-enclosed in parentheses. The external application will be executed
-in a child process, with its standard file handles connected to the
-Asterisk process as follows:
-
-stdin (0) - events will be received on this handle
-stdout (1) - commands can be sent on this handle
-stderr (2) - messages can be sent on this handle
-* Use of stderr for message communication is discouraged because
-it is not supported by a socket connection.
-
-To create a socket connection use the form:
-ExternalIVR(ivr://host[:port][(arguments)],options)
-
-The host can be a fqdn or an ip address. The port is optional, if
-not specified the default of 2949 will be used. The arguments are
-optional however if they exist they must be enclosed in parentheses.
-TheExternalIVR application will connect to the specified socket
-server and establish a bi-directional socket connection, where
-events will be sent to the TCP/IP server and commands received
-from it.
-
-The specific ExternalIVR options, events and commands are detailed
-below.
-
-Upon execution, if not specifically prevented by an option, the
-ExternalIVR application will answer the channel (if it's not
-already answered), create an audio generator, and start playing
-silence. When your application wants to send audio to the channel,
-it can send a command (see below) to add a file to the generator's
-playlist. The generator will then work its way through the list,
-playing each file in turn until it either runs out of files to
-play, the channel is hung up, or a command is received to clear
-the list and start with a new file. At any time, more files can
-be added to the list and the generator will play them in sequence.
-
-While the generator is playing audio (or silence), any DTMF events
-received on the channel will be sent to the child process (see
-below). Note that this can happen at any time, since the generator,
-the child process and the channel thread are all executing
-independently. It is very important that your external application
-be ready to receive events from Asterisk at all times (without
-blocking), or you could cause the channel to become non-responsive.
-
-If the child process dies, or the remote server disconnects,
-ExternalIVR() will notice this and hang up the channel
-immediately (and also send a message to the log).
-
-ExternalIVR() Options
----------------------
-n: 'n'oanswer, don't answer an otherwise unanswered channel.
-i: 'i'gnore_hangup, instead of sending an 'H' event and exiting
- ExternalIVR() upon channel hangup, it instead sends an 'I'
- event and expects the external application to exit the process.
-d: 'd'ead, allows the operation of ExternalIVR() on channels that
- have already been hung up.
-
-Events
-------
-
-All events are be newline-terminated strings and are sent in the
-following format:
-
-tag,timestamp[,data]
-
-The tag can be one of the following characters:
-
-0-9: DTMF event for keys 0 through 9
-A-D: DTMF event for keys A through D
-*: DTMF event for key *
-#: DTMF event for key #
-H: the channel was hung up by the connected party
-E: the script requested an exit
-Z: the previous command was unable to be executed. There may be a
- data element if appropriate, see specific commands below for
- details
-T: the play list was interrupted (see S command below)
-D: a file was dropped from the play list due to interruption (the
- data element will be the dropped file name) NOTE: this tag
- conflicts with the D DTMF event tag. The existence of the data
- element is used to differentiate between the two cases
-F: a file has finished playing (the data element will be the file
- name)
-P: a response to the 'P' command (see below)
-G: a response to the 'G' command (see below)
-I: a Inform message, meant to "inform" the client that something
- has occurred. (see Inform Messages below)
-
-The timestamp will be 10 digits long, and will be a decimal
-representation of a standard Unix epoch-based timestamp.
-
-Commands
---------
-
-All commands are newline-terminated strings.
-
-The child process can send one of the following commands:
-
-S,filename
-A,filename
-H,message
-E,message
-D,dtmf[,interval][,duration]
-O,option
-V,name=value[,name=value[,name=value]]
-G,name[,name[,name]]
-L,log_message
-P,TIMESTAMP
-T,TIMESTAMP
-
-The 'S' command checks to see if there is a playable audio file with
-the specified name, and if so, clear's the generator's playlist and
-places the file onto the list. Note that the playability check does
-not take into account transcoding requirements, so it is possible for
-the file to not be played even though it was found. If the file does
-not exist it sends a Z response with the data element set to the file
-requested. If the generator is not currently playing silence, then T
-and D events will be sent to signal the playlist interruption and
-notify it of the files that will not be played.
-
-The 'A' command checks to see if there is a playable audio file with
-the specified name, and if so, appends it to the generator's playlist.
-The same playability and exception rules apply as for the 'S' command.
-
-The 'H' command logs the supplied message to the Asterisk log, stops
-the generator, hangs up the channel and terminates the ExternalIVR
-application.
-
-The 'E' command logs the supplied message to the Asterisk log, stops
-the generator and terminates the ExternalIVR application, but continues
-execution in the dialplan.
-
-The 'D' command generates DTMF on the channel, dtmf is a string of one or
-more valid DTMF digits, w can be used for a half second pause. Interval
-is optional, defaults to 250 milliseconds and is the time between digits.
-Duration is optional and is the duration of each digit.
-
-The 'O' command allows the child to set/clear options in the
-ExternalIVR() application.
-
-The supported options are:
-(no)autoclear: Automatically interrupt and clear the playlist
- upon reception of DTMF input.
-
-The 'T' command will answer an unanswered channel. If it fails either
-answering the channel or starting the generator it sends a Z response
-of "Z,TIMESTAMP,ANSWER_FAILED" or "Z,TIMESTAMP,GENERATOR_FAILED"
-respectively.
-
-The 'V' command sets the specified channel variable(s) to the specified
-value(s).
-
-The 'G' command gets the specified channel variable(s). Multiple
-variables are separated by commas. Response is in name=value format.
-
-The 'P' command gets the parameters passed into ExternalIVR() minus
-the options to ExternalIVR() itself:
- If ExternalIVR() is executed as:
- ExternalIVR(/usr/bin/foo(arg1,arg2),n)
- The response to the 'P' command would be:
- P,TIMESTAMP,/usr/bin/foo,arg1,arg2
-NOTE: This is the only way for a TCP/IP server to be able to retrieve
-the arguments.
-
-The 'L' command puts a message into the Asterisk log. NOTE: This is
-prefered to using stderr and is the only way for a TCP/IP server to
-log a message.
-
-Inform Messages
----------------
-
-The only inform message that currently exists is a HANGUP message,
-in the form I,TIMESTAMP,HANGUP and is used to inform of a hangup
-when the i option is specified.
-
-Errors
-------
-
-Any newline-terminated output generated by the child process on its
-stderr handle will be copied into the Asterisk log.
+++ /dev/null
-Followme is now realtime-enabled:
-
-To use, you must define two backend data structures, with the following fields:
-
-followme:
- name Name of this followme entry. Specified when invoking the FollowMe
- application in the dialplan. This field is the only one which is
- mandatory. All of the other fields will inherit the default from
- followme.conf, if not specified in this data resource.
- musicclass OR The musiconhold class used for the caller while waiting to be
- musiconhold OR connected.
- music
- context Dialplan context from which to dial numbers
- takecall DTMF used to accept the call and be connected. For obvious reasons,
- this needs to be a single digit, '*', or '#'.
- declinecall DTMF used to refuse the call, sending it onto the next step, if any.
- call_from_prompt Prompt to play to the callee, announcing the call.
- norecording_prompt The alternate prompt to play to the callee, when the caller
- refuses to leave a name (or the option isn't set to allow them).
- options_prompt Normally, "press 1 to accept, 2 to decline".
- hold_prompt Message played to the caller while dialing the followme steps.
- status_prompt Normally, "Party is not at their desk".
- sorry_prompt Normally, "Unable to locate party".
-
-followme_numbers:
- name Name of this followme entry. Must match the name above.
- ordinal An integer, specifying the order in which these numbers will be
- followed.
- phonenumber The telephone number(s) you would like to call, separated by '&'.
- timeout Timeout associated with this step. See the followme documentation
- for more information on how this value is handled.
-
+++ /dev/null
-This document now lives here:
-
- http://svn.digium.com/view/asterisk/team/group/gsoc-2009/ideas.txt?view=markup
+++ /dev/null
-Using the Hoard Memory Allocator with Asterisk
-==============================================
-
-1) Install the Hoard Memory Allocator
-
- Download Hoard from http://www.hoard.org/ either via a package or the source
- tarball.
-
- If downloading the source, unpack the tarball and follow the instructions in
- the README file to build libhoard for your platform.
-
-2) Configure asterisk
-
- Run ./configure in the root of the asterisk source directory, passing the
- --with-hoard option specifying the location of the libhoard shared library.
-
- For example:
-
- ./configure --with-hoard=/usr/src/hoard-371/src/
-
- Note that we don't specify the full path to libhoard.so, just the directory
- where it resides.
-
-3) Enable Hoard in menuselect
-
- Run 'make menuselect' in the root of the asterisk source distribution. Under
- 'Compiler Flags' select the 'USE_HOARD_ALLOCATOR' option. If the option is
- not available (shows up with XXX next to it) this means that configure was
- not able to find libhoard.so. Check that the path you passed to the
- --with-hoard option is correct. Re-run ./configure with the correct option
- and then repeat step 3.
-
-4) Make and install asterisk
-
- Run the standard build commands:
-
- # make
- # make install
+++ /dev/null
-XMPP (Jabber) is an xml based protocol primarily for presence and messaging.
-It is an open standard and there are several open server implementations,
-ejabberd, jabberd(2), openfire, and many others, as well as several open source
-clients, Psi, gajim, gaim etc. XMPP differs from other IM applications as it
-is immensly extendable. This allows us to easily integrate Asterisk with
-XMPP. The Asterisk XMPP Interface is provided by res_jabber.so.
-
-res_jabber allows for Asterisk to connect to any XMPP (Jabber) server and
-is also used to provide the connection interface for chan_jingle and
-chan_gtalk.
-
-Functions (JABBER_STATUS, JABBER_RECEIVE) and applications (JabberSend)
-are exposed to the dialplan.
-
-You'll find examples of how to use these functions/applications
-hereafter. We assume that 'asterisk-xmpp' is properly configured in
-jabber.conf.
-
-**** JabberSend ****
-
-JabberSend sends an XMPP message to a buddy. Example :
-
-context default {
- _XXXX => {
- JabberSend(asterisk-xmpp,buddy@gmail.com,${CALLERID(name)} is calling ${EXTEN});
- Dial(SIP/${EXTEN}, 30);
- Hangup();
- }
-}
-
-**** JABBER_STATUS ****
-
-Note : as of version 1.6, the corresponding application JabberStatus is still
-available, but marked as deprecated in favor of this function.
-
-JABBER_STATUS stores the status of a buddy in a dialplan variable for
-further use. Here is an AEL example of how to use it :
-
-1234 => {
- Set(STATUS=${JABBER_STATUS(asterisk-xmpp,buddy@gmail.com)});
- if (${STATUS}=1) {
- NoOp(User is online and active, ring his Gtalk client.);
- Dial(Gtalk/asterisk-xmpp/buddy@gmail.com);
- } else {
- NoOp(Prefer the SIP phone);
- Dial(SIP/1234);
- }
-}
-
-**** JABBER_RECEIVE ****
-
-JABBER_RECEIVE waits (up to X seconds) for a XMPP message and returns
-its content. Used along with JabberSend (or SendText,
-provided it's implemented in the corresponding channel type),
-JABBER_RECEIVE helps Asterisk interact with users while calls flow
-through the dialplan.
-
-JABBER_RECEIVE/JabberSend are not tied to the XMPP media modules
-chan_gtalk and chan_jingle, and can be used anywhere in the dialplan.
-In the following example, calls targeted to extension 1234 (be it
-accessed from SIP, DAHDI or whatever channel type) are controlled by
-user bob@domain.com. Asterisk notifies him that a call is coming, and
-asks him to take an action. This dialog takes place over an XMPP chat.
-
-context from-ext {
- 1234 => {
- Answer();
- JabberSend(asterisk-xmpp,bob@jabber.org,Call from $CALLERID(num) - choose an option to process the call);
- JabberSend(asterisk-xmpp,bob@jabber.org,1 : forward to cellphone);
- JabberSend(asterisk-xmpp,bob@jabber.org,2 : forward to work phone);
- JabberSend(asterisk-xmpp,bob@jabber.org,Default action : forward to your voicemail);
- Set(OPTION=${JABBER_RECEIVE(asterisk-xmpp,bob@jabber.org,20)});
- switch (${OPTION}) {
- case 1:
- JabberSend(asterisk-xmpp,bob@jabber.org,(Calling cellphone...);
- Dial(SIP/987654321);
- break;
- case 2:
- JabberSend(asterisk-xmpp,bob@jabber.org,(Calling workphone...);
- Dial(SIP/${EXTEN});
- break;
- default:
- Voicemail(${EXTEN}|u)
- }
- }
-}
-
-When calling from a GoogleTalk or Jingle client, the CALLERID(name)
-is set to the XMPP id of the caller (i.e. his JID). In the
-following example, Asterisk chats back with the caller identified by the
-caller id. We also take advantage of the SendText implementation in
-chan_gtalk (available in chan_jingle, and chan_sip as well), to
-allow the caller to establish SIP calls from his GoogleTalk client :
-
-context gtalk-in {
- s => {
- NoOp(Caller id : ${CALLERID(all)});
- Answer();
- SendText(Please enter the number you wish to call);
- Set(NEWEXTEN=${JABBER_RECEIVE(asterisk-xmpp,${CALLERID(name)})});
- SendText(Calling ${NEWEXTEN} ...);
- Dial(SIP/${NEWEXTEN);
- Hangup();
- }
-}
-
-The maintainer of res_jabber is Philippe Sultan <philippe.sultan@gmail.com>.
+++ /dev/null
- -- Audit uses of usleep() to ensure that the argument is never greater than 1 million.
- On some systems, that is considered an error. In any such cases, convert the usage
- over to use nanosleep(), instead.
-
- -- Convert all existing uses of astobj.h to astobj2.h
- -- (chan_sip already in progress in a branch)
-
- -- There are many places where large character buffers are allocated in structures. There is a new system for string handling that uses dynamically allocatted memory pools which is documented in include/asterisk/stringfields.h. Examples of where they are currently used are the ast_channel structure defined in include/asterisk/channel.h, some structures in chan_sip.c, and chan_dahdi.c.
-
- -- There is a convenient set of macros defined in include/asterisk/linkedlists.h for handling linked lists. However, there are some open-coded lists throughout the code. Converting linked lists to use these macros will make list handling more consistent and reduce the possibility of coding errors.
-
- -- Clean up and add Doxygen Documentation. When generating the documentation with make progdocs, a lot of warnings are generated. All of these need to be fixed. There is also plenty of code that still needs to be documented. All public API functions should be documented. That is pretty much anything in include/asterisk/*.h.
-
- -- Check all ast_copy_string() usage to ensure that buffers are not being unnecessarily zeroed before or after calling it.
-
- -- Find any remaining open-coded struct timeval manipulation and convert to use new time library functions.
-
- -- Use the ast_str API in strings.h to replace multiple calls to strncat(), snprintf() with funky math, etc.
-
- -- Audit all channel/res/app/etc. modules to ensure that they do not register any entrypoints with the Asterisk core until after they are ready to service requests; all config file reading/processing, structure allocation, etc. must be completed before Asterisk is made aware of any services the module offers.
-
- -- Ensure that Realtime-enabled modules do not depend on the order of columns returned by the database lookup (example: outboundproxy and host settings in chan_sip).
-
- -- Convert all usage of the signal(2) system API to the more portable sigaction(2) system API.
-
- -- Find options and arguments in Asterisk which specify a time period in seconds or milliseconds and convert them to use the new ast_app_parse_timelen() function.
-
- -- Find applications and functions in Asterisk that would benefit from being able to encode control characters and extended ASCII and embed calls to ast_get_encoded_char, ast_get_encoded_str, and ast_str_get_encoded_str.
+++ /dev/null
-(Jingle support in asterisk is experimental)
-Jingle is an xmpp based protocol for signalling the transfer of media.
-Currently asterisk supports the proprietary GoogleTalk protocol that is
-very similar to jingle, and hopes to soon support true jingle specs
-(JEP-166,167,176,177,180,181 etc) as more clients support the true standard.
-Jingle's configuration is very similar to sip.conf only as we are not the
-jabber server in this case you must provide a connection for the peer to
-travel out on.
-chan_gtalk is for supporting the non-jingle google/libjingle spec and
-chan_jingle will continue to move in the direction of the correct spec.
+++ /dev/null
-Asterisk Realtime LDAP Driver
----------------------------
-
-With this driver Asterisk can retrieve information from an LDAP drectory, including
-sip/iax users, extensions and configuration.
-
-See configs/res_ldap.conf.sample for a configuration file sample
-
-
-Here is a LDAP diff sample:
-
-# Base SIP Phones Entry
-dn: uid=phone-base,dc=myDomain,dc=myDomainExt
-objectClass: top
-objectClass: AstAccount
-objectClass: AstAccountSIP
-uid: phone-base
-AstAccountAccountingCode: baseacccode
-AstAccountHost: dynamic
-preferredLanguage: FR
-AstAccountAMAFlags: billing
-AstAccountContext: ldaptest
-
-
-# A Phone. realmedPassword md5 hash should be the result of
-# echo -n "UID:SIPRealm:Password" | md5sum
-dn: uid=phone-test,dc=myDomain,dc=myDomainExt
-objectClass: top
-objectClass: AstAccount
-objectClass: AstAccountSIP
-uid: phone-test
-AstAccountAccountingCode: acc-phone-base
-AstAccountFullContact: Noone <1234>
-AstAccountCallerID: 1234
-AstAccountBaseDN: uid=phone-base,dc=myDomain,dc=myDomainExt
-realmedPassword: {MD5}f67965da780bf9c70d6e337f938cee6f
-
-
-# extensions,
-dn: ou=extensions,dc=myDomain,dc=myDomainExt
-ou: extensions
-objectClass: top
-objectClass: organizationalUnit
-
-# Extension 100 Priority 1 in context ldaptest
-dn: cn=100-1,ou=extensions,dc=myDomain,dc=myDomainExt
-AstExtensionApplication: NoOp
-AstExtensionApplicationData: TEST LDAP
-objectClass: top
-objectClass: AstExtension
-AstExtensionExten: 100
-AstExtensionContext: ldaptest
-cn: 100-1
-AstExtensionPriority: 1
-
-# Extension 100 Priority 1 in context ldaptest
-dn: cn=100-2,ou=extensions,dc=myDomain,dc=myDomainExt
-objectClass: top
-objectClass: AstExtension
-AstExtensionExten: 100
-AstExtensionContext: ldaptest
-cn: 100-2
-AstExtensionPriority: 2
-AstExtensionApplication: hangup
-
+++ /dev/null
-About the MacroExclusive application
-------------------------------------
-
-Steve Davies <steve@connection-telecom.com
-
-
-The MacroExclusive application was added to solve the problem of
-synchronisation between calls running at the same time.
-
-This is usually an issue when you have calls manipulating global
-variables or the Asterisk database, but may be useful elsewhere.
-
-Consider this example macro, intended to return a "next" number -
-each caller is intended to get a different number:
-
-[macro-next]
-exten => s,1,Set(RESULT=${COUNT})
-exten => s,n,SetGlobalVar(COUNT=$[${COUNT} + 1])
-
-The problem is that in a box with high activity, you can be sure
-that two calls will come along together - both will get the same
-"RESULT", or the "COUNT" value will get mangled.
-
-Calling this Macro via MacroExclusive will use a mutex to make sure
-that only one call executes in the Macro at a time. This ensures
-that the two lines execute as a unit.
-
-Note that even the s,2 line above has its own race problem. Two
-calls running that line at once will step on each other and
-the count will end up as +1 rather than +2.
-
-I've also been able to use MacroExclusive where I have two Macros
-that need to be mutually exclusive.
-
-Here's the example:
-
-[macro-push]
-; push value ${ARG2} onto stack ${ARG1}
-exten => s,1,Set(DB(STACK/${ARG1})=${ARG2}^${DB(STACK/${ARG1})})
-
-[macro-pop]
-; pop top value from stack ${ARG1}
-exten => s,1,Set(RESULT=${DB(STACK/${ARG1})})
-exten => s,n,Set(DB(STACK/${ARG1})=${CUT(RESULT,^,2)})
-exten => s,n,Set(RESULT=${CUT(RESULT,^,1)})
-
-All that futzing with the STACK/${ARG1} in the astdb needs protecting
-if this is to work. But neither push nor pop can run together.
-
-So add this "pattern":
-
-[macro-stack]
-exten => Macro(${ARG1},${ARG2},${ARG3})
-
-... and use it like so:
-
-exten => s,1,MacroExclusive(stack,push,MYSTACK,bananas)
-exten => s,n,MacroExclusive(stack,push,MYSTACK,apples)
-exten => s,n,MacroExclusive(stack,push,MYSTACK,guavas)
-exten => s,n,MacroExclusive(stack,push,MYSTACK,pawpaws)
-exten => s,n,MacroExclusive(stack,pop,MYSTACK) ; RESULT gets pawpaws (yum)
-exten => s,n,MacroExclusive(stack,pop,MYSTACK) ; RESULT gets guavas
-exten => s,n,MacroExclusive(stack,pop,MYSTACK) ; RESULT gets apples
-exten => s,n,MacroExclusive(stack,pop,MYSTACK) ; RESULT gets bananas
-
-We get to the push and pop macros "via" the stack macro. But only one call
-can execute the stack macro at a time; ergo, only one of push OR pop can
-run at a time.
-
-Hope people find this useful.
-
-Lastly, its worth pointing out that only Macros that access shared data
-will require this MacroExclusive protection. And Macro's that you call
-with macroExclusive should run quickly or you will clog up your Asterisk
-system.
-
-Regards,
-Steve
+++ /dev/null
-Changes to manager version 1.1:
--------------------------------
-
-* SYNTAX CLEANUPS
------------------
-
-- Response: headers are now either
- "Success" - Action OK, this message contains response
- "Error" - Action failed, reason in Message: header
- "Follows" - Action OK, response follows in following Events.
-
-- Manager version changed to 1.1
-
-* CHANGED EVENTS AND ACTIONS
-----------------------------
-- The Hold/Unhold events
- - Both are now "Hold" events
- For hold, there's a "Status: On" header, for unhold, status is off
- - Modules chan_sip/chan_iax2
-
-- The Ping Action
- - Now use Response: success
- - New header "Ping: pong" :-)
-
-- The Events action
- - Now use Response: Success
- - The new status is reported as "Events: On" or "Events: Off"
-
-- The JabberSend action
- - The Response: header is now the first header in the response
- - now sends "Response: Error" instead of "Failure"
-
-- Newstate and Newchannel events
- - these have changed headers
- "State" -> ChannelStateDesc Text based channel state
- -> ChannelState Numeric channel state
- - The events does not send "<unknown>" for unknown caller IDs just an empty field
-
-- Newchannel event
- - Now includes "AccountCode"
-
-- Newstate event
- - Now has "CalleridNum" for numeric caller id, like Newchannel
- - The event does not send "<unknown>" for unknown caller IDs just an empty field
-
-- Newexten and VarSet events
- - Now are part of the new Dialplan privilege class, instead of the Call class
-
-- Dial event
- - Event Dial has new headers, to comply with other events
- - Source -> Channel Channel name (caller)
- - SrcUniqueID -> UniqueID Uniqueid
- (new) -> Dialstring Dialstring in app data
-
-- Link and Unlink events
- - The "Link" and "Unlink" bridge events in channel.c are now renamed to "Bridge"
- - The link state is in the bridgestate: header as "Link" or "Unlink"
- - For channel.c bridges, "Bridgetype: core" is added. This opens up for
- bridge events in rtp.c
- - The RTP channel also reports Bridge: events with bridgetypes
- - rtp-native RTP native bridge
- - rtp-direct RTP peer-2-peer bridge (NAT support only)
- - rtp-remote Remote (re-invite) bridge. (Not reported yet)
-
-- The "Rename" manager event has a renamed header, to use the same
- terminology for the current channel as other events
- - Oldname -> Channel
-
-- The "NewCallerID" manager event has a renamed header
- - CallerID -> CallerIDnum
- - The event does not send "<unknown>" for unknown caller IDs just an empty field
-
-- Reload event
- - The "Reload" event sent at manager reload now has a new header and is now implemented
- in more modules than manager to alert a reload. For channels, there's a CHANNELRELOAD
- event to use.
- (new) -> Module: manager | CDR | DNSmgr | RTP | ENUM
- (new) -> Status: enabled | disabled
- - To support reload events from other modules too
- - cdr module added
-
-- Status action replies (Event: Status)
- Header changes
- - link -> BridgedChannel
- - Account -> AccountCode
- - (new) -> BridgedUniqueid
-
-- StatusComplete Event
- New header
- - (new) -> Items Number of channels reported
-
-
-- The ExtensionStatus manager command now has a "StatusDesc" field with text description of the state
-
-- The Registry and Peerstatus events in chan_sip and chan_iax now use "ChannelType" instead of "ChannelDriver"
-
-- The Response to Action: IAXpeers now have a Response: Success header
-
-- The MeetmeJoin now has caller ID name and Caller ID number fields (like MeetMeLeave)
-
-- Action DAHDIShowChannels
- Header changes
- - Channel: -> DAHDIChannel
- For active channels, the Channel: and Uniqueid: headers are added
- You can now add a "DAHDIChannel: " argument to DAHDIshowchannels actions
- to only get information about one channel.
-
-- Event DAHDIShowChannelsComplete
- New header
- - (new) -> Items: Reports number of channels reported
-
-- Action VoicemailUsersList
- Added new headers for SayEnvelope, SayCID, AttachMessage, CanReview
- and CallOperator voicemail configuration settings.
-
-- Action Originate
- Now requires the new Originate privilege.
- If you call out to a subshell in Originate with the Application parameter,
- you now also need the System privilege.
-
-- Event QueueEntry now also returns the Uniqueid field like other events from app_queue.
-
-- Action IAXpeerlist
- Now includes if the IAX link is a trunk or not
-
-- Action IAXpeers
- Now includes if the IAX link is a trunk or not
-
-- Action Ping
- Response now includes a timestamp
-
-- Action SIPshowpeer
- Response now includes the configured parkinglot
-
-- Action SKINNYshowline
- Response now includes the configured parkinglot
-
-* NEW ACTIONS
--------------
-- Action: DataGet
- Modules: data.c
- Purpose:
- To be able to retrieve the asterisk data tree.
- Variables:
- ActionID: <id> Action ID for this transaction. Will be returned.
- Path: <data path> The path to the callback node to retrieve.
- Filter: <filter> Which nodes to retrieve.
- Search: <search> Search condition.
-
-- Action: IAXregistry
- Modules: chan_iax2
- Purpose:
- To list all IAX2 peers in the IAX registry with their registration status.
- Variables:
- ActionID: <id> Action ID for this transaction. Will be returned.
-
-- Action: ModuleLoad
- Modules: loader.c
- Purpose:
- To be able to unload, reload and unload modules from AMI.
- Variables:
- ActionID: <id> Action ID for this transaction. Will be returned.
- Module: <name> Asterisk module name (including .so extension)
- or subsystem identifier:
- cdr, enum, dnsmgr, extconfig, manager, rtp, http
- LoadType: load | unload | reload
- The operation to be done on module
- If no module is specified for a reload loadtype, all modules are reloaded
-
-- Action: ModuleCheck
- Modules: loader.c
- Purpose:
- To check version of a module - if it's loaded
- Variables:
- ActionID: <id> Action ID for this transaction. Will be returned.
- Module: <name> Asterisk module name (not including extension)
- Returns:
- If module is loaded, returns version number of the module
-
- Note: This will have to change. I don't like sending Response: failure
- on both command not found (trying this command in earlier versions of
- Asterisk) and module not found.
- Also, check if other manager actions behave that way.
-
-- Action: QueueSummary
- Modules: app_queue
- Purpose:
- To request that the manager send a QueueSummary event (see the NEW EVENTS
- section for more details).
- Variables:
- ActionID: <id> Action ID for this transaction. Will be returned.
- Queue: <name> Queue for which the summary is desired
-
-- Action: QueuePenalty
- Modules: app_queue
- Purpose:
- To change the penalty of a queue member from AMI
- Variables:
- Interface: <tech/name> The interface of the member whose penalty you wish to change
- Penalty: <number> The new penalty for the member. Must be nonnegative.
- Queue: <name> If specified, only set the penalty for the member for this queue;
- Otherwise, set the penalty for the member in all queues to which
- he belongs.
-
-- Action: QueueRule
- Modules: app_queue
- Purpose:
- To list queue rules defined in queuerules.conf
- Variables:
- Rule: <name> The name of the rule whose contents you wish to list. If this variable
- is not present, all rules in queuerules.conf will be listed.
-
-- Action: Atxfer
- Modules: none
- Purpose:
- Initiate an attended transfer
- Variables:
- Channel: The transferer channel's name
- Exten: The extension to transfer to
- Priority: The priority to transfer to
- Context: The context to transfer to
-
-- Action: SipShowRegistry
- Modules: chan_sip
- Purpose:
- To request that the manager send a list of RegistryEntry events.
- Variables:
- ActionId: <id> Action ID for this transaction. Will be returned.
-
-- Action: QueueReload
- Modules: app_queue
- Purpose:
- To reload queue rules, a queue's members, a queue's parameters, or all of the aforementioned
- Variable:
- Queuename: <name> The name of the queue to take action on. If no queue name is specified, then all queues are affected
- Rules: <yes or no> Whether to reload queue_rules.conf
- Members: <yes or no> Whether to reload the queue's members
- Parameters: <yes or no> Whether to reload the other queue options
-
-- Action: QueueReset
- Modules: app_queue
- Purpose:
- Reset the statistics for a queue
- Variables:
- Queuename: <name> The name of the queue on which to reset statistics
-
-- Action: SKINNYdevices
- Modules: chan_skinny
- Purpose:
- To list all SKINNY devices configured.
- Variables:
- ActionId: <id> Action ID for this transaction. Will be returned.
-
-- Action: SKINNYlines
- Modules: chan_skinny
- Purpose:
- To list all SKINNY lines configured.
- Variables:
- ActionId: <id> Action ID for this transaction. Will be returned.
-
-- Action SKINNYshowdevice
- Modules: chan_skinny
- Purpose:
- To list the information about a specific SKINNY device.
- Variables:
- Device: <device> Device to show information about.
-
-- Action SKINNYshowline
- Modules: chan_skinny
- Purpose:
- To list the information about a specific SKINNY line.
- Variables:
- Line: <line> Line to show information about.
-
-- Action: CoreSettings
- Modules: manager.c
- Purpose: To report core settings, like AMI and Asterisk version,
- maxcalls and maxload settings.
- * Integrated in SVN trunk as of May 4th, 2007
- Example:
- Response: Success
- ActionID: 1681692777
- AMIversion: 1.1
- AsteriskVersion: SVN-oej-moremanager-r61756M
- SystemName: EDVINA-node-a
- CoreMaxCalls: 120
- CoreMaxLoadAvg: 0.000000
- CoreRunUser: edvina
- CoreRunGroup: edvina
-
-- Action: CoreStatus
- Modules: manager.c
- Purpose: To report current PBX core status flags, like
- number of concurrent calls, startup and reload time.
- * Integrated in SVN trunk as of May 4th, 2007
- Example:
- Response: Success
- ActionID: 1649760492
- CoreStartupTime: 22:35:17
- CoreReloadTime: 22:35:17
- CoreCurrentCalls: 20
-
-- Action: MixMonitorMute
- Modules: app_mixmonitor.c
- Purpose:
- Mute / unMute a Mixmonitor recording.
- Variables:
- ActionId: <id> Action ID for this transaction. Will be returned.
- Channel: the channel MixMonitor is running on
- Direction: Which part of the recording to mute: read, write or both (from
- channel, to channel or both channels).
- State: Turn mute on or off : 1 to turn on, 0 to turn off.
-
-* NEW EVENTS
-------------
-
-- Event: FullyBooted
- Modules: loader.c
- Purpose:
- It is handy to have a single event notification for when all Asterisk
- modules have been loaded--especially for situations like running
- automated tests. This event will fire 1) immediately upon all modules
- loading or 2) upon connection to the AMI interface if the modules have
- already finished loading before the connection was made. This ensures
- that a user will never miss getting a FullyBooted event. In vary rare
- circumstances, it might be possible to get two copies of the message
- if the AMI connection is made right as the modules finish loading.
- Example:
- Event: FullyBooted
- Privilege: system,all
- Status: Fully Booted
-
-- Event: Transfer
- Modules: res_features, chan_sip
- Purpose:
- Inform about call transfer, linking transferer with transfer target
- You should be able to trace the call flow with this missing piece
- of information. If it works out well, the "Transfer" event should
- be followed by a "Bridge" event
- The transfermethod: header informs if this is a pbx core transfer
- or something done on channel driver level. For SIP, check the example:
- Example:
-
- Event: Transfer
- Privilege: call,all
- TransferMethod: SIP
- TransferType: Blind
- Channel: SIP/device1-01849800
- SIP-Callid: 091386f505842c87016c4d93195ec67d@127.0.0.1
- TargetChannel: SIP/device2-01841200
- TransferExten: 100
- TransferContext: default
-
-- Event: ChannelUpdate
- Modules: chan_sip.c, chan_iax2.c
- Purpose:
- Updates channel information with ID of PVT in channel driver, to
- be able to link events on channel driver level.
- * Integrated in SVN trunk as of May 4th, 2007
-
- Example:
-
- Event: ChannelUpdate
- Privilege: system,all
- Uniqueid: 1177271625.27
- Channel: SIP/olle-01843c00
- Channeltype: SIP
- SIPcallid: NTQzYWFiOWM4NmE0MWRkZjExMzU2YzQ3OWQwNzg3ZmI.
- SIPfullcontact: sip:olle@127.0.0.1:49054
-
-- Event: NewAccountCode
- Modules: cdr.c
- Purpose: To report a change in account code for a live channel
- Example:
- Event: NewAccountCode
- Privilege: call,all
- Channel: SIP/olle-01844600
- Uniqueid: 1177530895.2
- AccountCode: Stinas account 1234848484
- OldAccountCode: OllesAccount 12345
-
-- Event: ModuleLoadReport
- Modules: loader.c
- Purpose: To report that module loading is complete. Some aggressive
- clients connect very quickly to AMI and needs to know when
- all manager events embedded in modules are loaded
- Also, if this does not happen, something is seriously wrong.
- This could happen to chan_sip and other modules using DNS.
- Example:
- Event: ModuleLoad
- ModuleLoadStatus: Done
- ModuleSelection: All
- ModuleCount: 24
-
-- Event: QueueSummary
- Modules: app_queue
- Purpose: To report a summary of queue information. This event is generated by
- issuing a QueueSummary AMI action.
- Example:
- Event: QueueSummary
- Queue: Sales
- LoggedIn: 12
- Available: 5
- Callers: 10
- HoldTime: 47
- If an actionID was specified for the QueueSummary action, it will be appended as the
- last line of the QueueSummary event.
-
-- Event: AgentRingNoAnswer
- Modules: app_queue
- Purpose: Reports when a queue member was rung but there was no answer.
- Example:
- Event: AgentRingNoAnswer
- Queue: Support
- Uniqueid: 1177530895.2
- Channel: SIP/1000-53aee458
- Member: SIP/1000
- MemberName: Thaddeus McClintock
- Ringtime: 10
-
-- Event: RegistryEntry
- Modules: chan_sip
- Purpose: Reports the state of the SIP registrations. This event is generated by
- issuing a QueueSummary AMI action.
- The RegistrationTime header is expressed as epoch.
- Example:
- Event: RegistryEntry
- Host: sip.myvoipprovider.com
- Port: 5060
- Username: guestuser
- Refresh: 105
- State: Registered
- RegistrationTime: 1219161830
- If an actionID was specified for the SipShowRegistry action, it will be appended as the
- last line of the RegistrationsComplete event.
-
-- Event: ChanSpyStart
- Modules: app_chanspy
- Purpose: Reports when an active channel starts to be monitored by someone.
- Example:
- Event: ChanSpyStart
- SpyerChannel: SIP/4321-13bba124
- SpyeeChannel: SIP/1234-56ecc098
-
-- Event: ChanSpyStop
- Modules: app_chanspy
- Purpose: Reports when an active channel stops to be monitored by someone.
- Example:
- Event: ChanSpyStop
- SpyeeChannel: SIP/1234-56ecc098
-
-* TODO
-------
-
+++ /dev/null
-All modules must have at least the following:
-
-static int load_module():
-
- Do what you need to do when you get started. This function can return
-AST_MODULE_LOAD_FAILURE if an action fails and the module is prevented from loading,
-AST_MODULE_LOAD_DECLINE if the module can not load because of a non-critical failure
-(the configuration file was not found), or AST_MODULE_LOAD_SUCCESS if the module
-loaded fine.
-
-static int unload_module():
-
- The module will soon be unloaded. If any channels are using your
-features, you should give them a softhangup in an effort to keep the
-program from crashing. Generally, unload_module is only called when the
-usecount is 0 or less, but the user can force unloading at their
-discretion, and thus a module should do its best to comply (although in
-some cases there may be no way to avoid a crash). This function should
-return 0 on success and non-zero on failure (i.e. it cannot yet be
-unloaded).
-
-AST_MODULE_INFO_STANDARD(keystr, desc);
-
-keystr: Applicable license for module. In most cases this is ASTERISK_GPL_KEY.
-desc: Description of module.
+++ /dev/null
-
-
-
-
-
-
-
-OSP User Guide for Asterisk V1.6
-9 February 2007
-
-Table of Contents
-
-Revision History 3
-1 Introduction 4
-2 OSP Toolkit 4
-2.1 Build OSP Toolkit 4
-2.1.1 Unpacking the Toolkit 4
-2.1.2 Preparing to build the OSP Toolkit 5
-2.1.3 Building the OSP Toolkit 5
-2.1.4 Installing the OSP Toolkit 6
-2.1.5 Building the Enrollment Utility 6
-2.2 Obtain Crypto Files 6
-3 Asterisk 8
-3.1 Configure for OSP Support 8
-3.1.1 Build Asterisk with OSP Toolkit 8
-3.1.2 osp.conf 8
-3.1.3 extensions.conf 10
-3.1.4 dahdi/sip/iax/h323/ooh323.conf 13
-3.2 OSP Dial Plan Functions 13
-3.2.1 OSPAuth 13
-3.2.2 OSPLookup 14
-3.2.3 OSPNext 14
-3.2.4 OSPFinish 15
-3.3 extensions.conf Examples 15
-3.3.1 Source Gateway 15
-3.3.2 Destination Gateway 17
-3.3.3 Proxy 18
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Asterisk is a trademark of Digium, Inc.
-TransNexus and OSP Secures are trademarks of TransNexus, Inc.
-
-Revision History
-Revision Date of Issue Description
-
-1 26 Jul 2005 OSP Module User Guide for Asterisk V1.2
-1.4 16 Jun 2006 OSP Module User Guide for Asterisk V1.4
-1.6.0 13 Dec 2006 OSP Module User Guide for Asterisk V1.6
-1.6.1 4 Jan 2007 Clarifying edits, add revision history, add general
- purpose extensions.conf example
-1.6.2 9 Feb 2007 Replace OSP Toolkit site from SIPfoundry with
- SourceForge
-
-
-1 Introduction
-This document provides instructions on how to build and configure Asterisk V1.6 with the OSP Toolkit to enable secure, multi-lateral peering. This document is also available in the Asterisk source package as doc/osp.txt. The OSP Toolkit is an open source implementation of the OSP peering protocol and is freely available from https://sourceforge.net/projects/osp-toolkit. The OSP standard defined by the European Telecommunications Standards Institute (ETSI TS 101 321) www.etsi.org. If you have questions or need help, building Asterisk with the OSP Toolkit, please post your question on the OSP mailing list at https://lists.sourceforge.net/lists/listinfo/osp-toolkit-client.
-
-2 OSP Toolkit
-Please reference the OSP Toolkit document "How to Build and Test the OSP Toolkit\94 available from https://sourceforge.net/projects/osp-toolkit.
-
-2.1 Build OSP Toolkit
-The software listed below is required to build and use the OSP Toolkit:
-* OpenSSL (required for building) - Open Source SSL protocol and Cryptographic Algorithms (version 0.9.7g recommended) from www.openssl.org. Pre-compiled OpenSSL binary packages are not recommended because of the binary compatibility issue.
-* Perl (required for building) - A programming language used by OpenSSL for compilation. Any version of Perl should work. One version of Perl is available from www.activestate.com/Products/ActivePer. If pre-compiled OpenSSL packages are used, Perl package is not required.
-* C compiler (required for building) - Any C compiler should work. The GNU Compiler Collection from www.gnu.org is routinely used for building the OSP Toolkit for testing.
-* OSP Server (required for testing) - Access to any OSP server should work. An open source reference OSP server developed by Cisco System is available at http://www.vovida.org/applications/downloads/openosp/. RAMS, a java based open source OSP server is available at https://sourceforge.net/projects/rams. A free version of the TransNexus commercial OSP server may be downloaded from http://www.transnexus.com/OSP%20Toolkit/Peering_Server/VoIP_Peering_Server.htm.
-
-2.1.1 Unpacking the Toolkit
-After downloading the OSP Toolkit (version 3.3.6 or later release) from www.sourceforge.net, perform the following steps in order:
-
-1) Copy the OSP Toolkit distribution into the directory where it will reside. The default directory for the OSP Toolkit is /usr/src.
-
-2) Un-package the distribution file by executing the following command:
-gunzip \96c OSPToolkit-###.tar.gz | tar xvf \96
-Where ### is the version number separated by underlines. For example, if the version is 3.3.6, then the above command would be:
-gunzip \96c OSPToolkit-3_3_6.tar.gz | tar xvf \96
-A new directory (TK-3_3_6-20060303) will be created within the same directory as the tar file.
-
-3) Go to the TK-3_3_6-20060303 directory by running this command:
-cd TK-3_3_6-20060303
-Within this directory, you will find directories and files similar to what is listed below if the command "ls -F" is executed):
-ls -F
-enroll/
-RelNotes.txt lib/
-README.txt license.txt
-bin/ src/
-crypto/ test/
-include/
-
-2.1.2 Preparing to build the OSP Toolkit
-4) Compile OpenSSL according to the instructions provided with the OpenSSL distribution (You would need to do this only if you don\92t have openssl already).
-
-5) Copy the OpenSSL header files (the *.h files) into the crypto/openssl directory within the osptoolkit directory. The OpenSSL header files are located under the openssl/include/openssl directory.
-
-6) Copy the OpenSSL library files (libcrypto.a and libssl.a) into the lib directory within the osptoolkit directory. The OpenSSL library files are located under the openssl directory.
-Note: Since the Asterisk requires the OpenSSL package. If the OpenSSL package has been installed, steps 4 through 6 are not necessary.
-
-7) Optionally, change the install directory of the OSP Toolkit. Open the Makefile in the /usr/src/TK-3_3_6-20060303/src directory, look for the install path variable \96 INSTALL_PATH, and edit it to be anywhere you want (defaults /usr/local).
-Note: Please change the install path variable only if you are familiar with both the OSP Toolkit and the Asterisk.
-
-2.1.3 Building the OSP Toolkit
-8) From within the OSP Toolkit directory (/usr/src/TK-3_3_6-20060303), start the compilation script by executing the following commands:
-cd src
-make clean; make build
-
-2.1.4 Installing the OSP Toolkit
-The header files and the library of the OSP Toolkit should be installed. Otherwise, you must specify the OSP Toolkit path for the Asterisk.
-
-9) Use the make script to install the Toolkit.
-make install
-The make script is also used to install the OSP Toolkit header files and the library into the INSTALL_PATH specified in the Makefile.
-
-Note: Please make sure you have the rights to access the INSTALL_PATH directory. For example, in order to access /usr/local directory, root privileges are required.
-2.1.5 Building the Enrollment Utility
-Device enrollment is the process of establishing a trusted cryptographic relationship between the VoIP device and the OSP Server. The Enroll program is a utility application for establishing a trusted relationship between an OSP client and an OSP server. Please see the document "Device Enrollment" at http://www.transnexus.com/OSP%20Toolkit/OSP%20Toolkit%20Documents/Device_Enrollment.pdf for more information about the enroll application.
-
-10) From within the OSP Toolkit directory (example: /usr/src/TK-3_3_6-20060303), execute the following commands at the command prompt:
-cd enroll
-make clean; make linux
-Compilation is successful if there are no errors in the compiler output. The enroll program is now located in the OSP Toolkit/bin directory (example: /usr/src/ TK-3_3_6-20060303/bin).
-
-2.2 Obtain Crypto Files
-The OSP module in Asterisk requires three crypto files containing a local certificate (localcert.pem), private key (pkey.pem), and CA certificate (cacert_0.pem). Asterisk will try to load the files from the Asterisk public/private key directory - /var/lib/asterisk/keys. If the files are not present, the OSP module will not start and the Asterisk will not support the OSP protocol. Use the enroll.sh script from the toolkit distribution to enroll Asterisk with an OSP server and obtain the crypto files. Documentation explaining how to use the enroll.sh script (Device Enrollment) to enroll with an OSP server is available at http://www.transnexus.com/OSP%20Toolkit/OSP%20Toolkit%20Documents/Device_Enrollment.pdf. Copy the files generated by the enrollment process to the Asterisk /var/lib/asterisk/keys directory.
-
-Note: The osptestserver.transnexus.com is configured only for sending and receiving non-SSL messages, and issuing signed tokens. If you need help, post a message on the OSP mailing list at https://lists.sourceforge.net/lists/listinfo/osp-toolkit-client..
-
-The enroll.sh script takes the domain name or IP addresses of the OSP servers that the OSP Toolkit needs to enroll with as arguments, and then generates pem files \96 cacert_#.pem, certreq.pem, localcert.pem, and pkey.pem. The \91#\92 in the cacert file name is used to differentiate the ca certificate file names for the various SP\92s (OSP servers). If only one address is provided at the command line, cacert_0.pem will be generated. If 2 addresses are provided at the command line, 2 files will be generated \96 cacert_0.pem and cacert_1.pem, one for each SP (OSP server). The example below shows the usage when the client is registering with osptestserver.transnexus.com.
-./enroll.sh osptestserver.transnexus.com
-Generating a 512 bit RSA private key
-........................++++++++++++
-.........++++++++++++
-writing new private key to 'pkey.pem'
------
-You are about to be asked to enter information that will be incorporated
-into your certificate request.
-What you are about to enter is what is called a Distinguished Name or a DN.
-There are quite a few fields but you can leave some blank
-For some fields there will be a default value,
-If you enter '.', the field will be left blank.
------
-Country Name (2 letter code) [AU]: _______
-State or Province Name (full name) [Some-State]: _______
-Locality Name (eg, city) []:_______
-Organization Name (eg, company) [Internet Widgits Pty Ltd]: _______
-Organizational Unit Name (eg, section) []:_______
-Common Name (eg, YOUR name) []:_______
-Email Address []:_______
-
-Please enter the following 'extra' attributes
-to be sent with your certificate request
-A challenge password []:_______
-An optional company name []:_______
-
-Error Code returned from openssl command : 0
-
-CA certificate received
-[SP: osptestserver.transnexus.com]Error Code returned from getcacert command : 0
-
-output buffer after operation: operation=request
-output buffer after nonce: operation=request&nonce=1655976791184458
-X509 CertInfo context is null pointer
-Unable to get Local Certificate
-depth=0 /CN=osptestserver.transnexus.com/O=OSPServer
-verify error:num=18:self signed certificate
-verify return:1
-depth=0 /CN=osptestserver.transnexus.com/O=OSPServer
-verify return:1
-The certificate request was successful.
-Error Code returned from localcert command : 0
-The files generated should be copied to the /var/lib/asterisk/keys directory.
-Note: The script enroll.sh requires AT&T korn shell (ksh) or any of its compatible variants. The /usr/src/TK-3_3_6-20060303/bin directory should be in the PATH variable. Otherwise, enroll.sh cannot find the enroll file.
-
-3 Asterisk
-In Asterisk, all OSP support is implemented as dial plan functions. In Asterisk V1.6, all combinations of routing between OSP and non-OSP enabled networks using any combination of SIP, H.323 and IAX protocols are fully supported. Section
-3.1 describes the three easy steps to add OSP support to Asterisk:
-1. Build Asterisk with OSP Toolkit
-2. Configure osp.conf file
-3. Cut and paste to extensions.conf
-Sections 3.2 and 3.3 provide a detailed explanation of OSP dial plan functions and configuration examples. The detailed information provided in Sections 3.2 and 3.3 is not required for operating Asterisk with OSP, but may be helpful to developers who want to customize their Asterisk OSP implementation.
-
-3.1 Configure for OSP Support
-3.1.1 Build Asterisk with OSP Toolkit
-The first step is to build Asterisk with the OSP Toolkit. If the OSP Toolkit is installed in the default install directory, /usr/local, no additional configuration is required. Compile Asterisk according to the instructions provided with the Asterisk distribution.
-If the OSP Toolkit is installed in another directory, such as /myosp, Asterisk must be configured with the location of the OSP Toolkit. See the example below.
---with-osptk=/myosp
-Note: Please change the install path only if you familiar with both the OSP Toolkit and the Asterisk. Otherwise, the change may result in Asterisk not supporting the OSP protocol.
-
-3.1.2 osp.conf
-The /etc/asterisk/osp.conf file, shown below, contains configuration parameters for using OSP. Two parameters, servicepoint and source must be configured. The default values for all other parameters will work well for standard OSP implementations.
-;
-; Open Settlement Protocol Sample Configuration File
-;
-; This file contains configuration of OSP server providers that
-; are used by the Asterisk OSP module. The section "general" is
-; reserved for global options. All other sections describe specific
-; OSP Providers. The provider "default" is used when no provider is
-; otherwise specified.
-:
-: The "servicepoint" and "source" parameters must be configured. For
-; most implementations the other parameters in this file can be left
-; unchanged.
-;
-[general]
-;
-; Enable cryptographic acceleration hardware.
-;
-accelerate=no
-;
-; Defines the status of tokens that Asterisk will validate.
-; 0 - signed tokens only
-; 1 - unsigned tokens only
-; 2 - both signed and unsigned
-; The default value is 0, i.e. the Asterisk will only validate signed
-; tokens.
-;
-tokenformat=0
-;
-[default]
-;
-; List all service points (OSP servers) for this provider. Use
-; either domain name or IP address. Most OSP servers use port 5045.
-;
-;servicepoint=http://osptestserver.transnexus.com:5045/osp
-servicepoint=http://OSP server IP:5045/osp
-;
-; Define the "source" device for requesting OSP authorization.
-: This value is usually the domain name or IP address of the
-: the Asterisk server.
-;
-;source=domain name or [IP address in brackets]
-source=[host IP]
-;
-; Define path and file name of crypto files.
-; The default path for crypto file is /var/lib/asterisk/keys. If no
-; path is defined, crypto files should be in
-; /var/lib/asterisk/keys directory.
-;
-; Specify the private key file name.
-; If this parameter is unspecified or not present, the default name
-; will be the osp.conf section name followed by "-privatekey.pem"
-; (for example: default-privatekey.pem)
-;
-privatekey=pkey.pem
-;
-; Specify the local certificate file.
-; If this parameter is unspecified or not present, the default name
-; will be the osp.conf section name followed by "- localcert.pem "
-; (for example: default-localcert.pem)
-;
-localcert=localcert.pem
-;
-; Specify one or more Certificate Authority key file names. If none
-; are listed, a single Certificate Authority key file name is added
-; with the default name of the osp.conf section name followed by
-; "-cacert_0.pem " (for example: default-cacert_0.pem)
-;
-cacert=cacert_0.pem
-;
-; Configure parameters for OSP communication between Asterisk OSP
-; client and OSP servers.
-;
-; maxconnections: Max number of simultaneous connections to the
-; provider OSP server (default=20)
-; retrydelay: Extra delay between retries (default=0)
-; retrylimit: Max number of retries before giving up (default=2)
-; timeout: Timeout for response in milliseconds (default=500)
-;
-maxconnections=20
-retrydelay=0
-retrylimit=2
-timeout=500
-;
-; Set the authentication policy.
-; 0 - NO - Accept all calls.
-; 1 \96 YES - Accept calls with valid token or no token.
-; Block calls with invalid token.
-; 2 \96 EXCLUSIVE \96 Accept calls with valid token.
-; Block calls with invalid token or no token.
-; Default is 1,
-;
-authpolicy=1
-;
-; Set the default destination protocol. The OSP module supports
-; SIP, H323, and IAX protocols. The default protocol is set to SIP.
-;
-defaultprotocol=SIP
-
-3.1.3 extensions.conf
-OSP functions are implemented as dial plan functions in the extensions.conf file. To add OSP support to your Asterisk server, simply copy and paste the text box below to your extensions.conf file. These functions will enable your Asterisk server to support all OSP call scenarios. Configuration of your Asterisk server for OSP is now complete.
-[globals]
-DIALOUT=DAHDI/1
-
-[SrcGW] ; OSP Source Gateway
-exten => _XXXX.,1,NoOp(OSPSrcGW)
-; Set calling number if necessary
-exten => _XXXX.,n,Set(CALLERID(numner)=1234567890)
-; OSP lookup using default provider, if fail/error jump to lookup+101
-exten => _XXXX.,n(lookup),OSPLookup(${EXTEN}||j)
-; Deal with outbound call according to protocol
-exten => _XXXX.,n,Macro(outbound)
-; Dial to destination, 60 timeout, with call duration limit
-exten => _XXXX.,n,Dial(${OSPDIALSTR},60,oL($[${OSPOUTTIMELIMIT}*1000]))
-; Wait 1 second
-exten => _XXXX.,n,Wait,1
-; Hangup
-exten => _XXXX.,n,Hangup
-; Deal with OSPLookup fail/error
-exten => _XXXX.,lookup+101,Hangup
-exten => h,1,NoOp()
-; OSP report usage
-exten => h,n,OSPFinish(${HANGUPCAUSE})
-
-[DstGW] ; OSP Destination Gateway
-exten => _XXXX.,1,NoOp(OSPDstGW)
-; Deal with inbound call according to protocol
-exten => _XXXX.,n,Macro(inbound)
-; Validate token using default provider, if fail/error jump to auth+101
-exten => _XXXX.,n(auth),OSPAuth(|j)
-; Ringing
-exten => _XXXX.,n,Ringing
-; Wait 1 second
-exten => _XXXX.,n,Wait,1
-; Check inbound call duration limit
-exten => _XXXX.,n,GoToIf($[${OSPINTIMELIMIT}=0]?100:200)
-; Without duration limit
-exten => _XXXX.,100,Dial(${DIALOUT},15,o)
-exten => _XXXX.,n,Goto(1000)
-; With duration limit
-exten => _XXXX.,200,Dial(${DIALOUT},15,oL($[${OSPINTIMELIMIT}*1000]))
-exten => _XXXX.,n,Goto(1000)
-; Wait 1 second
-exten => _XXXX.,1000,Wait,1
-; Hangup
-exten => _XXXX.,n,Hangup
-; Deal with OSPAuth fail/error
-exten => _XXXX.,auth+101,Hangup
-exten => h,1,NoOp()
-; OSP report usage
-exten => h,n,OSPFinish(${HANGUPCAUSE})
-
-[GeneralProxy] ; Proxy
-exten => _XXXX.,1,NoOp(OSP-GeneralProxy)
-; Deal with inbound call according to protocol
-exten => _XXXX.,n,Macro(inbound)
-; Validate token using default provider, if fail/error jump to auth+101
-exten => _XXXX.,n(auth),OSPAuth(|j)
-; OSP lookup using default provider, if fail/error jump to lookup+101
-exten => _XXXX.,n(lookup),OSPLookup(${EXTEN}||j)
-; Deal with outbound call according to protocol
-exten => _XXXX.,n,Macro(outbound)
-; Dial to destination, 14 timeout, with call duration limit
-exten => _XXXX.,n,Dial(${OSPDIALSTR},14,oL($[${OSPOUTTIMELIMIT}*1000]))
-; OSP lookup next destination using default provider, if fail/error jump to next1+101
-exten => _XXXX.,n(next1),OSPNext(${HANGUPCAUSE}||j)
-; Deal with outbound call according to protocol
-exten => _XXXX.,n,Macro(outbound)
-; Dial to destination, 15 timeout, with call duration limit
-exten => _XXXX.,n,Dial(${OSPDIALSTR},15,oL($[${OSPOUTTIMELIMIT}*1000]))
-; OSP lookup next destination using default provider, if fail/error jump to next2+101
-exten => _XXXX.,n(next2),OSPNext(${HANGUPCAUSE}||j)
-; Deal with outbound call according to protocol
-exten => _XXXX.,n,Macro(outbound)
-; Dial to destination, 16 timeout, with call duration limit
-exten => _XXXX.,n,Dial(${OSPDIALSTR},16,oL($[${OSPOUTTIMELIMIT}*1000]))
-; Hangup
-exten => _XXXX.,n,Hangup
-; Deal with OSPAuth fail/error
-exten => _XXXX.,auth+101,Hangup
-; Deal with OSPLookup fail/error
-exten => _XXXX.,lookup+101,Hangup
-; Deal with OSPNext fail/error
-exten => _XXXX.,next1+101,Hangup
-; Deal with OSPNext fail/error
-exten => _XXXX.,next2+101,Hangup
-exten => h,1,NoOp()
-; OSP report usage
-exten => h,n,OSPFinish(${HANGUPCAUSE})
-
-[macro-inbound]
-exten => s,1,NoOp(inbound)
-; Get inbound protocol
-exten => s,n,Set(CHANTECH=${CUT(CHANNEL,/,1)})
-exten => s,n,GoToIf($["${CHANTECH}"="H323"]?100)
-exten => s,n,GoToIf($["${CHANTECH}"="IAX2"]?200)
-exten => s,n,GoToIf($["${CHANTECH}"="SIP"]?300)
-exten => s,n,GoTo(1000)
-; H323 --------------------------------------------------------
-; Get peer IP
-exten => s,100,Set(OSPPEERIP=${H323CHANINFO(peerip)})
-; Get OSP token
-exten => s,n,Set(OSPINTOKEN=${H323CHANINFO(osptoken)})
-exten => s,n,GoTo(1000)
-; IAX ----------------------------------------------------------
-; Get peer IP
-exten => s,200,Set(OSPPEERIP=${IAXPEER(CURRENTCHANNEL)})
-; Get OSP token
-exten => s,n,Set(OSPINTOKEN=${IAXCHANINFO(osptoken)})
-exten => s,n,GoTo(1000)
-; SIP ----------------------------------------------------------
-; Get peer IP
-exten => s,300,Set(OSPPEERIP=${SIPCHANINFO(peerip)})
-; Get OSP token
-exten => s,n,Set(OSPINTOKEN=${SIP_HEADER(P-OSP-Auth-Token)})
-exten => s,n,GoTo(1000)
-; --------------------------------------------------------------
-exten => s,1000,MacroExit
-
-[macro-outbound]
-exten => s,1,NoOp(outbound)
-; Set calling number which may be translated
-exten => s,n,Set(CALLERID(num)=${OSPCALLING})
-; Check destinatio protocol
-exten => s,n,GoToIf($["${OSPTECH}"="H323"]?100)
-exten => s,n,GoToIf($["${OSPTECH}"="IAX2"]?200)
-exten => s,n,GoToIf($["${OSPTECH}"="SIP"]?300)
-; Something wrong
-exten => s,n,Hangup
-exten => s,n,GoTo(1000)
-; H323 --------------------------------------------------------
-; Set call id
-exten => s,100,Set(H323CHANINFO(callid)=${OSPOUTCALLID})
-; Set OSP token
-exten => s,n,Set(H323CHANINFO(osptoken)=${OSPOUTTOKEN})
-exten => s,n,GoTo(1000)
-; IAX ----------------------------------------------------------
-; Set OSP token
-exten => s,200,Set(IAXCHANINFO(osptoken)=${OSPOUTTOKEN})
-exten => s,n,GoTo(1000)
-; SIP ----------------------------------------------------------
-exten => s,300,GoTo(1000)
-; --------------------------------------------------------------
-exten => s,1000,MacroExit
-
-3.1.4 dahdi/sip/iax/h323/ooh323.conf
-There is no configuration required for OSP.
-
-3.2 OSP Dial Plan Functions
-This section provides a description of each OSP dial plan function.
-3.2.1 OSPAuth
-OSP token validation function.
-Input:
-* OSPPEERIP: last hop IP address
-* OSPINTOKEN: inbound OSP token
-* provider: OSP service provider configured in osp.conf. If it is empty, default provider is used.
-* priority jump
-Output:
-* OSPINHANDLE: inbound OSP transaction handle
-* OSPINTIMELIMIT: inbound call duration limit
-* OSPAUTHSTATUS: OSPAuth return value. SUCCESS/FAILED/ERROR
-
-3.2.2 OSPLookup
-OSP lookup function.
-Input:
-* OSPPEERIP: last hop IP address
-* OSPINHANDLE: inbound OSP transaction handle
-* OSPINTIMELIMIT: inbound call duration limit
-* exten: called number
-* provider: OSP service provider configured in osp.conf. If it is empty, default provider is used.
-* priority jump
-* callidtypes: Generate call ID for the outbound call. h: H.323; s: SIP; i: IAX. Only h, H.323, has been implemented.
-Output:
-* OSPOUTHANDLE: outbound transaction handle
-* OSPTECH: outbound protocol
-* OSPDEST: outbound destination IP address
-* OSPCALLED: outbound called nummber
-* OSPCALLING: outbound calling number
-* OSPOUTTOKEN: outbound OSP token
-* OSPRESULTS: number of remaining destinations
-* OSPOUTTIMELIMIT: outbound call duration limit
-* OSPOUTCALLIDTYPES: same as input callidtypes
-* OSPOUTCALLID: outbound call ID. Only for H.323
-* OSPDIALSTR: outbound dial string
-* OSPLOOKUPSTATUS: OSPLookup return value. SUCCESS/FAILED/ERROR
-
-3.2.3 OSPNext
-OSP lookup next function.
-Input:
-* OSPINHANDLE: inbound transaction handle
-* OSPOUTHANDLE: outbound transaction handle
-* OSPINTIMELIMIT: inbound call duration limit
-* OSPOUTCALLIDTYPES: types of call ID generated by Asterisk.
-* OSPRESULTS: number of remain destinations
-* cause: last destination disconnect cause
-* priority jump
-Output:
-* OSPTECH: outbound protocol
-* OSPDEST: outbound destination IP address
-* OSPCALLED: outbound called number
-* OSPCALLING: outbound calling number
-* OSPOUTTOKEN: outbound OSP token
-* OSPRESULTS: number of remain destinations
-* OSPOUTTIMELIMIT: outbound call duration limit
-* OSPOUTCALLID: outbound call ID. Only for H.323
-* OSPDIALSTR: outbound dial string
-* OSPNEXTSTATUS: OSPLookup return value. SUCCESS/FAILED/ERROR
-
-3.2.4 OSPFinish
-OSP report usage function.
-Input:
-* OSPINHANDLE: inbound transaction handle
-* OSPOUTHANDLE: outbound transaction handle
-* OSPAUTHSTATUS: OSPAuth return value
-* OSPLOOKUPTSTATUS: OSPLookup return value
-* OSPNEXTSTATUS: OSPNext return value
-* cause: last destination disconnect cause
-* priority jump
-Output:
-* OSPFINISHSTATUS: OSPLookup return value. SUCCESS/FAILED/ERROR
-
-3.3 extensions.conf Examples
-The extensions.conf file example provided in Section 3.1 is designed to handle all OSP call scenarios when Asterisk is used as a source or destination gateway to the PSTN or as a proxy between VoIP networks. The extenstion.conf examples in this section are designed for specific use cases only.
-3.3.1 Source Gateway
-The examples in this section apply when the Asterisk server is being used as a TDM to VoIP gateway. Calls originate on the TDM network and are converted to VoIP by Asterisk. In these cases, the Asterisk server queries an OSP server to find a route to a VoIP destination. When the call ends, Asterisk sends a CDR to the OSP server.
-For SIP protocol.
-[SIPSrcGW]
-exten => _XXXX.,1,NoOp(SIPSrcGW)
-; Set calling number if necessary
-exten => _XXXX.,n,Set(CALLERID(numner)=CallingNumber)
-; OSP lookup using default provider, if fail/error jump to lookup+101
-exten => _XXXX.,n(lookup),OSPLookup(${EXTEN}||j)
-; Set calling number which may be translated
-exten => _XXXX.,n,Set(CALLERID(num)=${OSPCALLING})
-; Dial to destination, 60 timeout, with call duration limit
-exten => _XXXX.,n,Dial(${OSPDIALSTR},60,oL($[${OSPOUTTIMELIMIT}*1000]))
-; Wait 3 seconds
-exten => _XXXX.,n,Wait,3
-; Hangup
-exten => _XXXX.,n,Hangup
-; Deal with OSPLookup fail/error
-exten => _XXXX.,lookup+101,Hangup
-exten => h,1,NoOp()
-; OSP report usage
-exten => h,n,OSPFinish(${HANGUPCAUSE})
-For IAX protocol.
-[IAXSrcGW]
-exten => _XXXX.,1,NoOp(IAXSrcGW)
-; Set calling number if necessary
-exten => _XXXX.,n,Set(CALLERID(numner)=CallingNumber)
-; OSP lookup using default provider, if fail/error jump to lookup+101
-exten => _XXXX.,n(lookup),OSPLookup(${EXTEN}||j)
-; Set outbound OSP token
-exten => _XXXX.,n,Set(IAXCHANINFO(osptoken)=${OSPOUTTOKEN})
-; Set calling number which may be translated
-exten => _XXXX.,n,Set(CALLERID(num)=${OSPCALLING})
-; Dial to destination, 60 timeout, with call duration limit
-exten => _XXXX.,n,Dial(${OSPDIALSTR},60,oL($[${OSPOUTTIMELIMIT}*1000]))
-; Wait 3 seconds
-exten => _XXXX.,n,Wait,3
-; Hangup
-exten => _XXXX.,n,Hangup
-; Deal with OSPLookup fail/error
-exten => _XXXX.,lookup+101,Hangup
-exten => h,1,NoOp()
-; OSP report usage
-exten => h,n,OSPFinish(${HANGUPCAUSE})
-For H.323 protocol.
-[H323SrcGW]
-exten => _XXXX.,1,NoOp(H323SrcGW)
-; Set calling number if necessary
-exten => _XXXX.,n,Set(CALLERID(numner)=CallingNumber)
-; OSP lookup using default provider, if fail/error jump to lookup+101
-; \93h\94 parameter is used to generate a call id
-; Cisco OSP gateways use this call id to validate OSP token
-exten => _XXXX.,n(lookup),OSPLookup(${EXTEN}||jh)
-; Set outbound call id
-exten => _XXXX.,n,Set(OH323CHANINFO(callid)=${OSPOUTCALLID})
-; Set outbound OSP token
-exten => _XXXX.,n,Set(OH323CHANINFO(osptoken)=${OSPOUTTOKEN})
-; Set calling number which may be translated
-exten => _XXXX.,n,Set(CALLERID(num)=${OSPCALLING})
-; Dial to destination, 60 timeout, with call duration limit
-exten => _XXXX.,n,Dial(${OSPDIALSTR},60,oL($[${OSPOUTTIMELIMIT}*1000]))
-; Wait 3 seconds
-exten => _XXXX.,n,Wait,3
-; Hangup
-exten => _XXXX.,n,Hangup
-; Deal with OSPLookup fail/error
-exten => _XXXX.,lookup+101,Hangup
-exten => h,1,NoOp()
-; OSP report usage
-exten => h,n,OSPFinish(${HANGUPCAUSE})
-
-3.3.2 Destination Gateway
-The examples in this section apply when Asterisk is being used as a VoIP to TDM gateway. VoIP calls are received by Asterisk which validates the OSP peering token and completes to the TDM network. After the call ends, Asterisk sends a CDR to the OSP server.
-For SIP protocol
-[SIPDstGW]
-exten => _XXXX.,1,NoOp(SIPDstGW)
-; Get peer IP
-exten => _XXXX.,n,Set(OSPPEERIP=${SIPCHANINFO(peerip)})
-; Get OSP token
-exten => _XXXX.,n,Set(OSPINTOKEN=${SIP_HEADER(P-OSP-Auth-Token)})
-; Validate token using default provider, if fail/error jump to auth+101
-exten => _XXXX.,n(auth),OSPAuth(|j)
-; Ringing
-exten => _XXXX.,n,Ringing
-; Wait 1 second
-exten => _XXXX.,n,Wait,1
-; Dial phone, timeout 15 seconds, with call duration limit
-exten => _XXXX.,n,Dial(${DIALOUTANALOG}/${EXTEN:1},15,oL($[${OSPINTIMELIMIT}*1000]))
-; Wait 3 seconds
-exten => _XXXX.,n,Wait,3
-; Hangup
-exten => _XXXX.,n,Hangup
-; Deal with OSPAuth fail/error
-exten => _XXXX.,auth+101,Hangup
-exten => h,1,NoOp()
-; OSP report usage
-exten => h,n,OSPFinish(${HANGUPCAUSE})
-For IAX protocol
-[IAXDstGW]
-exten => _XXXX.,1,NoOp(IAXDstGW)
-; Get peer IP
-exten => _XXXX.,n,Set(OSPPEERIP=${IAXPEER(CURRENTCHANNEL)})
-; Get OSP token
-exten => _XXXX.,n,Set(OSPINTOKEN=${IAXCHANINFO(osptoken)})
-; Validate token using default provider, if fail/error jump to auth+101
-exten => _XXXX.,n(auth),OSPAuth(|j)
-; Ringing
-exten => _XXXX.,n,Ringing
-; Wait 1 second
-exten => _XXXX.,n,Wait,1
-; Dial phone, timeout 15 seconds, with call duration limit
-exten => _XXXX.,n,Dial(${DIALOUTANALOG}/${EXTEN:1},15,oL($[${OSPINTIMELIMIT}*1000]))
-; Wait 3 seconds
-exten => _XXXX.,n,Wait,3
-; Hangup
-exten => _XXXX.,n,Hangup
-; Deal with OSPAuth fail/error
-exten => _XXXX.,auth+101,Hangup
-exten => h,1,NoOp()
-; OSP report usage
-exten => h,n,OSPFinish(${HANGUPCAUSE})
-For H.323 protocol
-[H323DstGW]
-exten => _XXXX.,1,NoOp(H323DstGW)
-; Get peer IP
-exten => _XXXX.,n,Set(OSPPEERIP=${H323CHANINFO(peerip)})
-; Get OSP token
-exten => _XXXX.,n,Set(OSPINTOKEN=${H323CHANINFO(osptoken)})
-; Validate token using default provider, if fail/error jump to auth+101
-exten => _XXXX.,n(auth),OSPAuth(|j)
-; Ringing
-exten => _XXXX.,n,Ringing
-; Wait 1 second
-exten => _XXXX.,n,Wait,1
-; Dial phone, timeout 15 seconds, with call duration limit
-exten => _XXXX.,n,Dial(${DIALOUTANALOG}/${EXTEN:1},15,oL($[${OSPINTIMELIMIT}*1000]))
-; Wait 3 seconds
-exten => _XXXX.,n,Wait,3
-; Hangup
-exten => _XXXX.,n,Hangup
-; Deal with OSPAuth fail/error
-exten => _XXXX.,auth+101,Hangup
-exten => h,1,NoOp()
-; OSP report usage
-exten => h,n,OSPFinish(${HANGUPCAUSE})
-
-3.3.3 Proxy
-The example in this section applies when Asterisk is a proxy between two VoIP networks.
-[GeneralProxy]
-exten => _XXXX.,1,NoOp(GeneralProxy)
-; Get peer IP and inbound OSP token
-; SIP, un-comment the following two lines.
-;exten => _XXXX.,n,Set(OSPPEERIP=${SIPCHANINFO(peerip)})
-;exten => _XXXX.,n,Set(OSPINTOKEN=${SIP_HEADER(P-OSP-Auth-Token)})
-; IAX, un-comment the following 2 lines
-;exten => _XXXX.,n,Set(OSPPEERIP=${IAXPEER(CURRENTCHANNEL)})
-;exten => _XXXX.,n,Set(OSPINTOKEN=${IAXCHANINFO(osptoken)})
-; H323, un-comment the following two lines.
-;exten => _XXXX.,n,Set(OSPPEERIP=${OH323CHANINFO(peerip)})
-;exten => _XXXX.,n,Set(OSPINTOKEN=${OH323CHANINFO(osptoken)})
-;---------------------------------------------------------------
-; Validate token using default provider, if fail/error jump to auth+101
-exten => _XXXX.,n(auth),OSPAuth(|j)
-; OSP lookup using default provider, if fail/error jump to lookup+101
-; \93h\94 parameter is used to generate a call id for H.323 destinations
-; Cisco OSP gateways use this call id to validate OSP token
-exten => _XXXX.,n(lookup),OSPLookup(${EXTEN}||jh)
-; Set outbound call id and OSP token
-; IAX, un-comment the following line.
-;exten => _XXXX.,n,Set(IAXCHANINFO(osptoken)=${OSPOUTTOKEN})
-; H323, un-comment the following two lines.
-;exten => _XXXX.,n,Set(OH323CHANINFO(callid)=${OSPOUTCALLID})
-;exten => _XXXX.,n,Set(OH323CHANINFO(osptoken)=${OSPOUTTOKEN})
-;---------------------------------------------------------------
-; Set calling number which may be translated
-exten => _XXXX.,n,Set(CALLERID(num)=${OSPCALLING})
-; Dial to destination, 14 timeout, with call duration limit
-exten => _XXXX.,n,Dial(${OSPDIALSTR},14,oL($[${OSPOUTTIMELIMIT}*1000]))
-; OSP lookup next destination using default provider, if fail/error jump to next1+101
-exten => _XXXX.,n(next1),OSPNext(${HANGUPCAUSE}||j)
-; Set outbound call id and OSP token
-; IAX, un-comment the following line.
-;exten => _XXXX.,n,Set(IAXCHANINFO(osptoken)=${OSPOUTTOKEN})
-; H323, un-comment the following two lines.
-;exten => _XXXX.,n,Set(OH323CHANINFO(callid)=${OSPOUTCALLID})
-;exten => _XXXX.,n,Set(OH323CHANINFO(osptoken)=${OSPOUTTOKEN})
-;---------------------------------------------------------------
-; Set calling number which may be translated
-exten => _XXXX.,n,Set(CALLERID(num)=${OSPCALLING})
-; Dial to destination, 15 timeout, with call duration limit
-exten => _XXXX.,n,Dial(${OSPDIALSTR},15,oL($[${OSPOUTTIMELIMIT}*1000]))
-; OSP lookup next destination using default provider, if fail/error jump to next2+101
-exten => _XXXX.,n(next2),OSPNext(${HANGUPCAUSE}||j)
-; Set outbound call id and OSP token
-; IAX, un-comment the following line.
-;exten => _XXXX.,n,Set(IAXCHANINFO(osptoken)=${OSPOUTTOKEN})
-; H323, un-comment the following two lines.
-;exten => _XXXX.,n,Set(OH323CHANINFO(callid)=${OSPOUTCALLID})
-;exten => _XXXX.,n,Set(OH323CHANINFO(osptoken)=${OSPOUTTOKEN})
-;---------------------------------------------------------------
-; Set calling number which may be translated
-exten => _XXXX.,n,Set(CALLERID(num)=${OSPCALLING})
-; Dial to destination, 16 timeout, with call duration limit
-exten => _XXXX.,n,Dial(${OSPDIALSTR},16,oL($[${OSPOUTTIMELIMIT}*1000]))
-; Hangup
-exten => _XXXX.,n,Hangup
-; Deal with OSPAuth fail/error
-exten => _XXXX.,auth+101,Hangup
-; Deal with OSPLookup fail/error
-exten => _XXXX.,lookup+101,Hangup
-; Deal with 1st OSPNext fail/error
-exten => _XXXX.,next1+101,Hangup
-; Deal with 2nd OSPNext fail/error
-exten => _XXXX.,next2+101,Hangup
-exten => h,1,NoOp()
-; OSP report usage
-exten => h,n,OSPFinish(${HANGUPCAUSE})
-
-19
-
+++ /dev/null
-Asterisk Call Queues
---------------------
-
-<template holder while we wait for input on a good README
- for call queues. Please open a bug report and add text to this
- document>
-
-* General advice on the agent channel
--------------------------------------
-
-* Using dynamic queue members
------------------------------
-
-* SIP channel configuration
----------------------------
-Queues depend on the channel driver reporting the proper state
-for each member of the queue. To get proper signalling on
-queue members that use the SIP channel driver, you need to
-enable a call limit (could be set to a high value so it
-is not put into action) and also make sure that both inbound
-and outbound calls are accounted for.
-
-Example:
-
- [general]
- limitonpeer = yes
-
- [peername]
- type=friend
- call-limit=10
-
-
-* Other references
--------------------
-
-* queuelog.txt
-* queues-with-callback-members.txt
-
-(Should we merge those documents into this?)
+++ /dev/null
-Real-time text in Asterisk
---------------------------
-The SIP channel has support for real-time text conversation calls in Asterisk (T.140).
-This is a way to perform text based conversations in combination with other media,
-most often video. The text is sent character by character as a media stream.
-
-During a call sometimes there are losses of T.140 packets and a solution to that is to
-use redundancy in the media stream (RTP).
-See "http://en.wikipedia.org/wiki/Text_over_IP"http://en.wikipedia.org/wiki/Text_over_IP
-and RFC 5194 for more information.
-
-The supported real-time text codec is t.140.
-Real-time text redundancy support is now available in Asterisk.
-
-ITU-T T.140
------------
-You can find more information about T.140 at www.itu.int. RTP is used for the transport T.140,
-as specified in RFC 4103.
-
-How to enable T.140
--------------------
-In order to enable real-time text with redundancy in Asterisk, modify sip.conf to add:
-
- [general]
- disallow=all
- allow=ulaw
- allow = alaw
- allow=t140
- allow=t140red
- textsupport=yes
- videosupport=yes ; needed for proper SDP handling even if only text and voice calls are handled
- allow=h263 ; at least one video codec as H.261, H.263 or H.263+ is needed.
-
-The codec settings may change, depending on your phones. The important settings here are to allow
-t140 and 140red and enable text support.
-
-General information about real-time text support in Asterisk
-------------------------------------------------------------
-With the configuration above, calls will be supported with any combination of real-time text,
-audio and video.
-
-Text for both t140 and t140red is handled on channel and application level in Asterisk conveyed in
-Text frames, with the subtype "t140". Text is conveyed in such frames usually only containing one or
-a few characters from the real-time text flow. The packetization interval is 300 ms, handled on lower
-RTP level, and transmission redundancy level is 2, causing one original and two redundant transmissions
-of all text so that it is reliable even in high packet loss situations. Transmitting applications do not
-need to bother about the transmission interval. The t140red support handles any buffering needed during
-the packetization intervals.
-
-Clients known to support text, audio/text or audio/video/text calls with Asterisk:
-----------------------------------------------------------------------------------
-
-- Omnitor Allan eC - SIP audio/video/text softphone
-- AuPix APS-50 - audio/video/text softphone.
-- France Telecom eConf –audio/video/text softphone.
-- SIPcon1 - open source SIP audio/text softphone available in Sourceforge.
-
-
-Limitations
------------
-
-A known general problem with Asterisk is that when a client which uses audio/video/T.140 calls to
-an Asterisk with T.140 media offered but video support not specified. In this case Asterisk handles
-the sdp media description (m=) incorrectly, and the sdp response is not created correctly.
-To solve this problem, turn on video support in Asterisk.
-
-Modify sip.conf to add
- [general]
- videosupport=yes
- allow=h263 ; at least one video codec as H.261, H.263 or H.263+ is needed.
-
-The problem with sdp is a bug and is reported to Asterisk bugtracker, it has id 0012434.
-
-Credits
--------
- - Asterisk real-time text support is developed by AuPix
- - Asterisk real-time text redundancy support is developed by Omnitor
-
-The work with Asterisk real-time text redundancy was supported with funding from the National Institute
-on Disability and Rehabilitation Research (NIDRR), U.S. Department of Education, under grant number
-H133E040013 as part of a co-operation between the Telecommunication Access Rehabilitation Engineering
-Research Center of the University of Wisconsin – Trace Center joint with Gallaudet University, and Omnitor.
-Olle E. Johansson, Edvina AB, has been a liason between the Asterisk project and this project.
-
+++ /dev/null
-/*
- * res_config_sqlite - SQLite 2 support for Asterisk
- *
- * This module can be used as a static/RealTime configuration module, and a CDR
- * handler. See the Doxygen documentation for a detailed description of the
- * module, and the configs/ directory for the sample configuration file.
- */
-
-/*
- * Tables for res_config_sqlite.so.
- */
-
-/*
- * RealTime static table.
- */
-CREATE TABLE ast_config (
- id INTEGER,
- cat_metric INT(11) NOT NULL DEFAULT 0,
- var_metric INT(11) NOT NULL DEFAULT 0,
- commented TINYINT(1) NOT NULL DEFAULT 0,
- filename VARCHAR(128) NOT NULL DEFAULT '',
- category VARCHAR(128) NOT NULL DEFAULT 'default',
- var_name VARCHAR(128) NOT NULL DEFAULT '',
- var_val TEXT NOT NULL DEFAULT '',
- PRIMARY KEY (id)
-);
-
-CREATE INDEX ast_config__idx__cat_metric ON ast_config(cat_metric);
-CREATE INDEX ast_config__idx__var_metric ON ast_config(var_metric);
-CREATE INDEX ast_config__idx__filename_commented ON ast_config(filename, commented);
-
-/*
- * CDR table (this table is automatically created if non existent).
- */
-CREATE TABLE ast_cdr (
- id INTEGER,
- clid VARCHAR(80) NOT NULL DEFAULT '',
- src VARCHAR(80) NOT NULL DEFAULT '',
- dst VARCHAR(80) NOT NULL DEFAULT '',
- dcontext VARCHAR(80) NOT NULL DEFAULT '',
- channel VARCHAR(80) NOT NULL DEFAULT '',
- dstchannel VARCHAR(80) NOT NULL DEFAULT '',
- lastapp VARCHAR(80) NOT NULL DEFAULT '',
- lastdata VARCHAR(80) NOT NULL DEFAULT '',
- start DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
- answer DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
- end DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
- duration INT(11) NOT NULL DEFAULT 0,
- billsec INT(11) NOT NULL DEFAULT 0,
- disposition VARCHAR(45) NOT NULL DEFAULT '',
- amaflags INT(11) NOT NULL DEFAULT 0,
- accountcode VARCHAR(20) NOT NULL DEFAULT '',
- uniqueid VARCHAR(32) NOT NULL DEFAULT '',
- userfield VARCHAR(255) NOT NULL DEFAULT '',
- PRIMARY KEY (id)
-);
-
-/*
- * SIP RealTime table.
- */
-CREATE TABLE ast_sip (
- id INTEGER,
- commented TINYINT(1) NOT NULL DEFAULT 0,
- name VARCHAR(80) NOT NULL DEFAULT '',
- host VARCHAR(31) NOT NULL DEFAULT '',
- nat VARCHAR(5) NOT NULL DEFAULT 'no',
- type VARCHAR(6) NOT NULL DEFAULT 'friend',
- accountcode VARCHAR(20) DEFAULT NULL,
- amaflags VARCHAR(13) DEFAULT NULL,
- callgroup VARCHAR(10) DEFAULT NULL,
- callerid VARCHAR(80) DEFAULT NULL,
- cancallforward CHAR(3) DEFAULT 'yes',
- directmedia CHAR(3) DEFAULT 'yes',
- context VARCHAR(80) DEFAULT NULL,
- defaultip VARCHAR(15) DEFAULT NULL,
- dtmfmode VARCHAR(7) DEFAULT NULL,
- fromuser VARCHAR(80) DEFAULT NULL,
- fromdomain VARCHAR(80) DEFAULT NULL,
- insecure VARCHAR(4) DEFAULT NULL,
- language CHAR(2) DEFAULT NULL,
- mailbox VARCHAR(50) DEFAULT NULL,
- md5secret VARCHAR(80) DEFAULT NULL,
- deny VARCHAR(95) DEFAULT NULL,
- permit VARCHAR(95) DEFAULT NULL,
- mask VARCHAR(95) DEFAULT NULL,
- musiconhold VARCHAR(100) DEFAULT NULL,
- pickupgroup VARCHAR(10) DEFAULT NULL,
- qualify CHAR(3) DEFAULT NULL,
- regexten VARCHAR(80) DEFAULT NULL,
- restrictcid CHAR(3) DEFAULT NULL,
- rtptimeout CHAR(3) DEFAULT NULL,
- rtpholdtimeout CHAR(3) DEFAULT NULL,
- secret VARCHAR(80) DEFAULT NULL,
- setvar VARCHAR(100) DEFAULT NULL,
- disallow VARCHAR(100) DEFAULT 'all',
- allow VARCHAR(100) DEFAULT 'g729,ilbc,gsm,ulaw,alaw',
- fullcontact VARCHAR(80) NOT NULL DEFAULT '',
- ipaddr VARCHAR(15) NOT NULL DEFAULT '',
- port INT(11) NOT NULL DEFAULT 0,
- regserver VARCHAR(100) DEFAULT NULL,
- regseconds INT(11) NOT NULL DEFAULT 0,
- username VARCHAR(80) NOT NULL DEFAULT '',
- PRIMARY KEY (id)
- UNIQUE (name)
-);
-
-CREATE INDEX ast_sip__idx__commented ON ast_sip(commented);
-
-/*
- * Dialplan RealTime table.
- */
-CREATE TABLE ast_exten (
- id INTEGER,
- commented TINYINT(1) NOT NULL DEFAULT 0,
- context VARCHAR(80) NOT NULL DEFAULT '',
- exten VARCHAR(40) NOT NULL DEFAULT '',
- priority INT(11) NOT NULL DEFAULT 0,
- app VARCHAR(128) NOT NULL DEFAULT '',
- appdata VARCHAR(128) NOT NULL DEFAULT '',
- PRIMARY KEY (id)
-);
-
-CREATE INDEX ast_exten__idx__commented ON ast_exten(commented);
-CREATE INDEX ast_exten__idx__context_exten_priority ON ast_exten(context, exten, priority);
+++ /dev/null
-Overview
--------
-Asterisk currently supports configurable RTP packetization per codec for
-select RTP-based channels.
-
-Channels
--------
-These channel drivers allow RTP packetization on a user/peer/friend
-or global level:
- chan_sip
- chan_skinny
- chan_h323
- chan_ooh323 (Asterisk-Addons)
- chan_gtalk
- chan_jingle
-
-Configuration
--------
-To set a desired packetization interval on a specific codec,
-append that inteval to the allow= statement.
-
-Example:
-allow=ulaw:30,alaw,g729:60
-
-No packetization is specified in the case of alaw in this example,
-so the default of 20ms is used.
-
-Autoframing
--------
-In addition, chan_sip has the ability to negotiate the desired
-framing at call establishment.
-
-In sip.conf if autoframing=yes is set in the global section, then
-all calls will try to set the packetization based on the remote
-endpoint's preferences. This behaviour depends on the endpoints
-ability to present the desired packetization (ptime:) in the SDP.
-If the endpoint does not include a ptime attribute, the call will
-be established with 20ms packetization.
-
-Autoframing can be set at the global level or on a user/peer/friend
-basis. If it is enabled at the global level, it applies to all
-users/peers/friends regardless of their prefered codec packetization.
-
-Codec framing options
--------
-The following table lists the minimum and maximum values that are
-valid per codec, as well as the increment value used for each.
-Please note that the maximum values here are only recommended
-maximums, and should not exceed the RTP MTU.
-
-Name Min Max Default Increment
-g723 30 300 30 30
-gsm 20 300 20 20
-ulaw 10 150 20 10
-alaw 10 150 20 10
-g726 10 300 20 10
-ADPCM 10 300 20 10
-SLIN 10 70 20 10
-lpc10 20 20 20 20
-g729 10 230 20 10
-speex 10 60 20 10
-ilbc 30 30 30 30
-g726_aal2 10 300 20 10
-
-Invalid framing options are handled based on the following rules:
- 1. If the specified framing is less than the codec's minimum, then
- the minimum value is used.
- 2. If the specific framing is greater than the codec's maximum, then
- the maximum value is used
- 3. If the specificed framing does not meet the increment requirement,
- the specified framing is rounded down to the closest valid
- framing options.
- example allow=ulaw:33 will set the codec to 30ms framing
- 4. If no framing is specified in the allow= directive, then the
- codec default is used.
+++ /dev/null
-What is the problem with SIP retransmits?
------------------------------------------
-
-Sometimes you get messages in the console like these:
-
-- "retrans_pkt: Hanging up call XX77yy - no reply to our critical packet."
-- "retrans_pkt: Cancelling retransmit of OPTIONs"
-
-The SIP protocol is based on requests and replies. Both sides send
-requests and wait for replies. Some of these requests are important.
-In a TCP/IP network many things can happen with IP packets. Firewalls,
-NAT devices, Session Border Controllers and SIP Proxys are in the
-signalling path and they will affect the call.
-
-SIP Call setup - INVITE-200 OK - ACK
-------------------------------------
-To set up a SIP call, there's an INVITE transaction. The SIP software that
-initiates the call sends an INVITE, then wait to get a reply. When a
-reply arrives, the caller sends an ACK. This is a three-way handshake
-that is in place since a phone can ring for a very long time and
-the protocol needs to make sure that all devices are still on line
-when call setup is done and media starts to flow.
-
-- The first reply we're waiting for is often a "100 trying".
- This message means that some type of SIP server has received our
- request and makes sure that we will get a reply. It could be
- the other endpoint, but it could also be a SIP proxy or SBC
- that handles the request on our behalf.
-
-- After that, you often see a response in the 18x class, like
- "180 ringing" or "183 Session Progress". This typically means that our
- request has reached at least one endpoint and something
- is alerting the other end that there's a call coming in.
-
-- Finally, the other side answers and we get a positive reply,
- "200 OK". This is a positive answer. In that message, we get an
- address that goes directly to the device that answers. Remember,
- there could be multiple phones ringing. The address is specified
- by the Contact: header.
-
-- To confirm that we can reach the phone that answered our call,
- we now send an ACK to the Contact: address. If this ACK doesn't
- reach the phone, the call fails. If we can't send an ACK, we
- can't send anything else, not even a proper hangup. Call
- signalling will simply fail for the rest of the call and there's
- no point in keeping it alive.
-
-- If we get an error response to our INVITE, like "Busy" or
- "Rejected", we send the ACK to the same address as we sent the
- INVITE, to confirm that we got the response.
-
-In order to make sure that the whole call setup sequence works and that
-we have a call, a SIP client retransmits messages if there's too much
-delay between request and expected response. We retransmit a number of
-times while waiting for the first response. We retransmit the answer to an
-incoming INVITE while waiting for an ACK. If we get multiple answers,
-we send an ACK to each of them.
-
-If we don't get the ACK or don't get an answer to our INVITE,
-even after retransmissions, we will hangup the call with the first
-error message you see above.
-
-Other SIP requests
-------------------
-Other SIP requests are only based on request - reply. There's
-no ACK, no three-way handshake. In Asterisk we mark some of
-these as CRITICAL - they need to go through for the call to
-work as expected. Some are non-critical, we don't really care
-what happens with them, the call will go on happily regardless.
-
-The qualification process - OPTIONS
------------------------------------
-If you turn on qualify= in sip.conf for a device, Asterisk will
-send an OPTIONS request every minute to the device and check
-if it replies. Each OPTIONS request is retransmitted a number
-of times (to handle packet loss) and if we get no reply, the
-device is considered unreachable. From that moment, we will
-send a new OPTIONS request (with retransmits) every tenth
-second.
-
-Why does this happen?
----------------------
-
-For some reason signalling doesn't work as expected between
-your Asterisk server and the other device. There could be many reasons
-why this happens.
-
-- A NAT device in the signalling path
- A misconfigured NAT device is in the signalling path
- and stops SIP messages.
-- A firewall that blocks messages or reroutes them wrongly
- in an attempt to assist in a too clever way.
-- A SIP middlebox (SBC) that rewrites contact: headers
- so that we can't reach the other side with our reply
- or the ACK.
-- A badly configured SIP proxy that forgets to add
- record-route headers to make sure that signalling works.
-- Packet loss. IP and UDP are unreliable transports. If
- you loose too many packets the retransmits doesn't help
- and communication is impossible. If this happens with
- signalling, media would be unusable anyway.
-
-What can I do?
---------------
-
-Turn on SIP debug, try to understand the signalling that happens
-and see if you're missing the reply to the INVITE or if the
-ACK gets lost. When you know what happens, you've taken the
-first step to track down the problem. See the list above and
-investigate your network.
-
-For NAT and Firewall problems, there are many documents
-to help you. Start with reading sip.conf.sample that is
-part of your Asterisk distribution.
-
-The SIP signalling standard, including retransmissions
-and timers for these, is well documented in the IETF
-RFC 3261.
-
-Good luck sorting out your SIP issues!
-
-/Olle E. Johansson
-
-
--- oej (at) edvina.net, Sweden, 2008-07-22
--- http://www.voip-forum.com
+++ /dev/null
-Asterisk SIP/TLS Transport
-==========================
-
-When using TLS the client will typically check the validity of the
-certificate chain. So that means you either need a certificate that is
-signed by one of the larger CAs, or if you use a self signed certificate
-you must install a copy of your CA certificate on the client.
-
-So far this code has been test with:
-- Asterisk as client and server (TLS and TCP)
-- Polycom Soundpoint IP Phones (TLS and TCP)
- Polycom phones require that the host (ip or hostname) that is
- configured match the 'common name' in the certificate
-- Minisip Softphone (TLS and TCP)
-- Cisco IOS Gateways (TCP only)
-- SNOM 360 (TLS only)
-- Zoiper Biz Softphone (TLS and TCP)
-
-
-sip.conf options
-----------------
-tlsenable=[yes|no]
- Enable TLS server, default is no
-
-tlsbindaddr=<ip address>
- Specify IP address to bind TLS server to, default is 0.0.0.0
-
-tlscertfile=</path/to/certificate>
- The server's certificate file. Should include the key and
- certificate. This is mandatory if your going to run a TLS server.
-
-tlscafile=</path/to/certificate>
- If the server your connecting to uses a self signed certificate
- you should have their certificate installed here so the code can
- verify the authenticity of their certificate.
-
-tlscadir=</path/to/ca/dir>
- A directory full of CA certificates. The files must be named with
- the CA subject name hash value.
- (see man SSL_CTX_load_verify_locations for more info)
-
-tlsdontverifyserver=[yes|no]
- If set to yes, don't verify the servers certificate when acting as
- a client. If you don't have the server's CA certificate you can
- set this and it will connect without requiring tlscafile to be set.
- Default is no.
-
-tlscipher=<SSL cipher string>
- A string specifying which SSL ciphers to use or not use
- A list of valid SSL cipher strings can be found at:
- http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS
-
-
-Sample config
--------------
-
-Here are the relevant bits of config for setting up TLS between 2
-asterisk servers. With server_a registering to server_b
-
-On server_a:
-
-[general]
-tlsenable=yes
-tlscertfile=/etc/asterisk/asterisk.pem
-tlscafile=/etc/ssl/ca.pem ; This is the CA file used to generate both certificates
-register => tls://100:test@192.168.0.100:5061
-
-[101]
-type=friend
-context=internal
-host=192.168.0.100 ; The host should be either IP or hostname and should
- ; match the 'common name' field in the servers certificate
-secret=test
-dtmfmode=rfc2833
-disallow=all
-allow=ulaw
-transport=tls
-port=5061
-
-On server_b:
-[general]
-tlsenable=yes
-tlscertfile=/etc/asterisk/asterisk.pem
-
-[100]
-type=friend
-context=internal
-host=dynamic
-secret=test
-dtmfmode=rfc2833
-disallow=all
-allow=ulaw
-;You can specify transport= and port=5061 for TLS, but its not necessary in
-;the server configuration, any type of SIP transport will work
-;transport=tls
-;port=5061
-
+++ /dev/null
-===============================================================================
-===============================================================================
-=== Asterisk SMDI (Simple Message Desk Interface) integration =================
-===============================================================================
-===============================================================================
-
-===============================================================================
-===== 1) Accessing SMDI information in the dialplan. ==========================
-===============================================================================
-
-There are two dialplan functions that can be used to access the details of
-incoming SMDI messages.
-
-*CLI> core show function SMDI_MSG_RETRIEVE
-
- -= Info about function 'SMDI_MSG_RETRIEVE' =-
-
-[Syntax]
-SMDI_MSG_RETRIEVE(<smdi port>,<search key>[,timeout[,options]])
-
-[Synopsis]
-Retrieve an SMDI message.
-
-[Description]
- This function is used to retrieve an incoming SMDI message. It returns
-an ID which can be used with the SMDI_MSG() function to access details of
-the message. Note that this is a destructive function in the sense that
-once an SMDI message is retrieved using this function, it is no longer in
-the global SMDI message queue, and can not be accessed by any other Asterisk
-channels. The timeout for this function is optional, and the default is
-3 seconds. When providing a timeout, it should be in milliseconds.
- The default search is done on the forwarding station ID. However, if
-you set one of the search key options in the options field, you can change
-this behavior.
- Options:
- t - Instead of searching on the forwarding station, search on the message
- desk terminal.
- n - Instead of searching on the forwarding station, search on the message
- desk number.
-
-
-*CLI> core show function SMDI_MSG
-
- -= Info about function 'SMDI_MSG' =-
-
-[Syntax]
-SMDI_MSG(<message_id>,<component>)
-
-[Synopsis]
-Retrieve details about an SMDI message.
-
-[Description]
- This function is used to access details of an SMDI message that was
-pulled from the incoming SMDI message queue using the SMDI_MSG_RETRIEVE()
-function.
- Valid message components are:
- station - The forwarding station
- callerid - The callerID of the calling party that was forwarded
- type - The call type. The value here is the exact character
- that came in on the SMDI link. Typically, example values
- are: D - Direct Calls, A - Forward All Calls,
- B - Forward Busy Calls, N - Forward No Answer Calls
-
-
-Here is an example of how to use these functions:
-
-; Retrieve the SMDI message that is associated with the number that
-; was called in Asterisk.
-exten => _0XXX,1,Set(SMDI_MSG_ID=${SMDI_MSG_RETRIEVE(/dev/tty0,${EXTEN})})
-
-; Ensure that the message was retrieved.
-exten => _0XXX,n,GotoIf($["x${SMDI_MSG_ID}" != "x"]?processcall:hangup)
-exten => _0XXX,n(hangup),NoOp(No SMDI message retrieved for ${EXTEN})
-
-; Grab the details out of the SMDI message.
-exten => _0XXX,n(processcall),NoOp(Message found for ${EXTEN})
-exten => _0XXX,n,Set(SMDI_EXTEN=${SMDI_MSG(${SMDI_MSG_ID},station)})
-exten => _0XXX,n,Set(SMDI_CID=${SMDI_MSG(${SMDI_MSG_ID},callerid)})
-
-; Map SMDI message types to the right voicemail option. If it is "B", use the
-; busy option. Otherwise, use the unavailable option.
-exten => _0XXX,n,GotoIf($["${SMDI_MSG(${SMDI_MSG_ID},type)}" == "B"]?usebusy:useunavail)
-
-exten => _0XXX,n(usebusy),Set(SMDI_VM_TYPE=b)
-exten => _0XXX,n,Goto(continue)
-
-exten => _0XXX,n,(useunavil),Set(SMDI_VM_TYPE=u)
-
-exten => _0XXX,n(continue),NoOp( Process the rest of the call ... )
-
-
-===============================================================================
-===== 2) Ensuring complete MWI information over SMDI ==========================
-===============================================================================
-
-Another change has been made to ensure that MWI state is properly propagated
-over the SMDI link. This replaces the use of externnotify=smdi for
-voicemail.conf. The issue is that we have to poll mailboxes occasionally for
-changes that were made using an IMAP client. So, this ability was added to
-res_smdi. To configure this, there is a new section in smdi.conf. It looks
-like this:
-
-[mailboxes]
-; This section configures parameters related to MWI handling for the SMDI link.
- ;
-; This option configures the polling interval used to check to see if the
-; mailboxes have any new messages. This option is specified in seconds.
-; The default value is 10 seconds.
-;
-;pollinginterval=10
-;
-; Before specifying mailboxes, you must specify an SMDI interface. All mailbox
-; definitions that follow will correspond to that SMDI interface. If you
-; specify another interface, then all definitions following that will correspond
-; to the new interface.
-;
-; Every other entry in this section of the configuration file is interpreted as
-; a mapping between the mailbox ID on the SMDI link, and the local Asterisk
-; mailbox name. In many cases, they are the same thing, but they still must be
-; listed here so that this module knows which mailboxes it needs to pay
-; attention to.
-;
-; Syntax:
-; <SMDI mailbox ID>=<Asterisk Mailbox Name>[@Asterisk Voicemail Context]
-;
-; If no Asterisk voicemail context is specified, "default" will be assumed.
-;
-;
-;smdiport=/dev/ttyS0
-;2565551234=1234@vmcontext1
-;2565555678=5678@vmcontext2
-;smdiport=/dev/ttyS1
-;2565559999=9999
-
-===============================================================================
-===============================================================================
-===============================================================================
+++ /dev/null
-* The SMS application
----------------------
-SMS() is an application to handles calls to/from text message capable phones and
-message centres using ETSI ES 201 912 protocol 1 FSK messaging over analog calls.
-
-Basically it allows sending and receiving of text messages over the PSTN. It is
-compatible with BT Text service in the UK and works on ISDN and PSTN lines. It is
-designed to connect to an ISDN or DAHDI interface directly and uses FSK so would
-probably not work over any sort of compressed link (like a VoIP call using GSM codec).
-
-Typical applications include:-
-
-1. Connection to a message centre to send text messages - probably initiated via the
- manager interface or "outgoing" directory
-2. Connection to an POTS line with an SMS capable phone to send messages - probably
- initiated via the manager interface or "outgoing" directory
-3. Acceptance of calls from the message centre (based on CLI) and storage of
- received messages
-4. Acceptance of calls from a POTS line with an SMS capable phone and storage of
- received messages
-
-* Arguments to sms():
-
-- First argument is queue name
-- Second is options:
- a: SMS() is to act as the answering side, and so send the initial FSK frame
- s: SMS() is to act as a service centre side rather than as terminal equipment
-
-- If a third argument is specified, then SMS does not handle the call at all,
- but takes the third argument as a destination number to send an SMS to
-- The forth argument onward is a message to be queued to the number in the
- third argument. All this does is create the file in the me-sc directory.
- If 's' is set then the number is the source
- address and the message placed in the sc-me directory.
-
-All text messages are stored in /var/spool/asterisk/sms
-A log is recorded in /var/log/asterisk/sms
-
-There are two subdirectories called sc-me.<queuename> holding all
-messages from service centre to phone, and me-sc.<queuename> holding all
-messages from phone to service centre.
-
-In each directory are messages in files, one per file, using any filename not
-starting with a dot.
-
-When connected as a service centre, SMS(s) will send all messages waiting in
-the sc-me-<queuename> directory, deleting the files as it goes. Any
-received in this mode are placed in the me-sc-<queuename> directory.
-
-When connected as a client, SMS() will send all messages waiting in the
-me-sc-<queuename> directory, deleting the files as it goes. Any received in
-this mode are placed in the sc-me-<queuename> directory.
-
-Message files created by SMS() use a time stamp/reference based filename.
-
-The format of the sms file is lines that have the form of key=value
-Keys are :
-
-oa Originating Address
- Telephone number, national number if just digits
- Telephone number starting with + then digits for international
- Ignored on sending messages to service centre (CLI used)
-da Destination Address
- Telephone number, national number if just digits
- Telephone number starting with + then digits for international
-scts Service Centre Time Stamp
- In the format YYYY-MM-DD HH:MM:SS
-pid Protocol Identifier (decimal octet value)
-dcs Data coding scheme (decimal octet value)
-mr Message reference (decimal octet value)
-ud The message (see escaping below)
-srr 0/1 Status Report Request
-rp 0/1 Return Path
-vp mins validity period
-
-Omitted fields have default values.
-
-Note that there is special format for ud, ud# instead of ud= which is followed
-by raw hex (2 characters per octet). This is used in output where characters
-other than 10,13,32-126,128-255 are included in the data. In this case a comment (line
-starting ;) is added showing the printable characters
-
-When generating files to send to a service centre, only da and ud need be
-specified. oa is ignored.
-
-When generating files to send to a phone, only oa and ud need be specified. da is ignored.
-
-When receiving a message as a service centre, only the destination address is
-sent, so the originating address is set to the callerid.
-
-EXAMPLES
-
-The following are examples of use within the UK using BT Text SMS/landline
-service.
-
-This is a context to use with a manager script.
-
-[smsdial]
-; create and send a text message, expects number+message and
-; connect to 17094009
-exten => _X.,1,SMS(${CALLERIDNUM},,${EXTEN},${CALLERIDNAME})
-exten => _X.,n,SMS(${CALLERIDNUM})
-exten => _X.,n,Hangup
-
-The script sends
-
- action: originate
- callerid: message <from>
- exten: to
- channel: Local/17094009
- context: smsdial
- priority: 1
-
-You put the message as the name of the caller ID (messy, I know), the
-originating number and hence queue name as the number of the caller ID and the
-exten as the number to which the sms is to be sent. The context uses SMS to
-create the message in the queue and then SMS to communicate with 17094009 to
-actually send the message.
-
-Note that the 9 on the end of 17094009 is the sub address 9 meaning no sub
-address (BT specific). If a different digit is used then that is the sub
-address for the sending message source address (appended to the outgoing CLI
-by BT).
-
-For incoming calls you can use a context like this :-
-
-[incoming]
-exten => _XXXXXX/_8005875290,1,SMS(${EXTEN:3},a)
-exten => _XXXXXX/_8005875290,n,System(/usr/lib/asterisk/smsin ${EXTEN:3})
-exten => _XXXXXX/_80058752[0-8]0,1,SMS(${EXTEN:3}${CALLERIDNUM:8:1},a)
-exten => _XXXXXX/_80058752[0-8]0,n,System(/usr/lib/asterisk/smsin ${EXTEN>:3}${CALLERIDNUM:8:1})
-exten => _XXXXXX/_80058752[0-8]0,n,Hangup
-
-
-In this case the called number we get from BT is 6 digits (XXXXXX) and we are
-using the last 3 digits as the queue name.
-
-Priority 1 causes the SMS to be received and processed for the incoming call.
-It is from 080058752X0. The two versions handle the queue name as 3 digits (no
-sub address) or 4 digits (with sub address). In both cases, after the call a
-script (smsin) is run - this is optional, but is useful to actually processed
-the received queued SMS. In our case we email them based on the target number.
-Priority 3 hangs up.
-
-If using the CAPI drivers they send the right CLI and so the _800... would be
-_0800...
-
+++ /dev/null
-Asterisk SNMP Support
----------------------
-
-Rudimentary support for SNMP access to Asterisk is available. To build
-this, one needs to have Net-SNMP development headers and libraries on
-the build system, including any libraries Net-SNMP depends on.
-
-Note that on some (many?) Linux-distributions the dependency list in
-the net-snmp-devel list is not complete, and additional packages will
-need to be installed. This is usually seen as configure failing to
-detect net-snmp-devel as the configure script does a sanity check of
-the net-snmp build environment, based on the output of
-'net-snmp-config --agent-libs'.
-
-To see what your distribution requires, run 'net-snmp-config --agent-libs'.
-
-You will receive a response similar to the following:
--L/usr/lib -lnetsnmpmibs -lnetsnmpagent -lnetsnmphelpers -lnetsnmp -ldl
--lrpm -lrpmio -lpopt -lz -lcrypto -lm -lsensors -L/usr/lib/lib -lwrap
--Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE
--L/usr/local/lib
-/usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a
--L/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -lperl -lresolv -lnsl
--ldl -lm -lcrypt -lutil -lpthread -lc
-
-The packages required may include the following:
- * bzip2-devel
- * lm_sensors-devel
- * newt-devel
-
-SNMP support comes in two varieties -- as a sub-agent to a running SNMP
-daemon using the AgentX protocol, or as a full standalone agent. If
-you wish to run a full standalone agent, Asterisk must run as root in
-order to bind to port 161.
-
-Configuring access when running as a full agent is something that is
-left as an exercise to the reader.
-
-To enable access to the Asterisk SNMP subagent from a master SNMP
-daemon, one will need to enable AgentX support, and also make sure that
-Asterisk will be able to access the Unix domain socket. One way of
-doing this is to add the following to /etc/snmp/snmpd.conf:
-
- # Enable AgentX support
- master agentx
-
- # Set permissions on AgentX socket and containing
- # directory such that process in group 'asterisk'
- # will be able to connect
- agentXPerms 0660 0550 nobody asterisk
-
-This assumes that you run Asterisk under group 'asterisk' (and does
-not care what user you run as).
+++ /dev/null
-The Asterisk Speech Recognition API
-===================================
-
-The generic speech recognition engine is implemented in the res_speech.so module.
-This module connects through the API to speech recognition software, that is
-not included in the module.
-
-To use the API, you must load the res_speech.so module before any connectors.
-For your convenience, there is a preload line commented out in the modules.conf
-sample file.
-
-* Dialplan Applications:
-------------------------
-
-The dialplan API is based around a single speech utilities application file,
-which exports many applications to be used for speech recognition. These include an
-application to prepare for speech recognition, activate a grammar, and play back a
-sound file while waiting for the person to speak. Using a combination of these applications
-you can easily make a dialplan use speech recognition without worrying about what
-speech recognition engine is being used.
-
-- SpeechCreate(Engine Name):
-
-This application creates information to be used by all the other applications.
-It must be called before doing any speech recognition activities such as activating a
-grammar. It takes the engine name to use as the argument, if not specified the default
-engine will be used.
-
-If an error occurs are you are not able to create an object, the variable ERROR will be
-set to 1. You can then exit your speech recognition specific context and play back an
-error message, or resort to a DTMF based IVR.
-
-- SpeechLoadGrammar(Grammar Name|Path):
-
-Loads grammar locally on a channel. Note that the grammar is only available as long as the
-channel exists, and you must call SpeechUnloadGrammar before all is done or you may cause a
-memory leak. First argument is the grammar name that it will be loaded as and second
-argument is the path to the grammar.
-
-- SpeechUnloadGrammar(Grammar Name):
-
-Unloads a locally loaded grammar and frees any memory used by it. The only argument is the
-name of the grammar to unload.
-
-- SpeechActivateGrammar(Grammar Name):
-
-This activates the specified grammar to be recognized by the engine. A grammar tells the
-speech recognition engine what to recognize, and how to portray it back to you in the
-dialplan. The grammar name is the only argument to this application.
-
-- SpeechStart():
-
-Tell the speech recognition engine that it should start trying to get results from audio
-being fed to it. This has no arguments.
-
-- SpeechBackground(Sound File|Timeout):
-
-This application plays a sound file and waits for the person to speak. Once they start
-speaking playback of the file stops, and silence is heard. Once they stop talking the
-processing sound is played to indicate the speech recognition engine is working. Note it is
-possible to have more then one result. The first argument is the sound file and the second is the
-timeout. Note the timeout will only start once the sound file has stopped playing.
-
-- SpeechDeactivateGrammar(Grammar Name):
-
-This deactivates the specified grammar so that it is no longer recognized. The
-only argument is the grammar name to deactivate.
-
-- SpeechProcessingSound(Sound File):
-
-This changes the processing sound that SpeechBackground plays back when the speech
-recognition engine is processing and working to get results. It takes the sound file as the
-only argument.
-
-- SpeechDestroy():
-
-This destroys the information used by all the other speech recognition applications.
-If you call this application but end up wanting to recognize more speech, you must call
-SpeechCreate again before calling any other application. It takes no arguments.
-
-* Getting Result Information:
------------------------------
-
-The speech recognition utilities module exports several dialplan functions that you can use to
-examine results.
-
-- ${SPEECH(status)}:
-
-Returns 1 if SpeechCreate has been called. This uses the same check that applications do to see if a
-speech object is setup. If it returns 0 then you know you can not use other speech applications.
-
-- ${SPEECH(spoke)}:
-
-Returns 1 if the speaker spoke something, or 0 if they were silent.
-
-- ${SPEECH(results)}:
-
-Returns the number of results that are available.
-
-- ${SPEECH_SCORE(result number)}:
-
-Returns the score of a result.
-
-- ${SPEECH_TEXT(result number)}:
-
-Returns the recognized text of a result.
-
-- ${SPEECH_GRAMMAR(result number)}:
-
-Returns the matched grammar of the result.
-
-- SPEECH_ENGINE(name)=value
-
-Sets a speech engine specific attribute.
-
-* Dialplan Flow:
------------------
-
-1. Create a speech recognition object using SpeechCreate()
-2. Activate your grammars using SpeechActivateGrammar(Grammar Name)
-3. Call SpeechStart() to indicate you are going to do speech recognition immediately
-4. Play back your audio and wait for recognition using SpeechBackground(Sound File|Timeout)
-5. Check the results and do things based on them
-6. Deactivate your grammars using SpeechDeactivateGrammar(Grammar Name)
-7. Destroy your speech recognition object using SpeechDestroy()
-
-* Dialplan Examples:
-
-This is pretty cheeky in that it does not confirmation of results. As well the way the
-grammar is written it returns the person's extension instead of their name so we can
-just do a Goto based on the result text.
-
-- Grammar: company-directory.gram
-
-#ABNF 1.0;
-language en-US;
-mode voice;
-tag-format <lumenvox/1.0>;
-root $company_directory;
-
-$josh = ((Joshua | Josh) [Colp]):"6066";
-$mark = (Mark [Spencer] | Markster):"4569";
-$kevin = (Kevin [Fleming]):"2567";
-
-$company_directory = ($josh | $mark | $kevin) { $ = $$ };
-
-- Dialplan logic
-
- [dial-by-name]
- exten => s,1,SpeechCreate()
- exten => s,2,SpeechActivateGrammar(company-directory)
- exten => s,3,SpeechStart()
- exten => s,4,SpeechBackground(who-would-you-like-to-dial)
- exten => s,5,SpeechDeactivateGrammar(company-directory)
- exten => s,6,Goto(internal-extensions-${SPEECH_TEXT(0)})
-
-- Useful Dialplan Tidbits:
-
-A simple macro that can be used for confirm of a result. Requires some sound files.
-ARG1 is equal to the file to play back after "I heard..." is played.
-
- [macro-speech-confirm]
- exten => s,1,SpeechActivateGrammar(yes_no)
- exten => s,2,Set(OLDTEXT0=${SPEECH_TEXT(0)})
- exten => s,3,Playback(heard)
- exten => s,4,Playback(${ARG1})
- exten => s,5,SpeechStart()
- exten => s,6,SpeechBackground(correct)
- exten => s,7,Set(CONFIRM=${SPEECH_TEXT(0)})
- exten => s,8,GotoIf($["${SPEECH_TEXT(0)}" = "1"]?9:10)
- exten => s,9,Set(CONFIRM=yes)
- exten => s,10,Set(CONFIRMED=${OLDTEXT0})
- exten => s,11,SpeechDeactivateGrammar(yes_no)
-
-* The Asterisk Speech Recognition C API
----------------------------------------
-
-The module res_speech.so exports a C based API that any developer can use to speech
-recognize enable their application. The API gives greater control, but requires the
-developer to do more on their end in comparison to the dialplan speech utilities.
-
-For all API calls that return an integer value, a non-zero value indicates an error has occurred.
-
-- Creating a speech structure:
-
- struct ast_speech *ast_speech_new(char *engine_name, int format)
-
- struct ast_speech *speech = ast_speech_new(NULL, AST_FORMAT_SLINEAR);
-
-This will create a new speech structure that will be returned to you. The speech recognition
-engine name is optional and if NULL the default one will be used. As well for now format should
-always be AST_FORMAT_SLINEAR.
-
-- Activating a grammar:
-
- int ast_speech_grammar_activate(struct ast_speech *speech, char *grammar_name)
-
- res = ast_speech_grammar_activate(speech, "yes_no");
-
-This activates the specified grammar on the speech structure passed to it.
-
-- Start recognizing audio:
-
- void ast_speech_start(struct ast_speech *speech)
-
- ast_speech_start(speech);
-
-This essentially tells the speech recognition engine that you will be feeding audio to it from
-then on. It MUST be called every time before you start feeding audio to the speech structure.
-
-- Send audio to be recognized:
-
- int ast_speech_write(struct ast_speech *speech, void *data, int len)
-
- res = ast_speech_write(speech, fr->data, fr->datalen);
-
-This writes audio to the speech structure that will then be recognized. It must be written
-signed linear only at this time. In the future other formats may be supported.
-
-- Checking for results:
-
-The way the generic speech recognition API is written is that the speech structure will
-undergo state changes to indicate progress of recognition. The states are outlined below:
-
- AST_SPEECH_STATE_NOT_READY - The speech structure is not ready to accept audio
- AST_SPEECH_STATE_READY - You may write audio to the speech structure
- AST_SPEECH_STATE_WAIT - No more audio should be written, and results will be available soon.
- AST_SPEECH_STATE_DONE - Results are available and the speech structure can only be used again by
- calling ast_speech_start
-
-It is up to you to monitor these states. Current state is available via a variable on the speech
-structure. (state)
-
-- Knowing when to stop playback:
-
-If you are playing back a sound file to the user and you want to know when to stop play back because the
-individual started talking use the following.
-
- ast_test_flag(speech, AST_SPEECH_QUIET) - This will return a positive value when the person has started talking.
-
-- Getting results:
-
- struct ast_speech_result *ast_speech_results_get(struct ast_speech *speech)
-
- struct ast_speech_result *results = ast_speech_results_get(speech);
-
-This will return a linked list of result structures. A result structure looks like the following:
-
- struct ast_speech_result {
- char *text; /*!< Recognized text */
- int score; /*!< Result score */
- char *grammar; /*!< Matched grammar */
- struct ast_speech_result *next; /*!< List information */
- };
-
-- Freeing a set of results:
-
- int ast_speech_results_free(struct ast_speech_result *result)
-
- res = ast_speech_results_free(results);
-
-This will free all results on a linked list. Results MAY NOT be used as the memory will have been freed.
-
-- Deactivating a grammar:
-
- int ast_speech_grammar_deactivate(struct ast_speech *speech, char *grammar_name)
-
- res = ast_speech_grammar_deactivate(speech, "yes_no");
-
-This deactivates the specified grammar on the speech structure.
-
-- Destroying a speech structure:
-
- int ast_speech_destroy(struct ast_speech *speech)
-
- res = ast_speech_destroy(speech);
-
-This will free all associated memory with the speech structure and destroy it with the speech recognition engine.
-
-- Loading a grammar on a speech structure:
-
- int ast_speech_grammar_load(struct ast_speech *speech, char *grammar_name, char *grammar)
-
- res = ast_speech_grammar_load(speech, "builtin:yes_no", "yes_no");
-
-- Unloading a grammar on a speech structure:
-
-If you load a grammar on a speech structure it is preferred that you unload it as well,
-or you may cause a memory leak. Don't say I didn't warn you.
-
- int ast_speech_grammar_unload(struct ast_speech *speech, char *grammar_name)
-
- res = ast_speech_grammar_unload(speech, "yes_no");
-
-This unloads the specified grammar from the speech structure.
+++ /dev/null
-("Taken from the README in libss7")
-Tested Switches:
-================
-Siemens EWSD - (ITU style) MTP2 and MTP3 comes up, ISUP inbound and outbound calls work as well.
-DTI DXC 4K - (ANSI style) 56kbps link, MTP2 and MTP3 come up, ISUP inbound and outbound calls work as well.
-Huawei M800 - (ITU style) MTP2 and MTP3 comes up, ISUP National, International inbound and outbound calls work as well, CallerID presentation&screening work.
-and MORE~!
-
-Thanks:
-=======
-Mark Spencer, for writing Asterisk and libpri and being such a great friend and boss.
-
-Luciano Ramos, for donating a link in getting the first "real" ITU switch working.
-
-Collin Rose and John Lodden, John for introducing me to Collin, and Collin for the first
-"real" ANSI link and for holding my hand through the remaining changes that had to be
-done for ANSI switches.
-
-To Use:
-=======
-In order to use libss7, you must get at least the following versions of DAHDI and Asterisk:
-DAHDI: 2.0.x
-libss7: trunk (currently, there *only* is a trunk release).
-Asterisk: 1.6.x
-
-You must then do a `make; make install` in each of the directories that you installed
-in the given order (DAHDI first, libss7 second, and Asterisk last).
-
-NOTE: In order to check out the code, you must have the subversion client installed. This
-is how to check them out from the public subversion server.
-
-These are the commands you would type to install them:
-
-`svn co http://svn.digium.com/svn/dahdi/linux/trunk dahdi-trunk`
-`cd dahdi-trunk`
-`make; make install`
-
-`svn co http://svn.digium.com/svn/dahdi/tools/trunk dahdi-tools`
-`cd dahdi-tools`
-`./configure; make; make install`
-
-`svn co http://svn.digium.com/svn/libss7/trunk libss7-trunk`
-`cd libss7-trunk`
-`make; make install`
-
-`svn co http://svn.digium.com/svn/asterisk/trunk asterisk-trunk`
-`cd asterisk-trunk`
-`./configure; make; make install;`
-
-This should build DAHDI, libss7, and Asterisk with SS7 support.
-
-In the past, there was a special asterisk-ss7 branch to use which contained the SS7 code.
-That code has been merged back into the trunk version of Asterisk, and the old asterisk-ss7
-branch has been deprecated and removed. If you are still using the asterisk-ss7 branch, it
-will not work against the current version of libss7, and you should switch to asterisk-trunk
-instead.
-
-CONFIGURATION:
-In /etc/dahdi/system.conf, your signalling channel(s) should be a "dchan" and your bearers should
-be set as "bchan".
-
-The sample chan_dahdi.conf contains sample configuration for setting up an E1 link.
-
-In brief, here is a simple ss7 linkset setup:
-
-signalling = ss7
-ss7type = itu ; or ansi if you are using an ANSI link
-
-linkset = 1 ; Pick a number for your linkset identifier in chan_dahdi.conf
-
-pointcode = 28 ; The decimal form of your point code. If you are using an
- ; ANSI linkset, you can use the xxx-xxx-xxx notation for
- ; specifying your linkset pointcode.
-adjpointcode = 2 ; The point code of the switch adjacent to your linkset
-
-defaultdpc = 3 ; The point code of the switch you want to send your ISUP
- ; traffic to. A lot of the time, this is the same as your
- ; adjpointcode.
-
-; Now we configure our Bearer channels (CICs)
-
-cicbeginswith = 1 ; Number to start counting the CICs from. So if DAHDI/1 to
- ; DAHDI/15 are CICs 1-15, you would set this to 1 before you
- ; declare channel=1-15
-
-channel=1-15 ; Use DAHDI/1-15 and assign them to CICs 1-15
-
-cicbeginswith = 17 ; Now for DAHDI/17 to DAHDI/31, they are CICs 17-31 so we initialize
- ; cicbeginswith to 17 before we declare those channels
-
-channel = 17-31 ; This assigns CICs 17-31 to channels 17-31
-
-sigchan = 16 ; This is where you declare which DAHDI channel is your signalling
- ; channel. In our case it is DAHDI/16. You can add redundant
- ; signalling channels by adding additional sigchan= lines.
-
-; If we want an alternate redundant signalling channel add this
-
-sigchan = 48 ; This would put two signalling channels in our linkset, one at
- ; DAHDI/16 and one at DAHDI/48 which both would be used to send/receive
- ; ISUP traffic.
-
-; End of chan_dahdi.conf
-
-This is how a basic linkset is setup. For more detailed chan_dahdi.conf SS7 config information
-as well as other options available for that file, see the default chan_dahdi.conf that comes
-with the samples in asterisk. If you would like, you can do a `make samples` in your
-asterisk-trunk directory and it will install a sample chan_dahdi.conf for you that contains
-more information about SS7 setup.
-
-For more information, please use the asterisk-ss7 or asterisk-dev mailing
-lists (I monitor them regularly) or email me directly.
-
-Matthew Fredrickson
-creslin@digium.com
-
+++ /dev/null
-include ../../makeopts
-
-pdf: asterisk.pdf
-
-asterisk.pdf: $(wildcard *.tex)
-ifeq ($(findstring rubber,$(RUBBER)),)
- @echo "**********************************************"
- @echo "** You must install the \"rubber\" tool ***"
- @echo "** to generate the Asterisk reference PDF. ***"
- @echo "**********************************************"
-else
- @echo "**********************************************"
- @echo "** The Asterisk reference PDF will now be ***"
- @echo "** generated. When complete, it will be ***"
- @echo "** located at asterisk.pdf. ***"
- @echo "**********************************************"
-ifneq ($(findstring kpsewhich,$(KPATHSEA)),)
-ifeq ($(findstring fncychap.sty,$(shell find `$(KPATHSEA) --expand-braces='$${TEXMF}'| tr -d \! | sed 's/:/ /g'` -name fncychap.sty -print)),)
- @echo
- @echo "WARNING: The fncychap.sty document was not found"
- @echo "On Ubuntu, install the texlive-latex-extra package."
- @echo
- @exit 1
-endif
-endif
- @cp asterisk.tex asterisk.tex.orig
- @sed -e 's/ASTERISKVERSION/$(shell echo $(ASTERISKVERSION) | sed -e 's/\//\\\//g' | sed -e 's/_/\\\\_/g')/' asterisk.tex > asterisk_local.tex
- @mv asterisk_local.tex asterisk.tex
- -@$(RUBBER) --pdf asterisk.tex
- @mv asterisk.tex.orig asterisk.tex
-endif
-
-html:
- @echo "**********************************************"
- @echo "** The Asterisk reference HTML will now be ***"
- @echo "** generated. When complete, it will be ***"
- @echo "** located in the asterisk/ directory. ***"
- @echo "** Note that the latex2html tool is ***"
- @echo "** required for this to work. ***"
- @echo "**********************************************"
- @cp asterisk.tex asterisk.tex.orig
- @sed -e 's/ASTERISKVERSION/$(ASTERISKVERSION)/' asterisk.tex > asterisk_local.tex
- @mv asterisk_local.tex asterisk.tex
- @latex2html asterisk.tex
- @mv asterisk.tex.orig asterisk.tex
-
-txt: asterisk.txt
-
-asterisk.txt: $(wildcard *.tex)
-ifeq ($(findstring catdvi,$(CATDVI)),)
- @echo "**********************************************"
- @echo "** You must install the \"catdvi\" tool ***"
- @echo "** to generate the Asterisk reference TXT. ***"
- @echo "**********************************************"
-else
- @echo "**********************************************"
- @echo "** The Asterisk reference TXT will now be ***"
- @echo "** generated. When complete, it will be ***"
- @echo "** located at asterisk.txt. ***"
- @echo "**********************************************"
-ifneq ($(findstring kpsewhich,$(KPATHSEA)),)
-ifeq ($(findstring fncychap.sty,$(shell find `$(KPATHSEA) --expand-braces='$${TEXMF}'| tr -d \! | sed 's/:/ /g'` -name fncychap.sty -print)),)
- @echo
- @echo "WARNING: The fncychap.sty document was not found"
- @echo "On Ubuntu, install the texlive-latex-extra package."
- @echo
- @exit 1
-endif
-endif
- @cp asterisk.tex asterisk.tex.orig
- @sed -e 's/ASTERISKVERSION/$(ASTERISKVERSION)/' asterisk.tex > asterisk_local.tex
- @mv asterisk_local.tex asterisk.tex
- @latex asterisk.tex
- -@$(CATDVI) -e 1 -U asterisk.dvi | sed -re "s/\[U\+2022\]/*/g" | sed -re "s/\[U\+02C6\]/^/g" | sed -re "s/([^^[:space:]])\s+/\1 /g" > asterisk.txt
- @mv asterisk.tex.orig asterisk.tex
-endif
+++ /dev/null
-Asterisk Reference Documentation
---------------------------------
-
-1) To generate a PDF from this documentation, you will need the rubber tool,
- and all of its dependencies. The web site for this tool is:
-
- http://www.pps.jussieu.fr/~beffara/soft/rubber/
-
- Then, once this tool is installed, running "make pdf" will generate
- the PDF automatically using this tool. The result will be asterisk.pdf.
-
- NOTE: After installing rubber, you will need to re-run the top level
- configure script. It checks to see if rubber is installed, so that the
- asterisk.pdf Makefile target can produce a useful error message when it is
- not installed.
-
-2) To generate HTML from this documentation, you will need the latex2html tool,
- and all of its dependencies. The web site for this tool is:
-
- http://www.latex2html.org/
-
- Then, once this tool is installed, running "make html" will generate the
- HTML documentation. The result will be an asterisk directory full of
- HTML files.
+++ /dev/null
-\section{Introduction}
-
-AEL is a specialized language intended purely for
-describing Asterisk dial plans.
-
-The current version was written by Steve Murphy, and is a rewrite of
-the original version.
-
-This new version further extends AEL, and
-provides more flexible syntax, better error messages, and some missing
-functionality.
-
-AEL is really the merger of 4 different 'languages', or syntaxes:
-
-\begin{itemize}
- \item The first and most obvious is the AEL syntax itself. A BNF is
- provided near the end of this document.
-
- \item The second syntax is the Expression Syntax, which is normally
- handled by Asterisk extension engine, as expressions enclosed in
- \$[...]. The right hand side of assignments are wrapped in \$[ ... ]
- by AEL, and so are the if and while expressions, among others.
-
- \item The third syntax is the Variable Reference Syntax, the stuff
- enclosed in \$\{..\} curly braces. It's a bit more involved than just
- putting a variable name in there. You can include one of dozens of
- 'functions', and their arguments, and there are even some string
- manipulation notation in there.
-
- \item The last syntax that underlies AEL, and is not used
- directly in AEL, is the Extension Language Syntax. The
- extension language is what you see in extensions.conf, and AEL
- compiles the higher level AEL language into extensions and
- priorities, and passes them via function calls into
- Asterisk. Embedded in this language is the Application/AGI
- commands, of which one application call per step, or priority
- can be made. You can think of this as a "macro assembler"
- language, that AEL will compile into.
-\end{itemize}
-
-Any programmer of AEL should be familiar with its syntax, of course,
-as well as the Expression syntax, and the Variable syntax.
-
-
-\section{Asterisk in a Nutshell}
-
-Asterisk acts as a server. Devices involved in telephony, like DAHDI
-cards, or Voip phones, all indicate some context that should be
-activated in their behalf. See the config file formats for IAX, SIP,
-dahdi.conf, etc. They all help describe a device, and they all
-specify a context to activate when somebody picks up a phone, or a
-call comes in from the phone company, or a voip phone, etc.
-
-\subsection{Contexts}
-
-Contexts are a grouping of extensions.
-
-Contexts can also include other contexts. Think of it as a sort of
-merge operation at runtime, whereby the included context's extensions
-are added to the contexts making the inclusion.
-
-\subsection{Extensions and priorities}
-
-A Context contains zero or more Extensions. There are several
-predefined extensions. The "s" extension is the "start" extension, and
-when a device activates a context the "s" extension is the one that is
-going to be run. Other extensions are the timeout "t" extension, the
-invalid response, or "i" extension, and there's a "fax" extension. For
-instance, a normal call will activate the "s" extension, but an
-incoming FAX call will come into the "fax" extension, if it
-exists. (BTW, asterisk can tell it's a fax call by the little "beep"
-that the calling fax machine emits every so many seconds.).
-
-Extensions contain several priorities, which are individual
-instructions to perform. Some are as simple as setting a variable to a
-value. Others are as complex as initiating the Voicemail application,
-for instance. Priorities are executed in order.
-
-When the 's" extension completes, asterisk waits until the timeout for
-a response. If the response matches an extension's pattern in the
-context, then control is transferred to that extension. Usually the
-responses are tones emitted when a user presses a button on their
-phone. For instance, a context associated with a desk phone might not
-have any "s" extension. It just plays a dialtone until someone starts
-hitting numbers on the keypad, gather the number, find a matching
-extension, and begin executing it. That extension might Dial out over
-a connected telephone line for the user, and then connect the two
-lines together.
-
-The extensions can also contain "goto" or "jump" commands to skip to
-extensions in other contexts. Conditionals provide the ability to
-react to different stimuli, and there you have it.
-
-\subsection{Macros}
-
-Think of a macro as a combination of a context with one nameless
-extension, and a subroutine. It has arguments like a subroutine
-might. A macro call can be made within an extension, and the
-individual statements there are executed until it ends. At this point,
-execution returns to the next statement after the macro call. Macros
-can call other macros. And they work just like function calls.
-
-\subsection{Applications}
-
-Application calls, like "Dial()", or "Hangup()", or "Answer()", are
-available for users to use to accomplish the work of the
-dialplan. There are over 145 of them at the moment this was written,
-and the list grows as new needs and wants are uncovered. Some
-applications do fairly simple things, some provide amazingly complex
-services.
-
-Hopefully, the above objects will allow you do anything you need to in
-the Asterisk environment!
-
-\section{Getting Started}
-
-The AEL parser (res\_ael.so) is completely separate from the module
-that parses extensions.conf (pbx\_config.so). To use AEL, the only
-thing that has to be done is the module res\_ael.so must be loaded by
-Asterisk. This will be done automatically if using 'autoload=yes' in
-\path{/etc/asterisk/modules.conf}. When the module is loaded, it will look
-for 'extensions.ael' in \path{/etc/asterisk/}. extensions.conf and
-extensions.ael can be used in conjunction with
-each other if that is what is desired. Some users may want to keep
-extensions.conf for the features that are configured in the 'general'
-section of extensions.conf.
-
-To reload extensions.ael, the following command can be issued at the
-CLI:
-
- *CLI$>$ ael reload
-
-\section{Debugging}
-
-Right at this moment, the following commands are available, but do
-nothing:
-
-Enable AEL contexts debug
-
- *CLI$>$ ael debug contexts
-
-Enable AEL macros debug
-
- *CLI$>$ ael debug macros
-
-Enable AEL read debug
-
- *CLI$>$ ael debug read
-
-Enable AEL tokens debug
-
- *CLI$>$ ael debug tokens
-
-Disable AEL debug messages
-
- *CLI$>$ ael no debug
-
-If things are going wrong in your dialplan, you can use the following
-facilities to debug your file:
-
-1. The messages log in \path{/var/log/asterisk}. (from the checks done at load time).
-2. the "show dialplan" command in asterisk
-3. the standalone executable, "aelparse" built in the utils/ dir in the source.
-
-
-\section{About "aelparse"}
-
-You can use the "aelparse" program to check your extensions.ael
-file before feeding it to asterisk. Wouldn't it be nice to eliminate
-most errors before giving the file to asterisk?
-
-aelparse is compiled in the utils directory of the asterisk release.
-It isn't installed anywhere (yet). You can copy it to your favorite
-spot in your PATH.
-
-aelparse has two optional arguments:
-
-\begin{itemize}
- \item -d
- \begin{itemize}
- \item Override the normal location of the config file dir, (usually
- \path{/etc/asterisk}), and use the current directory instead as the
- config file dir. Aelparse will then expect to find the file
- "./extensions.ael" in the current directory, and any included
- files in the current directory as well.
- \end{itemize}
- \item -n
- \begin{itemize}
- \item don't show all the function calls to set priorities and contexts
- within asterisk. It will just show the errors and warnings from
- the parsing and semantic checking phases.
- \end{itemize}
-\end{itemize}
-
-\section{General Notes about Syntax}
-
-Note&nbs
projects / asterisk/asterisk.git / commitdiff