Recently, I have been toying with Asterisk 1.6.0 to work in some new internal features that I want to leverage.
One of the key features I took advantage of is the context option for each SIP peer. It is possible to exclude one group of users from calling another group by using contexts.
Let’s say I want user 300 to never be able to call two users, 400 and 420. 420 and 400 can call each other, and call 300. User 300 is simply someone who will get bullied by 400 & 420, but won’t be able to get back at them.
This is accomplished easily through the use of extensions and SIP peer contexts.
I set the context for 300 to ‘victim’. I set the context for 400 and 420 to ‘attack’.
Then, in extensions.conf I create the appropriate configurations.
[victim]
exten => _310X.,1,Dial(SIP/${EXTEN})
exten => _310X.,n,Hangup
[attack]
exten => _4X.,1,Dial(SIP/${EXTEN})
exten => _4X.,n,Hangup
exten => _3X.,n,Dial(SIP/${EXTEN})
exten => _3X.,n,Hangup
The sip configuration for each is similar to the below:
[310]
type=friend
username=310
secret=yamomma
allow=all
context=victim
[400]
type=friend
username=400
secret=md5
allow=all
context=attack
[420]
type=friend
username=420
secret=secret
allow=all
context=attack
Try as 310 might, there is no way they can call via the system to 400, however, 400 and 420 can ring 310 as often as they wish.
You can of course add the 4X route to the extensions, and playback a message to the user.
This method can be used to restrict calls to certain areas, such as 1900, or international numbers. It can also be used as a call control method, in the event you don’t want a specific extension calling someone.
It is important to have a peer and user definition. After upgrading to Asterisk 1.6.0 on my test server, I found my test development server (used for simulation) running Trixbox 1.1 (yep, ancient crap), would not accept calls.
I upgraded to 1.4.22 on the test development server, and found the same issue. This was resolved by changing the sip definitions used for interserver communication to be ‘friend’ type, rather than ‘user’ type that appears to have been automatically created by Trixbox – no longer used.
Oh well, back to enjoying a long weekend here in NSW. Another day for me to experiment some more and try and push forward with the updates planned for OzVoIPStatus!
Speaking of OzVoIPStatus – one of the areas I’m having difficulties enhancing is the method in which providers may specify plan data – some have included calls, others have none. Some have unlimited calls, and others have untimed call rates. It’s not so much a difficulty designing this – it’s more in the way of presentation on the page.
Enjoy!