Crossed Wires

Vic’s Blog

Archive for July, 2009

Asterisk chan_mobile fail

Jul 23

Posted by Vic in Linux, Telephony | 3 Comments

I’ve been struggling with setting up chan_mobile on my Asterisk system.  For those fortunate enough to actually get it working, chan_mobile provides an interface for Asterisk to treat a mobile phone like a PSTN or VoIP trunk–when someone calls your mobile phone it can ring your desk phone or softphone, or you can use your normal handset to make an outgoing call on your mobile.  It works by making the Asterisk system look like a Bluetooth headset or handsfree to the phone.  You can even connect Bluetooth headsets to Asterisk using chan_mobile and have them appear like an extension in your dialplan (although that capability doesn’t seem to be covered very much).

I figured this would be an ideal way to make use of an old Nokia 6230 with a broken speaker.  Somewhat foolishly, on the assumption that it would Just Work (and that all the troubles experienced by others would not beset me) I went and bought a two-pack of prepaid mobile SIM cards and went through the adventure of activating them.  One of these SIMs I threw into the 6230, the other I kept on hand for after I got everything working.  The plan, you see, was to be able to take advantage of free calls between the two accounts by taking one of the phones with me when travelling and leaving the other strapped to Asterisk at home.

I think it’s probably fair to say that I’ve had more success with it than a lot of other folk have.  The process of configuring Asterisk to use the Bluetooth dongle is quite straightforward, and it’s even quite easy to configure the chan_mobile driver to have calls enter your Asterisk system in a routable way.  When I dialled the “tethered” mobile from another phone, I was rewarded with the ringing of my desk phone–and at this point, I think I gave myself the kiss-of-death.  “Wow, that was easy,” I thought…

When I picked up the desk phone, I was rewarded with silence.  Not just the silence of the phone not ringing any more, but also the silence of no audio being passed either way over the call path.  Nothing put the pure, desolate sound of FAIL.

Things actually went downhill from there, believe it or not.  I have tried a total of four different Bluetooth dongles, with results ranging from the aforementioned signalling-but-no-audio to why-the-@#%$-won’t-this-thing-pair.  The three different phones I’ve tried elicited a similar spectrum of results.  “Make sure your dongle has a Cambridge Silicon radio, they definitely work” say the forum experts…  Sorry guys, one of the biggest failures I had–failure of Asterisk to pick up the call–was on the last dongle I tried and, yes, it was a CSR.  I’ve even had two different versions of the bluez stack and (I think) two different asterisk-addons versions.

The one thing that I’ve distilled from all the experiences I read through is that there is a ridiculously high level of sensitivity to particular phone and dongle features.  For example, great success has been reported with the Nokia 6230i.  I figured that I was lucky and that a 6230 would be close enough…  Doesn’t look like it.  There is one model of D-Link Bluetooth device–no longer in production, by the way–generally reported to give the most success.  Tweaking the device class reported by the bluez stack in the Linux host is said to give success too, but led to me being unable to get a connection to Asterisk.  Unfortunately, I have neither the time nor the patience to spend too much time trying to go through the motions of getting it working.  I tell you, if it really is that difficult to get two Bluetooth devices to talk to each other it’s no wonder that the majority of folks still use wired headsets!

Luckily all this little experiment has cost me so far is time.  The two-pack of SIM cards cost me the grand total of $2, and they had enough start-up credit on them to allow me to receive calls without a top-up.  The handsets are from that ever-growing pile of GSM hardware that just about every modern household is accumulating now (well, at least the ones that house a gadget-freak who can’t even bear to part with a broken one).  The kernel version I’m running on the system could be an issue, since I get ugly error messages from the btusb module when I take a call, so a kernel update might help.  After that though it’s likely to cost real money–buying a new/different Bluetooth dongle, for example.

If anyone out there has suggestions on something else to try, I’m listening (reading? watching?).  I don’t mean to complain, after all I am one that usually subscribes to the “it’s Open Source, it’s the hard work and dedication of others, you got it for nothing, you’ve got no right to complain” philosophy.  It is really frustrating to come away from a couple of days’ effort with nothing to show for it, though.

Tags: , , ,

LDAP-backed DNS and DHCP…?

Jul 22

Posted by Vic in Linux, Networks | 7 Comments

I’m having a bit of an infrastructure redesign here at the Crossed Wires campus.  Each time I have an outage (the last one was caused by a power failure) I learn a little more about the holes in my current setup and what I can do better.

I’m implementing a router box on an old low(-ish)-power PC that will be backed up by a virtual machine on my main virt-box.  I’ve already done most of the preparation of using keepalived to implement VRRP, and a colleague has given me some pointers in using the Linux-HA tools like Heartbeat and DRBD to make services like e-mail and Samba redundant.

I’ve had a soft spot for LDAP for ages; I’ve always thought that putting as much backend data into LDAP as you can would be a really good way to get failover and redundancy.  Instead of having to deal with every single server’s different way of doing replication and failover, just bung everything into LDAP and get that replicating.  Sounds good in theory, but in a nutshell it’s not working out that way for the two least-celebrated but most important components of my (arguably any) network: DNS and DHCP.

There are a number of LDAP-backed DNS projects out there.  If I’m willing to go to the bleeding edge with BIND on my Gentoo build I can get access to the two most talked-about ones (bind9-sdb-ldap and the BIND DLZ LDAP driver), and other solutions like PowerDNS and ldapdns are available.  But none of them offer integration with DHCP, and I’m currently using dhcpd’s “interim DDNS update method” to make sure that hostnames are seen in my DNS when a lease is granted (okay, there’s a Perl daemon that goes with bind9-sdb-ldap, but it seems like a sort-of clunky afterthought).

Speaking of DHCP, LDAP backends for it are virtually non-existent.  The only LDAP-enablement I’ve found for ISC DHCP involves putting the config file into LDAP, not the leases…  I actually used that for a few days a while ago and pulled it out because it was actually more work to do it that way (and for no benefit in failover).

It seems to me it would be a project ripe for the picking: take an integrated DNS/DHCP server like dnsmasq and make it write into LDAP instead of to a file.  If I had more free time I’d probably have a go at it, except for the fact that no-one really seems to be that interested in storing DNS and DHCP in LDAP: that it hasn’t been done says to me that there’s no demand for it, and it’d end up being a big waste of time and effort.

Over to you, lazyweb…  Is this a yawning chasm of unfulfilled networking dreams, or a case of me trying to make something more complex than it needs to be?  After all, the rest of the world gets by with DNS master-slave and DHCP failover, they should be good enough for me too, right?  ;-)

Tags: , , , ,

Nokia SIP client: WTF?

Jul 17

Posted by Vic in Soapbox, Telephony | 6 Comments

I was having a browse around the excellent Nerd Vittles site tonight, and stumbled onto a disturbing conversation about the removal of the Nokia SIP client from S60 Third Edition Feature Pack 2 (as used on recent phones like the N78 and N96).

Nerd Vittles linked to this blog, which alludes to the possibility of mobile carriers putting pressure on Nokia to remove “free” calling capability (i.e. VoIP) from their phones.  Within the comments on that blog post comes a link to a post on Nokia Conversations (I’ve never seen that site before, but it seems to simply be a bit of a PR site…).

“Charlie” from Nokia Conversations tries to spin the changes to Nokia’s SIP support.  Firstly, in what seems to be almost believable at first he says “no, the SIP stack is still there, in fact it is actually better in FP2 than previous versions”.  Apparently, the improvements meant that the integrated VoIP client had to be dropped because it wasn’t ready.  This explanation loses credibility, however, when you see that Charlie’s blog post was made on 27 August 2008: nearly one year ago! And folks are still commenting on that thread, saying “where’s my VoIP client?”.  I cannot believe that it would take Nokia a full year to update the VoIP client and package a firmware update for these phones–especially given that two other S60 3rd-ed FP2 phones released after the N78 and N96, namely the N79 and N85, apparently do have the VoIP client!

On 8 December 2008, Charlie posts a follow-up on Nokia Conversations.  In it he says “well we made some folks unhappy, but we’ve made a fix”.  He points to something called the “SIP VoIP Settings” application that was supposed to bring back what people were asking for.  Problem is, it’s not a VoIP client at all: it’s simply a configuration tool allowing more detailed control over the configuration of a SIP profile.

In the final insult it appears that the new N97, Nokia’s current flagship also has no VoIP client.  The N97 is based on S60 5th edition and not 3rd edition, but 5th is supposedly just 3rd updated for touch-screen anyway (not a significant change in technology).

Looking more closely at the specifications pages for these N-series phones, the tiny-tiny text that says “VoIP” is missing.  It’s probably arguable therefore that Nokia never advertised the phones as having VoIP capability[1], so anyone who bought one without checking has created their own situation.  However, Nokia, why is the “upgrade” to the N95 missing one of that phone’s most popular features?

At one point Nokia’s story changes… it seems that VoIP is a function that doesn’t fit the product direction of N-series and belongs in the E-series phones (indeed both the E75 and the soon-to-be-released E72, reportedly S60 3rd-ed FP2 phones, list VoIP capability).  Why, then, do other S60 3rd-ed FP2 phones like the N79 and N85 have VoIP?

This whole “affair” seems to have been handled really poorly by Nokia.  Firstly, claim a technical limitation.  When that fails (because you discover that your users actually know something about tech), claim that your third-party providers have developed a solution.  When it turns out that the third-party products are steamers that don’t even use the infrastructure your OS provides (something you didn’t know before either), claim that the product has been “realigned” and doesn’t service that market any more–while simultaneously marketing a product in the same series with the same technology that still has the disputed feature.

I must admit to being a lot less angry about this after researching this post than when I started it.  I’m more angry about the survey I completed earlier today when I visited the Nokia website–I was very complimentary about .  My shopping-slash-wish list just lost an item–not that I was seriously contemplating buying the N97, but it’s nice to have a technical reason not to buy it rather than the boring can’t-really-justify-it line. :)

[1] Of course it’s easy to make this statement based on what the product pages look like now…

Tags: , , ,

Is it catching on…?

Jul 14

Posted by Vic in Uncategorized | No Comments

Mark isgetting an internal server error on http://tinyurl.com/n5fgd9.  I think I amgetting an internal server error too.

Unless, of course, I don’t get it.

(The first result got fixed, this version (courtesy Google’s cache) has the goodness.)

Lifeblog test post (photo fun with Nicholas)

Jul 13

Posted by Vic in Life | No Comments

A spooky pic of Nicholas playing with an LED toy.

Tue 23/06/2009 08:39 23062009081

FreePBX device-and-user mode, part two

Jul 12

Posted by Vic in Telephony | 1 Comment

In part one, I described how I reconsidered device-and-user mode in FreePBX, and did the initial changeover.  Read on to find out how I overcame a major issue with the configuration!

I have an ISDN phone line coming into my Asterisk system.  One of the indials is for our home number, the other is one I use for work.  Before I found FreePBX, I had manually worked the Asterisk dialplan to have calls made from my work phone(s) appear from the work phone number–useful not just for Caller-ID, but also required for the long-distance provider I use to bill calls for work.  With FreePBX I was able to use a custom context to pre-select a route that dialled the provider override prefix to send the calls through the other provider, but it was a bit of a hack using hand-written dialplan code and a bit of luck.

Before I changed to device-and-user, I naively assumed that FreePBX would allow a user to be associated with a context in the same way a device/extension can be.  This is not the case, and the context of the device is still used for routing.  This meant that I could not use a device for either work or personal calls without having to log onto FreePBX and change the device context (logging on as the work user was not enough).  I was back to square one…

I did a little research.  Firstly, I rediscovered how I was making the existing routing work.  The ISDN interface I use (driven by chan_capi in Asterisk) simply uses the outgoing caller-id of the call to select from available MSNs[1].  So I had one route that had the “normal” MSN set as the outbound caller-id, another route with the “work” MSN (plus the rewrites to add the long-distance override code at the front), and a custom context for the work devices that made only the route with the work MSN available.

Looking more closely at the user definition page, I saw that there is an “Outgoing Caller-ID” field.  By using this field, I was able to do away with the separate route and the custom context and set the work MSN there instead.  This gives me just what I need: a way to control my outbound MSN on a per-user basis!  This got me half-way there, as I still needed a way to set the long-distance override codes for work calls.  A bit more research turned up a predialling macro hook that the FreePBX folks made available.  With a bit of code to test the caller-id and the number dialled (the long distance company doesn’t handle free calls, for instance) I get just what I need.

Here’s the macro hook (this is added to extensions_custom.conf):

[macro-dialout-trunk-predial-hook]
exten => s,1,NoOp(Trunk is ${OUT_${DIAL_TRUNK}}, CallerID ${CALLERID(num)} calling ${OUTNUM} )
exten => s,n,GotoIf($["${CALLERID(num)}" != "xxxxxxxxx"]?endit)
exten => s,n,GotoIf($["${OUT_${DIAL_TRUNK}:4:11}" != "CAPI/contr1"]?endit)
exten => s,n,GotoIf($["${OUTNUM}:0:4}" = "1800"]?endit)
exten => s,n,Set(OUTNUM=1xxx${OUTNUM})
exten => s,n(endit),MacroExit()

So I’m now a happy device-and-user user!

[1] Actually I don’t know if that’s chan_capi doing it for me or whether it’s just the way the ISDN network works.

Tags: , , , ,

Revisiting device-and-user mode in FreePBX

Jul 12

Posted by Vic in Telephony | No Comments

Buoyed by the success of a colleague I introduced to Asterisk and FreePBX a little while ago, I decided to have another look at the extension configuration mode I use on our system.

Check this post for a recap of the FreePBX configuration modes and my first thoughts.

Last time I looked at this I thought there were some problems with the way it was implemented that meant it didn’t work for my installation, so I ended up hacking together a mess of fake extensions, ring groups and queues that more-or-less reimplemented the good parts of device-and-user mode and still letting me use things from extensions mode.  Doing this however meant that FreePBX always complained about what it called “invalid destinations”, and I had to use some custom logic for doing something simple like a common voicemail access number.

What won me over to device-and-user mode again though was the ability to log a device on and off from a number.  I have a couple of Nokia handsets that have SIP clients now, and it’s handy to just have one device that all my work calls (for example) arrive on.  After-hours though, I didn’t want that device to still be tied up to the work line; it made more sense to be able to use that device for home calls.  To do that with extensions mode and my ring-group hack would mean reprogramming the ring-group (and one other change, which I’ll talk about later) when I wanted to switch over.  Presumably I could write some script or AGI logic that I could tie to a feature code in FreePBX, but I’d simply be making more custom modifications for little real gain.

In the end, I realised that the main thing keeping me in extensions mode–the ability to call a device by it’s “extension” number regardless of who’s logged on to it–wasn’t something I used often enough to warrant all the work I’d have to do to make extensions mode do what I needed.  With that in mind, I edited amportal.conf and made the all-important change:

AMPEXTENSIONS=deviceanduser

I had to reload the FreePBX admin page a couple of times, but eventually the “Extensions” tab changed into two tabs, “Devices” and “Users”.  True to the description of extension and device-and-user modes given in the FreePBX doco, the Devices and Users tabs had the same number of entries.  All I needed to do was delete the users that were no longer required (i.e. almost all of them) and the devices that belonged to the voicemail extensions from my original setup.  I then ran through each of the device definitions and correctly assigned them as either “Fixed” (statically allocated to a user) or “Ad-Hoc” (able to be logged on to a user).

This was the point at which I worked out a solution to my original dial-a-device-directly problem.  I realised that the majority of times I need that functionality is when testing.  So, for those devices that I use for testing, I left the user definition in place and made it the “default” user for that device.  This means that when I log out of the real user from that device it is reachable by the default user number, and I can dial it directly for testing.  The other use for direct-connection to a device, the intercom, requires a separate SIP endpoint anyway (due to the Cisco phones not adhering to the SIP command for remote off-hook) so I need to keep those as separate users too.

I’m quite happy with how it’s turned out–at least, I was once I’d overcome the showstopper I found!  Read about that in part two.

Tags: , , , , ,

New blog engine

Jul 9

Posted by Vic in Life | 2 Comments

Here is the new and improved (well time will tell about that, I suppose) Crossed Wires.  Changing to a more mainstream blog engine will I hope allow me to provide a bit more function.  I’ve adopted the Disqus comment system as the first improvement; I was unhappy about turning off comments on the old system.

I imported all the entries from the old engine (I’m even gradually working through them to categorise and tag them).  I even found some Perl and SQL mojo I never knew I had to make nice redirections from the old blog to the new.

As I said when I first started this blog, none of this coolness is likely to make me write more…  But here’s hoping!  :)