When last we spoke, we had created an internal phone system. We had four extensions that could all happily call each other. This time we\u00e2\u20ac\u2122re going to extend that facility to include the ability to dial arbitrary numbers using our outgoing trunks.<\/p>\n
Recall how we arranged our contexts in the dialplan?<\/p>\n
[stdexten]\n; ... standard code for handling a dialled local extension ...\n\n[internal-extensions]\n; ... extension definitions and hints for all our local extensions ...\n\n[internal-residential]\ninclude => internal-extensions\n[internal-business] \ninclude => internal-extensions<\/code><\/pre>\nAlso recall that we used the \u00e2\u20ac\u0153context=<\/code>\u00e2\u20ac\u009d option in sip.conf<\/code> to place SIP\/andyp<\/code>, SIP\/wife<\/code>, and SIP\/handytone1<\/code> in the \u00e2\u20ac\u0153[internal-residential]<\/code>\u00e2\u20ac\u009d context; and SIP\/handytone2<\/code> in the \u00e2\u20ac\u0153[internal-business]<\/code>\u00e2\u20ac\u009d context.<\/p>\nAt this point, \u00e2\u20ac\u0153internal-residential\u00e2\u20ac\u009d and \u00e2\u20ac\u0153internal-business\u00e2\u20ac\u009d behave identically since they both only include the extensions definition. However, our \u00e2\u20ac\u0153internal-extensions\u00e2\u20ac\u009d context only says what to do for a very limited subset of possible dial strings. What if an endpoint in the \u00e2\u20ac\u0153internal\u00e2\u20ac\u009d context dials something other than another extension? At the moment \u00e2\u20ac\u201c nothing. Let\u00e2\u20ac\u2122s change that to \u00e2\u20ac\u0153something\u00e2\u20ac\u009d.<\/p>\n
[internal-residential]\ninclude => internal-extensions\nexten => _0X.,1,Dial(SIP\/voiptalkRESIDENTIAL\/${EXTEN})\n\n[internal-business] \ninclude => internal-extensions\nexten => _0X.,1,Dial(SIP\/voiptalkOFFICE\/${EXTEN})<\/code><\/pre>\nAsterisk scans the dialplan in the order it\u00e2\u20ac\u2122s defined, so when a new call enters, say \u00e2\u20ac\u0153internal-residential\u00e2\u20ac\u009d, it hits the included \u00e2\u20ac\u0153internal-extensions\u00e2\u20ac\u009d first. If none of them matches the dialled string, asterisk continues scanning \u00e2\u20ac\u0153internal-residential\u00e2\u20ac\u009d. Here I\u00e2\u20ac\u2122ve added a special extension, \u00e2\u20ac\u0153_0X.<\/code>\u00e2\u20ac\u009d. The \u00e2\u20ac\u0153_<\/code>\u00e2\u20ac\u009d tells Asterisk that it shouldn\u00e2\u20ac\u2122t match this extension literally, instead it should do a pattern match.<\/p>\n\n- \u00e2\u20ac\u0153
_<\/code>\u00e2\u20ac\u009d pattern match<\/li>\n- \u00e2\u20ac\u0153
0<\/code>\u00e2\u20ac\u009d match a literal zero. Therefore anything dialled without a zero prefix will not match.<\/li>\n- \u00e2\u20ac\u0153
X<\/code>\u00e2\u20ac\u009d match any digit 0-9.<\/li>\n- \u00e2\u20ac\u0153
.<\/code>\u00e2\u20ac\u009d match any number of any character<\/li>\n<\/ul>\nYou can therefore read this extension to mean \u00e2\u20ac\u0153anything prefixed with a zero\u00e2\u20ac\u009d. All UK numbers start with a zero (if you count the area code), so will be handled by this entry. The handler runs the following command:<\/p>\n
Dial(SIP\/voiptalkRESIDENTIAL\/${EXTEN})<\/code><\/pre>\nHere, \u00e2\u20ac\u0153${EXTEN}<\/code>\u00e2\u20ac\u009d will be replaced not with the pattern but with the string that matched the pattern \u00e2\u20ac\u201c i.e.\u00c2\u00a0what the caller dialled. This form of \u00e2\u20ac\u0153Dial()\u00e2\u20ac\u009d references one of our endpoints that we defined (and named) in sip.conf<\/code>. In reality, Asterisk looks up the options from sip.conf<\/code> and translates this to:<\/p>\nDial(SIP\/${EXTEN}:password::username@voiptalk.org)<\/code><\/pre>\nBut our symbolic form is far more meaningful to us.<\/p>\n
Note now that I\u00e2\u20ac\u2122ve added a different dial target to each of [internal-residential]<\/code> and [internal-extensions]<\/code>. This means when no local extension matches each dials out externally on a different trunk<\/em>.<\/p>\nFor now we\u00e2\u20ac\u2122ve addresses the two outgoing requirements from our list:<\/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>\n<\/ul>\nWe\u00e2\u20ac\u2122ll return to the internal part of the dial plan later, but now we turn to how to process incoming calls.<\/p>\n
Recall one of our trunk configurations from sip.conf<\/code>.<\/p>\n[voiptalkOFFICE](voiptalk)\n defaultuser=222222222\n secret=your_222222222_secret_goes_here\n fromuser=222222222\n context=external\n callbackextension=trunkOFFICE<\/code><\/pre>\nNow we\u00e2\u20ac\u2122re more familiar with the dialplan, the context<\/code> and callbackextension<\/code> options should make more sense. We already know that the context<\/code> option defines which dialplan context handles inbound calls from this endpoint. Just as we put all our internal endpoints to be handled within an \u00e2\u20ac\u0153[internal-extensions]\u00e2\u20ac\u009d context, we have put our two external endpoints in an \u00e2\u20ac\u0153[external]\u00e2\u20ac\u009d context.<\/p>\nWhat about the dialled extension though? Remember that from the point of view of our trunk provider, we have only one extension, \u00e2\u20ac\u0153222222222\u00e2\u20ac\u009d in the case of this \u00e2\u20ac\u0153voiptalkOFFICE\u00e2\u20ac\u009d endpoint. In essence then \u00e2\u20ac\u201c there is no information for us to obtain from the dialled extension given by a trunk it will always<\/em> be our single number. That\u00e2\u20ac\u2122s why Asterisk is able to use the callbackextension<\/code> option as a trigger for registration with the provider, all we\u00e2\u20ac\u2122re doing is overriding one fixed piece of information with another (as a fringe benefit it would also address the situation where we had the same username at two providers \u00e2\u20ac\u201c how would we tell them apart in the dialplan?). callbackextension<\/code> then simply defines what Asterisk will rewrite the dialstring to when it runs the dialplan context to handle this incoming call.<\/p>\nLet\u00e2\u20ac\u2122s now add an appropriate \u00e2\u20ac\u0153[external]<\/code>\u00e2\u20ac\u009d context for these incoming calls from an external trunk.<\/p>\n[external]\nexten => voiptalkRESIDENTIAL,1,Verbose(1,Incoming call on callbackextension=${EXTEN})\nexten => voiptalkRESIDENTIAL,n,Dial(SIP\/andyp&SIP\/wife&SIP\/handytone1)\nexten => voiptalkOFFICE,1,Verbose(1,Incoming call on callbackextension=${EXTEN} from ${CALLERID(all)})\nexten => voiptalkOFFICE,n,Dial(SIP\/andyp&SIP\/handytone2)<\/code><\/pre>\nHere we\u00e2\u20ac\u2122ve used Asterisk\u00e2\u20ac\u2122s ability to specify multiple endpoints in a single \u00e2\u20ac\u0153Dial()\u00e2\u20ac\u009d to ring exactly the extensions we wanted in our original spec.<\/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>\nCheck, check, check, check, check.<\/p>\n
We\u00e2\u20ac\u2122ve now got a perfectly workable telephone system. Why stop now though? Next time we\u00e2\u20ac\u2122ll look at adding some additional features; in particular: voicemail. Then you can chuck away that answering machine.<\/p>\n
asterisk1<\/a> asterisk2<\/a> asterisk3<\/a> asterisk4<\/a> asterisk5<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"When last we spoke, we had created an internal phone system. We had four extensions that could all happily call each other. This time we\u00e2\u20ac\u2122re going to extend that facility to include the ability to dial arbitrary numbers using our outgoing trunks. Recall how we arranged our contexts in the dialplan? [stdexten] ; … standard\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\/447"}],"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=447"}],"version-history":[{"count":9,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/447\/revisions"}],"predecessor-version":[{"id":773,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/447\/revisions\/773"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=447"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=447"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=447"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}