Last time we left ourselves in the position of having two outgoing trunks available and four locally connected phone extensions. Let\u00e2\u20ac\u2122s remind ourselves of these endpoints.<\/p>\n
$ asterisk -r\nhostname*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 \nhandytone1\/handytone1 192.168.1.10 D 5060 OK (5 ms)\nhandytone2\/handytone2 192.168.1.10 D 5062 OK (6 ms)\nvoiptalkOFFICE\/222222222 77.240.48.94 N 5060 Unmonitored\nvoiptalkRESIDENTIAL\/11111 77.240.48.94 N 5060 Unmonitored\n6 sip peers [Monitored: 3 online, 1 offline Unmonitored: 2 online, 0 offline]<\/code><\/pre>\nLet\u00e2\u20ac\u2122s now start thinking about what we want our phone system to do (or rather, what I want mine to do, and hope that you want something similar).<\/p>\n
\nandyp<\/code>, wife<\/code>, handytone1<\/code> and handytone2<\/code> should all be able to ring each other internally.<\/li>\nandyp<\/code>, wife<\/code>, and handytone1<\/code> shall make outgoing calls on voiptalkRESIDENTIAL<\/code> by default.<\/li>\nhandytone2<\/code> shall make outgoing calls on voiptalkOFFICE<\/code> by default.<\/li>\n- Incoming calls to
voiptalkOFFICE<\/code> shall ring andyp<\/code> and handytone2<\/code><\/li>\n- Incoming calls to
voiptalkRESIDENTIAL<\/code> shall ring andyp<\/code>, wife<\/code>, and handytone1<\/code>.<\/li>\n<\/ul>\nThat\u00e2\u20ac\u2122ll do us as a reasonable start. This time we\u00e2\u20ac\u2122ll deal with the first of these requirements.<\/p>\n
Recall one of our local SIP endpoint definitions:<\/p>\n
[handytone1](user,ht386)\n secret=handytonesecret1\n callerid="Residential" <2102>\n context=internal-residential\n mailbox=household@default<\/code><\/pre>\nIn particular note the \u00e2\u20ac\u0153context<\/code>\u00e2\u20ac\u009d option. This tells Asterisk which extension context incoming calls from this endpoint should be \u00e2\u20ac\u0153run\u00e2\u20ac\u009d in. What does that mean? To understand that, we need to start looking in \/etc\/asterisk\/extensions.conf<\/code>. This file creates what Asterisk refers to as its \u00e2\u20ac\u0153dialplan\u00e2\u20ac\u009d. Don\u00e2\u20ac\u2122t be confused when you see it referred to like that.<\/p>\nMy suggestion is to delete or comment out everything not in the \u00e2\u20ac\u0153[general]<\/code>\u00e2\u20ac\u009d section, and even that is a lot of cruft. It\u00e2\u20ac\u2122s a thorough example configuration, but just causes us difficulties when we\u00e2\u20ac\u2122re making our own setup. In [general]<\/code> I suggest making sure you have the following options set:<\/p>\n[general]\nstatic=yes\nwriteprotect=yes\nclearglobalvariables=no<\/code><\/pre>\nWith that out of the way, let\u00e2\u20ac\u2122s begin with defining the \u00e2\u20ac\u0153internal-residential\u00e2\u20ac\u009d context that we\u00e2\u20ac\u2122ve placed andyp<\/code>, wife<\/code> and handytone1<\/code> in. While we\u00e2\u20ac\u2122re at it, we\u00e2\u20ac\u2122ll define \u00e2\u20ac\u0153internal-business\u00e2\u20ac\u009d for handytone2<\/code>.<\/p>\n[internal-residential]\ninclude => internal-extensions\n[internal-business] \ninclude => internal-extensions<\/code><\/pre>\nTo make these two contexts we\u00e2\u20ac\u2122ve simply included a third (as yet not defined) context, \u00e2\u20ac\u0153internal-extensions\u00e2\u20ac\u009d. We\u00e2\u20ac\u2122ll see why this is sensible later. Let\u00e2\u20ac\u2122s now define this common context, but we\u00e2\u20ac\u2122ll just write one extension for now:<\/p>\n
[internal-extensions]\nexten => andyp,1,Dial(SIP\/andyp,20)\nexten => andyp,2,Verbose(1,No answer from SIP\/andyp)\nexten => andyp,3,Hangup<\/code><\/pre>\nExtensions are like little programs, the form of the \u00e2\u20ac\u0153exten<\/code>\u00e2\u20ac\u009d line is<\/p>\nDIALSTRING,PRIORITY,COMMAND<\/code><\/pre>\nYou can see then we\u00e2\u20ac\u2122re defining the andyp<\/code> extension, i.e.\u00c2\u00a0this is what to do when someone calls the andyp<\/code> extension in the internal-extensions<\/code> context. Asterisk doesn\u00e2\u20ac\u2122t mind whether you use all numeric names or, as I have here, all alphabetic names in a dial string. When processing starts, the priority is at one, and is incremented after each command completes. So you can run multiple commands in response to a single DIALSTRING. In this case, we\u00e2\u20ac\u2122ve made it so that if someone dials the string \u00e2\u20ac\u0153andyp\u00e2\u20ac\u009d, Asterisk runs the Dial()<\/code> function which rings an endpoint, in this case \u00e2\u20ac\u0153SIP\/andyp\u00e2\u20ac\u009d. Note that it didn\u00e2\u20ac\u2122t have to be \u00e2\u20ac\u0153SIP\/andyp\u00e2\u20ac\u009d there is nothing that stop us (except common sense) from having the \u00e2\u20ac\u0153andyp\u00e2\u20ac\u009d extension dial the \u00e2\u20ac\u0153SIP\/wife\u00e2\u20ac\u009d endpoint. If after 20 seconds, there has been no answer, then the next priority runs. That priority uses the Verbose()<\/code> function to issue a message at verbosity level 1. The final priority, 3, hangs up.<\/p>\nIt can get tedious maintaining these priority numbers, so Asterisk offers a short cut in the form of the special, \u00e2\u20ac\u0153n\u00e2\u20ac\u009d priority.<\/p>\n
[internal-extensions]\nexten => andyp,1,Dial(SIP\/andyp,20)\nexten => andyp,n,Verbose(1,No answer from SIP\/andyp)\nexten => andyp,n,Hangup<\/code><\/pre>\nThis simply means, \u00e2\u20ac\u0153one more than the previous\u00e2\u20ac\u009d. So this is identical in function to the first version.<\/p>\n
There are other special priorities, but one in particular is important to us here. The \u00e2\u20ac\u0153hint\u00e2\u20ac\u009d priority.<\/p>\n
[internal-extensions]\nexten => andyp,1,Dial(SIP\/andyp,20)\nexten => andyp,n,Verbose(1,No answer from SIP\/andyp)\nexten => andyp,n,Hangup\nexten => andyp,hint,SIP\/andyp<\/code><\/pre>\nWith this in place run the asterisk command line again.<\/p>\n
hostname*CLI> reload\nhostname*CLI> core show hints\n\n -= Registered Asterisk Dial Plan Hints =-\n andyp@internal-extensions : SIP\/andyp State:Idle Watchers 0\n----------------\n- 1 hints registered<\/code><\/pre>\nAsterisk hints form a connection between an arbitrarily named extension and an endpoint. This connection allows use of the SIP SUBSCRIBE command. SIP phones can ask to be notified of the presence or absence of another extension. But extensions are not endpoints, so when, say, SIP\/wife<\/code> sends a \u00e2\u20ac\u0153SUBSCRIBE andyp\u00e2\u20ac\u009d command, Asterisk (without the hint) has no way of knowing which endpoint\u00e2\u20ac\u2122s presence should be reported. The hint fixes that problem \u00e2\u20ac\u201c Asterisk will now know.<\/p>\nBack to our extensions.conf<\/code>. Do you notice that we wrote \u00e2\u20ac\u0153andyp\u00e2\u20ac\u009d a lot in that definition? If we ever renamed \u00e2\u20ac\u0153andyp\u00e2\u20ac\u009d it\u00e2\u20ac\u2122s a lot of work to change. It\u00e2\u20ac\u2122s also makes copy and pasting this entry to create others a lot more work. Let\u00e2\u20ac\u2122s address that.<\/p>\n[internal-extensions]\nexten => andyp,1,Dial(SIP\/${EXTEN},20)\nexten => andyp,n,Verbose(1,No answer from SIP\/${EXTEN})\nexten => andyp,n,Hangup\nexten => andyp,hint,SIP\/${EXTEN}<\/code><\/pre>\n\u00e2\u20ac\u0153${EXTEN}<\/code>\u00e2\u20ac\u009d is an Asterisk variable. It is expanded when processing the line. \u00e2\u20ac\u0153${EXTEN}<\/code>\u00e2\u20ac\u009d in particular is a built-in variable and it expands to the name of the current extension. So now, provided we name our extensions the same as our SIP endpoints, we have made our extension handling generic.<\/p>\n[internal-extensions]\nexten => andyp,1,Dial(SIP\/${EXTEN},20)\nexten => andyp,n,Verbose(1,No answer from SIP\/${EXTEN})\nexten => andyp,n,Hangup\nexten => andyp,hint,SIP\/${EXTEN}\nexten => wife,1,Dial(SIP\/${EXTEN},20)\nexten => wife,n,Verbose(1,No answer from SIP\/${EXTEN})\nexten => wife,n,Hangup\nexten => wife,hint,SIP\/${EXTEN}<\/code><\/pre>\nOur use of a variable has improved things, but this is still a lot of duplicated code. Further, if we add a new feature to the andyp<\/code> extension, we have to remember to add it to the wife<\/code> extension too. Wouldn\u00e2\u20ac\u2122t it be better if we just had one copy of the extension handling code? Yep.<\/p>\n[stdexten]\nexten => s,1,Verbose(1,Start stdexten ${ARG1},${ARG2})\nexten => s,n,Set(LOCAL(ext)=${ARG2})\nexten => s,n,Set(LOCAL(dev)=${ARG1})\nexten => s,n,Dial(${dev},20)\nexten => s,n,Goto(s-${DIALSTATUS},1)\nexten => s-NOANSWER,1,Verbose(1,No answer from ${ext})\nexten => s-NOANSWER,n,Return()\nexten => s-BUSY,n,Verbose(1,${ext} is busy)\nexten => s-BUSY,n,Return()\nexten => _s-.,1,Goto(s-NOANSWER,1)\n\n[internal-extensions]\nexten => andyp,1,Gosub(stdexten,s,1(SIP\/${EXTEN},${EXTEN}))\nexten => andyp,hint,SIP\/${EXTEN}\nexten => wife,1,Gosub(stdexten,s,1(SIP\/${EXTEN},${EXTEN}))\nexten => wife,hint,SIP\/${EXTEN}<\/code><\/pre>\nNow we\u00e2\u20ac\u2122re cooking. We\u00e2\u20ac\u2122ve made a fairly large handler that behaves identically for both andyp<\/code> and wife<\/code> and yet doesn\u00e2\u20ac\u2122t duplicate any code. I won\u00e2\u20ac\u2122t go into exactly how [stdexten]<\/code> works, the Asterisk documentation will tell you if you are interested (it\u00e2\u20ac\u2122s not rocket science though, you should be able to guess just by looking at it here).<\/p>\nWe can now add all of our endpoints to internal-extensions<\/code> and have their hints set and have them callable. Should you have a genuine SIP phone which supports text extensions, you would then be able to call any of them. However, we need to cater for numeric keypads too. We can do that easily. Here\u00e2\u20ac\u2122s our completed [internal-extensions]<\/code> with numeric aliases that match the callerid<\/code> options we gave in sip.conf<\/code>.<\/p>\n[internal-extensions]\n; Numeric aliases\nexten => 2100,1,Goto(andyp,1)\nexten => 2101,1,Goto(wife,1)\nexten => 2102,1,Goto(handytone1,1)\nexten => 2103,1,Goto(handytone2,1)\n; Named extensions\nexten => andyp,1,Gosub(stdexten,s,1(SIP\/${EXTEN},${EXTEN}))\nexten => andyp,hint,SIP\/${EXTEN}\nexten => wife,1,Gosub(stdexten,s,1(SIP\/${EXTEN},${EXTEN}))\nexten => wife,hint,SIP\/${EXTEN}\nexten => handytone1,1,Gosub(stdexten,s,1(SIP\/${EXTEN},${EXTEN}))\nexten => handytone1,hint,SIP\/${EXTEN}\nexten => handytone2,1,Gosub(stdexten,s,1(SIP\/${EXTEN},${EXTEN}))\nexten => handytone2,hint,SIP\/${EXTEN}<\/code><\/pre>\nReload from the command line interface and you should then be able to dial extensions from each other just like you would on a much more expensive PBX.<\/p>\n
Next time we\u00e2\u20ac\u2122ll look at making outgoing calls on different trunks for different extensions.<\/p>\n
asterisk1<\/a> asterisk2<\/a> asterisk3<\/a> asterisk4<\/a> asterisk5<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Last time we left ourselves in the position of having two outgoing trunks available and four locally connected phone extensions. Let\u00e2\u20ac\u2122s remind ourselves of these endpoints. $ asterisk -r 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\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[31,6],"_links":{"self":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/445"}],"collection":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=445"}],"version-history":[{"count":10,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/445\/revisions"}],"predecessor-version":[{"id":1088,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/445\/revisions\/1088"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=445"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=445"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=445"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}