Adding a pause when dialling a number from a softphone or mobile phone

Back in the days when Nokia phones had monochrome screens and batteries lasted for days, a colleague explained to me how to include a p in a number to make the phone pause before dialling the next few digits – for example when entering a PIN for voicemail (I think w also worked for a wait). More recently, another colleague was asking me how to do this with our CUCILync softphones when dialling into a conference call (as described for Microsoft Lync).

Well, it seems the modern equivalent of a p for a soft pause is inserting a comma (at least it is on a Lumiaon an iPhone and on Android) and a semi-colon is a hard pause/wait (on an iPhone). Unfortunately the CUCILync client we use strips out , and ; (and, even worse, it replaces p with 7). I guess it could be an error in the dial-plan but it’s inconvenient…

The conference call productivity drain…

The following script is based on a real conference call. The names and times have been changed to protect the not-so-innocent but, other than that, it’s pretty accurate:

9:45 (15 minutes before the meeting): Reminder pops up, “snooze” it until 5 minutes before.

9:55: I’ll just finish writing this email… I wonder, was there any preparation required for this meeting? I haven’t done any but no-one else will have either…

9:59: Ah yes, that meeting – how long?! An  hour and a half! Dial the conference service. What was the meeting passcode again? Got it, I’m in. Ah, hold music.

10:00 (advertised meeting start time): “The chairperson has not arrived. Please wait…” more hold music.

Just after 10:00: Call is opened, just two people so far. Social chat about what’s going on.

10:01: Someone else joins the call. Say hello, bring them into the chat. More banter.

10:02: Two more attendees join. Roll call. Explain that we’re waiting for a few more.

10:03: More attendees. Almost quorate now. Roll call, just waiting for Michael and Stuart. Michael did say he would join but, in the interests of time, start the meeting.

10:05: Michael joins the call. Apologies for lateness. Quick roll call and bring up to speed on introduction. Start meeting properly.

10:07: Stuart joins the call. He’s in the same building as the meeting organiser and wants to join in person. He’s told the room number and drops off the call.

(call continues for another hour or so…)

This is “normal”?! Several middle-managers, not exactly inexpensive resources, waste time waiting for others to get themselves organised. A few minutes, multiplied by several attendees soon becomes an hour of lost productivity for the company.  I’ve even seen this on calls with hundreds of people (literally) waiting.

I admit, sometimes meetings over-run for good reasons. Only last week I had to delay a meeting and missed another two calls completely because an important issue arose which needed immediate resolution (a personnel issue – and people trump process in my mental rule-book) so I allowed a meeting to over-run. I tried to keep others informed though, rather than leaving them hanging on a conference call waiting for me to arrive.

But, in our organisation, people accept the sort of practice I’ve laid out above as normal (or at least, they tolerate it) and I’ve coined a term to describe the company timezone (which is 3 minutes after the real time).

The thing is, we’re not alone. That’s why I feel comfortable talking about this issue on a public forum – it happens in organisations all over the country – indeed, all over the world, all of the time.

Yesterday, Matt Ballantine published a blog post entitled “clock watching”, in which he suggests it’s not collaboration tools we need, it’s somebody asking “why are we meeting?”. Quoting from Matt’s post:

“Imagine if the workflow for setting up a meeting, rather than being ‘find a slot available for the attendees, book the meeting’, was more like:

– state the objectives and outcomes required for the meeting
– understand who might be active participants
– describe who should be informed, yet not necessarily attend
– validate that this will require a meeting to achieve the necessary outcomes
– plan out the activities for the session
– validate again that a meeting is the best route for the outcomes to be achieved
– work out the correct time for the meeting
– find an appropriate time slot for the meeting
– send out participant briefing notes to everyone concerned”

For a while now, I’ve been asking “Do you need me on this call? I’m not sure what value I’ll be adding”. In future I’ll be more strict. And I’ll be starting the meetings that I control right on time, rather than when we have most people on the call. If people realise that they miss things by turning up late, maybe they will be more punctual? Or maybe I just need to chill out?

Searching Active Directory with PowerShell and a user’s phone number

I have a guilty secret: I screen my incoming phone calls. I no longer answer blocked numbers on my work phone – it’s always PPI spam – and I recognise the numbers of those I work closely with, so I can prioritise my response (i.e. do I want to be interrupted by that person, or can I respond to voicemail later?). To be honest, it’s just the same with email – some people will get an immediate response, others will need more thought and I’ll respond when I have more time (or not, in some cases). Is it unprofessional? I don’t think so – it’s about time management.

Recently, I had a missed call on my mobile from a number I didn’t recognise. I could see it was internal (all of our mobile phones have the same first few digits) so I thought I’d search the Global Address List in Outlook. Unfortunately though, Outlook doesn’t let me search the GAL on phone numbers…

I could have just called them back (actually, I did!) but the geek in me had the bit between the teeth… could I script up some kind of reverse lookup for phone numbers? And, in true Barack Obama (or Bob the Builder if you’re on this side of the Atlantic) style, the answer turns out to be:

“Yes, we can!”

So, if you use a Windows PC and you like scripting, read on. If you don’t, probably best just call the number back and see who answers!

Getting ready to query Active Directory with PowerShell

The first hurdle was that, in order to query Active Directory from PowerShell, I needed to have the Remote Server Administration Tools (RSAT) component installed on my Windows 7 workstation in order to do this, but it’s actually a two-step installation process.

  1. Firstly, download and install the RSATs to the workstation.
  2. In Control Panel, Programs, Programs and Features, Turn Windows features on or off, make sure that the Active Directory Module for Windows PowerShell is available under Role Administration Tools, AD DS and AD LDS Tools.

Once the RSATs were installed and the Active Directory Module for Windows PowerShell was enabled, I could fire up Windows PowerShell and issue the command to load the Active Directory management cmdlets:

Import-Module ActiveDirectory

Finding the available attributes to search against

Next up, I needed to know which properties are available for an Active Directory User object. I used my own email address as a filter to Get-User, which retrieved the details for the given AD User object, then selected all properties and piped the resulting output into Get-Member (which gets the properties and methods of objects):

Get-ADUser -Filter {EmailAddress -like "user@domain.com"} -Properties * |
Get-Member -MemberType property

Building up confidence, I started to play around and query individual attributes for the selected object:

$user = Get-ADUser -Filter {EmailAddress -like "user@domain.com"} -Properties *
$user.Title
$user.OfficePhone
$user.SAMAccountName

I found that each of these returned the information I would expect for my own user account in Active Directory.

Constructing the query

The next step was to search the whole directory but this time to filter the properties returned and to pipe through Where-Object to match certain criteria, then pipe the resulting output from that query into a table:

Get-AdUser -Filter * -Properties OfficePhone |
Where-Object {$_.UserPrincipalName -match "Wilson"} |
Format-Table OfficePhone,UserPrincipalName

This returns the office phone number for everyone whose user name contains the string Wilson.  That tested the principle but was not the query I was trying to create, so I edited the query to match a number against a number of phone number properties (making sure that all the properties that need to be displayed are in the filter) and also prompted for the search string, storing it in a variable:

$Search = Read-Host 'What number would you like to search for?'
Get-AdUser -Filter * -Properties OfficePhone,MobilePhone,TelephoneNumber |
Where-Object {$_.OfficePhone -match $Search -or $_.MobilePhone -match
$Search -or $_.TelephoneNumber -match $Search} |
Format-Table GivenName,Surname,OfficePhone,MobilePhone,TelephoneNumber

This time, the resulting output was exactly what I was after – a single entry matching the partial phone number I’d asked it to match (824753 in the example below):

GivenName  Surname  OfficePhone  MobilePhone    TelephoneNumber
---------  -------  -----------  -----------    ---------------
Mark       Wilson   73824753     +447xxx824753  73824753

Finally, I wrapped the whole thing up in a script and, as long as I’ve done the usual Set-ExecutionPolicy remotesigned stuff, I can perform reverse lookups on phone numbers to my heart’s content… now, if only I could have an iPhone app to do this for me when the calls come in…

Sometimes, simplicity is the best answer

I have an iPhone that I use for work, but I also have a separate SIM with my personal (private) number – the one I give to friends and family (and the one you’ll catch me on at the weekend). For a while now I’ve been using that in an old Nokia 6730 that used to be my work handset but I hate that phone. It’s got some awful, unintuitive Symbian interface and I spend a lot of time swearing at it.

I’ve been looking for a new handset for my personal SIM – nothing flash, just a simple phone, with Bluetooth (to connect to the car) and I thought I could get something inexpensive on a pay-as-you-go deal until I realised that the PAYG handsets are all locked to their networks. Then I found an old Nokia 6021 in my office (actually, I have two – the kids play with one of them…) – it’s got all the functionality I want, a classic, simple Nokia interface (the sort that works really well) – and the battery life is OK too (even though my handset is now 6 years old). The trouble was, it looked a bit tatty.

No worries, I spent £2.79 on eBay, and a couple of days later a new faceplate arrived. Now I have a smart “new” featurephone that suits my needs perfectly.

Configuring a Cisco IP phone for VoIP using SIP – revisited

Cisco logoA couple of years ago, I blogged about getting my Cisco 7940G IP Phone working with SIP firmware and an external VoIP provider (in my case, it was Sipgate).  I also wanted to get a couple more Cisco IP Phones working – the Cisco IP Communicator softphone and a 7911G for my wife’s business but, unlike the 7940 and 7960, these phones use a different configuration file format – an XML file that I’d never managed to get working properly.

Now, with the help of Garry Martin, I’ve got the 7911G working.  Hopefully the IP Communicator will follow soon but, for now, this post describes the steps I needed to take.

Installing the SIP firmware

Just as with the 7940, I needed to load the firmware using a TFTP server – in my case it was a simple case of adding a few extra files to the existing server – I used v8.5.4 of Cisco’s SIP firmware for the 7911 and, once the phone located the server and found the term11.default.loads file, it pulled down the remaining firmware images and updated itself.

Next up, I created two configuration files: XMLDefault.cnf.xml (note the case); and SEPmacaddress.cnf.xml.  Just as for the 7940’s SIPDefault.cnf and SIPmacaddress.cnf, these configuration files provide default and device-specific settings respectively.

The TFTP logs show the phone attempting to load some other files too (CTLSEPmacaddress.tlv, English_United_Kingdom\tc-sip.jar and English_United_Kingdom\g3-tones.xml) but the fact they don’t exist doesn’t seem to matter.

The last file that the phone downloads is dialplan.xml.

SIP Providers

I mentioned that, with my 7940G, I connect directly to Sipgate and I initially tried to do the same thing with the 7911G but it doesn’t work.  This is where Garry helped me out – he’s already been through this with a 7965G – and he found that the newer Cisco IP phones will attempt to register using a high port number but expect a response on the configured VoIP Control Port. To make this work, they append the rport parameter on the VIA headers in SIP registration.  This is RFC compliant but doesn’t take into account the symmetric network address translation (NAT) workarounds that some providers have in place to maximise device support.

In Garry’s testing with a few different providers, he found the SIP Proxy Voxalot had a Web UI option for Symmetric NAT enable/disable that allowed his 7965G to succesfully register, and both SIP Providers VoIPtalk and Orbtalk worked without modification. However Sipgate (like me, his main SIP provider) failed consistently.

The workaround we used was to use another SIP Proxy (Sipsorcery) to act as a broker between SIP providers (although, in my case I only use one provider). Working with Aaron (Sipsorcery creator and admin), two changes were put in place. The first was for Aaron to remove the troublesome rport parameter in the top VIA header for phones registering against Sipsorcery with a specific UserAgent. In Garry’s case the UserAgent string was “Cisco-CP7965G/8.5.3”, and in mine “Cisco-CP7911G/8.5.3”. The second change was to apply a dialplan on our accounts that modifies the bindings for SIP responses that use high port numbers.  My dialplan is called incoming and it contains the following Ruby code:

bindingURI = sys.GetBindings()[0].ContactSIPURI
bindingURI.Host = bindingURI.ToSIPEndPoint().SocketEndPoint.Address.ToString() + “:5060”
sys.Dial(bindingURI.ToString())

Once I’d made sure that my SIP account had appropriate incoming and outgoing dialplans, my registration authentication failures went away – for reference, the outgoing dialplan that I use contains:

sys.Trace = true
sys.Dial(“sipgate”)

Where sipgate is the name of the SIP Provider that I have registered on Sipsorcery.

A few more things to know

Unlike my 7940G, the 7911G configuration needed to know about my external IP address for NAT purposes.  Without the <natAddress> parameter I could call out, but the phone didn’t ring for inbound calls and so I didn’t answer, meaning that callers were redirected to my Sipgate voicemail.

At this point, my configuration should have been working but there were still some issues. Rather than embarrassing myself by pointing out my stupid firewall (mis)configuration issues, I’ll highlight some key facts:

The control ports that are needed for SIP communications are:

  • SIP: TCP and UDP 5060.
  • SIP-TLS: UDP 5061.

Some more ports are needed for the actual communications – these are called media ports (RTP/RTCP) and are configurable in the phone configuration files but both TCP and UDP ports are required, generally for Cisco products in the range 16384 to 32766.  Two ports are required for each media stream – an even numbered port for RTP and the next higher odd numbered port for RTCP. So on a 2-line Cisco phone, you need 4 ports (say 16384-16387), and on a 6-line phone, you need 12 ports (say 16388-99).

If you use multiple phones, you’ll need to think about assigning different port numbers (e.g. 5062/3 for SIP) and using IP address reservations with appropriate IP filters set on your firewall.  I haven’t done this yet – it could be the subject of a future post as I still need to get the 7940G and the 7911G working in tandem, once I’ve sorted out a second power supply, or some Power over Ethernet (PoE) for the handsets.

Remember that, just because you have selected a certain range for media on a given device, doesn’t mean that the remote party will use the same range so only set the destination port numbers in your inbound firewall rules, not the source port numbers (i.e. allow responses from any source port to be passed through to the appropriate destination media ports).

Finally, some tools that may help (if you don’t have a good friend who’s already gone through this, like I did!):

  • Wireshark is great for seeing what the SIP/RTP conversations look like (e.g. SIP authorisation issues, one-way conversation streams, etc.).
  • Sipsorcery has its own console and, not only can the event * filter be used to trace proxy activities and interactions but event full gives an extremely verbose log.

Recording VoIP calls using Wireshark

Gary Marshall writes about how the UK Government plans to pour billions of pounds (as if they weren’t wasting enough money already) into recording all of our telephone calls. Well, funnily enough, I want to do the same thing… and it turns out to be remarkably easy – at least it is if you’re using a VoIP phone.

First of all, I should point out that, depending on where you live, it might be illegal to record phone calls without consent. In my case, I recorded a call from my desk phone to the voicemail on my mobile phone. As I was both the caller and the receiver I think it’s safe to say that there was consent – even if it does sound a bit mad. This was a proof of concept – the real usage case I have in mind is for the Coalface Tech podcasts, as last time James and I tried to record one over Skype there was just too much lag (and interference… although that might have been a local problem). Using the Cisco 7940 on my desk in the UK in to call a landline in Oz via my Sipgate account shouldn’t be too bad (and won’t cost too much either). What follows is a recipe for recording the call.

Ingredients

* If a softphone were used on the same computer as the packet capture, then it should be possible to capture the network traffic without needing to use a hub.

Method

  1. Install and configure Wireshark.
  2. Ensure that the computer being used for packet capture can see the phone traffic (i.e. that they are both connected to the hub – not a switch, unless port spanning or a tap are in use).
  3. Using Wireshark, start capturing traffic on the appropriate interface.
  4. Once the call(s) to be captured have been made, end the capture.
  5. In Wireshark, select VoIP calls from the Statistics menu – details of all captured calls should be listed:
  6. Viewing VoIP call statistics from a Wireshark trace

  7. At this point, it’s also possible to graph the traffic and also to play back the call (once decoded) – either one or both streams of the conversation:
  8. VoIP call graph generated from a Wireshark trace
    Playing back a VoIP call using the RTP packets from a Wireshark trace

  9. That’s enough to play back the call but to record it a different approach is required. Return to the list of captured packets and select the first RTP packet in a conversation.
  10. From the Statistics menu, select RTP and then Stream Analysis… This will show the packets in either direction:
  11. Analysing an RTP stream based on a Wireshark trace

  12. Click the Save payload… button to save to file – .au format with both streams is probably most useful:
  13. Saving the payload from an RTP stream based on a Wireshark trace

  14. The .au format is generally used for UNIX-generated sound files and can be played in Windows Media Player (see Microsoft knowledge base article 316992). Alternatively convert it to another format using whatever tools are appropriate (I used Switch on a Mac to convert from .AU to .MP3).

Results

I’m not sharing the full packet capture for security reasons but I have made the MP3 version of the RTP recording available.

Conclusion

Recording VoIP calls seems remarkably simple – given sufficient access to the network. Implementing IPSec should prevent such packet sniffing on the local network but, once a VoIP call is out on the ‘net, who knows who might be listening?

Acknowledgements

Whilst researching for this post, I found the following very useful:

The British government’s next step on the transition to an Orwellian nightmare

<rant>As if CCTV on every street corner (which even police admit hasn’t significantly reduced crime) and speed cameras that track movements over 30 miles weren’t bad enough, I’ve just read about the UK government’s plans that, in order to buy a mobile phone, we will soon need a passport (on the pretence that this is part of the fight against terrorism and organised crime). As Gary Marshall points out, have the UK Government never heard of Skype, e-mail, chat over public WiFi, payphones (and do they think that terrorists don’t have passports)?

There are those who say that, if you’ve nothing to hide, you’ve nothing to fear. I’ve nothing to hide – I simply just don’t trust the government not to mix my details up with someone else’s in a monumental database administration error. Only when they can keep my personal details secure, stop leaving top secret documents on trains, etc. will I be happy for them to store more information about me.

In the meantime, I’m counting the days until we get the chance to vote this bunch of inept <insert expletive here> out of office…</rant>

Microsoft Unified Communications: part 3 (putting it all together)

Over the last few days, I’ve been describing the Microsoft view on Unified Communications (UC), based on a presentation given recently by James O’Neill.

In the first two posts in this series based on James’ presentation, I outlined the business need for unified communications and some of the Microsoft technologies that can be used to address those requirements before examining some of the benefits to be gained thorough adaptation of communications to fit modern working practises. In this third post in the series, I finally move on to the technology, looking at the main steps involved in implementing a UC solution using Microsoft products.

It may also help to check out my post from April 2006 which provides an introduction to voice telecommunications for IT professionals.

In a traditional communications infrastructure, voice and data networks are managed independently:

Traditional (non-unified) communications

Even though there has been a move to replace telephone cables with standard CAT5/5e/6 cabling in recent years, and IP telephony has become more commonplace so there has been some convergence at the network level, the voice and data systems are typically separate (although their directories may have been integrated).

Implementing Exchange Server 2007’s unified messaging capabilities allows the removal of the PBX voice-mail system and provides voice-mail, fax and speech capabilities within Exchange, accessible via standard e-mail clients, Outlook Web Access or through a voice call:

Unified messaging with Exchange Server 2007

To enable the integration with the PBX, a VoIP gateway may be required (some PBXs may integrate directly).

Replacing any existing instant messaging systems with Office Communications Server (OCS) 2007 (or implementing OCS as a new service) can provide VoIP connectivity with the existing telephony systems, enabling both “soft” and “hard” IP phones to be used. In addition, Live Meeting can be used to provide conferencing facilities:

Unified communications with Office Communications Server 2007

With this infrastructure, OCS will integrate with Exchange and work collaboratively to route calls, present caller ID information (used in the subject of messages), perform directory lookups, etc. but for OCS to integrate with a PBX a gateway is required. A basic gateway also requires an OCS Mediation Server to be deployed whereas an advanced gateway includes the necessary technology to integrate directly with the PBX.

Effectively, there a four levels of integration:

  1. None at all.
  2. Basic gateway with mediation server.
  3. Advanced gateway.
  4. VoIP capabilities built-in to PBX.

Microsoft has partnered with a number of manufacturers to provide hardware that integrates with OCS, and the strategic gateway partners are Audiocodes, Dialogic and Quintum.

This approach allows legacy routers, gateways, PBX and phones to be maintained (after all they are a significant investment) but integrated with software solutions to adopt new ways of working, as featured in Microsoft’s VoIP as you are campaign. For organisations that are ready to remove the legacy telephony altogether (e.g. in a green field site) an advanced gateway can be used to integrate the VoIP system with public telephone networks:

Full Microsoft Unified Communications

The call path is as follows:

  • User initiates a call.
  • OCS looks for valid endpoints and sends a packet to say that there is an incoming call (including call forking, if configured).
  • An endpoint (possibly voice-mail) accepts the call and the server drops the other connections.
  • Once the call is established, the server drops out of the conversation (aside from logging the call details) and the call continues on a peer-to-peer basis.

There are a few additional points to note:

  • Where network address translation is in use, an OCS Access Proxy may be deployed.
  • If the call is routed over the PSTN, the gateway is just another party on the call (as if it were a phone).
  • In a conference scenario, Office Communicator clients only have a single channel of data in each direction and so where multi-party calls are placed, a media control unit (MCU) is required to act as a negotiator. At this point, the direct call is dropped and a new multi-party call is set up via the MCU. Live Meeting clients can send multiple video channels (plus sound and desktop conferencing on separate channels).

Having outlined a VoIP-only solution, it’s often the case that the legacy infrastructure cannot be completely removed – there are still some limitations around VoIP that OCS cannot address (at least not in the current release). For example, if there is a loss of power, then there are no network switches and there is no telephony (the same issue also applies for IP Phone systems using Power over Ethernet – such as Cisco IP Phones). As a consequence, and to meet health and safety requirements, it may be necessary to retain some traditional telephony infrastructure for emergency calls. Even if they are accessible through OCS, emergency calls present another challenge in that the call will be placed at the gateway, which may be in another city, country, or even continent to the person making the call, so dial plans need to be carefully designed.

Clearly this post is heavily biased towards Microsoft products and another major player in the unified communications space is Cisco. In the next post in this series, I’ll take a brief look at the approaches that the two vendors have taken to unified communications (and it will be a brief look, as I have very limited Cisco experience!) before I wrap the series up with some notes from my own OCS implementation last year.

Microsoft Unified Communications: part 2 (unlocking the potential for new communications experiences)

Last week I spent some time at Microsoft in one of James O’Neill‘s presentations on the Microsoft View of Unified Communications.

In the first post in this series from James’ presentation, I outlined the business need for unified communications and some of the Microsoft technologies that can be used to address those requirements. This post looks at some more of the benefits, as communications experiences are adapted to match modern working practises.

The first goal of unified communications: whenever I see a name, I also see presence

We communicate with people, not addresses, yet it doesn’t seem strange to us to dial a network address (a phone number) to speak to someone. Obviously, that’s because telephony has a long history, but it seems pretty odd today – after all, when did you last e-mail someone by IP address? That’s where directories come into play – just as on a mobile phone we tend to store contacts by name, in a corporate environment we should be able to contact our colleagues (or federated contacts) using Active Directory (possibly integrated with other directory systems – such as the internal telephone system).

Having found the right contact, we have a huge choice of media for communications, and the most appropriate medium may vary according to a number of factors:

  • Would you phone someone you know is out? Possibly – but you’d probably call their mobile phone.
  • Would an IM chat save a long e-mail exchange? This one is a little more tenuous – I often find that I’ve spent 20 minutes on IM when a 2 minute phone call would have sufficed.
  • Do you ever ask “is this a good time for a call”? Almost always!

The choice of medium is driven by presence – and when we have presence information, we can use it to make a decision.

After all, how would you connect of the person was:

  • On holiday for a week?
  • In a meeting for the next 30 minutes?
  • Around but not at their PC?
  • At their PC but with a do not disturb sign?
  • Available?

Technologies like the Office Communicator client can even set levels of permission (e.g. personal contacts may be able to override do not disturb status, certain contacts may be able to view home phone numbers but not everyone, etc.) and Office applications can also show presence through smart tags which include a “jellybean” presence icon.

The second goal of unified communications: where I see presence, I should be able to start a conversation (in the right medium)

Once I have a contact’s presence information, I can choose an appropriate form of communication. Should I contact them on a 1:1 basis or multi-party? Should I use voice, video, a data conference, instant messaging or e-mail? Then, using unified communication technologies I can let the computer place the call so that it may be routed according to my contact’s working hours, availability (presence), or other rules – possibly even allowing call forking so that two or more devices ring simultaneously and the first to be answered takes the call.

Using unified communications products a conversation can even switch modes mid-communication, for example:

(Instant message) “Are you free for a call?”
(Instant message) “Yes, but I’m travelling right now!”
(Click to call – and the call is routed to the contact’s mobile phone based on their working hours)
(Communicator-mobile voice call) The conversation continues until… “I’m in the office now, let’s transfer this to my desk phone.”
(Transfer call)
(Communicator-communicator voice call) The conversation continues until some expert advice is needed “Let’s bring Dave into the call – he’s the expert in this area.”
(Click to invite others)
(Multi-party voice call) “But what if I show you this diagram”
(Click to start Live Meeting)
(Conferencing) Each party can see a shared desktop, etc.

This example shows that the rich functionality provided by the various unified communications technologies allows for new conferencing experiences. Add in devices like the Office RoundTable and the whole feeling of a conference call changes (I’ve lost count of the number of times when I’ve tuned out of a voice conference because I’d lost track of who was talking or couldn’t hear them properly on a conference phone) – and meeting content can be recorded and stored for subsequent playback. Then there is Unified Messaging in Exchange Server, allowing voice-mails to be stored with notes in the recipient’s Inbox as well as voice access to have e-mails read over a voice call, to move calendar appointments, to access the directory and call contacts, etc.

That’s just the unified communications part – but why should web applications be restricted to e-mail and web addresses to provide contact details? tel: URIs can extend contact to voice calls, and can integrate with directory systems that use the E.164 standard for number formatting.

Incorrectly formatted phone number on Microsoft's websiteSadly, I know of at least one large IT services company that mandates the +44 (0) xxxxxxxxxx format for its directory updates (which is confusing to computers, as they will dial the +44 and the 0, rather than substituting one for the other) and even Microsoft’s own contact pages have an incorrect number which not only includes the UK (44) code in front of a full 11-digit number (including the 0 – which won’t work) but prefixes that with (011) which is the US international dialling code but is by no means universal (it’s 00 in the UK, and 0011 in Australia – hence the standardisation on the + symbol).

LG-Nortel IP8540 (Tanjay) deviceThe unified communications experience need not be limited to software either. Whilst Microsoft claim that the desk phone reached an evolutionary dead end some years back (Cisco, Siemens, et al. may disagree), they have also partnered with LG-Nortel, and Polycom to produce IP and USB phones to integrate with Microsoft unified communications software. Codenamed Tanjay and Catalina respectively, these devices either include an Office Communicator client with a touch screen and a fingerprint reader for authentication or extend the Office Communicator desktop experience to include a handset.

Hopefully, this post has helped to illustrate some of the new ways of working that incorporating unified communications technologies into the infrastructure can facilitate. In the next post in this series, I’ll move past the theory and benefits of unified communications and start to look at implementing the technology.

After more than four years of avoiding Skype, I discovered it’s not bad at all…

In 2004, one of my colleagues tried to get me to use Skype. I wasn’t impressed, especially as I was working on a client site and the proxy server kept on blocking connections to strange educational sites all over the world.

I’ve since learnt that was because of the peer-to-peer networking nature of Skype with it’s system of supernodes but, even so, for the last few years, I’ve managed to avoid it, favouring traditional voice communications and more recently, SIP-based VoIP. Then, as I blogged previously, James Bannan and I decided that we would like to put a podcast together and, as he’s in Australia and I’m in the UK, Skype looks like the most sensible communications option. I listen to a lot of podcasts where the presenters are geographically dispersed and apart from the odd glitch when someone is clearly on a weak connection or running some CPU-intensive software, everything seems fine.

Skype main pageSkype main page
So, one night last month, we gave it a go (we’ll only need audio but we tried the full video capabilities) and I was actually quite impressed. I was at home, using Skype 2.7.0.330 for Mac OS X with the built-in iSight webcam in my MacBook and James was using a recent version of Skype on a Windows PC in his office.

Don’t be put off by the pixellated picture… that was just because it wasn’t exactly the best picture of James (stills from video calls rarely are) but, apart from the deliberately mosaiced face, you can see that the video quality is not bad at all.

Skype technical informationGiven that I have a consumer broadband connection and that James was on the other side of the world (although I don’t know what sort of network connection he had), things were pretty good.

If you check out the technical call information screenshot you can see that the round trip (of at least 21,000 miles, through 4 relays was taking an average of 374ms (just about the limit before delay becomes noticeable but not exactly causing a problem) and there was negligible jitter and barely any packet loss, although the SVOPC codec is designed to tolerate packet loss (I found a forum post on a German site which describes the various metrics used by Skype). Most notably for me, both CPU cores on my 2.2GHz Intel Core2Duo were being hammered as Skype encoded/decoded the video conversation but we were still managing a respectable 15 frames per second.

So, in all the whole experience was a good one. Of course, like any VoIP connection across the Internet, experiences will vary according to the traffic conditions at the time but I was suitably impressed.