Asterisk: The Future of Telephony, 2nd Edition

SIP

Just as with IAX, the SIP configuration file (sip.conf) contains configuration information for SIP channels. The headings for the channel definitions are formed by a word framed in square brackets ([])—again, with the exception of the [general] section, where we define global SIP parameters. Don’t forget to use comments generously in your sip.conf file. Precede the comment text with a semicolon; everything to the right will be ignored.

General SIP Parameters

The following options are to be used within the [general] section of sip.conf:

allowexternalinvites

If set to no, this setting disables INVITE and REFER messages to non-local domains. See the domain setting.

allowexternalinvites=yes|no

allowguest

If set to no, this disallows guest SIP connections. The default is to allow guest connections. SIP normally requires authentication, but you can accept calls from users who do not support authentication (i.e., do not have a secret field defined). Certain SIP appliances (such as the Cisco Call Manager v4.1) do not support authentication, so they will not be able to connect if you set allowguest=no:

allowguest=no|yes

allowoverlap

If set to no, overlap dialing is disabled:

allowoverlap=no|yes

allowsubscribe

Specifies whether or not to allow external devices to subscribe to extension status (as set in the hint priority). Defaults to yes:

allowsubscribe=yes|no

allowtransfers

If set to no, transfers are disabled for all SIP calls, unless specifically enabled on a per-user or per-peer basis:

allowtransfers=no|yes

alwaysauthreject

If this option is enabled, whenever Asterisk rejects an INVITE or REGISTER, it will always reject it with a 401 Unauthorized message instead of letting the caller know whether there was a matching user or peer for his request:

alwaysauthreject=no|yes

autodomain

Set this option to yes to have Asterisk add the local hostname and local IP addresses to the domain list:

autodomain=yes|no

bindaddr and bindport

These optional parameters allow you to control the IP interface and port on which you wish to accept SIP connections. If omitted, the port will be set to 5060, and all IP addresses in your Asterisk system will accept incoming SIP connections. If multiple bind addresses are configured, only those interfaces will listen for connections. The address 0.0.0.0 tells Asterisk to listen on all interfaces:

bindaddr=0.0.0.0
bindport=5060

buggymwi

This setting allows Asterisk to send a message-waiting indication to certain Cisco SIP phones with firmware that doesn’t fully support the message-waiting Internet RFC. Enable this option to avoid getting error messages when sending MWI messages on phones with this bug:

buggymwi=no|yes

callevents

Set this to yes when you want SIP to generate Manager events. This will be important if you have external programs that use the Asterisk Manager interface, such as the Flash Operator Panel:

callevents=yes

checkmwi

This option specifies the default amount of time, in seconds, between mailbox checks for peers:

checkmwi=30

compactheaders

You can set compactheaders to yes or no. If it’s set to yes, the SIP headers will use a compact format, which may be required if the size of the SIP header is larger than the maximum transmission unit (MTU) of your IP headers, causing the IP packet to be fragmented. Do not use this option unless you know what you are doing:

compactheaders=yes|no

defaultexpiry

This sets the default SIP registration expiration time, in seconds, for incoming and outgoing registrations. A client will normally define this value when it initially registers, so the default value you set here will be used only if the client does not specify a timeout when it registers. If you are registering to another user agent server (UAS), this is the registration timeout that it will send to the far end:

defaultexpiry=300

directrtpsetup

This setting configures the direct RTP setup between two endpoints without the need for RE-INVITEs.

directrtpsetup=yes|no

Warning

As of the time that this book was written, directrtpsetup was still considered experimental, and as such should not be enabled unless you fully understand the consequences. This option will not work for video calls and cases where the called party sends RTP payloads and FMTP headers in the 200 OK response that do not match the caller’s INVITE request.

domain

Incoming INVITE and REFER messages can be matched against a list of 'allowed' domains, each of which can direct the call to a specific context if desired. By default, all domains are accepted and sent to the default context or the context associated with the user/peer placing the call. Domains can be specified using: domain=<domain>[,<context>]. Examples:

domain=myasterisk.dom
domain=customer.com, customer-context

dumphistory

You can set dumphistory to yes or no to enable or disable the printing of the SIP history report at the end of the SIP dialog. The SIP history is printed to the DEBUG logging channel:

dumphistory=yes|no

externhost

externhost takes a fully qualified domain name as its argument. If Asterisk is behind NAT, the SIP header will normally use the private IP address assigned to the server. If you set this option, Asterisk will perform periodic DNS lookups on the hostname and replace the private IP address with the IP address returned from the DNS lookup:

externhost=my.hostname.tld

Warning

The use of externhost is not recommended in production systems, because if the IP address of the server changes, the wrong IP address will be set in the SIP headers until the next lookup is performed. The use of externip is recommended instead.

externip

externip takes an IP address as its argument. If Asterisk is behind NAT, the SIP header will normally use the private IP address assigned to the server. The remote server will not know how to route back to this address; thus, it must be replaced with a valid, routeable address:

externip=216.239.39.104

externrefresh

If externhost is used, externrefresh configures how long, in seconds, should pass between DNS lookups:

externrefresh=30

g726nonstandard

This parameter can be set when dealing with peers that incorrectly use the wrong encoding for the G.726 codec. This setting tells Asterisk to use AAL2 packing order instead of RFC3551 packing order if the peer negotiates G726-32 audio. Ordinarily, that would be contrary to the RFC3551 specification, as the peer should be negotiating AAL2-G726-32 instead. You may need to set this option if you’re using a Sipura or Grandstream device:

g726nonstandard=yes

ignoreregexpire (global)

If ignoreregexpire is set to yes, Asterisk could do one of two things, for:

Non-realtime peers

When their registration expires, the information will not be removed from memory or the Asterisk database. If you attempt to place a call to the peer, the existing information will be used in spite of it having expired.

Realtime peers

When the peer is retrieved from realtime storage, the registration information will be used regardless of whether it has expired or not; if it expires while the realtime peer is still in memory (due to caching or other reasons), the information will not be removed from realtime storage:

ignoreregexpire=yes|no

jbenable

Enables the use of an RTP jitter buffer on the receiving side of a SIP channel. Defaults to no. An enabled jitter buffer will be used only if the sending side can create and the receiving side cannot accept jitter. The SIP channel can accept jitter; thus a jitter buffer on the receiving side will be used only if it is forced and enabled:

jbenable=yes|no

jbforce

Forces the use of the RTP jitter buffer on the receiving side of a SIP channel. Defaults to no:

jbforce=yes|no

jbimpl

This setting is used to specify which jitter buffer implementation to use, the fixed jitter buffer or the adaptive jitter buffer. If the fixed jitter buffer is used, it will always be the size defined by jbmaxsize. If the adaptive jitter buffer is specified, then the jitter buffer will vary in size up to the maximum size specified by jbmaxsize. This setting defaults to fixed:

jbimpl=fixed|adaptive

jblog

Specifies whether or not to enable jitter buffer frame logging. Defaults to no:

jblog=yes|no

jbmaxsize

Sets the maximum length of the jitter buffer, in milliseconds:

jbmaxsize=200

jbresyncthreshold

Jump in the frame timestamps over which the jitter buffer is resynchronized. This is useful to improve the quality of the voice, with big jumps in/broken timestamps that are usually sent from exotic devices and programs. Defaults to 1000:

jbresyncthreshold=1000

limitonpeers

This setting tells Asterisk to apply call limits to peers only. This will improve call limits and status notification for devices set to type=friend because the peer limit will be checked, and not create a separate limit for the user and peer portions of a friend:

limitonpeers=yes|no

localnet

localnet is used to tell Asterisk which IP addresses are considered local, so that the address in the SIP header can be translated to that specified by externip or the IP address can be looked up with externhost. The IP addresses should be specified in CIDR notation:

localnet=192.168.1.0/24
localnet=172.16.0.0/16

matchexterniplocally

Specifies that Asterisk should substitute the externip or externhost setting only if it matches your localnet setting. Unless you have some sort of strange network setup you will not need to enable this:

matchexterniplocally=yes|no

maxexpiry

This sets the maximum amount of time, in seconds, until a peer’s registration expires:

maxexpiry=3600

minexpiry

This sets the minimum amount of time, in seconds, allowed for a registration or subscription:

maxexpiry=3600

notifymimetype

This takes as its argument a string specifying the MIME type used for the message-waiting indication (MWI) in the SIP NOTIFY message. The most common setting for this field is text/plain, although it can be customized if need be:

notifymimetype=text/plain

notifyringing

Specifies whether Asterisk should notify subscriptions on RINGING state:

notifyringing=yes|no

notifyhold

Specifies whether Asterisk should notify subscriptions on HOLD state:

notifyhold=yes|no

pedantic

You can set pedantic to yes or no. Setting it to yes enables slow pedantic checking for phones that require it, such as the Pingtel, and enables more strict SIP RFC compliancy. In an effort to improve performance, SIP RFC compliance is not normally strictly adhered to:

pedantic=yes

realm

This option sets the realm for digest authentication. Set realm to your fully qualified domain name, which must be globally unique:

realm=mybox.example.com

recordhistory

You can set recordhistory to yes or no to enable or disable SIP history recording for all channels:

recordhistory=yes|no

registerattempts

Specifies how many times Asterisk will attempt its outbound registrations before giving up. This setting defaults to 0, which means that Asterisk will retry indefinitely:

registerattempts=0

registertimeout

Specifies how often Asterisk should attempt to re-register to other devices:

registertimeout=30

relaxdtmf

You can set relaxdtmf to yes or no. Setting it to yes will relax the DTMF detection handling. Use this if Asterisk is having a difficult time determining the DTMF on the SIP channel. Note that this may cause “talkoff,” where Asterisk incorrectly detects DTMF when it should not:

relaxdtmf=yes|no

rtautoclear (global)

This specifies whether or not Asterisk should auto-expire friends created on the fly on the same schedule as if they had just registered. 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 that number of seconds instead of the normal registration interval:

rtautoclear=yes|no|seconds

rtcachefriends (global)

If rtcachefriends is turned on, Asterisk will cache friends that come from the realtime engine, just as if they had come from sip.conf. This often helps with items such as message-waiting indications on realtime peers:

rtcachefriends=yes|no

rtsavesysname (global)

Specifies whether or not Asterisk should save the systemname in the realtime database at the time of registration:

rtsavesysname=yes|no

rtupdate (global)

If set to yes Asterisk will update the IP address, origination port, and registration period of a peer upon registration. Defaults to yes:

rtupdate=yes|no

sipdebug

Specifies whether or not Asterisk should turn on SIP debugging from the time that Asterisk loads the SIP channel driver:

sipdebug=yes|no

sendrpid

Specifies whether or not Asterisk should send a Remote-Party-ID header:

sendrpid=yes|no

srvlookup

DNS SRV records are a way of setting up a logical, resolvable address where you can be reached. This allows calls to be forwarded to different locations without the need to change the logical address. By using SRV records, you gain many of the advantages of DNS, whereas disabling them removes the ability to place SIP calls based on domain names.

Warning

Currently, the support for SRV records in Asterisk is somewhat lacking. If multiple SRV records are returned, Asterisk will use only the first record.

Using DNS SRV record lookups is highly recommended. To enable them, set srvlookup=yes in the [general] section of sip.conf:

srvlookup=yes

t1min

This is the minimum round-trip time for messages to monitored hosts in milliseconds. Defaults to 100 milliseconds:

t1min=100

subscribecontext

Limits SUBSCRIBE requests to the specified context. This is useful if you want to limit subscriptions to internal extensions, for example.

This option may also be set on a per-user or per-peer basis:

subscribecontext=internal

t38pt_udptl

Setting t38pt_udptl to yes enables T.38 fax (UDPTL) passthrough on SIP-to-SIP calls, provided both parties have T.38 support. This setting must be enabled in the general section for all devices to work. You can then disable it on a per-device basis:

t38pt_udptl=yes|no

Warning

T.38 fax passthrough works only in SIP-to-SIP calls, without any local or agent channel being used. Asterisk cannot currently originate or terminate T.38 fax calls; it can only passthrough UDPTL from one device to another.

tos_sip, tos_audio, and tos_video

Asterisk can set the TOS bits in the IP header to help improve performance on routers that respect TOS bits in their routing calculations. The tos_sip, tos_audio, and tos_video settings control the TOS bits for the SIP messages, the RTP audio, and RTP video respectively. Valid: CS0, CS1, CS2, CS3, CS4, CS5, CS6, CS7, AF11, AF12, AF13, AF21, AF22, AF23, AF31, AF32, AF33, AF41, AF42, AF43, and ef (expedited forwarding). You may also use a numeric value for the TOS bits.

For more information, see the doc/ip-tos.txt file in the Asterisk source directory.

trustrpid

Specifies whether or not Asterisk should trust the value in the Remote-Party-ID header:

trustrpid=yes|no

useragent

useragent takes as its argument a string specifying the value for the useragent field in the SIP header. The default value is asterisk:

useragent=Asterisk PBX v1.4

usereqphone

The usereqphone option tells Asterisk to add ;user=phone to SIP URIs that contain a valid phone number:

usereqphone

videosupport (both)

You can set videosupport to yes or no. You can turn it off on a per-peer basis if general video support is enabled, but you can’t enable it for one peer only without enabling it in the general section:

videosupport=yes|no

vmexten

This option sets the dialplan extension to reach the voicemailbox, and will be sent in the Message-Account section of the MWI NOTIFY message. Set this if your SIP device supports the Message-Account setting. This option defaults to asterisk:

vmexten=8500

SIP Channel Definitions

Now that we’ve covered the global SIP parameters, we will discuss the channel-specific parameters. These parameters can be defined for a user, a peer, or both (as noted in parentheses):

accountcode (both)

The account code can be defined on a per-user basis. If defined, this account code will be assigned to a call record whenever no specific user account code is set. The accountcode name configured will be used as the <filename>.csv in the /var/log/asterisk/cdr-csv/ directory to store CDRs for the user/peer/friend:

accountcode=iax-username

allow and disallow (both)

Specific codecs can be allowed or disallowed, limiting codec use to those preferred by the system designer. allow and disallow can also be defined on a per-channel basis. Keep in mind that allow statements in the [general] section will carry over to each of the channels, unless you reset with a disallow=all. Codec negotiation is attempted in the order in which the codecs are defined. Best practice suggests that you define disallow=all, followed by explicit allow statements for each codec you wish to use. If nothing is defined, allow=all is assumed:

disallow=all
allow=ulaw
allow=gsm
allow=ilbc

amaflags (both)

Automatic Message Accounting (AMA) is defined in the Telcordia Family of Documents listed under FR-AMA-1. These documents specify standard mechanisms for generation and transmission of CDRs. You can specify one of four AMA flags (default, omit, billing, or documentation) to apply to all SIP connections:

amaflags=documentation

callerid (both)

You can set a suggested Caller ID string for a user or peer with callerid. If you define a Caller ID field for a user, any calls that come in on that channel will have that Caller ID assigned to them, regardless of what the far end sends to you. If Caller ID is defined for a peer, you are requesting that the far end use that to identify you (keep in mind, however, that you have no way to ensure that it will do so). If you want incoming callers to be able to define their own Caller IDs (i.e., for guests), make sure you do not set the callerid field:

callerid=John Smith <[phone]>

callgroup and pickupgroup (both)

You can use the callgroup parameter to assign a channel definition to one or more groups, and you can use the pickupgroup option in conjunction with this parameter to allow a ringing phone to be answered from another extension. The pickupgroup option is used to control which callgroups a channel may pick up—a channel is given authority to answer another ringing channel if it is assigned to the same pickupgroup as the ringing channel’s callgroup. By default, remote ringing extensions can be answered with *8 (this is configurable in the features.conf file):

callgroup=1,3-5
pickupgroup=1,3-5

callingpres (both)

Sets Caller ID presentation for this user/peer. This setting takes one of the following options:

allowed_not_screened

Presentation allowed, not screened

allowed_passed_screen

Presentation allowed, passed screen

allowed_failed_screen

Presentation allowed, failed screen

allowed

Presentation allowed, network number

prohib_not_screened

Presentation prohibited, not screened

prohib_passed_screen

Presentation prohibited, passed screen

prohib_failed_screen

Presentation prohibited, failed screen

prohib

Presentation prohibited, network number

unavailable

Number unavailable

=yes|no

canreinvite (both)

The SIP protocol tries to connect endpoints directly. However, Asterisk must remain in the transmission path between the endpoints if it is required to detect DTMF (for more information, see Chapter 4):

canreinvite=no

context (both)

A context is assigned to a channel definition to direct incoming calls into the matching context in extensions.conf, where call handling is performed (see Chapters Chapter 4 and Chapter 5). Any channel connecting to an Asterisk machine has to have a context defined into which it will arrive. The context is essential for any user channel definition; if you do not define a context, incoming calls will be directed to the default context:

context=incoming

Warning

You should be aware of an unusual scenario that will require a context definition for a peer. When a call comes through the SIP channel, it first tries to find a matching user definition (based on the user name in square brackets and the secret). If it can’t find any matching users, it then looks for matching peers, based on the IP address that the call is coming from. Since peers don’t normally have contexts, this will cause such a call to arrive in the default context. While this will work, the default context shouldn’t really be used to handle incoming calls. The solution is to define a context, on a per-peer basis, for any peers that might match on incoming calls. To experiment with this, you can call your Free World Dialup number; the call will come right back to you.

defaultip (peer)

The defaultip setting complements host=dynamic. If a host has not yet registered with your server, you’ll attempt to send messages to the default IP address configured here:

defaultip=192.168.1.101

deny (both)

Specific IP addresses and ranges can be controlled with the deny option. To restrict access from a range of IP addresses, use a subnet mask—for example, deny=192.168.1.0/255.255.255.0. You can also deny all addresses with deny=0.0.0.0/0.0.0.0 and then allow only certain addresses with the permit command. Be aware of the security implications of this setting (see also permit):

deny=0.0.0.0/0.0.0.0

disallow (both)

See allow.

dtmfmode (both)

You can set dtmfmode to inband, rfc2833, or info. DTMF digits can be sent either in band (as part of the audio stream), or out of band (as signaling information), using the RFC 2833 or INFO methods. The inband method works reliably only when using an uncompressed codec such as G.711, μlaw, or alaw. The recommended method is to use rfc2833; however, some devices—such as those by Grandstream—support the info method:

dtmfmode=rfc2833

Note

In Asterisk 1.4, Variable Length DTMF was introduced in order to allow Asterisk to correctly signal to the far end the duration of a key press on the phone connected to the incoming channel (per IETF RFC 2833). Older Asterisk systems do not understand the variable-length parameter. In older Asterisk systems, DTMF delivered via RFC 2833 may not be correctly interpreted, leading to strange effects in sessions such as voicemail. If you want to have the older (pre-1.4) behaviour of the rfc2833 setting, you must add the rfc2833compensate=yes option to the peer in sip.conf that defines communication with your pre-1.4 Asterisk system.

fromdomain (peer)

This allows you to set the domain in the From: field of the SIP header. It may be required by some providers for authentication:

fromdomain=my.hostname.tld

fromuser (peer)

This allows you to set the username with which to authenticate. The name contained within the square brackets of the channel definition is usually used, but this can be overridden with the fromuser option. This allows a channel definition to be referenced with a name other than that used to authenticate:

fromuser=john_smith

host (peer)

This configures the host to which this peer is to connect. Use a fully qualified domain name:

host=remote.hostname.tld

incominglimit (both)

This option limits the total number of simultaneous calls for a peer or user. It sets the max number of simultaneous outgoing calls for a peer, or the max number of incoming calls for a user.

incominglimit=3

insecure (both)

When an INVITE is received from a remote location, Asterisk attempts to authenticate the string of characters before the @ sign on the INVITE line received in the SIP header with the name of a channel definition in sip.conf. If the remote end is a user agent, it will authenticate based on a user definition. However, if the remote end is a SIP proxy service, it will authenticate on the peer entry. When calls come from a provider such as Free World Dialup, which acts as a proxy for the true remote end who is calling you, that provider cannot authenticate the call on behalf of the endpoint. Since it would be impractical to have an authentication configured for every FWD user, and since FWD cannot respond to a 407 Proxy Authentication Required response, there must be an alternate way to allow calls from these callers.

If you set insecure=invite, you’ll determine which peer to match on by comparing the IP address or hostname and port number to those provided in the Contact field of the SIP header with the host and port options in sip.conf. If a match is found, authentication will not be required on the initial INVITE, and the call will be allowed.

If you have multiple endpoints behind a NAT device, you need to enable insecure=port to match against only the IP address. To not require authentication on the incoming INVITE for the peer, set insecure=invite,port:

insecure=invite

language (both)

This sets the language flag to whatever you define. The global default language is English. The language that is set is sent by the channel as an information element. It is also used by applications such as SayNumber() that have different files for different languages. Keep in mind that languages other than English are not explicitly installed on the system, and it is up to you to configure the system to ensure that the language you specify is handled properly:

language=en

mailbox (peer)

If you associate a mailbox with a peer within the channel definition, voicemail will send a MWI to the nodes on the end of that channel. If the mailbox number is in a voicemail context other than default, you can specify it as mailbox @ context. To associate multiple mailboxes with a single peer, use multiple mailbox statements:

mailbox=1000@internal

maxcallbitrate (both)

Sets the maximum bitrate for an individual call from this user or to this peer. Defaults to 384 Kb/s:

maxcallbitrate=384

md5secret (both)

If you do not wish to have plain-text secrets in your sip.conf files, you can use md5secret to configure the MD5 hash that can be used for authentication. To generate the MD5 hash from the Linux console, use the following command:

# echo -n "username:realm:secret" | md5sum

Be sure to use the -n flag, or echo will add a \n to the end of the string; the line feed will then be calculated into the MD5 hash, creating the incorrect hash. The realm, if not specified with the realm option (discussed in the list of general SIP parameters), defaults to asterisk. If both an md5secret and a secret are specified in the same channel definition, the secret will be ignored:

md5secret=0bcbe762982374c276fb01af6d272dca

mohinterpret (channel)

This option specifies a preference for which MoH class this channel should listen to when put on hold if the music class has not been set on the channel with Set(CHANNEL(musicclass)=whatever) in the dialplan, and the peer channel putting this one on hold did not suggest a music class.

This option may be specified globally, or on a per-user or per-peer basis:

mohinterpret=default

mohsuggest (channel)

This option specifies which music-on-hold class (as defined in musiconhold.conf) to suggest to the peer channel when this channel places the peer on hold. It may be specified globally or on a per-user or per-peer basis:

mohsuggest=default

musicclass (both)

This option sets the default music-on-hold class:

musicclass=classical

nat (both)

You can set nat to yes, no, or never. If you set it to yes, Asterisk ignores the IP address in the SIP and SDP headers and responds to the address and port in the IP header. The never option is for devices that cannot handle rport in the SIP header, such as the Uniden UIP200:

nat=yes|no|never

permit (both)

See deny.

pickupgroup (both)

See callgroup.

port (peer)

You can use this to define the port on which to listen for SIP signaling, if you want to listen on a nonstandard port. (The default port for SIP signaling is 5060.)

port=5060

progressinband (both)

You can set progressinband to yes, no, or never, to configure whether or not to generate in-band ringing. Normally, Asterisk will send the progress of a call via a few methods, such as 183 Session Progress, 180 Ringing, 486 Busy, and so on. If you set progressinband=yes, Asterisk will indicate the call progress in band by generating tones:

progressinband=yes|no|never

promiscredir (both)

You can set promiscredir to yes or no. Normally, when you perform call forwarding on a phone, Asterisk will use the Local channel (for example, local/18005551212@peer). If you set promiscredir=yes, Asterisk will use the SIP channel instead, which enables you to forward the calls to remote boxes:

promiscredir=yes|no

Warning

Note that if Asterisk performs a redirect to itself when promiscredir=yes, the system will receive an INVITE with the same Caller ID and detect a loop to itself. SIP does not have the ability to perform a hairpin call, so the channel will then be destroyed.

qualify (peer)

You can set qualify to yes, no, or a time in milliseconds. If you set qualify=yes, NOTIFY messages will be sent periodically to the remote peers to determine whether they are available and what the latency between replies is. A peer is determined unreachable if no reply is received within 2,000 ms (to change this default, instead set qualify to the number of milliseconds to wait for the reply). Use this option in conjunction with nat=yes to keep the path through the NAT device alive:

qualify=yes|no|seconds

regcontext (peer)

By specifying the context that contains the actions to perform, you can configure Asterisk to perform a number of actions when a peer registers to your server. This option works in conjunction with regexten by specifying the extension to execute. If no regexten is configured, the peer name is used as the extension. Asterisk will dynamically create and destroy a NoOp at priority 1 for the extension. All actions to be performed upon registration should start at priority 2. More than one regexten may be supplied, if separated by an &. regcontext can be set on a per-peer basis or globally:

regcontext=peer_registrations

regexten (peer)

The regexten option is used in conjunction with regcontext to specify the extension that is executed within the configured context. If regexten is not explicitly configured, the peer name is used as the extension to match:

regexten=1000

rtpholdtimeout (peer)

This takes as its argument an integer, specified in seconds. It terminates a call if no RTP data is received while on hold within the time specified. The value of rtpholdtimeout must be greater than that of rtptimeout (see also rtptimeout):

rtpholdtimeout=120

rtpkeepalive (peer)

Specifies how often Asterisk should send keepalives in the RTP stream, in seconds. Defaults to zero, which means Asterisk won’t send any RTP keepalives:

rtpkeepalive=45

rtptimeout (peer)

This takes as its argument an integer, specified in seconds. It terminates a call if no RTP data is received within the time specified:

rtptimeout=60

secret (both)

This sets the password to use for authentication:

secret=welcome

setvar (both)

This sets a channel variable, which will be available when a channel to the peer or user is created and will be destroyed when the call is hung up. For example, to set the channel variable foo with a value of bar, use:

setvar=foo=bar

username (peer)

The username field allows you to attempt contact with a peer before it has registered with you. At registration, a SIP device tells Asterisk which SIP URI to use to contact it. The username is used in conjunction with defaultip to create the SIP URI in the SIP INVITE header. This might be useful following a reboot, in order to place a call. The endpoints will not attempt to register with the server until their registration timeouts expire, so you will not know their locations. For nondynamic hosts, you will require the username to be specified, as it is used to construct the authorization username:

username=john_smith