Asterisk.org: Developer Documentation (28 Oct 2009)

Wed Oct 28 15:49:24 2009

## Asterisk developer's documentation

# IAX2 configuration

IAX2 is implemented in chan_iax2.c

- iax.conf Configuration file example

## IAX readme file

    Inter-Asterisk eXchange Protocol
    ================================

    INTRODUCTION
    ------------

    This document is intended as an introduction to the Inter-Asterisk
    eXchange (or simply IAX) protocol.  It provides both a theoretical
    background and practical information on its use.

    WHY IAX
    -------
    The first question most people are thinking at this point is "Why do you
    need another VoIP protocol?  Why didn't you just use SIP or H.323?"

    Well, the answer is a fairly complicated one, but in a nutshell it's like
    this...  Asterisk is intended as a very flexible and powerful
    communications tool.  As such, the primary feature we need from a VoIP
    protocol is the ability to meet our own goals with Asterisk, and one with
    enough flexibility that we could use it as a kind of laboratory for
    inventing and implementing new concepts in the field.  Neither H.323 or
    SIP fit the roles we needed, so we developed our own protocol, which,
    while not standards based, provides a number of advantages over both SIP
    and H.323, some of which are:

    	* Interoperability with NAT/PAT/Masquerade firewalls
    	     IAX seamlessly interoperates through all sorts of NAT and PAT
                 and other firewalls, including the ability to place and
                 receive calls, and transfer calls to other stations.

    	* High performance, low overhead protocol
    	     When running on low-bandwidth connections, or when running
    	     large numbers of calls, optimized bandwidth utilization is
    	     imperative.  IAX uses only 4 bytes of overhead

    	* Internationalization support
    	     IAX transmits language information, so that remote PBX
    	     content can be delivered in the native language of the
    	     calling party.

    	* Remote dialplan polling
    	     IAX allows a PBX or IP phone to poll the availability of a
    	     number from a remote server.  This allows PBX dialplans to
    	     be centralized.

    	* Flexible authentication
    	     IAX supports cleartext, md5, and RSA authentication,
    	     providing flexible security models for outgoing calls and
    	     registration services.

    	* Multimedia protocol
    	     IAX supports the transmission of voice, video, images, text,
    	     HTML, DTMF, and URL's.  Voice menus can be presented in both
    	     audibly and visually.

    	* Call statistic gathering
    	     IAX gathers statistics about network performance (including
    	     latency and jitter, as well as providing end-to-end latency
    	     measurement.

    	* Call parameter communication
    	     Caller*ID, requested extension, requested context, etc are
    	     all communicated through the call.

    	* Single socket design
    	     IAX's single socket design allows up to 32768 calls to be
    	     multiplexed.

    While we value the importance of standards based (i.e. SIP) call handling,
    hopefully this will provide a reasonable explanation of why we developed
    IAX rather than starting with SIP.

    CONFIG FILE CONVENTIONS
    -----------------------
    Lines beginning with '>' represent lines which might appear in an actual
    configuration file.  The '>' is used to help separate them from the
    descriptive text and should not actually be included in the file itself.

    Lines within []'s by themselves represent section labels within the
    configuration file.  like this:

    > [mysection]

    Options are set using the "=" sign, for example

    > myoption = value

    Sometimes an option will have a number of discrete values which it can
    take.  In that case, in the documentation, the options will be listed
    within square brackets (the "[" and "]" ones) separated by the pipe symbol
    ("|").  For example:

    > myoption = [value1|value2|value3]

    means the option "myoption" can be assigned a value of "value1", "value2",
    or "value3".

    Objects, or pseudo-objects are instantiated using the "=>" construct.  For
    example:

    > myobject => parameter

    creates an object called "myobject" with some parameter whose definition
    would be specific to that object.  Note that the config file parser
    considers "=>" and "=" to be equivalent and their use is purely to make
    configuration files more readable and easier to "humanly parse".

    The comment character in Asterisk configuration files is the semicolon
    ";".  The reason it is not "#" is because the "#" symbol can be used as
    parts of extensions and it didn't seem like a good idea to have to escape
    it.

    IAX CONFIGURATION IN ASTERISK
    -----------------------------

    Like everything else in Asterisk, IAX's configuration lies in
    /etc/asterisk -- specifically /etc/asterisk/iax.conf

    The IAX configuration file is a collection of sections, each of which
    (with the exception of the "general" section) represents an entity within
    the IAX scope.

    ------------

    The first section is typically the "general" section.  In this area,
    a number of parameters which affect the entire system are configured.
    Specifically, the default codecs, port and address, jitter behavior, TOS
    bits, and registrations.

    The first line of the "general" section is always:

    > [general]

    Following the first line are a number of other possibilities:

    > bindport = <portnum>

    This sets the port that IAX will bind to.  The default IAX version 1
    port number is 5036.  For IAX version 2, that is now the default in
    Asterisk, the default port is 4569.
    It is recommended that this value not be altered in general.

    > bindaddr = <ipaddr>

    This allows you to bind IAX to a specific local IP address instead of
    binding to all addresses.  This could be used to enhance security if, for
    example, you only wanted IAX to be available to users on your LAN.

    > bandwidth = [low|medium|high]

    The bandwidth selection initializes the codec selection to appropriate
    values for given bandwidths.  The "high" selection enables all codecs and
    is recommended only for 10Mbps or higher connections.  The "medium"
    bandwidth eliminates signed linear, Mu-law and A-law codecs, leaving only
    the codecs which are 32kbps and smaller (with MP3 as a special case).  It
    can be used with broadband connections if desired. "low" eliminates ADPCM
    and MP3 formats, leaving only the G.723.1, GSM, and LPC10.

    > allow = [gsm|lpc10|g723.1|adpcm|ulaw|alaw|mp3|slinear|all]
    > disallow = [gsm|lpc10|g723.1|adpcm|ulaw|alaw|mp3|slinear|all]

    The "allow" and "disallow" allow you to fine tune the codec selection
    beyond the initial bandwidth selection on a codec-by-codec basis.

    The recommended configuration is to select "low" bandwidth and then
    disallow the LPC10 codec just because it doesn't sound very good.

    > jitterbuffer = [yes|no]
    > dropcount = <dropamount>
    > maxjitterbuffer = <max>
    > maxexcessbuffer = <max>

    These parameters control the operation of the jitter buffer.  The
    jitterbuffer should always be enabled unless you expect all your
    connections to be over a LAN.
    * drop count is the maximum number of voice packets to allow to drop
      (out of 100).  Useful values are 3-10.
    * maxjitterbuffer is the maximum amount of jitter buffer to permit to be
      used.
    * maxexcessbuffer is the maximum amount of excess jitter buffer
      that is permitted before the jitter buffer is slowly shrunk to eliminate
      latency.
    * minexcessbuffer is the minimum amout of excess jitter buffer

    > accountcode = <code>
    > amaflags = [default|omit|billing|documentation]

    These parameters affect call detail record generation.  The first sets the
    account code for records received with IAX.  The account code can be
    overridden on a per-user basis for incoming calls (see below).  The
    amaflags controls how the record is labeled ("omit" causes no record to be
    written.  "billing" and "documentation" label the records as billing or
    documentation records respectively, and "default" selects the system
    default.

    > tos = [lowdelay|throughput|reliability|mincost|none]

    IAX can optionally set the TOS (Type of Service) bits to specified values
    to help improve performance in routing.  The recommended value is
    "lowdelay", which many routers (including any Linux routers with 2.4
    kernels that have not been altered with ip tables) will give priority to
    these packets, improving voice quality.

    > register => <name>[:<secret>]@<host>[:port]

    Any number of registry entries may be instantiated in the general
    section.  Registration allows Asterisk to notify a remote Asterisk server
    (with a fixed address) what our current address is.  In order for
    registration to work, the remote Asterisk server will need to have a
    dynamic peer entry with the same name (and secret if provided).

    The name is a required field, and is the remote peer name that we wish to
    identify ourselves as.  A secret may be provided as well.  The secret is
    generally a shared password between the local server and the remote
    server.  However, if the secret is in square brackets ([]'s) then it is
    interpreted as the name of a RSA key to use.  In that case, the local Asterisk
    server must have the *private* key (/var/lib/asterisk/keys/<name>.key) and
    the remote server will have to have the corresponding public key.

    The "host" is a required field and is the hostname or IP address of the
    remote Asterisk server.  The port specification is optional and is by
    default 4569 for iax2 if not specified.

    > notransfer = yes | no

    If an IAX phone calls another IAX phone by using a Asterisk server,
    Asterisk will transfer the call to go peer to peer. If you do not
    want this, turn on notransfer with a "yes". This is also settable
    for peers and users.

    -------------

    The following sections, after "general" define either users, peers or
    friends.  A "user" is someone who connects to us.  A "peer" is someone
    that we connect to.  A "friend" is simply shorthand for creating a "user"
    and "peer" with identical parameters (i.e. someone who can contact us and
    who we contact).

    > [identifier]

    The section begins with the identifier in square brackets.  The identifier
    should be an alphanumeric string.

    > type = [user|peer|friend]

    This line tells Asterisk how to interpret this entity.  Users are things
    that connect to us, while peers are phones we connect to, and a friend is
    shorthand for creating a user and a peer with identical information

    ----------------
    User fields:

    > context = <context>

    One or more context lines may be specified in a user, thus giving the user
    access to place calls in the given contexts.  Contexts are used by
    Asterisk to divide dialing plans into logical units each with the ability
    to have numbers interpreted differently, have their own security model,
    auxiliary switch handling, and include other contexts.  Most users are
    given access to the default context.  Trusted users could be given access
    to the local context for example.

    > permit = <ipaddr>/<netmask>
    > deny = <ipaddr>/<netmask>

    Permit and deny rules may be applied to users, allowing them to connect
    from certain IP addresses and not others.  The permit and deny rules are
    interpreted in sequence and all are evaluated on a given IP address, with
    the final result being the decision.  For example:

    > permit = 0.0.0.0/0.0.0.0
    > deny = 192.168.0.0/255.255.255.0

    would deny anyone in 192.168.0.0 with a netmask of 24 bits (class C),
    whereas:

    > deny = 192.168.0.0/24
    > permit = 0.0.0.0/0

    would not deny anyone since the final rule would permit anyone, thus
    overriding the denial.

    If no permit/deny rules are listed, it is assumed that someone may connect
    from anywhere.

    > callerid = <callerid>

    You may override the Caller*ID information passed by a user to you (if
    they choose to send it) in order that it always be accurate from the
    perspective of your server.

    > auth = [md5|plaintext|rsa]

    You may select which authentication methods are permitted to be used by
    the user to authenticate to us.  Multiple methods may be specified,
    separated by commas. If md5 or plaintext authentication is selected, a
    secret must be provided. If RSA authentication is specified, then one or
    more key names must be specified with "inkeys"

    If no secret is specified and no authentication method is specified, then
    no authentication will be required.

    > secret = <secret>

    The "secret" line specifies the shared secret for md5 and plaintext
    authentication methods.  It is never suggested to use plaintext except in
    some cases for debugging.

    > inkeys = key1[:key2...]

    The "inkeys" line specifies which keys we can use to authenticate the
    remote peer.  If the peer's challenge passes with any of the given keys,
    then we accept its authentication.  The key files live in
    /var/lib/asterisk/keys/<name>.pub and are *public keys*.  Public keys are
    not typically DES3 encrypted and thus do not usually need initialization.

    ---------------
    Peer configuration

    > allow = [gsm|lpc10|g723.1|adpcm|ulaw|alaw|mp3|slinear|all]
    > disallow = [gsm|lpc10|g723.1|adpcm|ulaw|alaw|mp3|slinear|all]

    The "allow" and "disallow" may be used to enable or disable specific codec
    support on a per-peer basis.

    > host = [<ipaddr>|dynamic]

    The host line specifies the hostname or IP address of the remote host, or
    may be the word "dynamic" signifying that the host will register with us
    (see register => in the general section above).

    > defaultip = <ipaddr>

    If the host uses dynamic registration, Asterisk may still be given a
    default IP address to use when dynamic registration has not been performed
    or has timed out.

    > peercontext = <context>

    Specifies the context name to be passed to the peer for it to use when routing
    the call through its dial plan. This entry will be used only if a context
    is not included in the IAX2 channel name passed to the Dial command.

    > qualify = [yes | no | <value>]

    Qualify turns on checking of availability of the remote peer. If the
    peer becomes unavailable, no calls are placed to the peer until
    it is reachable again. This is also helpful in certain NAT situations.

    > jitterbuffer = [yes | no]

    Turns on or off the jitterbuffer for this peer

    > mailbox = <mailbox>[@mailboxcontext]

    Specifies a mailbox to check for voicemail notification.

    > permit = <ipaddr>/<netmask>
    > deny = <ipaddr>/<netmask>

    Permit and deny rules may be applied to users, allowing them to connect
    from certain IP addresses and not others.  The permit and deny rules are
    interpreted in sequence and all are evaluated on a given IP address, with
    the final result being the decision.  See the user section above
    for examples.

    ----------------------------------------------------------------------
    For more examples of a configuration, please see the iax.conf.sample in
    your the /configs directory of you source code distribution

## IAX2 configuration

    ; Inter-Asterisk eXchange driver definition
    ;
    ; This configuration is re-read at reload
    ; or with the CLI command
    ; 	reload chan_iax2.so
    ;
    ; General settings, like port number to bind to, and
    ; an option address (the default is to bind to all
    ; local addresses).
    ;
    [general]
    ;bindport=4569			; bindport and bindaddr may be specified
    ;                               ; NOTE: bindport must be specified BEFORE bindaddr
    ;                               ; or may be specified on a specific bindaddr if followed by
    ;                               ; colon and port (e.g. bindaddr=192.168.0.1:4569)
    ;bindaddr=192.168.0.1		; more than once to bind to multiple
    ;                               ; addresses, but the first will be the
    ;                               ; default
    ;
    ; Set iaxcompat to yes if you plan to use layered switches or
    ; some other scenario which may cause some delay when doing a
    ; lookup in the dialplan. It incurs a small performance hit to
    ; enable it. This option causes Asterisk to spawn a separate thread
    ; when it receives an IAX DPREQ (Dialplan Request) instead of
    ; blocking while it waits for a response.
    ;
    ;iaxcompat=yes
    ;
    ; Disable UDP checksums (if nochecksums is set, then no checkums will
    ; be calculated/checked on systems supporting this feature)
    ;
    ;nochecksums=no
    ;
    ;
    ; For increased security against brute force password attacks
    ; enable "delayreject" which will delay the sending of authentication
    ; reject for REGREQ or AUTHREP if there is a password.
    ;
    ;delayreject=yes
    ;
    ; You may specify a global default AMA flag for iaxtel calls.  It must be
    ; one of 'default', 'omit', 'billing', or 'documentation'.  These flags
    ; are used in the generation of call detail records.
    ;
    ;amaflags=default
    ;
    ; You may specify a default account for Call Detail Records in addition
    ; to specifying on a per-user basis
    ;
    ;accountcode=lss0101
    ;
    ; You may specify a global default language for users.
    ; Can be specified also on a per-user basis
    ; If omitted, will fallback to english
    ;
    ;language=en
    ;
    ; Specify bandwidth of low, medium, or high to control which codecs are used
    ; in general.
    ;
    bandwidth=low
    ;
    ; You can also fine tune codecs here using "allow" and "disallow" clauses
    ; with specific codecs.  Use "all" to represent all formats.
    ;
    ;allow=all			; same as bandwidth=high
    ;disallow=g723.1		; Hm...  Proprietary, don't use it...
    disallow=lpc10			; Icky sound quality...  Mr. Roboto.
    ;allow=gsm			; Always allow GSM, it's cool :)
    ;

    ; You can adjust several parameters relating to the jitter buffer.
    ; The jitter buffer's function is to compensate for varying
    ; network delay.
    ;
    ; There are presently two jitterbuffer implementations available for Asterisk
    ; and chan_iax2; the classic and the new, channel/application independent
    ; implementation.  These are controlled at compile-time.  The new jitterbuffer
    ; additionally has support for PLC which greatly improves quality as the
    ; jitterbuffer adapts size, and in compensating for lost packets.
    ;
    ; All the jitter buffer settings except dropcount are in milliseconds.
    ; The jitter buffer works for INCOMING audio - the outbound audio
    ; will be dejittered by the jitter buffer at the other end.
    ;
    ; jitterbuffer=yes|no: global default as to whether you want
    ; the jitter buffer at all.
    ;
    ; forcejitterbuffer=yes|no: in the ideal world, when we bridge VoIP channels
    ; we don't want to do jitterbuffering on the switch, since the endpoints
    ; can each handle this.  However, some endpoints may have poor jitterbuffers
    ; themselves, so this option will force * to always jitterbuffer, even in this
    ; case.
    ; [This option presently applies only to the new jitterbuffer implementation]
    ;
    ; dropcount: the jitter buffer is sized such that no more than "dropcount"
    ; frames would have been "too late" over the last 2 seconds.
    ; Set to a small number.  "3" represents 1.5% of frames dropped
    ; [This option is not applicable to, and ignored by the new jitterbuffer implementation]
    ;
    ; maxjitterbuffer: a maximum size for the jitter buffer.
    ; Setting a reasonable maximum here will prevent the call delay
    ; from rising to silly values in extreme situations; you'll hear
    ; SOMETHING, even though it will be jittery.
    ;
    ; resyncthreshold: when the jitterbuffer notices a significant change in delay
    ; that continues over a few frames, it will resync, assuming that the change in
    ; delay was caused by a timestamping mix-up. The threshold for noticing a
    ; change in delay is measured as twice the measured jitter plus this resync
    ; threshold.
    ; Resyncing can be disabled by setting this parameter to -1.
    ; [This option presently applies only to the new jitterbuffer implementation]
    ;
    ; maxjitterinterps: the maximum number of interpolation frames the jitterbuffer
    ; should return in a row. Since some clients do not send CNG/DTX frames to
    ; indicate silence, the jitterbuffer will assume silence has begun after
    ; returning this many interpolations. This prevents interpolating throughout
    ; a long silence.
    ; [This option presently applies only to the new jitterbuffer implementation]
    ;
    ; maxexcessbuffer: If conditions improve after a period of high jitter,
    ; the jitter buffer can end up bigger than necessary.  If it ends up
    ; more than "maxexcessbuffer" bigger than needed, Asterisk will start
    ; gradually decreasing the amount of jitter buffering.
    ; [This option is not applicable to, and ignored by the new jitterbuffer implementation]
    ;
    ; minexcessbuffer: Sets a desired mimimum amount of headroom in
    ; the jitter buffer.  If Asterisk has less headroom than this, then
    ; it will start gradually increasing the amount of jitter buffering.
    ; [This option is not applicable to, and ignored by the new jitterbuffer implementation]
    ;
    ; jittershrinkrate: when the jitter buffer is being gradually shrunk
    ; (or enlarged), how many millisecs shall we take off per 20ms frame
    ; received?  Use a small number, or you will be able to hear it
    ; changing.  An example: if you set this to 2, then the jitter buffer
    ; size will change by 100 millisecs per second.
    ; [This option is not applicable to, and ignored by the new jitterbuffer implementation]

    jitterbuffer=no
    forcejitterbuffer=no
    ;dropcount=2
    ;maxjitterbuffer=1000
    ;maxjitterinterps=10
    ;resyncthreshold=1000
    ;maxexcessbuffer=80
    ;minexcessbuffer=10
    ;jittershrinkrate=1

    ;trunkfreq=20			; How frequently to send trunk msgs (in ms)

    ; Should we send timestamps for the individual sub-frames within trunk frames?
    ; There is a small bandwidth use for these (less than 1kbps/call), but they
    ; ensure that frame timestamps get sent end-to-end properly.  If both ends of
    ; all your trunks go directly to TDM, _and_ your trunkfreq equals the frame
    ; length for your codecs, you can probably suppress these.  The receiver must
    ; also support this feature, although they do not also need to have it enabled.
    ;
    ; trunktimestamps=yes
    ;
    ; Minimum and maximum amounts of time that IAX peers can request as
    ; a registration expiration interval (in seconds).
    ; minregexpire = 60
    ; maxregexpire = 60
    ;
    ; We can register with another IAX server to let him know where we are
    ; in case we have a dynamic IP address for example
    ;
    ; Register with tormenta using username marko and password secretpass
    ;
    ;register => marko:secretpass@tormenta.linux-support.net
    ;
    ; Register joe at remote host with no password
    ;
    ;register => joe@remotehost:5656
    ;
    ; Register marko at tormenta.linux-support.net using RSA key "torkey"
    ;
    ;register => marko:[torkey]@tormenta.linux-support.net
    ;
    ; Sample Registration for iaxtel
    ;
    ; Visit http://www.iaxtel.com to register with iaxtel.  Replace "user"
    ; and "pass" with your username and password for iaxtel.  Incoming
    ; calls arrive at the "s" extension of "default" context.
    ;
    ;register => user:pass@iaxtel.com
    ;
    ; Sample Registration for IAX + FWD
    ;
    ; To register using IAX with FWD, it must be enabled by visiting the URL
    ; http://www.fwdnet.net/index.php?section_id=112
    ;
    ; Note that you need an extension in you default context which matches
    ; your free world dialup number.  Please replace "FWDNumber" with your
    ; FWD number and "passwd" with your password.
    ;
    ;register => FWDNumber:passwd@iax.fwdnet.net
    ;
    ;
    ; You can disable authentication debugging to reduce the amount of
    ; debugging traffic.
    ;
    ;authdebug=no
    ;
    ; Finally, you can set values for your TOS bits to help improve
    ; performance.  Valid values are:
    ;   lowdelay		-- Minimize delay
    ;   throughput		-- Maximize throughput
    ;   reliability		-- Maximize reliability
    ;   mincost		-- Minimize cost
    ;   none		-- No flags
    ;
    tos=lowdelay
    ;
    ; If mailboxdetail is set to "yes", the user receives
    ; the actual new/old message counts, not just a yes/no
    ; as to whether they have messages.  this can be set on
    ; a per-peer basis as well
    ;
    ;mailboxdetail=yes
    ;
    ; If regcontext is specified, Asterisk will dynamically create and destroy
    ; a NoOp priority 1 extension for a given peer who registers or unregisters
    ; with us.  The actual extension is the 'regexten' parameter of the registering
    ; peer or its name if 'regexten' is not provided.  More than one regexten
    ; may be supplied if they are separated by '&'.  Patterns may be used in
    ; regexten.
    ;
    ;regcontext=iaxregistrations
    ;
    ; If we don't get ACK to our NEW within 2000ms, and autokill is set to yes,
    ; then we cancel the whole thing (that's enough time for one retransmission
    ; only).  This is used to keep things from stalling for a long time for a host
    ; that is not available, but would be ill advised for bad connections.  In
    ; addition to 'yes' or 'no' you can also specify a number of milliseconds.
    ; See 'qualify' for individual peers to turn on for just a specific peer.
    ;
    autokill=yes
    ;
    ; codecpriority controls the codec negotiation of an inbound IAX call.
    ; This option is inherited to all user entities.  It can also be defined
    ; in each user entity separately which will override the setting in general.
    ;
    ; The valid values are:
    ;
    ; caller   - Consider the callers preferred order ahead of the host's.
    ; host     - Consider the host's preferred order ahead of the caller's.
    ; disabled - Disable the consideration of codec preference altogether.
    ;            (this is the original behaviour before preferences were added)
    ; reqonly  - Same as disabled, only do not consider capabilities if
    ;            the requested format is not available the call will only
    ;            be accepted if the requested format is available.
    ;
    ; The default value is 'host'
    ;
    ;codecpriority=host
    ;
    ; allowfwdownload controls whether this host will serve out firmware to
    ; IAX clients which request it.  This has only been used for the IAXy,
    ; and it has been recently proven that this firmware distribution method
    ; can be used as a source of traffic amplification attacks.  Also, the
    ; IAXy firmware has not been updated for at least 18 months, so unless
    ; you are provisioning IAXys in a secure network, we recommend that you
    ; leave this option to the default, off.
    ;
    ;allowfwdownload=yes

    ;rtcachefriends=yes		; Cache realtime friends by adding them to the internal list
    				; just like friends added from the config file only on a
    				; as-needed basis? (yes|no)

    ;rtupdate=yes			; Send registry updates to database using realtime? (yes|no)
    				; If set to yes, when a IAX2 peer registers successfully, the ip address,
    				; the origination port, the registration period, and the username of
    				; the peer will be set to database via realtime. If not present, defaults to 'yes'.

    ;rtautoclear=yes		; Auto-Expire friends created on the fly on the same schedule
    				; as if it had just registered? (yes|no|<seconds>)
    				; If set to yes, when the registration expires, the friend will vanish from
    				; the configuration until requested again. If set to an integer,
    				; friends expire within this number of seconds instead of the
    				; registration interval.

    ;rtignoreregexpire=yes		; When reading a peer from Realtime, if the peer's registration
    				; has expired based on its registration interval, used the stored
    				; address information regardless. (yes|no)

    ;
    ; The following two options are used to disable call token validation for the
    ; purposes of interoperability with IAX2 endpoints that do not yet support it.
    ;
    ; Call token validation can be set as optional for a single IP address or IP
    ; address range by using the 'calltokenoptional' option. 'calltokenoptional' is
    ; only a global option.
    ;
    ;calltokenoptional=209.16.236.73/255.255.255.0
    ;
    ; In a peer/user/friend definition, the 'requirecalltoken' option may be used.
    ; By setting 'requirecalltoken=no', call token validation becomes optional for
    ; that peer/user.  By setting 'requirecalltoken=auto', call token validation
    ; is optional until a call token supporting peer registers successfully using
    ; call token validation.  This is used as an indication that from now on, we
    ; can require it from this peer.  So, requirecalltoken is internally set to yes.
    ; By default, 'requirecalltoken=yes'.
    ;
    ;requirecalltoken=no
    ;

    ;
    ; These options are used to limit the amount of call numbers allocated to a
    ; single IP address.  Before changing any of these values, it is highly encouraged
    ; to read the user guide associated with these options first.  In most cases, the
    ; default values for these options are sufficient.
    ;
    ; The 'maxcallnumbers' option limits the amount of call numbers allowed for each
    ; individual remote IP address.  Once an IP address reaches it's call number
    ; limit, no more new connections are allowed until the previous ones close.  This
    ; option can be used in a peer definition as well, but only takes effect for
    ; the IP of a dynamic peer after it completes registration.
    ;
    ;maxcallnumbers=512
    ;
    ; The 'maxcallnumbers_nonvalidated' is used to set the combined number of call
    ; numbers that can be allocated for connections where call token  validation
    ; has been disabled.  Unlike the 'maxcallnumbers' option, this limit is not
    ; separate for each individual IP address.  Any connection resulting in a
    ; non-call token validated call number being allocated contributes to this
    ; limit.  For use cases, see the call token user guide.  This option's
    ; default value of 8192 should be sufficient in most cases.
    ;
    ;maxcallnumbers_nonvalidated=1024
    ;
    ; The [callnumberlimits] section allows custom call number limits to be set
    ; for specific IP addresses and IP address ranges.  These limits take precedence
    ; over the global 'maxcallnumbers' option, but may still be overridden by a
    ; peer defined 'maxcallnumbers' entry.  Note that these limits take effect
    ; for every individual address within the range, not the range as a whole.
    ;
    ;[callnumberlimits]
    ;10.1.1.0/255.255.255.0 = 24
    ;10.1.2.0/255.255.255.0 = 32
    ;

    ; Guest sections for unauthenticated connection attempts.  Just specify an
    ; empty secret, or provide no secret section.
    ;
    [guest]
    type=user
    context=default
    callerid="Guest IAX User"

    ;
    ; Trust Caller*ID Coming from iaxtel.com
    ;
    [iaxtel]
    type=user
    context=default
    auth=rsa
    inkeys=iaxtel

    ;
    ; Trust Caller*ID Coming from iax.fwdnet.net
    ;
    [iaxfwd]
    type=user
    context=default
    auth=rsa
    inkeys=freeworlddialup

    ;
    ; Trust callerid delivered over DUNDi/e164
    ;
    ;
    ;[dundi]
    ;type=user
    ;dbsecret=dundi/secret
    ;context=dundi-e164-local

    ;
    ; Further user sections may be added, specifying a context and a secret used
    ; for connections with that given authentication name.  Limited IP based
    ; access control is allowed by use of "allow" and "deny" keywords.  Multiple
    ; rules are permitted.  Multiple permitted contexts may be specified, in
    ; which case the first will be the default.  You can also override caller*ID
    ; so that when you receive a call you set the Caller*ID to be what you want
    ; instead of trusting what the remote user provides
    ;
    ; There are three authentication methods that are supported:  md5, plaintext,
    ; and rsa.  The least secure is "plaintext", which sends passwords cleartext
    ; across the net.  "md5" uses a challenge/response md5 sum arrangement, but
    ; still requires both ends have plain text access to the secret.  "rsa" allows
    ; unidirectional secret knowledge through public/private keys.  If "rsa"
    ; authentication is used, "inkeys" is a list of acceptable public keys on the
    ; local system that can be used to authenticate the remote peer, separated by
    ; the ":" character.  "outkey" is a single, private key to use to authenticate
    ; to the other side.  Public keys are named /var/lib/asterisk/keys/<name>.pub
    ; while private keys are named /var/lib/asterisk/keys/<name>.key.  Private
    ; keys should always be 3DES encrypted.
    ;
    ;
    ; NOTE: All hostnames and IP addresses in this file are for example purposes
    ;       only; you should not expect any of them to actually be available for
    ;       your use.
    ;
    ;
    ;[markster]
    ;type=user
    ;context=default
    ;context=local
    ;auth=md5,plaintext,rsa
    ;secret=markpasswd
    ;setvar=foo=bar
    ;dbsecret=mysecrets/place	; Secrets can be stored in astdb, too
    ;notransfer=yes		; Disable IAX native transfer
    ;jitterbuffer=yes	; Override global setting an enable jitter buffer
    ;			; for this user
    ;maxauthreq=10		; Set maximum number of outstanding AUTHREQs waiting for replies. Any further authentication attempts will be blocked
    ;			; if this limit is reached until they expire or a reply is received.
    ;callerid="Mark Spencer" <(256) 428-6275>
    ;deny=0.0.0.0/0.0.0.0
    ;accountcode=markster0101
    ;permit=209.16.236.73/255.255.255.0
    ;language=en		; Use english as default language
    ;
    ; Peers may also be specified, with a secret and
    ; a remote hostname.
    ;
    [demo]
    type=peer
    username=asterisk
    secret=supersecret
    host=216.207.245.47
    ;sendani=no
    ;host=asterisk.linux-support.net
    ;port=5036
    ;mask=255.255.255.255
    ;qualify=yes			; Make sure this peer is alive
    ;qualifysmoothing = yes		; use an average of the last two PONG
    				; results to reduce falsely detected LAGGED hosts
    				; Default: Off
    ;qualifyfreqok = 60000		; how frequently to ping the peer when
    				; everything seems to be ok, in milliseconds
    ;qualifyfreqnotok = 10000	; how frequently to ping the peer when it's
    				; either LAGGED or UNAVAILABLE, in milliseconds
    ;jitterbuffer=no		; Turn off jitter buffer for this peer

    ;
    ; Peers can remotely register as well, so that they can be mobile.  Default
    ; IP's can also optionally be given but are not required.  Caller*ID can be
    ; suggested to the other side as well if it is for example a phone instead of
    ; another PBX.
    ;

    ;[dynamichost]
    ;host=dynamic
    ;secret=mysecret
    ;mailbox=1234		; Notify about mailbox 1234
    ;inkeys=key1:key2
    ;peercontext=local	; Default context to request for calls to peer
    ;defaultip=216.207.245.34
    ;callerid="Some Host" <(256) 428-6011>
    ;

    ;
    ;[biggateway]
    ;type=peer
    ;host=192.168.0.1
    ;context=*
    ;secret=myscret
    ;trunk=yes			; Use IAX2 trunking with this host
    ;timezone=America/New_York	; Set a timezone for the date/time IE
    ;

    ;
    ; Friends are a short cut for creating a user and
    ; a peer with the same values.
    ;
    ;[marko]
    ;type=friend
    ;host=dynamic
    ;regexten=1234
    ;secret=moofoo   ; Multiple secrets may be specified. For a "user", all
    ;secret=foomoo   ; specified entries will be accepted as valid. For a "peer",
    ;secret=shazbot  ; only the last specified secret will be used.
    ;context=default
    ;permit=0.0.0.0/0.0.0.0

## IAX Jitterbuffer information

    The new Jitterbuffer in Asterisk
    --------------------------------
    Steve Kann

    The new jitterbuffer, PLC, and the IAX2-integration of the new jitterbuffer
    have been integrated into Asterisk. The jitterbuffer is generic and work is
    going on to implement it in SIP/RTP as well.

    Also, we've added a feature called "trunktimestamps", which adds individual
    timestamps to trunked frames within a trunk frame.

    Here's how to use this stuff:

    1) The new jitterbuffer:
    ------------------------
    You must add "jitterbuffer=yes" to either the [general] part of
    iax.conf, or to a peer or a user.  (just like the old jitterbuffer).
    Also, you can set "maxjitterbuffer=n", which puts a hard-limit on the size of the
    jitterbuffer of "n milliseconds".  It is not necessary to have the new jitterbuffer
    on both sides of a call; it works on the receive side only.

    2) PLC:
    -------
    The new jitterbuffer detects packet loss.  PLC is done to try to recreate these
    lost packets in the codec decoding stage, as the encoded audio is translated to slinear.
    PLC is also used to mask jitterbuffer growth.

    This facility is enabled by default in iLBC and speex, as it has no additional cost.
    This facility can be enabled in adpcm, alaw, g726, gsm, lpc10, and ulaw by setting
    genericplc => true in the [plc] section of codecs.conf.

    3) Trunktimestamps:
    -------------------
    To use this, both sides must be using Asterisk v1.2.
    Setting "trunktimestamps=yes" in iax.conf will cause your box to send 16-bit timestamps
    for each trunked frame inside of a trunk frame. This will enable you to use jitterbuffer
    for an IAX2 trunk, something that was not possible in the old architecture.

    The other side must also support this functionality, or else, well, bad things will happen.
    If you don't use trunktimestamps, there's lots of ways the jitterbuffer can get confused because
    timestamps aren't necessarily sent through the trunk correctly.

    4) Communication with Asterisk v1.0.x systems
    ---------------------------------------------
    You can set up communication with v1.0.x systems with the new jitterbuffer, but
    you can't use trunks with trunktimestamps in this communication.

    If you are connecting to an Asterisk server with earlier versions of the software (1.0.x),
    do not enable both jitterbuffer and trunking for the involved peers/users
    in order to be able  to communicate. Earlier systems will not support trunktimestamps.

    You may also compile chan_iax2.c without the new jitterbuffer, enabling the old
    backwards compatible architecture. Look in the source code for instructions.

    5) Testing and monitoring:
    --------------------------
    You can test the effectiveness of PLC and the new jitterbuffer's detection of loss by using
    the new CLI command "iax2 test losspct <n>".  This will simulate n percent packet loss
    coming _in_ to chan_iax2. You should find that with PLC and the new JB, 10 percent packet
    loss should lead to just a tiny amount of distortion, while without PLC, it would lead to
    silent gaps in your audio.

    "iax2 show netstats" shows you statistics for each iax2 call you have up.
    The columns are "RTT" which is the round-trip time for the last PING, and then a bunch of s
    tats for both the local side (what you're receiving), and the remote side (what the other
    end is telling us they are seeing).  The remote stats may not be complete if the remote
    end isn't using the new jitterbuffer.

    The stats shown are:
    * Jit: The jitter we have measured (milliseconds)
    * Del: The maximum delay imposed by the jitterbuffer (milliseconds)
    * Lost: The number of packets we've detected as lost.
    * %: The percentage of packets we've detected as lost recently.
    * Drop: The number of packets we've purposely dropped (to lower latency).
    * OOO: The number of packets we've received out-of-order
    * Kpkts: The number of packets we've received / 1000.

    Reporting problems
    ==================

    There's a couple of things that can make calls sound bad using the jitterbuffer:

    1) The JB and PLC can make your calls sound better, but they can't fix everything.
    If you lost 10 frames in a row, it can't possibly fix that.  It really can't help much
    more than one or two consecutive frames.

    2) Bad timestamps:  If whatever is generating timestamps to be sent to you generates
    nonsensical timestamps, it can confuse the jitterbuffer.  In particular, discontinuities
    in timestamps will really upset it:  Things like timestamps sequences which go 0, 20, 40,
    60, 80,  34000, 34020, 34040, 34060...   It's going to think you've got about 34 seconds
    of jitter in this case, etc..
    The right solution to this is to find out what's causing the sender to send us such nonsense,
    and fix that.  But we should also figure out how to make the receiver more robust in
    cases like this.

    chan_iax2 will actually help fix this a bit if it's more than 3 seconds or so, but at
    some point we should try to think of a better way to detect this kind of thing and
    resynchronize.

    Different clock rates are handled very gracefully though; it will actually deal with a
    sender sending 20% faster or slower than you expect just fine.

    3) Really strange network delays:  If your network "pauses" for like 5 seconds, and then
    when it restarts, you are sent some packets that are 5 seconds old, we are going to see
    that as a lot of jitter.   We already throw away up to the worst 20 frames like this,
    though, and the "maxjitterbuffer" parameter should put a limit on what we do in this case.

    Reporting possible bugs
    -----------------------
    If you do find bad behaviors, here's the information that will help to diagnose this:

    1) Describe

    a) the source of the timestamps and frames:  i.e. if they're coming from another chan_iax2 box,
    a bridged RTP-based channel, an IAX2 softphone, etc..

    b) The network between, in brief (i.e. the internet, a local lan, etc).

    c) What is the problem you're seeing.

    2) Take a look and see what iax2 show netstats is saying about the call, and if it makes sense.

    3) a tcpdump of the frames, (or, tethereal output from), so we can see the timestamps and delivery
    times of the frames you're receiving.  You can make such a tcpdump with:

    tcpdump -s 2048 -w /tmp/example.dump udp and port 4569 [and host <other-end>]

    Report bugs in the Asterisk bugtracker, http://bugs.digium.com.
    Please read the bug guidelines before you post a bug.

    Have fun!

    -SteveK

- Implemented in chan_iax2.c

## iax.conf

    ; Inter-Asterisk eXchange driver definition
    ;
    ; This configuration is re-read at reload
    ; or with the CLI command
    ; 	reload chan_iax2.so
    ;
    ; General settings, like port number to bind to, and
    ; an option address (the default is to bind to all
    ; local addresses).
    ;
    [general]
    ;bindport=4569			; bindport and bindaddr may be specified
    ;                               ; NOTE: bindport must be specified BEFORE bindaddr
    ;                               ; or may be specified on a specific bindaddr if followed by
    ;                               ; colon and port (e.g. bindaddr=192.168.0.1:4569)
    ;bindaddr=192.168.0.1		; more than once to bind to multiple
    ;                               ; addresses, but the first will be the
    ;                               ; default
    ;
    ; Set iaxcompat to yes if you plan to use layered switches or
    ; some other scenario which may cause some delay when doing a
    ; lookup in the dialplan. It incurs a small performance hit to
    ; enable it. This option causes Asterisk to spawn a separate thread
    ; when it receives an IAX DPREQ (Dialplan Request) instead of
    ; blocking while it waits for a response.
    ;
    ;iaxcompat=yes
    ;
    ; Disable UDP checksums (if nochecksums is set, then no checkums will
    ; be calculated/checked on systems supporting this feature)
    ;
    ;nochecksums=no
    ;
    ;
    ; For increased security against brute force password attacks
    ; enable "delayreject" which will delay the sending of authentication
    ; reject for REGREQ or AUTHREP if there is a password.
    ;
    ;delayreject=yes
    ;
    ; You may specify a global default AMA flag for iaxtel calls.  It must be
    ; one of 'default', 'omit', 'billing', or 'documentation'.  These flags
    ; are used in the generation of call detail records.
    ;
    ;amaflags=default
    ;
    ; You may specify a default account for Call Detail Records in addition
    ; to specifying on a per-user basis
    ;
    ;accountcode=lss0101
    ;
    ; You may specify a global default language for users.
    ; Can be specified also on a per-user basis
    ; If omitted, will fallback to english
    ;
    ;language=en
    ;
    ; Specify bandwidth of low, medium, or high to control which codecs are used
    ; in general.
    ;
    bandwidth=low
    ;
    ; You can also fine tune codecs here using "allow" and "disallow" clauses
    ; with specific codecs.  Use "all" to represent all formats.
    ;
    ;allow=all			; same as bandwidth=high
    ;disallow=g723.1		; Hm...  Proprietary, don't use it...
    disallow=lpc10			; Icky sound quality...  Mr. Roboto.
    ;allow=gsm			; Always allow GSM, it's cool :)
    ;

    ; You can adjust several parameters relating to the jitter buffer.
    ; The jitter buffer's function is to compensate for varying
    ; network delay.
    ;
    ; There are presently two jitterbuffer implementations available for Asterisk
    ; and chan_iax2; the classic and the new, channel/application independent
    ; implementation.  These are controlled at compile-time.  The new jitterbuffer
    ; additionally has support for PLC which greatly improves quality as the
    ; jitterbuffer adapts size, and in compensating for lost packets.
    ;
    ; All the jitter buffer settings except dropcount are in milliseconds.
    ; The jitter buffer works for INCOMING audio - the outbound audio
    ; will be dejittered by the jitter buffer at the other end.
    ;
    ; jitterbuffer=yes|no: global default as to whether you want
    ; the jitter buffer at all.
    ;
    ; forcejitterbuffer=yes|no: in the ideal world, when we bridge VoIP channels
    ; we don't want to do jitterbuffering on the switch, since the endpoints
    ; can each handle this.  However, some endpoints may have poor jitterbuffers
    ; themselves, so this option will force * to always jitterbuffer, even in this
    ; case.
    ; [This option presently applies only to the new jitterbuffer implementation]
    ;
    ; dropcount: the jitter buffer is sized such that no more than "dropcount"
    ; frames would have been "too late" over the last 2 seconds.
    ; Set to a small number.  "3" represents 1.5% of frames dropped
    ; [This option is not applicable to, and ignored by the new jitterbuffer implementation]
    ;
    ; maxjitterbuffer: a maximum size for the jitter buffer.
    ; Setting a reasonable maximum here will prevent the call delay
    ; from rising to silly values in extreme situations; you'll hear
    ; SOMETHING, even though it will be jittery.
    ;
    ; resyncthreshold: when the jitterbuffer notices a significant change in delay
    ; that continues over a few frames, it will resync, assuming that the change in
    ; delay was caused by a timestamping mix-up. The threshold for noticing a
    ; change in delay is measured as twice the measured jitter plus this resync
    ; threshold.
    ; Resyncing can be disabled by setting this parameter to -1.
    ; [This option presently applies only to the new jitterbuffer implementation]
    ;
    ; maxjitterinterps: the maximum number of interpolation frames the jitterbuffer
    ; should return in a row. Since some clients do not send CNG/DTX frames to
    ; indicate silence, the jitterbuffer will assume silence has begun after
    ; returning this many interpolations. This prevents interpolating throughout
    ; a long silence.
    ; [This option presently applies only to the new jitterbuffer implementation]
    ;
    ; maxexcessbuffer: If conditions improve after a period of high jitter,
    ; the jitter buffer can end up bigger than necessary.  If it ends up
    ; more than "maxexcessbuffer" bigger than needed, Asterisk will start
    ; gradually decreasing the amount of jitter buffering.
    ; [This option is not applicable to, and ignored by the new jitterbuffer implementation]
    ;
    ; minexcessbuffer: Sets a desired mimimum amount of headroom in
    ; the jitter buffer.  If Asterisk has less headroom than this, then
    ; it will start gradually increasing the amount of jitter buffering.
    ; [This option is not applicable to, and ignored by the new jitterbuffer implementation]
    ;
    ; jittershrinkrate: when the jitter buffer is being gradually shrunk
    ; (or enlarged), how many millisecs shall we take off per 20ms frame
    ; received?  Use a small number, or you will be able to hear it
    ; changing.  An example: if you set this to 2, then the jitter buffer
    ; size will change by 100 millisecs per second.
    ; [This option is not applicable to, and ignored by the new jitterbuffer implementation]

    jitterbuffer=no
    forcejitterbuffer=no
    ;dropcount=2
    ;maxjitterbuffer=1000
    ;maxjitterinterps=10
    ;resyncthreshold=1000
    ;maxexcessbuffer=80
    ;minexcessbuffer=10
    ;jittershrinkrate=1

    ;trunkfreq=20			; How frequently to send trunk msgs (in ms)

    ; Should we send timestamps for the individual sub-frames within trunk frames?
    ; There is a small bandwidth use for these (less than 1kbps/call), but they
    ; ensure that frame timestamps get sent end-to-end properly.  If both ends of
    ; all your trunks go directly to TDM, _and_ your trunkfreq equals the frame
    ; length for your codecs, you can probably suppress these.  The receiver must
    ; also support this feature, although they do not also need to have it enabled.
    ;
    ; trunktimestamps=yes
    ;
    ; Minimum and maximum amounts of time that IAX peers can request as
    ; a registration expiration interval (in seconds).
    ; minregexpire = 60
    ; maxregexpire = 60
    ;
    ; We can register with another IAX server to let him know where we are
    ; in case we have a dynamic IP address for example
    ;
    ; Register with tormenta using username marko and password secretpass
    ;
    ;register => marko:secretpass@tormenta.linux-support.net
    ;
    ; Register joe at remote host with no password
    ;
    ;register => joe@remotehost:5656
    ;
    ; Register marko at tormenta.linux-support.net using RSA key "torkey"
    ;
    ;register => marko:[torkey]@tormenta.linux-support.net
    ;
    ; Sample Registration for iaxtel
    ;
    ; Visit http://www.iaxtel.com to register with iaxtel.  Replace "user"
    ; and "pass" with your username and password for iaxtel.  Incoming
    ; calls arrive at the "s" extension of "default" context.
    ;
    ;register => user:pass@iaxtel.com
    ;
    ; Sample Registration for IAX + FWD
    ;
    ; To register using IAX with FWD, it must be enabled by visiting the URL
    ; http://www.fwdnet.net/index.php?section_id=112
    ;
    ; Note that you need an extension in you default context which matches
    ; your free world dialup number.  Please replace "FWDNumber" with your
    ; FWD number and "passwd" with your password.
    ;
    ;register => FWDNumber:passwd@iax.fwdnet.net
    ;
    ;
    ; You can disable authentication debugging to reduce the amount of
    ; debugging traffic.
    ;
    ;authdebug=no
    ;
    ; Finally, you can set values for your TOS bits to help improve
    ; performance.  Valid values are:
    ;   lowdelay		-- Minimize delay
    ;   throughput		-- Maximize throughput
    ;   reliability		-- Maximize reliability
    ;   mincost		-- Minimize cost
    ;   none		-- No flags
    ;
    tos=lowdelay
    ;
    ; If mailboxdetail is set to "yes", the user receives
    ; the actual new/old message counts, not just a yes/no
    ; as to whether they have messages.  this can be set on
    ; a per-peer basis as well
    ;
    ;mailboxdetail=yes
    ;
    ; If regcontext is specified, Asterisk will dynamically create and destroy
    ; a NoOp priority 1 extension for a given peer who registers or unregisters
    ; with us.  The actual extension is the 'regexten' parameter of the registering
    ; peer or its name if 'regexten' is not provided.  More than one regexten
    ; may be supplied if they are separated by '&'.  Patterns may be used in
    ; regexten.
    ;
    ;regcontext=iaxregistrations
    ;
    ; If we don't get ACK to our NEW within 2000ms, and autokill is set to yes,
    ; then we cancel the whole thing (that's enough time for one retransmission
    ; only).  This is used to keep things from stalling for a long time for a host
    ; that is not available, but would be ill advised for bad connections.  In
    ; addition to 'yes' or 'no' you can also specify a number of milliseconds.
    ; See 'qualify' for individual peers to turn on for just a specific peer.
    ;
    autokill=yes
    ;
    ; codecpriority controls the codec negotiation of an inbound IAX call.
    ; This option is inherited to all user entities.  It can also be defined
    ; in each user entity separately which will override the setting in general.
    ;
    ; The valid values are:
    ;
    ; caller   - Consider the callers preferred order ahead of the host's.
    ; host     - Consider the host's preferred order ahead of the caller's.
    ; disabled - Disable the consideration of codec preference altogether.
    ;            (this is the original behaviour before preferences were added)
    ; reqonly  - Same as disabled, only do not consider capabilities if
    ;            the requested format is not available the call will only
    ;            be accepted if the requested format is available.
    ;
    ; The default value is 'host'
    ;
    ;codecpriority=host
    ;
    ; allowfwdownload controls whether this host will serve out firmware to
    ; IAX clients which request it.  This has only been used for the IAXy,
    ; and it has been recently proven that this firmware distribution method
    ; can be used as a source of traffic amplification attacks.  Also, the
    ; IAXy firmware has not been updated for at least 18 months, so unless
    ; you are provisioning IAXys in a secure network, we recommend that you
    ; leave this option to the default, off.
    ;
    ;allowfwdownload=yes

    ;rtcachefriends=yes		; Cache realtime friends by adding them to the internal list
    				; just like friends added from the config file only on a
    				; as-needed basis? (yes|no)

    ;rtupdate=yes			; Send registry updates to database using realtime? (yes|no)
    				; If set to yes, when a IAX2 peer registers successfully, the ip address,
    				; the origination port, the registration period, and the username of
    				; the peer will be set to database via realtime. If not present, defaults to 'yes'.

    ;rtautoclear=yes		; Auto-Expire friends created on the fly on the same schedule
    				; as if it had just registered? (yes|no|<seconds>)
    				; If set to yes, when the registration expires, the friend will vanish from
    				; the configuration until requested again. If set to an integer,
    				; friends expire within this number of seconds instead of the
    				; registration interval.

    ;rtignoreregexpire=yes		; When reading a peer from Realtime, if the peer's registration
    				; has expired based on its registration interval, used the stored
    				; address information regardless. (yes|no)

    ;
    ; The following two options are used to disable call token validation for the
    ; purposes of interoperability with IAX2 endpoints that do not yet support it.
    ;
    ; Call token validation can be set as optional for a single IP address or IP
    ; address range by using the 'calltokenoptional' option. 'calltokenoptional' is
    ; only a global option.
    ;
    ;calltokenoptional=209.16.236.73/255.255.255.0
    ;
    ; In a peer/user/friend definition, the 'requirecalltoken' option may be used.
    ; By setting 'requirecalltoken=no', call token validation becomes optional for
    ; that peer/user.  By setting 'requirecalltoken=auto', call token validation
    ; is optional until a call token supporting peer registers successfully using
    ; call token validation.  This is used as an indication that from now on, we
    ; can require it from this peer.  So, requirecalltoken is internally set to yes.
    ; By default, 'requirecalltoken=yes'.
    ;
    ;requirecalltoken=no
    ;

    ;
    ; These options are used to limit the amount of call numbers allocated to a
    ; single IP address.  Before changing any of these values, it is highly encouraged
    ; to read the user guide associated with these options first.  In most cases, the
    ; default values for these options are sufficient.
    ;
    ; The 'maxcallnumbers' option limits the amount of call numbers allowed for each
    ; individual remote IP address.  Once an IP address reaches it's call number
    ; limit, no more new connections are allowed until the previous ones close.  This
    ; option can be used in a peer definition as well, but only takes effect for
    ; the IP of a dynamic peer after it completes registration.
    ;
    ;maxcallnumbers=512
    ;
    ; The 'maxcallnumbers_nonvalidated' is used to set the combined number of call
    ; numbers that can be allocated for connections where call token  validation
    ; has been disabled.  Unlike the 'maxcallnumbers' option, this limit is not
    ; separate for each individual IP address.  Any connection resulting in a
    ; non-call token validated call number being allocated contributes to this
    ; limit.  For use cases, see the call token user guide.  This option's
    ; default value of 8192 should be sufficient in most cases.
    ;
    ;maxcallnumbers_nonvalidated=1024
    ;
    ; The [callnumberlimits] section allows custom call number limits to be set
    ; for specific IP addresses and IP address ranges.  These limits take precedence
    ; over the global 'maxcallnumbers' option, but may still be overridden by a
    ; peer defined 'maxcallnumbers' entry.  Note that these limits take effect
    ; for every individual address within the range, not the range as a whole.
    ;
    ;[callnumberlimits]
    ;10.1.1.0/255.255.255.0 = 24
    ;10.1.2.0/255.255.255.0 = 32
    ;

    ; Guest sections for unauthenticated connection attempts.  Just specify an
    ; empty secret, or provide no secret section.
    ;
    [guest]
    type=user
    context=default
    callerid="Guest IAX User"

    ;
    ; Trust Caller*ID Coming from iaxtel.com
    ;
    [iaxtel]
    type=user
    context=default
    auth=rsa
    inkeys=iaxtel

    ;
    ; Trust Caller*ID Coming from iax.fwdnet.net
    ;
    [iaxfwd]
    type=user
    context=default
    auth=rsa
    inkeys=freeworlddialup

    ;
    ; Trust callerid delivered over DUNDi/e164
    ;
    ;
    ;[dundi]
    ;type=user
    ;dbsecret=dundi/secret
    ;context=dundi-e164-local

    ;
    ; Further user sections may be added, specifying a context and a secret used
    ; for connections with that given authentication name.  Limited IP based
    ; access control is allowed by use of "allow" and "deny" keywords.  Multiple
    ; rules are permitted.  Multiple permitted contexts may be specified, in
    ; which case the first will be the default.  You can also override caller*ID
    ; so that when you receive a call you set the Caller*ID to be what you want
    ; instead of trusting what the remote user provides
    ;
    ; There are three authentication methods that are supported:  md5, plaintext,
    ; and rsa.  The least secure is "plaintext", which sends passwords cleartext
    ; across the net.  "md5" uses a challenge/response md5 sum arrangement, but
    ; still requires both ends have plain text access to the secret.  "rsa" allows
    ; unidirectional secret knowledge through public/private keys.  If "rsa"
    ; authentication is used, "inkeys" is a list of acceptable public keys on the
    ; local system that can be used to authenticate the remote peer, separated by
    ; the ":" character.  "outkey" is a single, private key to use to authenticate
    ; to the other side.  Public keys are named /var/lib/asterisk/keys/<name>.pub
    ; while private keys are named /var/lib/asterisk/keys/<name>.key.  Private
    ; keys should always be 3DES encrypted.
    ;
    ;
    ; NOTE: All hostnames and IP addresses in this file are for example purposes
    ;       only; you should not expect any of them to actually be available for
    ;       your use.
    ;
    ;
    ;[markster]
    ;type=user
    ;context=default
    ;context=local
    ;auth=md5,plaintext,rsa
    ;secret=markpasswd
    ;setvar=foo=bar
    ;dbsecret=mysecrets/place	; Secrets can be stored in astdb, too
    ;notransfer=yes		; Disable IAX native transfer
    ;jitterbuffer=yes	; Override global setting an enable jitter buffer
    ;			; for this user
    ;maxauthreq=10		; Set maximum number of outstanding AUTHREQs waiting for replies. Any further authentication attempts will be blocked
    ;			; if this limit is reached until they expire or a reply is received.
    ;callerid="Mark Spencer" <(256) 428-6275>
    ;deny=0.0.0.0/0.0.0.0
    ;accountcode=markster0101
    ;permit=209.16.236.73/255.255.255.0
    ;language=en		; Use english as default language
    ;
    ; Peers may also be specified, with a secret and
    ; a remote hostname.
    ;
    [demo]
    type=peer
    username=asterisk
    secret=supersecret
    host=216.207.245.47
    ;sendani=no
    ;host=asterisk.linux-support.net
    ;port=5036
    ;mask=255.255.255.255
    ;qualify=yes			; Make sure this peer is alive
    ;qualifysmoothing = yes		; use an average of the last two PONG
    				; results to reduce falsely detected LAGGED hosts
    				; Default: Off
    ;qualifyfreqok = 60000		; how frequently to ping the peer when
    				; everything seems to be ok, in milliseconds
    ;qualifyfreqnotok = 10000	; how frequently to ping the peer when it's
    				; either LAGGED or UNAVAILABLE, in milliseconds
    ;jitterbuffer=no		; Turn off jitter buffer for this peer

    ;
    ; Peers can remotely register as well, so that they can be mobile.  Default
    ; IP's can also optionally be given but are not required.  Caller*ID can be
    ; suggested to the other side as well if it is for example a phone instead of
    ; another PBX.
    ;

    ;[dynamichost]
    ;host=dynamic
    ;secret=mysecret
    ;mailbox=1234		; Notify about mailbox 1234
    ;inkeys=key1:key2
    ;peercontext=local	; Default context to request for calls to peer
    ;defaultip=216.207.245.34
    ;callerid="Some Host" <(256) 428-6011>
    ;

    ;
    ;[biggateway]
    ;type=peer
    ;host=192.168.0.1
    ;context=*
    ;secret=myscret
    ;trunk=yes			; Use IAX2 trunking with this host
    ;timezone=America/New_York	; Set a timezone for the date/time IE
    ;

    ;
    ; Friends are a short cut for creating a user and
    ; a peer with the same values.
    ;
    ;[marko]
    ;type=friend
    ;host=dynamic
    ;regexten=1234
    ;secret=moofoo   ; Multiple secrets may be specified. For a "user", all
    ;secret=foomoo   ; specified entries will be accepted as valid. For a "peer",
    ;secret=shazbot  ; only the last specified secret will be used.
    ;context=default
    ;permit=0.0.0.0/0.0.0.0