Friday, 16 December 2011

Microsoft Lync Mobile and WiFi

In the last week Microsoft have released their Lync Mobile Clients, which support IM, Presence and Call via Work. Competitors have made a lot of noise around the seemingly limited functionality such as not providing Voice over WiFi, Video or Desktop sharing. Like any competitors they will openly pick holes in a product rather than look at why Microsoft may have done this.

Taking a look at the Voice and Video over WiFi aspect of this (and to some extent desktop sharing). Current Wireless Technology is somewhat limited when it comes to Real Time Media and the average Wireless deployment is usually not designed with Real Time Media in mind.

While users can use their Laptop and use real time media within application such as having a Lync call over a wireless connection issues start to occur the moment someone starts to walk around with the laptop. This is because WiFi was never really designed to be used while people are moving, yes it is designed for mobile workers but for them to be stationary while using it.

This changes the moment you start to use a mobile device over WiFi as a user will often walk around with the device, potentially getting further away from an Access Point reducing the signal strength and available bandwidth, moving between access points or even worse outside of coverage completely.

The last two points, moving between access points and leaving the coverage are the ones which really cause issues with real time media over WiFi. Access points do not have the ability to seamlessly handover connections between them; due to this there can be instances where you lose the network connection for a few seconds when moving between them. For real time media this causes major issues and you will lose part of a call for example. This is why technologies such as DECT are still widely used (and seen as the industry standard for wireless telephony devices)  as they do offer this functionality and are specifically designed for users moving about while on a call.

Looking at the issue that occurs when leaving the wireless coverage completely, users will be in a position where their call terminates since there is no capability to provide a seamless handover between the WiFi and GSM (this isn't a Lync issue, it is industry wide). Due to this if a user moves out of coverage of the Wireless network then the call will drop and they will have to re-dial causing user frustration along with a bad experience.

This is why Lync Mobile sticks to Voice over GSM as it is the only way to guarantee good quality call and a good experience. This is the “Call via Work” functionality where Lync will place an outbound call to the Mobile Device and then an outbound call to the number dialled, this could be to another Lync user in which case it could be a SIP call or it could be out to the PSTN.

While there is generally a cost to placing these calls it is often the trade-off between having a good call and an alright call which could drop halfway through, personally I know which one I would prefer. There are also ways to mitigate these costs such as using a dedicated “Mobex” connection to your GSM provider or through Mobile Gateways which utilize SIM cards to place calls.

I have worked with several customers who use Mobile Gateways and associated SIM cards they are very easy to set-up and are usually connected to a Lync Certified Gateway, such as NET. On these gateways a static route could route all mobile calls to them or functionality such as LDAP lookups can be used to dynamically route calls for mobile devices owned by the organization to the Mobile Gateway.

Depending on the contracts negotiated with mobile providers it is sometimes possible to provide free calls between the Mobile Gateway (which are effectively mobile phones) and the mobile phones.

Lastly some vendors have stated that they are developing new Wireless Access Points to better support real time media over WiFi, if they do this it should benefit all users who want to run real time media over WiFi, but the very requirement that they need to do this demonstrates that today there are issues.

Sunday, 29 August 2010

RunAs Radio Show

A few weeks ago Richard Campbell from RunAs Radio, asked if I would participate in an interview for the Talk Show.

This was initially to be on Exchange UM but ended up been around Office Communications Server.

Recording this was a new experience, and an interesting one at that, the interactive nature and not knowing what questions would be asked made it a challenge.

The recording can be found here, and I encourage people to subscribe to the podcast.

If you have suggestions for other topics you would like covered, you can contact Richard Campbell and Greg Hughes, at info@runasradio.com.

Tuesday, 20 July 2010

Communications Server 14, Authentication and Certificates

In order to support new features in Communications Server 14 (CS14) such as IP Phones and Branch Office Survivability an additional authentication method has been added along with the introduction of User Certificates.

This additional Authentication method is in the form of an Extension and Pin combination allowing for users to login to the new IP Phones, this allows a user to easily login to a phone rather than needing to use their domain username and password.

The authentication method is limited to CS, in that CS authenticates the login within it’s own database, if the login is successful a User Certificate is issued to the IP Phone, this is then used to provide access to the CS Web Services and used for  authentication with the CS Servers.

Due to this being a CS authentication method, a Kerberos Token is not issued to the IP Phone, meaning that an IP Phone can not authenticate to Exchange Web Service causing some functionality loss (More details in a future post).

The Extension and Pin used for this processes is the same for Dial In Conferencing removing the “yet another Pin issue” although Exchange still uses it’s own Extension and Pin combination.

Moving forward it would be useful if Exchange could use the CS Pin Authentication Web Service rather than use it’s own when operating as part of an OCS environment. With Exchange 2010 Service Pack 1 moving to use UCMA for Unified Messaging hopefully having an option to use CS Pin Authentication is a logical next step.

The Pin is managed via a Web Interface in a similar way to the Dial In Conferencing Pin in OCS 2007 R2, the management of this has been moved from Communicator Web Access (CWA) to be part of the Web Components Role which is co-located with the CS Front Ends.

Taking a look at the User Certificates, these are issued by CS acting as the Issuing Authority, rather than proxying these requests to an Enterprise CA (Server Certificates issued by an Enterprise or Public CA are still required for TLS\MTLS).

Certificates are issued to the Client Endpoints (IP Phones, Office Communicator etc) allowing authentication to CS14, rather than using the Kerberos token each time. When using Office Communicator Kerberos is used for the initial logon (to get the Certificate) and for non-CS Web Services such as Exchange.

Certificates are also an integral part of the new Resiliency options in CS, allowing a client to authenticate and register to CS if connectivity to Active Directory Serves are lost; this is of particular importance in the branch office scenario when using the Survivable Branch Appliance (SBA).

When using Office Communicator these are issued to a user SIP URI and stored within the User’s Certificate store, meaning that if the same Domain User logs in as a different SIP URI,  a new authentication process will be initiated rather than using an existing certificate.

On IP Phones certificates are deleted when the “Switch User” process occurs, or a hot desking users session expires. Allowing for a new user to login using their Extension and Pin.

User Certificates by have a life span of several months helping to ensure that if a user logs into Communicator during a WAN outage they are still able to authenticate with CS. While it is currently unclear if this life span can be shortened the ability to deactivate certificates when necessary should suffice for most organizations.

Hopefully these additions will not add additional complexity and will simply become a backend process within CS14.

Tuesday, 8 June 2010

Communications Server “14” – TechEd Day 1

Since VoiceCon Orlando 2010, news about the Wave 14 release of Communications Server has been trickling out. At TechEd New Orleans this changed with a number of sessions focused around the Communications Server “14” release.

This also coincided with information being released on the Microsoft Product Pages.

This post will detail the information discussed in the Day 1 sessions, at a high level. My aim is to build on this as more information becomes available.

No dates were given for CS14, only that it would be this Calendar Year, also it is not clear if all the functionality mentioned would be available at RTM or if some would come at a later date.

Communicator:

  • Photos Displayed within Communicator, can be from Active Directory, SharePoint or User Specified URL. Can be restricted by Administrator. Along with the user being able to choose not to show their picture and hide pictures in their contact list.
  • Photos downloaded from AD using a new Web Service Address Book Service Web Query (ABS-WQ) and Cached locally.
  • ABS-WQ used for Distribution List Information and Hierarchy along with an alternative to downloading the Address Book everyday.
  • Option to use Address Book (same as R2) or Web Service, set on per User or Pool Level.
  • Exchange Web Services used over MAPI, functionality such as Conversation History will be via EWS.
  • New Contact Group – Frequent Contacts. Dynamically managed includes 10 most frequent contacts along with Team members and Pinned contacts.
  • New Presence State “Off Work”.
  • Time zone and Location published in Contact Card, Location Publishing can be disabled.
  • Enhanced Privacy, enabled at Pool Level. Only show presence to people on the users contact list. Users can opt out and display presence to all.
  • Ability to place a test call within Communicator.
  • In Call feedback of call Quality.

Devices:

  • Will use ABS-WQ for searches.

SharePoint:

  • Enabled via Inband Provisioning.
  • Client connected directly to SharePoint.
  • SharePoint 2007 or later supported.
  • Provides Expert Search, both specified on a user’s MySite but also inferred based on documents users post etc (Unclear if this is SharePoint 2010 only).
  • Phonetic Search for Users and Skills when using SharePoint (Unclear if this is SharePoint 2010 only).

Architecture:

  • Support for redundancy across Datacenters.

Conferencing:

  • LiveMeeting client is no more, the functionality is built in to Communicator “14”.
  • Attendee Console to provide full fidelity access to conferences by external participants.
  • There will be a Silverlight client to provide access to conferences where participants can not install the Attendee Console. It was inferred that this would not have all of the features of the Attendee Console.
  • Conferences can be recorded, these recordings record everything that happens within the conference, IM, Voice, Video, Sharing.
  • Recording are played back using the Recording Manager and including Handouts.
  • Recordings can be “published”to a WMA file, with the ability to publish all or parts of the recording such as only the Voice and Active Speaker Video for example as well as been able to specify a time window.
  • When creating meetings, options are available to specify who is allowed in automatically and who should be granted access by a Leader. Also settings on who should automatically be granted Leader Status.

Telephony:

  • E911 support, this is provided by routing calls via a SIP Trunk to a PSAP who in turn will route the call to the correct Emergency Call Center based on location of the caller.
  • Branch Office Survivability, if the connection to the OCS Server is lost, calls can be routed via local PSTN Connections.
  • Support for Call Access Control, allows administrators to specify if WAN links can be used for Voice and Video along with limiting the number of concurrent calls.
  • Media Bypass for PSTN calls, allows calls to bypass the Mediation Server if the client can route the RTP traffic direct to the Gateway. It is unclear if this is G711 only or if the Gateways will support RTAudio.

Cloud Support:

  • Communications Server “14” is designed to work in the cloud.
  • Support for some users on site and some in the cloud with shared namespace.
  • Support for Exchange in the Cloud and OCS on site, along with the same support for SharePoint.
  • No dates were provided as to when this will be available only that they are working on it. I also assume it will be staged.
  • Voice in the Cloud will be via Partner Solutions.

Development:

  • Ability to build Silverlight applications in to the “Conversation” Pane. Allowing developers to provide context based information such as Contact Center Functionality to users.

Virtualisation:

  • Supported, but within specified boundaries.
  • Will include support for Voice and Video.

Mobile Client:

  • Improved functionality.
  • Support for more devices.

Federation:

  • Support for Voice and HD Video Federation with Windows Live Messenger.

At a high level, I think I have covered off most of the “New” items, hopefully more information to come.

Tuesday, 1 June 2010

NET’s 21st Century Gateway

Network Equipment Technologies (NET) are due to launch a brand new gateway branded as the UX. This gateway will be designed with the 21st Century in mind breaking away from the TDM world gateways are usually found in.

Gateways were originally designed for bridging the TDM world with the IP world for purposes such as:

  • Connecting TDM PBXs together over an IP Network,
  • Providing connections to Software Products such as:
    • Microsoft Exchange
    • Microsoft Office Communications Server (OCS).
    • Software Fax Solutions
  • Providing TDM connectivity for  Softswitches.

Today the Telephony landscape has changed, organisations find their Telephony Estates are made up of a mix of PBXs which could be IP or TDM, and usually from a number of different vendors.

This is usually due to acquisitions or different regions doing their own thing. In order to link these together to provide functionality such as PSTN Bypass and Centralised Voicemail third party gateways are often required.

This is due to PBXs supporting different protocols such as H323 or SIP, and some may be pure TDM. Others require more complex number transformation and translation than is possible on the PBX.

The problem with the vast majority of gateways available today is that they were designed for a TDM world and while many have been updated to provide IP to IP Routing, there are still limitations around functionality such as Transcoding.

This is where the UX changes the playing field as it being designed with the new Telephony Landscape in mind.

While the UX will take the best parts from the NET VX and Quintum DX Gateways, it is being built from the ground up and for all intense purposes will be unrecognisable from its predecessors.

The UX is not going to replace the VX or DX which are still excellent gateways; the VX is more scalable and designed for the more complex and usually larger deployments, with the DX being for smaller deployments.

The fit for the UX appears to be branch offices or medium sized deployments.

Looking into the telephony side of the UX it will support two interface modules allowing for a combination of E1\T1 Ports along with FXS ports.

It will provide full support for features such as Any to Any routing, LDAP based routing logic and Transcoding.

The UX will be capable of providing Transcoding capabilities when used as a SIP Demarcation Device due to it not requiring E1\T1 Line Cards to provide this capability.

The UX will also provides the following:

  • Session Border Controller
  • SIP Registrar
  • IP Router and Switch
  • Application Solution Model (ASM)

The ASM will be a module within the gateway and for all intense purposes will be a standalone server based on the latest Intel i7 architecture. This will be an optional module and will not be required for the gateway to function.

The purpose of the ASM will be to provide a platform for Telephony Applications which would usually run on a separate server, this could include:

  • emFast Fax Solutions
  • FMC Solutions from Tango
  • Microsoft Communications Server Survivable Branch Appliance, announced at Voicecon Orlando 2010

Hopefully this gives an insight into what NET are going to provide at a relatively high level. My aim is to provide a more detailed and technical post as and when more information becomes available.

Sunday, 23 May 2010

Remote Call Control Lives On

At the start of December 2009 I wrote a blog post on how Remote Call Control (RCC) was going to be depreciated in the Wave 14 release of OCS.

This was based on Microsoft and Cisco: Joint Interoperability Support Statement, which was released at the time. This document has now been updated and can be found here.

Within this document is the following statement:

“Remote Call Control is supported by Microsoft in Office Communications Server 2007 and Office Communications Server 2007 R2 and will continue to be supported for both new customers and customers upgrading their Remote Call Control deployments to the next release of Office Communications Server. “

This new statement indicates that RCC will continue to be supported for both new and existing customers compared to the pervious statement which announced the deprecation and support for upgrades only.

This change will certainly have a knock on effect in terms of how people look to deploy Wave 14, how partners have positioned RCC and Wave 14 with existing and potential customers.

When RCC was not going to be supported for new deployments, customers had to make a decision:

  • Deploy OCS 2007 R2 with RCC today and upgrade to Wave 14
  • Not deploy RCC and for all intense purposes keep their PBX and OCS separate
  • Move to Wave 14 as their PBX and move away from the PBX they have today

Customers now have the same options as they did with OCS 2007 R2, which is to continue with their PBX and deploy OCS with RCC, assuming the PBX supports this.

For customers who see the value of using Wave 14 as their PBX this will not stop them moving but for those who want to use the OCS functionality but retain their PBX the decision is now a lot easier.

One thing is for certain, interesting times are ahead.

Sunday, 11 April 2010

Monitor Active Directory LDAP Queries

I recently had a requirement to view the LDAP Queries that Exchange 2010 was running against a 2008 Active Directory Server when a Service Starts.

When the LDAP queries are sent to the Active Directory Server they are encrypted meaning that tools like Wireshark and Network Monitor can’t be used.

In researching into how I could monitor these queries on Server 2008 I came across this blog post. Which describes how to use the Reliability and Performance Monitor (RPM) to monitor Active Directory which includes the LDAP queries.

The results are captured in a file called “Active Directory.etl” and stored in subfolders under “c:\perflogs\ADDS”. When the Capture is stopped, RPM generates a report which contains an analysis of the captured data, including the top 25 LDAP queries.

The top 25 LDAP queries appear to be the most CPU intensive queries, this may be useful for some people but of  little use if you are wanting to view all of the LDAP queries.

Luckily all is not lost all of the queries are stored within the Active Directory.etl filet. Looking into how I could extract information from this file, I found this post. The only slight difference is that I needed to use the –lr flag in order to extract the LDAP queries.  The full command is:

tracerpt -lr "Active Directory.etl""

This produces an XML file called dumpfile.xml and contains all of the captured LDAP queries, unfortunately it does not store the results of the queries.