Professional Geekism

A short while ago I discussed the merits of Cisco’s CallManager Express 4.0 software, over their previous 3.3 release which I had been using. It really was a big improvement, but alas there was still some functionality missing that I really required (namely the ‘blf-speed-dial’ command.)

So the hunt began, and seemingly not long before we’d started looking, Cisco had released IOS version 12.4(15)T, which indeed comes with CME 4.1 bundled in the appropriate voice-related featuresets. I chose this release, as the only alternative was an earlier X release. And I’m still quite un-sure of X releases, as it happens.

Now for the severe warning:

Do NOT attempt to register an Snom 360 SIP phone to the SIP registar with this release. We’ve tested a few non-Cisco SIP phones so far, all with varying degrees of success (the Grandstream GXP2000 worked well, though it’s far from usuable*), but the Snom actually caused the router to crash and reboot each time it attempted to register.

Strange but true – a SIP phone registering caused the router (a 2811) to bomb-out and restart at least six times before I realised what was going on. I guess there’s one reason why the more experienced Cisco geeks shy well away from T-train releases…

To make matters worse, I’ve found another strange, yet seemingly harmless bug with this new image. Whenever a call is made, and it doesn’t matter where it’s orginated or destined for; as soon as the call is answered the CLID is suffixed with seemingly random crap. Due to the fact that most of it is garbage, with the rest resembling bits of caller IDs from previous calls, I’d hazard a guess that this is some sort of memory over/underflow issue (but I’m no experienced programmer, so feel free to correct me.)

I’m also not sure whether it’s the IOS release, or CME 4.1 which is causing the problem. I’ve not had the 12.4(11)XJ3 release to test it with, and I’m more-likely to push fowards instead of backwards as there’s since been a newer IOS released with CME 4.2 and I’m hoping it will solve the problem. The only problem is, it’s another X release.

What I do know though, is that changing the 7960 firmware load makes no difference what-so-ever. I’ve tested 8.0(5.0) (which happens to be the recommended version for use with CME 4.1), 8.0(6.0) and even 8.0(4.0) with no change in behaviour. The only thing I can attest to is that the Grandstream SIP phone I’m using for testing purposes doesn’t exhibit the same problem. That’s one yay for SIP, at least.

If anyone out there is experiencing the same problem, then please let me know any possible solutions that I could test!

*The Grandstream can currently dial extensions registered to both CME, and our Asterisk gateway but as for calling externally – I merely receive a 403 error. Maybe I need to keep playing with it, but I don’t think Cisco’s implementation of SIP still particularly favourable…

I’ve decided that due to the immensely impressive way in which my network setup at home has turned out, it should be forever-stripped of that horrid, derogatory phrase, ‘wireless’.

Any systems adminstrator, network engineer or even anyone with a slight technical strain in them will most-likely tell you to avoid wireless networking like the plague. If you want retain the ideal of hassle-free and reliable networking, aside from simple light-user access, it’s quite often just a big pain in the arse.

However, you may remember that I wanted to create a wireless bridge from my bedroom, to the opposite side of my flat, where I was to have another router that would be connected to the ADSL. I didn’t want to simply buy a wireless card for my PC as I’m runnning Ubuntu 99% of the time, and as good as it is, Ubuntu hasn’t been able to magically write a bunch of WNIC drivers just yet. Using a bridge also means that I can share the link with other devices (like a phone, or second PC) without having to worry about running a temporary cable or finding them a WNIC.

Well, after conducting my research into simple wired-to-wireless bridges and finding them all to be wank, I’ve ended up with a Linksys WRT54GL (flashed with the DD-WRT firmware) that performs wired-to-wireless bridging to a Netgear DB834GT access point, which is actually located on the opposite side of my flat. The ADSL connection is in-fact ADSL2+, and due to the exchange being roughly 300m of wire away – it syncs to 18.9Mbit/sec at 7dB SnR. If I log in to the Netgear router via telnet, I can tweak the SnR and get as close to the theoretical maxmium of 24Mbit/sec as 21.9Mbit/sec (SnR @ 2.3dB). In real money, this means 2.2MB/sec downloads from the right server…

There’s a little extra latency due to the wireless bridge, but in reality this is still insignificant – the bulk of the RTT to our voice router (hosted in the UK) can be attributed to the ADSL network. Though it’s only an average of 40ms in total.

So a great success if I don’t say-so myself! I don’t think I’ve been more impressed with the capabilities of a £35 router. With nothing more than a firmware update, you can transform it into a BGP/OSPF/Wireless Bridge/Client/VPN endpoint/Router/Managed Switch.. It’s endlessly impressive. And if you think about it the alternatives; it could have cost me £35 for a decent Wireless NIC – and would that WNIC have been support up to 4 devices, with next to zero configuration? I think NOT!

Yes, I’m very impressed with how my network has turned-out. Aside from a great location and a killer ADSL2+ connection, it’s working so well due to good hardware. The Netgear has impressed me somewhat – it’s solid, configurable and worth the money I paid for it. I’d definitely recommend it again, but then it’s still no 54GL – DD-WRT has made that router the star of the show… If only they supported a router with an ADSL modem!

I haven’t updated for a while, due to being really fed-up with going in circles on this new phone system, so please bare with me. What follows is some hard-learned experience (and there’s certainly more of that to come) that I’d like to share with the world, as well as document for the future of course.

You could be mistaken for thinking that when sharing DNs between two SCCP ephones with Cisco’s CallManager Express software, that once a single call to that DN is answered, any other calls to the same number would still ring on an idle phone using that DN – much like a parallel hunt-group (which, for SCCP phones, is definitely missing from CME.)

But no, this just doesn’t happen. As soon as a call to a particular DN is answered on one ephone, any other ephones sharing that DN will not receive incoming calls – the original ephone locks the DN so that it is the only recipient of further calls to that DN, that is until the DN is not in use any more and only then does the ephone release control of the extension.

You could also be mistaken for thinking that specifying ‘dual line’ on the end of a DN would solve this, but it doesn’t – the second incoming call will only display as a call waiting on the ephone currently using the DN. It’s actually quite frustrating to setup a ‘simple’ parallel ring group with the required (read: correct) functionality for our primary office extension.

So I’ve concocted a dirty little hack to deliver the required functionality, which is actually based on this config snippet, andcommented it below for the benefit of anyone else experiencing the same headache.

First, you need to setup your ephone-dns:

!
ephone-dn  1  dual-line
 number 1000
 no huntstop
 ephone-dn-template 1
!
!
ephone-dn  2  dual-line
 number 1000
 preference 1
 huntstop channel
 no huntstop
 ephone-dn-template 1
!

The are some important things to note here are; firstly these are two separate DNs, but they are both set to ring with the same extension.

The ‘preference 1′ value in ephone-dn 2 forces the preference of that DN to a value lower than ephone-dn 1 (which has the default preference of 0 – lower value = higher preference) – this makes sure that hunting for number 1000 will always look towards ephone-dn 1 first.

The ‘huntstop channel’ command on ephone-dn 1 stops CME from placing a call in waiting to the first extension, when it’s already in use. If this isn’t configured, CME will see that there is a free line on the DN and simply queue up the call there, instead of pushing it to the next-preferred DN. You could just not use dual-line DNs to save yourself the trouble, but I didn’t want to limit our functionality in any way and has proven to be just as good.

Note that I have omitted ‘huntstop channel’ on our second DN, as it is unlikely that we will receive three consecutive incoming calls, but in that possible scenario, it is acceptable for the call to queue up as a call-waiting on the second DN. This is purely to avoid giving any of our customers busy signals! Of course, you should have configured ‘call-forward noan’ on these DNs so that un-answered calls are forwarded to voicemail.

Finally, the ‘no huntstop’ command prevents CME’s extension hunt from halting at the first DN, should the DN be busy with another call. If this is not configured, CME will examine the first DN, see that it is busy, and simply send a busy tone back to the caller – not at all useful. Using no huntstop will mean that if the preferred DN is busy, other DNs with the same extension will also be considered during the hunt.

When setting up your ephone configuration, the choice is yours. However, since all our staff are using Cisco 7960 phones, and have a number of blf-speed-dial lines as well as requiring the use of a DDI extension and 2 or more shared extensions – overlay buttons were chosen for efficiency.

!
ephone  1
 device-security-mode none
 description Tom's Phone
 mac-address 0123.4567.89AB
 ephone-template 1
 blf-speed-dial 2 1002 label "Extension 1002"
 blf-speed-dial 3 1003 label "Extension 1003"
 blf-speed-dial 4 1004 label "Extension 1004"
 blf-speed-dial 5 1005 label "Extension 1005"
 type 7960
 button  1o1001,1,2
!

So in this example, we have an ‘o’ type button defined, with 1001 (a DDI extension) as the primary line and our ring group extensions hiding behind it. If you were to press the corresponding button for this line, on your phone, CME would pick the first available line that isn’t in use (which should be your primary DDI extension… Unless you let someone share it! )

Note: ‘Busy Line Field’ speed dials aren’t available on anything prior to CME 4.1, but they sure are bloody useful.

Anyway, hopefully that’s helpful – I’d be very happy to know if it’s helped, so all comments are welcome!

Well, thanks to Ben for pointing out that the University grades are now available from the awful ‘Myportal’ web page – a labyrinth of dreadfully-designed hyperlinks. The long and short of it is though; I now have the results from my 2nd year modules!

They’re listed below, highest first (all grades are out of a maximum of 15!):

• Advanced Routing: 15
• Remote Access Networks: 15
• LAN Switching & WAN Networks: 15
• Introduction to IP Telephony: 14
• Management in Organisations: 12
• Fundamentals of Network Security: 10
• Communications: 10
• Organisational Systems for Engineers: 8

To put the numbers into perspective; 13-15 is a 1st, 10-12 is a 2:1, 7-9 is a 2:2, and 4-6 is a 3rd.

So for my second year, which contributes to 25% of my over-all degree mark, my mean average grade is currently 12.375 – a high 2:1. It can be said that it might’ve been a nice even 1st if it wasn’t for that 2:2 in Organisational Systems, but you could also say that I should’ve done better in Network Security (I really should – I definitely didn’t revise enough for that exam )

But, it’s a nice starting point for my third (and final) year. Come September ’08, if I put in as the required amount of work, I might just get that 1st class honours degree. Can only hope eh?