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.

No comments:

Post a Comment