Exchange 2010 and MWI

For months prior to the Exchange 2010 Beta being released there where rumours going around about what new features would be added.

One of the biggest features that interested me was something as seemingly minor as MWI. It is something that every voicemail system had, something that everyone took for granted, until it was no longer there.

Ever since Exchange 2007 came out, MWI has given me and many other consultants nightmares. The never ending discussions with customers as to if they needed MWI, it going so well until the one group of people (usually the Senior Executives)  that just couldn’t do without it. Everyone else was usually happy when it was pointed out that they lived in outlook so would just see the email.

Then came the painful discussion of, well you could have MWI but it would cost, and usually not a small cost either.

Well now those days are over and once again I can go into a meeting to discuss the advantages of moving to Exchange UM, without spending time talking about MWI (Let’s just hope fax support is not mentioned).

In order to see how good the MWI support is, I decided to set-up a new Exchange 2010 system and connect it to a Cisco CallManager 7. To my amazement MWI just worked, leave a voicemail and MWI lights up.

Who would have thought a small red light could bring so much pleasure (and grief)….

Communicator Automatic Updates

Today I was looking for the latest Knowledgebase number for Communicator R2 for a document and was expecting to find the article for 3.5.6907.9.

I was rather surprised to find the article for 3.5.6907.22 (kb971083), dated 19th May 2009. There are a number of updates within it but the one that jumped out was to fix a bug that has broken automatic updates.

For those of us who decided to use Automatic Updates and had to work though the numerous issues in getting it to work, this is to say the least rather annoying.

After doing some research I came across a post on Aaron Tiensivu’s Blog (link), on a way to update clients who are running 3.5.6907.9 to 3.5.6907.22. While this method allows clients to be updated without administrators having to visit each PC, it still requires user interaction and is not something that could be done without warning.

Anyone doing this should send out information to their users before hand on how to perform the update.

Another option would be to push out the patch via Group Policy, SCCM or other similar products; but if you wanted to use these methods why would you use the Communicator Update option in OCS?

Remote Call Control and OCS Conferencing

One of the new Voice Features to be added in OCS R2 is the ability to “Dial In” to an OCS Conference; this allows users to migrate away from expensive “Cloud” based conferencing solutions.

One of the key differentiators of OCS Conferencing is the ability to control the conference through Office Communicator.

When Enterprise users join an OCS Conference via Communicator they can either use the Computer Audio or use Communicator to dial out to a number such as a desk phone or mobile. This works for Enterprise Voice enabled users, but for users who only use Remote Call Control (RCC) and do not wish to use the Computer Audio, dialling out to another number fails.

This is expected behaviour as RCC users do not have Location Profile or Policies assigned allowing them to do this.

While users can “Dial In” by dialling the access numbers this removes useful features such as using Communicator to control the conference.  Users also have the option to use Communicator Web Access (CWA); this allows users to control conferences when they do not have access to communicator. Leaders join the conference by CWA dialling out to them; the OCS documentation provides details on how to enable this for users which are not enabled for Enterprise Voice.

While using these two methods are possible ways of allowing RCC users to access conferences, it takes them away from Communicator which a lot of companies do not like to do.

The following method can be used to allow RCC users to dial out to a number of their choose while still using Communicator to control the conference; this is a modification on the method used by CWA.

In order to allow RCC users to “Dial Out” a Route needs to be created on the OCS Pool, which routes SIP messages that contain a Phone URI to a mediation server, as shown below:

By adding this Route users can then Dial Out to their desk phone or mobile allowing them to join a conference and control it via Communicator; as shown below:

 

While this does allow users to use Communicator to control the conference it has the following draw backs:

• It is a Pool wide change
• It bypass dialling restrictions
• Only supports a single Mediation Server
• Users must enter a routable number, there are no normalisation rules to transform the number.

Ideally when deploying Remote Call Control, Dual Forking should be deployed at the same time, this allows users to access OCS Conferencing and at the same time does not have any of the draw backs listed above.

PSTN Codec Usage in OCS R2

In OCS R2 Microsoft made a change to which Codec’s are used for PSTN calls. In OCS R1 RTAudio was used for all calls, OCS R2 uses the G711 for some PSTN Calls.

G711 may be used for calls to the PSTN depending on a number of network characteristics these tend to be:

• Round trip delay of less than 20ms
• Call originates from the LAN

The codec can also be different for the Caller to Callee and Callee to Caller.

 

For some this may seem odd, we have been told since the release of OCS R1 that RTAudio is a superior codec and has many benefits over traditional codec's such as G711 and G729. While this is true it also has some drawbacks such as higher CPU usage both on the Client and the transcoding performed on the Mediation Server.

One of the advantages of the RTAudio Codec is the voice quality in Wideband environments. Since Wideband is not available for PSTN calls, using RTAudio when it is not required puts the extra load on the CPU.

Another was the ability to adapt to varying bandwidth limitations and network conditions. This is particularly important for users working remotely, or over Wi-Fi connections, when running on the same LAN as the mediation server the network conditions tend to not vary.

If, during the call, Communicator detects changes in the network characteristics, such as an increase in the round trip delay, the codec will automatically switch to RTAudio in order to ensure the call continues without issue.