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 = voicemail
The 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=rfc2833
Essentially: 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@default
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
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 No
Our use of
friend instead of
peer for the two local endpoints sets up these two user accounts. But
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 188.8.131.52 N 5060 Unmonitored voiptalkRESIDENTIAL/11111 184.108.40.206 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 “
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@default
With 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 220.127.116.11 N 5060 Unmonitored voiptalkRESIDENTIAL/11111 18.104.22.168 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.