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 <(800) 555-1234>
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_screenedPresentation Allowed, Not Screened
allowed_passed_screenPresentation Allowed, Passed Screen
allowed_failed_screenPresentation Allowed, Failed Screen
allowedPresentation Allowed, Network Number
prohib_not_screenedPresentation Prohibited, Not Screened
prohib_passed_screenPresentation Prohibited, Passed Screen
prohib_failed_screenPresentation Prohibited, Failed Screen
prohibPresentation Prohibited, Network Number
unavailableNumber 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 4
and 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.
![]() |
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 |
context=incoming
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 only works reliably when
using an uncompressed codec such as G.711, ulaw, 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 only against 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 message waiting indication 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 music on hold 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
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
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, ocal/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
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
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. 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.
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 non-dynamic hosts, you will require the username to
be specified, as it is used to construct the authorization
username.
username=john_smith