Last time we discussed registering multiple trunk lines from a provider using our Asterisk server. As yet, we have no way of making calls, nor any device to receive incoming calls on. Our two trunks are, at the moment, pretty useless.
This time then we’ll talk about how to configure some local endpoints. These are the other side of the coin we’ve already seen. When we defined our trunks we specified how to register ourselves with our SIP provider. For locally connected devices we are the provider and we expect them to register with us.
The broad strokes are exactly the same, we will make a template endpoint describing the SIP device connecting to us, then inherit that template and provide some device-specific settings. We’ll talk, here, only about SIP devices, but be aware that Asterisk supports other device types as well. Let’s first use a template (note the “(!)â€) to describe a locally-connected device:
[user](!)
type=friend
; address is dhcp assigned, so we can't match by host because we don't know it.
; host=dynamic means we allow the device to register with us.
host=dynamic
; Can only talk directly if not behind NAT (rename to directmedia)
canreinvite=nonat
; regularly poll the device to ensure connectivity (shows 'OK' instead of 'unmonitored'
; in 'sip show peers')
qualify=yes
; Where to direct SUBSCRIBE requests
subscribecontext = internal-extensions
; Keep track of calls-in-progress to this device, and stop at 2
callcounter = yes
busylevel = 2
; Help the device know what to dial to get voicemail
vmexten = voicemailThe last four options will be important for us later, simply accept them as they are for now. The two key options are “type=friend†and “host=dynamicâ€. Defining the endpoint as a friend makes it both a peer and a user. We have already seen type=peer in our trunk endpoint definitions, peers define how incoming calls are matched. Being a user as well (which is what friend does requires that the endpoint register with us). Then host=dynamic causes the IP address of the endpoint to be set when the endpoint registers.
The simplest devices to set up are softphones. I’ll use the Android softphone, CSipSimple for now as an example, but you’ll find that whatever device you use will be very similar. First a template to describe the device capabilities.
[csipsimple](!)
qualify=5000
disallow=all
allow=ulaw
allow=g726
allow=gsm
dtmfmode=rfc2833Essentially: codecs and DTMF mode. Set them to suit what the phone supports.
Now we create non-template entries to configure the phones themselves.
[andyp](user,csipsimple)
defaultuser=andyp
secret=make_up_a_secret1
mailbox=andyp@default
callerid="Andy (android)" <2100>
context=internal-residential
[wife](user,csipsimple)
defaultuser=wife
secret=make_up_a_secret2
callerid="Wife (android)" <2101>
context=internal-residential
mailbox=wife@defaultdefaultuser and secret are the key options. They are what enable the endpoint to identify itself to us. callerid is just stored, the number doesn’t signify anything to Asterisk. We’ll come back to the mailbox and context later.
Save this sip.conf and return to the command line interface.
$ asterisk -r
hostname*CLI> reload
hostname*CLI> sip show users
Username Secret Accountcode Def.Context ACL ForcerPort
andyp make_up_a_secre internal-re No No
wife make_up_a_secre internal-re No NoOur use of friend instead of peer for the two local endpoints sets up these two user accounts. But friends are peers as well in Asterisk.
hostname*CLI> sip show peers
Name/username Host Dyn Forcerport ACL Port Status
andyp/andyp 192.168.1.82 D OK (100 ms)
wife/wife (Unspecified) D 0 UNKNOWN
voiptalkOFFICE/222222222 77.240.48.94 N 5060 Unmonitored
voiptalkRESIDENTIAL/11111 77.240.48.94 N 5060 Unmonitored
4 sip peers [Monitored: 1 online, 1 offline Unmonitored: 2 online, 0 offline]Our two additional peers exist for the two local endpoints, one hasn’t registered with the server so is listed as “UNKNOWN†status. The other is 100ms of latency away, but is “OKâ€.
It should be clear now what the three lists show.
- “
sip show registry†gives a list of SIP servers our server registers to. It will show the same number of items regardless of whether the registration was successful (although in our example last time, we saw the successful “Registered†state), one entry per “callbackextensionâ€. - “
sip show users†gives a list of user accounts that can register with our server. It will show the same number of items regardless of how many are actually registered with us right now. - “
sip show peers†shows us all our peers and their status. Any endpoint that we expect to make calls to us must be in this list. It is this list that Asterisk checks incoming calls against to map to an endpoint definition.
Should you wish to, you can buy analogue telephone adapters (ATA) and connect them to your network. I’ve got a (now discontinued annoyingly, it’s very good) HandyTone 386 from Grandstream which has two FXS ports on it.
[ht386](!)
disallow=all
allow=ulaw
allow=alaw
allow=g726
[handytone1](user,ht386)
secret=handytonesecret1
callerid="Residential" <2102>
context=internal-residential
mailbox=household@default
[handytone2](user,ht386)
secret=handytonesecret2
callerid="Office" <2103>
context=internal-business
mailbox=business@defaultWith these in place we now have four local extensions to play with.
hostname*CLI> reload
hostname*CLI> sip show peers
Name/username Host Dyn Forcerport ACL Port Status
andyp/andyp 192.168.1.82 D OK (100 ms)
wife/wife (Unspecified) D 0 UNKNOWN
handytone1/handytone1 192.168.1.10 D 5060 OK (5 ms)
handytone2/handytone2 192.168.1.10 D 5062 OK (6 ms)
voiptalkOFFICE/222222222 77.240.48.94 N 5060 Unmonitored
voiptalkRESIDENTIAL/11111 77.240.48.94 N 5060 Unmonitored
6 sip peers [Monitored: 3 online, 1 offline Unmonitored: 2 online, 0 offline]Now we have trunks and extensions defined but we still don’t have a phone system. Next time we’ll look at joining our endpoints up under our control.