. Part 1
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=username (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
allow and disallow (both)
disallow=all
allow=ulaw
allow=gsm
allow=ilbc
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
amaflags=documentation (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
callerid=John Smith <1111-1234> (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.
callgroup and pickupgroup (both)
callgroup=1,3-5
pickupgroup=1,3-5
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.conffile)
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 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
defaultip=192.168.1.101 (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.
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)
disallow (both) See allow.
dtmfmode=rfc2833 (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
fromdomain=my.hostname.tld (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
fromuser=john_smith (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
host=remote.hostname.tld (peer)
This configures the host to which this peer is to connect. Use a fully qualified domain name
incominglimit=3 (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.
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
mailbox=100@internal (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
maxcallbitrate=384 (both)
Sets the maximum bitrate for an individual call from this user or to this peer. Defaults to 384 Kb/s
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
mohinterpret=default (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
mohsuggest=default (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
musicclass=classical (both)
This option sets the default music-on-hold class
nat=yes|no|never (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
permit (both) See deny.
pickupgroup (both) See callgroup.
port=5060 (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.)
progressinband=yes|no|never (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
promiscredir=yes|no (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/1800xxxx@peer). If you set promiscredir=yes, Asterisk will use the SIP channel instead, which enables you to forward the calls to remote boxes
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=yes|no|seconds (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
regcontext=peer_registrations (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
regexten=1000 (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
rtpholdtimeout=120 (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 rtphold timeout must be greater than that of rtptimeout (see also rtptimeout)
rtpkeepalive=45 (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
rtptimeout=60 (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
secret=your secret (both)
This sets the password to use for authentication
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=john_smith (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:
Comments
Post a Comment