Sunday, 28 March 2010

Communication Server “14” – Voicecon RFP Response Review

During Voicecon Orlando each of the PBX Vendors submitted a response to a hypothetical RFP for an IP Telephony Solution. The RFP was written by Allan Sulkin, along with being reviewed, analyzed and then a “wining” vendor chosen during VoiceCon.

This year Microsoft was the wining vendor due to them being the most cost effective solution along with fulfilling the requirements of the RFP.

The Microsoft response to the RFP has been published for review and can be found here, the response provides information on the new Wave 14 release and the reminder of this post will focus on this information.

Since Wave 14 has not been released the information within the response is subject to change, so items mentioned may not make the final cut or may work in a different way than detailed. Therefore the information is based on my interpretation of the RFP response contents along with assumptions of how things may work.

It appears that Wave 14 will support Windows Server 2008 R2 which is expected along with using the same hardware specifications as OCS 2007 R2, this will should enable organisations to migrate their OCS estate to Wave 14 with a minimal investment in new hardware.

In addition there will be PowerShell support for administrative functions, there is also reference to Role Based Access Console (RBAC) although it is unclear if this is for Wave 14 or in reference to Exchange 2010.

The architecture of Wave 14 appears to have changed, the first thing is the disappearance of the Mediation Server, it is not shown on the architecture diagrams or included in the architecture description. The description of the Front End mentions that it provides all Signalling and Media Functions therefore it looks like the Mediation Server is now a function or role of the Front End Server.

There also appears to be a new redundancy offering for redundancy across physical sites. A whitepaper was released for OCS 2007 R2 with regards to Site Resiliency which can be found here. This is the basis of the redundancy within the RFP response. The response also lists a another option which appears to be a concept of a backup Site, allowing endpoints to re-register to the backup site automatically.

In order to provide this there must be some form of replication of the databases to ensure that users to do not lose their Contact Lists along with other items such as conference details.

There is also an indication that this can be performed in both direction, implying that both sites can host users. Therefore it appears that the concept of Pools is being superseded by Sites with each Site hosting users and resources but also being a hot standby for another site.

For organisations that do not need a secondary site to host users this could be an expensive way of provide resiliency but it removes the network requirements detailed within the OCS 2007 R2 Site Resiliency whitepaper.

Also how resiliency around the Edge Servers across sites is also not detailed.

There is also an indication that the XMPP Gateway will be part of the Edge Server.

Moving on to look at the new telephony features within Wave 14 the following are detailed within the response:

  • E911 Support
  • Call Park
  • Malicious Call Trace
  • Private Lines
  • Music on Hold
  • Survivable Branch Appliance (SBA)
  • Call Admission Control (CAC)
  • Support for additional IP Phones

In order for E911 to be supported OCS needs to know the location of every logged in endpoint either through the system knowing their location through a pre-defined Location Database within OCS or by being entered by the user.

Within an Office Environment there appears to be two ways to identify were a user is. The first is through the mapping of IP Subnets to locations within an office building this relies on the network design issuing different subnets to different floors or specific areas on each floor. While many business will have their subnets set-up in this way some will not and would therefore needs to redesign the way their network works.

The second option is to go by the switch port the device is connected to and for each switch port on each switch to be specified with a location in the Location Database. It is unclear how the switch port details will be queried although it is assumed that this will be using technologies such as CDP for Cisco and other technologies for other switch vendors.

For wireless devices the MAC Address of the Access Point they are connected to is used to retrieve the location information.

If for any of these scenarios there is no location information available or when the user is working remotely the user will be prompted to enter their location. I am not sure how this will work for the IP Endpoints as entering an address on something like the CX500 (Non-touch screen) will be time-consuming using the 12 digit dial pad.

In addition when a 911 call is made an alert IM can be sent to places like the Security Office to alert them.

Malicious Call Trace allows for a user to flag as call as inappropriate, this flag is stored within the CDR data for the call. There is no mention of if a Malicious Call can be recorded, although there are areas of the response which indicate that calls can be recorded by the client. Such as the support for Group Listening which has the following comment “Users may take advantage of built-in recording to enable post-call group listening”

There also appears to be support for Private Lines, which are usually used to provide Managers with two numbers one which is their publish business number and the other which is private. It is unclear how this is implemented, whether is means each user can have two Line URIs of if it is implemented some other way.

In addition there is also an indication that Music on Hold will be supported on the endpoints, currently this in only available in the Attendant Console in OCS 2007 R2.

Looking at how conferencing has changed in Wave 14 there is an indication that Voice Conferences can be recorded this is something which was not available natively within OCS 2007 R2, even through there was a warning when entering a conference that it may be recorded; there was also an SDK sample application that could record conferences on an ad-hoc basis.

The following statement also indicates that conferences can be reserved “Users have the ability to schedule and reserve audio/video conferencing sessions through Microsoft Outlook calendaring”. This is a change from what OCS 2007 R2 offers in that in R2 conference can be scheduled but no resources are reserved within the MCUs. This statement would seem to indicate that the MCU resources can be reserved to ensure that their is capacity for the conference to take place.

In terms of the new IP endpoints it appears that to login to the CX600 an extension and pin is used whereas the CX700 continue to use the domain username and password, hopefully this PIN is the same as the Conferencing PIN and not another one to maintain and remember. There is an indication that users can login to the CX500 but no mention as to how, I am assuming it is also via an Extension and Pin combination.

This does start to provide support for a Virtual Office style system allowing the IP Phones to be used in hot desk style scenarios. USB tethering is also supported on the CX600. Hopefully this will also be mirrored on the Astra equivalent devices.

The CX500 designed for Common Areas are not associated with specific users but can have calling restrictions applied to them; I am assuming something like a Contact Object will be used to represent them in Active Directory and authentication hopefully via MAC Address. It is also mentioned that users can login to them if needed.

Analogue devices will also be supported and represented in Active Directory as Contact Objects allowing for calling restrictions to be applied. The route that these devices connect into OCS appears to be via Analogue Terminal Adapters (ATAs) or Survivable Branch Appliances with FXS ports. It is unclear how these will work together but I assume people like AudioCodes will release new firmware for their MediaPacks and hopefully other vendors like NET\Quintum will as well.

The final two elements to cover are Call Admission Control (CAC) and the Survivable Brach Appliances (SBA).

Call Admission Control allows for calls to either be rejected or alternatively routed depending on the number of calls currently taking place over a WAN connection. The settings are controlled via the Administrator and can be applied to WAN and Constricted LAN connections. It allows for example Voice Calls to be re-routed via PSTN connections if a WAN connection is saturated or for Video to be routed via the Internet and Voice via the WAN connection.

If all possible routes are unavailable then the call will be rejected.

What is not clear is how dynamic this functionality is and also if it relies on an SBA to be deployed in the branch to provide re-routing via the PSTN and\or Internet Connections.

For Example if a Video Call is going via a WAN connection and a Voice call needs to take place would a Video Call be re-routed via the Internet while in progress. Or if a Video Call will be downgraded from HD to VGA to provide capacity for another call. Or if the calculation are based purely on available Bandwidth or if other network characteristics such as Jitter and Packet Loss are also taken into account.

The final item is the Survivable Branch Appliance (SBA), this provides functionality to a branch office in the case of a WAN failure. The device appears to operate in two modes a standard mode and a Local Survivability Mode. Irrelevant of the mode the SBA is operating in clients within the branch will always register to the SBA, if the SBA fails the clients will re-register with the Front End Servers in the main office.

When the SBA comes back online clients will re-register with the SBA although it can be defined as to when this happens. Hopefully this means either out of business hours or next login.

What is not clear is how information will flow when the SBA is operating in the standard mode.

  • Will all SIP messaging go via the Front Ends?
  • Will it go via the SBA then be relayed to the Front Ends?
  • If for example it is an IM conversation between two users in the branch office will the traffic stay local to the SBA?
  • Are there MCU resources on the SBA?

Until the 3rd Parties start to release the products and until Microsoft release further information it is difficult to know how it will function.

The response does indicate that during Local Survivability Mode all functionality will be available with the exception of Call Forwarding Settings and Response Group Settings. Although this is contradicted in the following paragraph indicating that only Call Forwarding Settings are unavailable. This is while referring to two different sizes of Branch, so it does pose the question of if there are two types of SBA.

In order to still maintain functionality like Instant Messaging to other sites, the SBA must be able to route IMs etc via a Local Internet connection but again this is not clear. It does indicate that PSTN calls will route out via the local PSTN connections.

Voicemail will continue to work and allow deposit and retrieval via the PSTN (hopefully via an Internet Connection as well).

It is also unclear what will happen with things like CDR Data and IM Archiving, hopefully these will be cached and then relayed when the WAN connection returns.

I think that is about everything, although I might have missed one or two things. I am aware the ordering of this post is a little strange in terms of content but hopefully it all makes sense.

Saturday, 13 March 2010

Exchange 2010 UM – Behind the Scenes MWI

With the release of Exchange 2010 the uptake of using Exchange as a Voicemail platform appears to be increasing. I am unsure if this is due to the Message Waiting Indicator (MWI) functionality now been included, or if the time is now right for customers to start adopting it.

While researching into the UM features of Exchange 2010, information around the features available and how to configure them is plentiful but there appears to be very little information about how MWI operates behind the scenes.

Therefore this post is based on the limited information that appears to be available and from looking into the MWI functionality.

The initial information at a high level comes from a slide deck produced by Ankur Kothari a Sr. Technical Product Manager at Microsoft. This has been published in PDF format and can be found here. Due to it being a PDF there are a number of slides which are hard to read and understand these are due to them been animation based slides and the PDF shows all the animations on a single page.

A high level view of the UM processes for leaving a message and for MWI can be seen in the diagram below (borrowed from Ankur’s slide deck)

High Level Diag

As can be seen from the diagram above the process of leaving a message has not changed; one thing to note, step 3 shows the Voice message being delivered to the Mailbox server since this is an SMTP message from the UM Server to the recipient it goes via the Hub Server.

The new to Exchange 2010 part of the diagram above is the MWI part. This works in two parts the first is the notification from the Mailbox Role to the UM Role that MWI needs to either be turned on or off. The second is the SIP NOTIFY message between the UM Role and the IP-PBX or Gateway.

Before looking into this in more detail it is worth covering off some of the higher level details. MWI is enabled at both a UM Mailbox Policy and Gateway Level, for MWI to be set correctly it needs to be enabled on the UM Mailbox Policy and at least one Gateway associated with the Policy and Dial Plan. These are enabled by default but in some scenarios it may be necessary to disable MWI for some gateways.

Also MWI does not function if the Dial Plan has a URI type of SIP URI, even though the MWI settings are available. I am unsure why this is the case but I assume it is by design and probably due to the fact that a SIP URI dial plan is most commonly used for OCS.

Moving on to look at how MWI works, the process starts with the Mailbox Role which hosts the UM Mailbox Assistant this Assistant actively monitors the user’s mailbox for the number of read and unread messages. When this count changes it sends an RPC  message to a Unified Messaging Server which hosts the UM Dialplan the user is associated with. There can be a small delay in this task being performed, this is usually due to the time it takes for Outlook to update Exchange when a message’s read\unread flag gets changed.

The following message can be seen in the Event Log of the Mailbox Role Server when diagnostic logging is turned on:

MBX MWI Event Log

The UM Mailbox Assistant is housed within the Microsoft Exchange Mailbox Assistants Service; this Service needs to be running in order for MWI to function (along with a number of other Exchange functions) .

Once the message has been received by the UM Server, a SIP message is sent to the IP-PBX or Gateway, if the first gateway is unavailable or responds with a SIP error message it will attempt each remaining IP-PBX or Gateway associated with the Dial Plan and enabled for MWI.

The SIP message sent to the IP-PBX or Gateway is a NOTIFY message and contains the following information:

  • MWI On or Off
  • Account to modify MWI on
  • Number of Read and Unread messages

The Message Body of the SIP Message looks like:

Sample MWI SIP

The reasons why the number of read and unread messages are sent is some PBXs and Phones display the number of read and unread messages. This is as specified in the RFC3842, unfortunately Exchange does not implement an optional part of the RFC which is to provide the message count for urgent messages; this would have rounded the implementation off nicely since Exchange provides the ability to mark Voicemails as High Importance.

The RFC also provides scope for the number of read and unread fax messages to be passed to the IP-PBX or Gateway, this is not implemented within Exchange MWI and is not include as part of the Voicemail message count.

The following message can be seen in the Event Log of the UM Role Server  when diagnostic logging is turned on if the SIP Notify has been successful:

UM MWI Event Log Sucess

If an MWI notification fails messages similar to the following can be see, these are written to the Event Log on the UM Role Server irrelevant of the Diagnostic Logging Setting:

UM MWI Event Log Fail 1

UM MWI Event Log Fail 2

During the MWI process both on the Mailbox Role and the UM Role a number of LDAP queries are run against Active Directory these are to look up information such as if the UM Mailbox Policies are enabled for MWI and the associated Gateways, this information is not cached and is queried for each time.

Once the IP-PBX or Gateway has been acknowledged the MWI Notify message it is left to the IP-PBX or Gateway to locate the phone or phones associated with the specified extension and either turn on or off the Message Waiting Indicator.

Any IP-PBX or Gateway that supports RFC3842 should work with Exchange 2010 MWI although specific settings my be required on the PBX.

In summary MWI is something which was missing from Exchange 2007 and although there were third party applications to fill the gap, it was still seen as a major deployment blocker. Hopefully with Exchange 2010 supporting MWI it will increase the number of Exchange UM deployments.