Posts Tagged phone

Upgrading from Cisco

In case you weren’t aware, I am a VoIP nutcase.  I have an Asterisk phone system at home, and all the phones in the house are VoIP of some description (either real VoIP devices or analogue handsets through an ATA).  While I haven’t converted to VoIP as a replacement for PSTN, I have some connectivity to VoIP providers both here and overseas (and soon to be more, to help the phone-home situation while I’m overseas).

I’ve been a user of Cisco IP phones, buying 7960s and a couple of 7970s through a well-known internet site (maybe it starts with an “e”, not sure).  The phones have been excellent, and I’ve even written a few XML apps to supplement their use here.  The 7960s are getting a bit dated now, however, and I found myself contemplating buying 7971s (or even something newer, like the 7965 or 7975).  Before I committed myself further into the relationship with Cisco, though, I thought about what I was really getting out of using Cisco phones.

Like many users of second-hand Cisco gear, I only purchased the hardware.  I do occasionally succumb to a nagging feeling of being an “outlaw” (at least in the eyes of Cisco), but admittedly that feeling usually only comes when I find out that Cisco has released another new version of SIP software that I can’t get because I haven’t paid for SmartNet.  The last time I had this thought though, I had a realisation: even if I did pay for SmartNet, the only thing I’d get would be the firmware: Cisco will only support their phone software when connected to their CallManager server (yes, even the SIP firmware).  Anyone running Cisco phones against anything other than CUCM gets no support from Cisco in the event something doesn’t work–and based on the information floating around, the problems are many.

So basically I would be paying Cisco to allow me to run one of the worst SIP implementations in embedded existence, with no opportunity to report problems with it in my environment.  Hmm, let me think about that for a minute…

At around the same time, I happened across the NerdVittles site, and in particular the post where NerdUno nominated the Aastra 57i as the “World’s Best Asterisk Phone“.  I started to do some research into it, and was astounded at the level of support the manufacturer (a Canadian company which a few years ago acquired the telephony business of a little mob called Nortel) and the community provide for this phone and Asterisk.  Looking through the phone manual, I found functions that only work with Asterisk! I found a full set of integration scripts that provide XML applications, right through to automatic provisioning tools.  Possibly the best thing was that on the product page for their phones — right there on the page that descibes the product — are links to current versions of firmware, documentation, XML application development guides, even a Linux-based application to encrypt the phone configuration files.  Not hidden in some obscure hard-to-find portal, or behind a registration-only support site.

I started to think of the possibilities…  I’d be able to freely modify the phone configuration (even via a HTTP interface if I so chose), without having to make trial-and-error changes to a cryptic and totally undocumented configuration file.  I’d be able to write XML apps without having to do laborious debugging to cater for why the parser was choking on XML that was perfectly okay according to the documentation but apparently tripped over an undocumented field length restriction or character encoding limitation.  I could get access to things like Visual Voicemail, BLF, integration with Asterisk functions like day/night mode and call parking.  I could keep the phones up-to-date for new functions and bug fixes.  With a click of a mouse I could get proper Australian tones!

So, I decided to give one a try.  Finding nothing on that “e” site I went looking for a vendor locally, and found several places that would sell one to me (legitimate e-tailers, no less!  Zounds!  A VoIP phone with a warranty?  You jest!).  It took a while for my chosen vendor to source it for me, but I’ve had it now for a couple of weeks.  It’s probably going to take a while for it to live up to it’s full potential in my installation, but since that potential is so much greater than what I have been able to do with the Ciscos I think I’m already ahead.

More in the coming weeks as the Aastra settles in.

Tags: , , , , ,

Asterisk chan_mobile fail

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: , , ,

Nokia SIP client: WTF?

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: , , ,

FreePBX device-and-user mode, part two

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

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 gadget: Nokia E71

I have been in the mobile phone market on-and-off for nearly 12 months. There wasn’t really anything wrong with the N70, I guess I was just getting a little fidgety with lots of new “shiny” going around. The trip to the US in May, and seeing an iPhone in person for the first time, probably didn’t help, nor (obviously) did the local release of iPhone 3G. Once I’d talked myself out of getting an iPhone though, the itch was still there… and I must say it’s being well-and-truly scratched by the E71.

I’ve had this phone for just on a week now, and it’s certainly one of the best phone purchases I’ve ever made. In a nutshell, the key things about it are:

* QWERTY keyboard, in a form factor not much larger than the N70. Importantly, it’s much smaller than the E61 that preceded it (now there’s a phone that was just MADE of ugly). Despite it’s size the keyboard is amazingly easy to type on, although I may have to update this after I give my thumbnails a trim.

* Symbian OS. Maybe I’m biased, as the owner of a Psion 5, but to me Symbian has an edge over other phone OSes. Not only with the functions in the handset and Nokia’s Series 60 interface, but the range of third-party apps for Symbian (or Series 60 specifically) is great. Almost straight after charging the battery I downloaded PuTTY (SSH client) and “vejotp” (S/Key one-time-password utility). Plus, the recent news that Nokia intends to open-source Symbian is a great thing.

* Nokia Maps and A-GPS. While the iPhone glitterati download the entire UBD or Melways every time they walk down the street thanks to Google Maps, I get quick GPS mapping for zero download (the last few times I’ve used it, the download counter has stayed stuck on “0.0kb” even though A-GPS is supposed to cost a bit of data every startup). It’s not the most accurate GPS ever made, for sure, but it’ll do me for now at least.

* Built-in podcast support. I was getting more and more frustrated with the way that Amarok and iPod fought with each other over my podcasts. It never seemed to work as well as it did on iTunes! Now, I can use the device I download the podcasts with to listen to them as well. It’s self-contained, tidy (no more podcasts mixed in with the music library and causing havoc), elegant.

* Wi-fi capability and SIP client. Being able to connect to the home network obviously means that I can do things like update my podcasts without having to second-mortgage the house to pay for HSDPA data. The SIP client is very cool too: I’ve connected it to my Asterisk box, and now have a cordless home phone and mobile in one device.

* Solid construction. It’s got to be the most sturdy-feeling phone I’ve ever owned. The case is metal, and it has a nice weight to it. The buttons feel solid, almost like real keyboard keys.

* Drop-dead gorgeous. I got the grey version, the metal casing looks like titanium and has a glossy finish (which is a little prone to fingerprints, but cleans easily). The screen is just amazing, usable in daylight, bright and colourful and incredibly high resolution.

I’ll mention more as time goes on, but for now I am very happy!

Tags: , ,