Brain dumps...


Ok,

a very basic page to show what I'm working on at the moment.


New - Open79xx mods 8nd Jan 2006

Added the ability to take a snapshot of a device screen


Since I'm unsure at this time if the SIP image can handle this only SCCP phones have the snapshot option. Below is the result.






New - Open79xx mods 3nd Jan 2006

Added the ability to define SCCP information and generate the SEP[MAC_ADDRESS].cnf.xml files, can also regenerate the RINGLIST.XML file form this







New - Open79xx mods 2nd Jan 2006

Someone on the chan_sccp list pointed us to Open79XX which looked pretty useful. I decided to make a few modifications, the first of which is to allow the selection of different types of idle screen on my Cisco 7960's/40's

The next thing to add will be the generation of the SEP files with all the relavant information for each phone.



New - Late night work. Sample config file for the webserver 24th Apr 2005

Here's an example config file for the webserver. Note we now have the ability to apply ACL's to the service, plus we have authentication. I haven't quite decided on any layout details at this stage. The is some awkwardness, since most of the functions/procedures for the parts of asterisk aren't public (available to other apps) - simple example? Getting the version number of asterisk - it would be nice to have some things exposed to other apps. This might result in a) some duplication or b) changes to other parts of asterisk - at present pbx_web.so is all that's needed, no changes to the rest of asterisk are required.
;
; configuration for pbx_web.so
;
[general]
; If the parameters in this section need
; to be changed then an RESTART of asterisk
; is required!
;
; The port to use for the webserver
;
port=8011
;
; Which ip address to bind to. if this
; line is commented out then the webserver
; will bind to the same port on ALL ip
; addresses on the server
;
;bind=192.168.1.2
;
;
;
[users]
;
; only adminuser is supported at this
; time.
;
adminuser=admin
adminpassword=blah


[acl]
;
; ACL's (Access control lists) allow you
; to permit or deny access based on the
; remote users ip address
;
; There are some basic rules for using this feature
;
; 1. If you add 1 or more ACL's then a default DENY
;    rule is added at the end. This means if you
;    want to allow 1 host, the implication is that
;    ALL OTHER HOSTS should be denied.
;
; 2. You can add either specific addresses eg
;    192.168.7.45 or use the CIDR addressing
;    standard eg 192.168.7.0/24
;
; 3. You must add the permit/deny records in
;    the ORDER you wish them to be applied.





New - Wanna see something REALLY scarey? 23rd Apr 2005

Yes, it's true, your eyes are not lying to you, it's a webserver built into Asterisk.

In the Asterisk console:


And in Firefox:


Just a concept, it doesn't do a huge amount yet, who knows... :P



DANGER Will Robinson, DANGER!



New - Slight modifications to the implementation 17th Feb 2005


Cisco 7960/40's (SIP Firmware) phones register with their backup server at the same time as the primary. This makes perfect sense since you want no downtime on your phone. Other phones register on a failure. What I've added is the prefix= option in the config. This allows each server to specify it's own, unique identifier eg:

prefix=PEERA_

on server A and

prefix=PEERB_

on server B. This prevents the backup cache entry overwriting the primary cache entry. If ALL your phones operate by only registering with the backup if they can't reach the primary then you'd just make the two prefixes the same.

On the gateway server we can then find out which server(s) know where the phone is. I've also added auto-expire on the cache. When a phone registers with a SIP server it has an expiry time, I use this to tell the cache to expire the record - ie delete it. If the phone reregisters before that time, then the cache record is undated. Since the cache expiry is an offset from the current time on the cache server, when the reregistration takes place the offset is from the time the record was updated, extending the time before it's deleted.

What this means is, if either the SIP registration server or the phone dies then the cache entry will expire automatically, so the gateway can route immediately to the voicemail server, for example.

Using the following dialplan (yes it's basic, but it's an example!):

exten => _X.,1,GetUniVar(SERVERA=PEERA_200)
exten => _X.,2,GetUniVar(SERVERB=PEERB_200)

exten => _X.,3,GotoIf,"$[0${SERVERA} = 0]?6:4"
exten => _X.,4,Dial(IAX2/example:user${SERVERA}${EXTEN})
exten => _X.,5,Hangup

exten => _X.,6,GotoIf,"$[0${SERVERB} = 0]?9:7"
exten => _X.,7,Dial(IAX2/example:user${SERVERB}${EXTEN})
exten => _X.,8,Hangup

exten => _X.,9,NOOP(here we would try both servers anyway - we are desperate)
exten => _X.,10,Hangup

We can check and route the call

    -- Executing GetUniVar("SIP/201-22bc", "SERVERA=PEERA_200") in new stack
    -- Executing GetUniVar("SIP/201-22bc", "SERVERB=PEERB_200") in new stack
    -- Executing GotoIf("SIP/201-22bc", "0?6:4") in new stack
    -- Goto (sip,200,4)
    -- Executing Dial("SIP/201-22bc", "IAX2/example:user@192.168.1.203/200") in new stack
    -- Called example:user@192.168.1.203/200

Later that same day.....

Modified chan_iax2 to also report, update and remove to/from the cache. Works very well with IAXy's too :D


New - First implementation of SRI - 16th Feb 2005


Ok, so I now have this working with chan_sip when a client phone registers, unregisters or expires the cache is updated. I created a generic config that has servers in several sections, this is because you may want to use a different set of cache servers for different things. An example section is show below:

[sip]
servers=192.168.12.122:50441
identity = @192.168.12.203/

The servers= line is a space separated list of server-ip:port pointing to the cache servers, can be a list of 1 or more. eg:
servers=192.168.12.122:50411 192.168.12.123:50412 192.168.12.124:50423
The identity= entry can be used to identify the server that the client has registered to - ie this is what gets stored in the cache for each peer, in the example above I've made it part of the dial sequence, ie including the @ and trailing /. This allows me to do something like:

exten  => _X.,1,GetUniVar(SERVER=PEER_${EXTEN})
exten  => _X.,2,Dial(IAX2/username:password${SERVER}${EXTEN})

and have the call routed to the server that the client is actually registered to. You could of course make this pretty much anything and in conjunction with app_universal use them in the dialplan for more complex routing.

Also added a command to the cli interface of app_universal so that you can lookup a variable value.
CLI> univar PEER_200

Universal variable PEER_200 has a value of @192.168.1.203/


New - An implementation of shared registrations - 14th Feb 2005


One of the big problems facing implementors of asterisk and aefirion is handling registrations over multiple servers. With the poliferation of IAX phones there are some potential problems which can be overcome by using a Shared Registration Implementation (which I'll call an SRI (I just made that up) from now on) the same applies for SIP, and I dare say h323, mgcp.

By using an SRI we can allow our clients to register with our primary server during the normal course of events or an alternate, backup server, if the primary fails but sill allowing our gateways to know where to send the call. Not only this but it allows us to spread users over a number of machines, with differing primary servers. For the sake of example, say I have 200 users and I decide to split them into 2 blocks of 100. Each block will have it's own primary server and the secondary would be the other 100 block's primary.

ie:

Block 1-100: Primary server = ServerA, secondary server = ServerB
Block 101-200: Primary server = ServerB, secondary server = ServerA

I't worth pointing out that the client doesn't really need to know anything about the process, it's only requirement is to allow the configuration of a primary and a backup server.



Well, this is all very well and good, as the saying goes "You can talk the talk, but can you walk the walk" - essentially "Yeah, in theory that's fine, but can you actually do it". Seriously, I wouldn't have mentioned it if you couldn't, but the implementation itself varies. Some people would utilise a database server for storing the registrations and connected servers, what I'm proposing is the utilisation of dedicated cache servers that store everything in RAM, not in a database. I decided to use memcached for this since it's hugely flexible and the coding is trivial.

Peliminary results are encouraging, as the first stage in actually implementing and testing I've created an application (app_universal) which creates 3 dialplan commands:

SetUniVar: Set a Universal variable
GetUniVar: Get a Universal variable
DelUniVar: Delete a Universal variable

These applications allow me to set, get and, oddly enough, delete Universal variables. Ok, I can hear you saying "wtf is a 'Universal variable'?" - well you know that a Global variable (in asterisk/aefirion terms) applies on a single machine, well a Universal variable applies across multiple machines. That is to say If I set a Universal variable 'foo' to a value of 'bar' on Server A, and then perform a lookup of 'foo' on Server B; Server B will see the value 'bar'. If I then delete or change the variable on Server B, then Server A will see the new value.

See the potential?

You can download some example source here that will allow you to share variables across different asterisk machines.


As you can see below, I'm already logging registration/status information to allow the creation of the dynamic image (see next section)


New - Have I used my phone (in my test environment) recently? 12th Feb 2005





New - PeerMon concept application, this involved some right old jiggery pokery and quite a few mods to the source code






Older Stuff

New - Check who called you from your Symbian OS Mobile phone (Cell phone to our transatlantic friends). The first image shows the data retrieved from the asterisk server, clicking the list fills in the lower section of the screen with detail. Clicking on the call detail will cause screen 2 to appear. This will either immediatly dial the number or wait for you to click call, depending on how you set your preferences.

The data is stored in a local phone database and only more recent data is requested from the server.
  






Georeferencing a call - realtime

I wanted to see if I could trace the location of a call primarily to track/trace calls with spoofed callerid sp as an experiment I knocked up a small app to locate calls. This is being integrated into the application below (scroll down more)


Unfortunately since recent versions of asterisk have broken manager interfaces (similar applies to -rx commands) I'll be doing code tidying up and adding features that don't need direct output from asterisk. As you can imagine it makes the application being developed a little useless until the(se) bug(s) are fixed.

Below sample screenshots from Asterisk PBX monitor - numbers and identifying stuff removed

The first is an image of the screen showing peer states and optionally how many old and new voicemail messages there are associated with each. (broken as per bug above)



Similar screen to the one above, but showing the filter options. This has changed slightly since these screen captures you can now filter on server too (the application supports multiple asterisk servers)



This one shows current calls on the selected server - sorry that most of this is blanked out - little arrows show if a call is inbound or outboud (also broken as per bug @ top of page)




Ok, before you point out that if I have to explain what the icons do then they aren't doing their job, they've been described so that you can see some of the functions.. You'll not that some of the tab names have changed between the above versions and this on - this is the lastest ..

From this sreeen you can retrieve the configuration files from a server, and send changes ones back, restart, reload and stop asterisk. Any other commands I can find that are useful will be added too.. This uses a daemon running on the server to which requests are sent and data received...

The idea of this one is to create a tab that will allow easy editing of config files... still trying to think of the best way to do this...









Cheesy peas can't be far off!






The end.... nearly.. Mobile Customiser (DP-L10)