Version 0.1.10 from FTP

git-svn-id: http://svn.digium.com/svn/asterisk/trunk@401 f38db490-d61c-443f-a65b-d21fe96a405b

4 files changed, 710 insertions, 6 deletions

diff --git a/Makefile b/Makefile
index e7af3f77a..0545b47eb 100755
--- a/Makefile
+++ b/Makefile
@@ -26,8 +26,8 @@ PROC=i586
 
 DEBUG=-g #-pg
 INCLUDE=-Iinclude -I../include
-#CFLAGS=-pipe  -Wall -Wmissing-prototypes -Wmissing-declarations -O6 $(DEBUG) $(INCLUDE) -D_REENTRANT -Werror
 CFLAGS=-pipe  -Wall -Wmissing-prototypes -Wmissing-declarations -O6 $(DEBUG) $(INCLUDE) -D_REENTRANT
+#CFLAGS+=-Werror
 CFLAGS+=$(shell if $(CC) -march=$(PROC) -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-march=$(PROC)"; fi)
 ASTERISKVERSION=$(shell if [ -f .version ]; then cat .version; fi)
 RPMVERSION=$(shell sed 's/[-\/:]/_/g' .version)
@@ -37,11 +37,12 @@ CFLAGS+= -DDO_CRASH -DDEBUG_THREADS
 # Uncomment next one to enable ast_frame tracing (for debugging)
 #CLFAGS+= -DTRACE_FRAMES
 CFLAGS+=# -fomit-frame-pointer 
-SUBDIRS=channels pbx apps codecs formats agi
+SUBDIRS=res channels pbx apps codecs formats agi cdr
 LIBS=-ldl -lpthread -lreadline -lncurses -lm
 OBJS=io.o sched.o logger.o frame.o loader.o config.o channel.o \
 	translate.o file.o say.o pbx.o cli.o md5.o \
-	ulaw.o callerid.o fskmodem.o image.o app.o asterisk.o 
+	ulaw.o alaw.o callerid.o fskmodem.o image.o app.o \
+	cdr.o tdd.o asterisk.o 
 CC=gcc
 INSTALL=install
 
@@ -59,10 +60,13 @@ all: asterisk subdirs
 _version: 
 	if [ -d CVS ] && ! [ -f .version ]; then echo "CVS-`date +"%D-%T"`" > .version; fi 
 
+.version:
+	_version
+
 build.h:
 	./make_build_h
 
-asterisk: _version build.h $(OBJS)
+asterisk: .version build.h $(OBJS)
 	gcc -o asterisk -rdynamic $(OBJS) $(LIBS)
 
 subdirs: 
@@ -91,6 +95,7 @@ install: all datafiles
 	mkdir -p $(MODULES_DIR)
 	mkdir -p $(INSTALL_PREFIX)/usr/sbin
 	install -m 755 asterisk $(INSTALL_PREFIX)/usr/sbin/
+	install -m 755 astgenkey $(INSTALL_PREFIX)/usr/sbin/
 	for x in $(SUBDIRS); do $(MAKE) -C $$x install || exit 1 ; done
 	install -d $(INSTALL_PREFIX)/usr/include/asterisk
 	install include/asterisk/*.h $(INSTALL_PREFIX)/usr/include/asterisk
@@ -99,6 +104,9 @@ install: all datafiles
 	rm -f $(INSTALL_PREFIX)/usr/lib/asterisk/modules/chan_ixj.so
 	rm -f $(INSTALL_PREFIX)/usr/lib/asterisk/modules/chan_tor.so
 	mkdir -p $(INSTALL_PREFIX)/var/lib/asterisk/sounds
+	mkdir -p $(INSTALL_PREFIX)/var/log/asterisk/cdr-csv
+	mkdir -p $(INSTALL_PREFIX)/var/lib/asterisk/keys
+	install -m 644 keys/iaxtel.pub $(INSTALL_PREFIX)/var/lib/asterisk/keys
 	( cd $(INSTALL_PREFIX)/var/lib/asterisk/sounds  ; ln -s ../../../spool/asterisk/vm . )
 	@echo " +---- Asterisk Installation Complete -------+"  
 	@echo " +                                           +"
diff --git a/README.iax b/README.iax
new file mode 100755
index 000000000..58372e0d2
--- /dev/null
+++ b/README.iax
@@ -0,0 +1,326 @@
+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 
+	     imperitive.  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:
+
+> port = <portnum>
+
+This sets the port that IAX will bind to.  The default IAX port number is 
+5036.  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.  The drop count is the maximum number of 
+voice packets to allow to drop (out of 100).  Useful values are 3-10.  The 
+maxjitterbuffer is the maximum amount of jitter buffer to permit to be 
+used.  The "maxexcessbuffer" is the maximum amount of excess jitter buffer 
+that is permitted before the jitter buffer is slowly shrunk to eliminate 
+latency.
+
+> 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 registery 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 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 5036 if not specified.
+
+-------------
+
+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 people 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, 
+auxilliary 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/255.255.255.0
+> permit = 0.0.0.0/0.0.0.0
+
+would not deny anyone since the final rule would permit anyone, thsu 
+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 specifed 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.
+
+
diff --git a/configs/iax.conf.sample b/configs/iax.conf.sample
index a2e3716ca..2c474287c 100755
--- a/configs/iax.conf.sample
+++ b/configs/iax.conf.sample
@@ -10,6 +10,17 @@
 port=5036
 ;bindaddr=192.168.0.1
 ;
+; 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
+;
 ; Specify bandwidth of low, medium, or high to control which codecs are used
 ; in general.
 ;
@@ -39,9 +50,18 @@ disallow=lpc10			; Icky sound quality...  Mr. Roboto.
 ; 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
+;
 ; Finally, you can set values for your TOS bits to help improve 
 ; performance.  Valid values are:
 ;   lowdelay		-- Minimize delay
@@ -57,6 +77,15 @@ tos=lowdelay
 [iaxtel]
 type=user
 context=default
+auth=rsa
+inkeys=iaxtel
+
+[iaxtel2]
+;
+; Backwards compatible entry for IAXtel pre-RSA
+;
+type=user
+context=default
 deny=0.0.0.0/0.0.0.0
 permit=216.207.245.47/255.255.255.255
 
@@ -78,14 +107,28 @@ callerid="Guest IAX User"
 ; 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.
+;
+;
 ;[markster]
 ;type=user
 ;context=default
 ;context=local
-;auth=md5,plaintext
+;auth=md5,plaintext,rsa
 ;secret=markpasswd
 ;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
 ;
 ; Peers may also be specified, with a secret and
@@ -111,6 +154,7 @@ host=216.207.245.57
 ;[dynamichost]
 ;host=dynamic
 ;secret=mysecret
+;inkeys=key1:key2
 ;defaultip=216.207.245.34
 ;callerid="Some Host" <(256) 428-6011>
 ;
@@ -124,4 +168,4 @@ host=216.207.245.57
 ;host=dynamic
 ;secret=moofoo
 ;context=default
-;allow=0.0.0.0/0.0.0.0
+;permit=0.0.0.0/0.0.0.0
diff --git a/doc/README.iax b/doc/README.iax
new file mode 100755
index 000000000..58372e0d2
--- /dev/null
+++ b/doc/README.iax
@@ -0,0 +1,326 @@
+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 
+	     imperitive.  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:
+
+> port = <portnum>
+
+This sets the port that IAX will bind to.  The default IAX port number is 
+5036.  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.  The drop count is the maximum number of 
+voice packets to allow to drop (out of 100).  Useful values are 3-10.  The 
+maxjitterbuffer is the maximum amount of jitter buffer to permit to be 
+used.  The "maxexcessbuffer" is the maximum amount of excess jitter buffer 
+that is permitted before the jitter buffer is slowly shrunk to eliminate 
+latency.
+
+> 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 registery 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 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 5036 if not specified.
+
+-------------
+
+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 people 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, 
+auxilliary 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/255.255.255.0
+> permit = 0.0.0.0/0.0.0.0
+
+would not deny anyone since the final rule would permit anyone, thsu 
+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 specifed 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.
+
+