Saturday, 10 April 2010

Benelux Techdays – Communications Server “14” Sessions Review

On the 1st April François Doremieux presented at the Benelux Techdays Event.

He presented two sessions the first was an introduction to Microsoft Communications Server “W14” and the Second was New Voice capabilities and infrastructure in Microsoft Communications Server "W14".

On the 9th April the recordings of these sessions were published on the TechNet Edge site and can be found here and here.

These recording provide some additional detail around what is coming in Communications Server (CS) 14 and also some clarity of items mentioned in the Voice Con RFP response my review of which can be found here.

The reminder of this post will build on my review of the RFP and focus on items which I believe are new or where there is further clarity.

In addition due to the topics of the session delivered this will focus purely on the Voice aspects of Cs 14 with the exception of some architectural comments.

Starting with the new client functionality.

There will be the ability to easily place a test call from the Communicator Client, this appears to be similar in functionality to the Deployment Validation Tool for OCS 2007 R1 and R2 but built into the OCS Servers rather than a separate component.

The Music on Hold (MoH) functionality is local to the client rather than a server based function it is unclear however if the user will be able to select their own hold music or if the option is to simply enable or disable MoH.

There was also the mention of the ability to choose different ring tones, although this was not discussed in any further detail. In OCS 2007 R1 and R2 it is possible to change the ring tone via the Windows Sound Settings but this would imply the ability is built into the client, possibly with a list of different ring tones to choose from. What would be useful is the ability to choose different ring tones based on the person calling. Such as one ringtone for corporate contacts, another for external and another for certain Caller Line IDs etc.

There will also be the ability to record calls on the local client, although this can be disabled by the administrator if required.

Moving on to look at Call Admission Control (CAC), it was mentioned that this should not be a replacement for right sizing the network. If there is not enough bandwidth for Video at a site this functionality should be disabled for users at that site rather than risk them having a bad experience.

CAC should be used for when the usage of Voice or Video exceeds the planned usage for a site or if a user travels from a site were they are allowed to use Video to a site which is not designed for Video, CAC could either block the Video completely or if there is sufficient bandwidth allow it.

There was also mention of ability to prioritise Emergency Calls, I assume this means that even if the resources are allocated for other calls and there is no alternate route the Emergency Call will still be placed and risk bad quality rather than rejected.

Looking at the configuration options for CAC it was mentioned that it is fully configurable in terms of Locations, Topology, Network Links with limits for Voice and Video being separate and on a link by link basis.

What is not clear is if the limits are the number of concurrent calls or based on bandwidth limits. Due to the elastic nature of the RTAudio and RTVideo codecs it will be interesting to see how these are configured.

It was also mentioned that the full path of the call is assessed before if takes place, meaning that in a star topology where traffic goes via a hub site it will ensure that there is capacity on all the required links before it can take place and then re-route or reject if there is not enough capacity.

Rerouting can either be via different WAN links, via the Internet assuming local internet connections are available or via the PSTN for Voice Calls. What is not clear is how it will handle multiple links between sites such as primary MPLS links and then backup links which offer a high latency for example but suitable for some calls.

It was also mentioned that there will be the ability to down-rate video, so if the client\user wants to utilise HD but only enough bandwidth for VGA or CIF is possible then the video will be down-rated.

Looking at interoperability with other PBXs there will be support for getting and setting presence via SIP, this is often referred to as SIP Verb support. This will provide the ability retrieve presence from a PBX and update the users presence status if they are in a call. It is unclear if PBX will be able to retrieve presence information from OCS using the same method.

The new IP Phones were also covered but the only item I believe which has not been mentioned before is the ability to view the users calendar on the phone.

Moving on to Conference Calls, when the user is in a conference call in Communicator they can easily access the conference access details which include Dial In Number, Conference ID and URL so these can easily be shared with participants.

There is also improvements for users using a traditional PBX rather than Enterprise Voice but where they want to utilise the conference functionality in OCS. They are able to configure Communicator to automatically call their PBX extension, placing them immediately in the call when they answer. Along with an option to override this on a per call basis for situations when they are away from their PBX phone.

This would also require a connection between OCS and the PBX either via a Gateway or Direct SIP.

For the Location Information required for E.911 Support, this is provided via the Integrated Location Information Server Role (LIS), which I assume is part of the Front Ends.

Moving on to the Mediation Server, this will pretty much disappear in Wave 14 in terms of being a Standalone Server, it will become a Role within the Front End Servers for the majority of deployments.

Looking at why there was a requirement for a Mediation Server in the first place it was as a demarcation device and to perform trans-coding from RTAudio to G.711.

In order to not move this entire load to the Front Ends additional logic has been added as to when G.711 can be utilised instead of RTAudio, with the media being sent directly to the Gateways rather than the Mediation Server. I am hoping this also applies for Direct SIP capable PBXs. While OCS 2007 R2 was capable of using G.711 for some calls if the network conditions were correct it still relayed this via the Mediation Server.

A standalone Mediation Server will still be required when using a SIP Trunk from a Telephony ISP (TISP).

Looking at the Survivable Branch Appliance (SBA) this will either be a Server Blade in a Gateway or a Gateway Blade in a Server. If the WAN links fail the clients in the Branch will utilise the PSTN connectivity supplied by the Gateway or possibly a local Internet connection.

The Clients will register with the SBAs in the branch, if this fails the clients will re-register to the Front Ends. In order to do this the clients are aware of the additional locations at which it can register. It is unclear if this will always be the OCS Front End Servers or if it can be another SBA. Failover and Failback will be automatic.

It appears that although the client registers with the SBA they will use all the functionality of the Front Ends as long as they are accessible. The reasoning appears to be that the SBAs will be more stable and reliable than the WAN connections and as such while losing the WAN will result in restricted functionality the client will not need to re-register.

In order to provide the ability for client to register, the SBA will act as a SIP Registrar and provide Authentication, Client Configuration Details, Telephony Routes and Policies.

When in failover mode (Access to Frontends Lost) it was mentioned that Presence Information may be lost due to the Front Ends providing Presence Aggregation.

In addition the SBAs are designed to require minimal effort and knowledge to deploy in the branch and administered centrally. Allowing non IT staff or local 1st line support staff to deploy them.

It also appears that users outside of the Enterprise accessing via the Edge, I assume via VPNs as well will be able to register with another registrar if the Front Ends go offline. I assume this means to an SBA or secondary pool. I assume this will require Directors in place and that they are still online since these would be the “Next Hop” for the Edge Servers.

Moving on to look at the Architectural Changes, it was mentioned that all server roles can be co-located with the exception of the Monitoring Server. I am assuming they mean the Edge Server as well.

As mentioned in the RFP the Datacenter Redundancy will be improved, the ability to split a Pool across two Datacenters will still be possible assuming a low latency WAN link, less than 15 milliseconds, which is the SQL replication limit. Under this scenario there would be no loss of functionality and be fairly transparent to the end user.

The new Datacenter Redundancy scenario is designed for Datacenters were there is no option for a low latency WAN link such as one in the US and one in Europe. For this there is the concept of a secondary pool which clients can failover to. With this set-up there would be a loss of functionality such as Presence and Contact Lists, since these are held in the Pool Database. I also believe that scheduled conferences and “MeetMe” style conference will not be available due to these details being held within the Pool Database as well.

Functionality such as Call Routing, CDR, External User Access and Ad-hoc Conferencing will still be available.

If the Datacenter was completely lost then there is the ability to move the users to the secondary pool, meaning that full functionality will be restored. Although I am unsure if this means the Contact Lists will be lost along with other items stored in the Pool Database or if there will be a mechanism to retrieve this data from things like SQL backups.

The final item is the monitoring and alerting capabilities, this appears to be the reminder of the OCS 2007 R1 and R2 Deployment Validation Tool built into CS 14. This will provide the proactive monitoring and alerting of issues to System Center Operations Manager (SCOM). Agents can be deployed to machines and perform checks such as trying to register with CS and placing test calls to monitor network characteristics. These were referred to as Synthetic Transactions.

Again this is my interpretation of what was mentioned in the recordings of the sessions and these may or may not appear in the finial release; or the functionality may work in a different way.

And on a closing note it was mentioned in both sessions that at TechEd US, Everything that there is to know about CS14 will be revealed.

No comments:

Post a Comment