From 4494a6d2f440b017f0d94f69b522515e2dfefa55 Mon Sep 17 00:00:00 2001 From: Mark Spencer Date: Mon, 7 Jan 2002 02:01:04 +0000 Subject: [PATCH] Version 0.1.10 from FTP git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401 65c4cc65-6c06-0410-ace0-fbb531ad65f3 --- Makefile | 16 +- README.iax | 326 ++++++++++++++++++++++++++++++++++++++++ configs/iax.conf.sample | 48 +++++- doc/README.iax | 326 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 710 insertions(+), 6 deletions(-) create mode 100755 README.iax create mode 100755 doc/README.iax diff --git a/Makefile b/Makefile index e7af3f77af..0545b47eb8 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 0000000000..58372e0d28 --- /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 = + +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 = + +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 = +> maxjitterbuffer = +> maxexcessbuffer = + +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 = +> 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 => [:]@[: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/.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 = + +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 = / +> deny = / + +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 = + +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 = + +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/.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 = [|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 = + +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 a2e3716ca5..2c474287c1 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/.pub +; while private keys are named /var/lib/asterisk/keys/.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 0000000000..58372e0d28 --- /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 = + +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 = + +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 = +> maxjitterbuffer = +> maxexcessbuffer = + +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 = +> 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 => [:]@[: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/.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 = + +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 = / +> deny = / + +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 = + +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 = + +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/.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 = [|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 = + +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. + +