{"id":443,"date":"2012-08-30T01:00:00","date_gmt":"2012-08-29T23:00:00","guid":{"rendered":"https:\/\/www.fussylogic.co.uk\/blog\/?p=443"},"modified":"2013-06-26T11:53:42","modified_gmt":"2013-06-26T10:53:42","slug":"asterisk-for-a-small-business-ii","status":"publish","type":"post","link":"https:\/\/www.fussylogic.co.uk\/blog\/?p=443","title":{"rendered":"Asterisk For a Small Business (II)"},"content":{"rendered":"

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.<\/p>\n

This time then we\u00e2\u20ac\u2122ll talk about how to configure some local endpoints. These are the other side of the coin we\u00e2\u20ac\u2122ve 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.<\/p>\n

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\u00e2\u20ac\u2122ll talk, here, only about SIP devices, but be aware that Asterisk supports other device types as well. Let\u00e2\u20ac\u2122s first use a template (note the \u00e2\u20ac\u0153(!)\u00e2\u20ac\u009d) to describe a locally-connected device:<\/p>\n

[user](!)\n    type=friend\n    ; address is dhcp assigned, so we can't match by host because we don't know it.\n    ; host=dynamic means we allow the device to register with us.\n    host=dynamic\n    ; Can only talk directly if not behind NAT (rename to directmedia)\n    canreinvite=nonat\n    ; regularly poll the device to ensure connectivity (shows 'OK' instead of 'unmonitored'\n    ; in 'sip show peers')\n    qualify=yes\n    ; Where to direct SUBSCRIBE requests\n    subscribecontext = internal-extensions\n    ; Keep track of calls-in-progress to this device, and stop at 2\n    callcounter = yes\n    busylevel = 2\n    ; Help the device know what to dial to get voicemail\n    vmexten = voicemail<\/code><\/pre>\n
The last four options will be important for us later, simply accept them as they are for now. The two key options are \u00e2\u20ac\u0153type=friend<\/code>\u00e2\u20ac\u009d and \u00e2\u20ac\u0153host=dynamic<\/code>\u00e2\u20ac\u009d. Defining the endpoint as a friend makes it both a peer and a user. We have already seen type=peer<\/code> in our trunk endpoint definitions, peers define how incoming calls are matched. Being a user as well (which is what friend<\/code> does requires that the endpoint register with us). Then host=dynamic<\/code> causes the IP address of the endpoint to be set when the endpoint registers.<\/p>\n
The simplest devices to set up are softphones. I\u00e2\u20ac\u2122ll use the Android softphone, CSipSimple<\/a> for now as an example, but you\u00e2\u20ac\u2122ll find that whatever device you use will be very similar. First a template to describe the device capabilities.<\/p>\n
[csipsimple](!)\n    qualify=5000\n    disallow=all\n    allow=ulaw\n    allow=g726\n    allow=gsm\n    dtmfmode=rfc2833<\/code><\/pre>\n
Essentially: codecs and DTMF mode. Set them to suit what the phone supports.<\/p>\n
Now we create non-template entries to configure the phones themselves.<\/p>\n
[andyp](user,csipsimple)\n    defaultuser=andyp\n    secret=make_up_a_secret1\n    mailbox=andyp@default\n    callerid="Andy (android)" <2100>\n    context=internal-residential\n\n[wife](user,csipsimple)\n    defaultuser=wife\n    secret=make_up_a_secret2\n    callerid="Wife (android)" <2101>\n    context=internal-residential\n    mailbox=wife@default<\/code><\/pre>\n
defaultuser<\/code> and secret<\/code> are the key options. They are what enable the endpoint to identify itself to us. callerid<\/code> is just stored, the number doesn\u00e2\u20ac\u2122t signify anything to Asterisk. We\u00e2\u20ac\u2122ll come back to the mailbox<\/code> and context<\/code> later.<\/p>\n
Save this sip.conf<\/code> and return to the command line interface.<\/p>\n
$ asterisk -r\nhostname*CLI> reload\nhostname*CLI> sip show users\nUsername                   Secret           Accountcode  Def.Context ACL  ForcerPort\nandyp                      make_up_a_secre               internal-re No   No\nwife                       make_up_a_secre               internal-re No   No<\/code><\/pre>\n
Our use of friend<\/code> instead of peer<\/code> for the two local endpoints sets up these two user accounts. But friend<\/code>s are peer<\/code>s as well in Asterisk.<\/p>\n
hostname*CLI> sip show peers\nName\/username              Host           Dyn Forcerport ACL Port  Status     \nandyp\/andyp                192.168.1.82    D                       OK (100 ms)\nwife\/wife                  (Unspecified)   D   0                   UNKNOWN    \nvoiptalkOFFICE\/222222222   77.240.48.94        N             5060  Unmonitored\nvoiptalkRESIDENTIAL\/11111  77.240.48.94        N             5060  Unmonitored\n4 sip peers [Monitored: 1 online, 1 offline Unmonitored: 2 online, 0 offline]<\/code><\/pre>\n
Our two additional peers exist for the two local endpoints, one hasn\u00e2\u20ac\u2122t registered with the server so is listed as \u00e2\u20ac\u0153UNKNOWN\u00e2\u20ac\u009d status. The other is 100ms of latency away, but is \u00e2\u20ac\u0153OK\u00e2\u20ac\u009d.<\/p>\n
It should be clear now what the three lists show.<\/p>\n