simonfr

Day 4 - UC Voice Ignite conference – OCS 2007 QoE, Administration, Troubleshooting and more

simonfr — Mon, 11 Feb 2008 16:57:00 GMT

Day 4 (Go here to return to Day 3)

First up on Day 4 we were talking about QoE Server and what this does for our OCS deployment.

Microsoft’s approach to voice quality in OCS is called Quality of Experience. It was explained that QoS and NSQ both focus on the network aspect of voice quality while the QoE focus is on the end user perception of voice quality, which does include the network but it also includes the user environment (background noise), handsets / headsets (payload quality), user psychology, etc.

Very interesting...

QoE uses a combinations of adaptive endpoints that measure and monitor the actual experience for calls. Independent studies have shown that QoE, compared to traditional VoIP solutions in identical network conditions, provides superior Quality of Experience.

QoE comprises :

1. Comprehencsive, user-focused approach to “perceived” quality

2. Intelligent, adaptive endpoint including and advanced media stack

3. Real-time metrics of the actual experience.

NSQ defines what network performance should be for a guarantee of voice quality :

· <150ms (round-trip)

· Packet Loss <1%

· Jitter <100ms

· Bandwidth = 35 – 100kbps per voice stream (based on the codec used.

However these numbers are measured and managed against traditional network behaviour metrics. For instance the Microsoft claim the RTAudio codec can sustain 10% packet loss without significant problems.

To install the QoE Monitoring Server you will need a SQL backend (this can be shared), however you cannot co-locate the QoE front end.

A good thing is that the QoE Monitoring server can report on all OCS pools in your organisation, so you will likely only need to deploy one unless you have unimaginably heavy reporting requirements.

You can find a really good Step-by-step guide for the QoE Monitoring Server from this website <www.microsoft.com/downloads/details.aspx?FamilyId=9ED29D74-3391-4902-BF2C-6757410F3335>

Microsoft has a freely downloadable Deployment Validation Tool for OCS. This tools will allow OCS administrators to test voice quality for Jitter, packet loss, and delay in a point to point scenario. The best scenario is that you have deployed multiple DVT agents to various different strategic areas in your network, and these agents allow you to get a solid understanding about the performance of your network. Microsoft say, the more agents the better !

Something that came up again in todays session is around the Edge Server. The A/V Edge server external IP address must be a publicly routable address. “Why is this so?”, I hear you ask. Well....you need to have a publicly routable address somewhere in the equation in order to allow NAT traversal for all the other clients. OCS's A/V Edge NAT traversal functionality is based on the STUN standard, which was developed under IETF guidance through a multi-vendor working group including Microsoft and Cisco. <http://tools.ietf.org/html/rfc3489, and http://www.voip-info.org/wiki-ICE, and http://technet.microsoft.com/en-us/library/bb870364.aspx> But there’s an easy to read blog that I was directed to by Darin Preston, he stumbled across this gem when planning the Oltiva OCS Edge topology.

Labs

The labs are worth mentioning today as we have been given a “MakeItReal” scenario in which we group up and provide a design for an OCS & Exchange UM deployment. The MakeitReal deliverables included :

· A physical design

o Infrastructure pre-requisites

o By Site

§ OCS

§ Voice Components

§ Perimiter Server

§ Everything in between J

· Dial Plan

o Normalisation Rules for all routes.

I won’t give any information that would spoil the experience. However tomorrow I will share my lessons learned pertaining to this exercise.

Day 3 - UC Voice Ignite conference – OCS 2007 Voice Architecture, Topologies and Infrastructure

simonfr — Mon, 11 Feb 2008 14:55:00 GMT

Day 3 (Day 2 blog is here)

Now we are starting to get to the really good stuff. I made lots of notes on day 3 so I’ll try to limit the post to really juicy bits. Be warned – today was a BIG DAY.

First up Microsoft gave a nice introduction to their “Microsoft Unified Communications Open Interoperability Program”. The qualification program for gateways and IP PBXs ensures that customers have seamless experiences with setup, support, and use of qualified telephony gateways and IP-PBXs with Microsoft's unified communications software. It looks into which hardware is qualified, such as SIP-PSTN gateways and IP-PBXs, and explains the process for telephony infrastructure vendors to join and participate in the program. For a person of the infrastructure persuasion this is a great place to find which vendors are in or out, as far as Microsoft is concerned.

Hybrid Gateway:

· Supports SIP over TLS

· Supports SRTP natively

· Supports RTAudio natively

· Supports ICS for Firewall/NAT

Basic Gateway :

· TCP to TLS

· G.711 to RTAudio and Siren

· Apply SRTP to media on UC side

· Act as an ICE client

The most exiting evolution with OCS supported gateways is the “hybrid“ gateway devices which included the Mediation Server role functionality in the gateway. This was previously a vision, however partners have been busy and brought this into fruition...see here..<http://technet.microsoft.com/en-us/office/bb735838.aspx>

Microsoft took us through the differences in call flow in OCS 2007 when you have a standalone environment (Communicator endpoints) compared to a Co-existence environment (both Communicator endpoint & PBX phone). Below I will give a basic overview of the call flow of an inbound call for both a StandAlone and a Co-Existence configuration. This will demonstrate the difference between the two primary OCS configurations.

Call Flow (Inbound) StandAlone :

· Call routed from PSTN to Media Gateway

· Media Gateway converts to SIP call

· OCS2007 server locates the UC user

· OC 2007 endpoint rings

Call Flow (Inbound) Co-Existence :

· Call routed from PSTN to PBX (not Media Gateway)

· Call is then forked* by PBX to OCS Servers

· User decides which endpoint to pickup (either OC 2007 or PBX phone)

What I was trying to show is that the term Co-Existence refers to the endpoint to which the call will be routed. So you are looking at the end user experience to determine whether it will be StandAlone or Co-Existence.

*The term ”forked”; refers to the point at which a call will split to reach another registered endpoint for the target user.

I'll just do a quick sideways jump to User provisioning. When provisioning users for OCS it’s best to have the numbers already in Active Directory. In the perfect scenario the numbers are present in AD are already in E.164 format. However about 90% of the time that’s not the case, there will be spaces and special characters all over the place and even worse they may not be consistent. OCS doesn't look at the regular Active Directory phone attributes; instead it looks at the msRTCSIP-line attribute. You can populate the msRTCSIP-line attribute from the standard telephone AD attribute, but as I said, its best normalize the numbers to E.164 format first. <http://technet.microsoft.com/en-us/library/bb870372.aspx>

The OCS Resource Kit provides some sample scripts to help you get past this issue with relative ease. WMI is the weapon of choice for writing user provisioning scripts -- this allows you to do it in the language of your choice, including PowerShell (via PowerShell's WMI provider). We got a demo of this and a few people were escorted out of the building due to excessive drooling.

<http://www.microsoft.com/downloads/details.aspx?FamilyID=b9bf4f71-fb0b-4de9-962f-c56b70a8aecd&displaylang=en and http://blogs.technet.com/jamesone/archive/2007/08/19/powershell-and-paradigms-of-vb.aspx>

RTP (Realtime Transport Protocol, not RealTime Protocol as many people think). Many hours have gone into RTP and the result is a very robust protocol. We did talk a lot about the comparative size of the header and payload being a distorted, especially once you get all the UDP, IP, and physical link overhead in there. Here’s some links to remind you what I’m referring to. <http://tools.ietf.org/html/rfc3550 & http://forums.microsoft.com/unifiedcommunications/ShowPost.aspx?PostID=2697675&SiteID=57>

OCS 2007 - Update Service

I haven’t read much about this role so far but they covered it in a fair amount of detail here, in terms of what it’s used for and the infrastructure requirements for deployment.

Basically this role is present to manage the OCS support devices that are slowly being released into the environment. For example with the Avanade OCS TAP there are a few Tanjay phones (Nortel IP8540 & Polycom CX700) loose in the environment, how are those devices managed ? Ahh...OCS 2007 Update Service! This service works with WSUS to download firmware releases, which come in the form of an image, and then schedule a deployment to the device. There are a few limitations with the flexibility of how and when these updates are deployed, but the job gets done.

To include an Update Service role into your OCS deployment you will need the following :

· Update Server role is installed onto your OCS Web Component Server

· Mgmt Console Web Site (FQDN)

· WSUS Server or Automatic Downloads of updates

· Windows SharePoint Services (WSS) (not MOSS), to store the firmware images, logs, and internal configuration information of the devices. (must be on a separate server to the Web Component Server role)

The big surprise for me, initially, was around WSS being a requirement for the Update Service, however when you think about it is an efficient and well known document management system. It provides a good level of reporting and management of the devices and it’s free.

The later parts of the day focus on Remote Access, Voice Security and finally, everyone’s favourite Certificates, Port, DNS Requirements

EDGE Servers

The Edge Server Role can be complex one, there was plenty of discussion about this role and it’s many functions. Much of the discussion was around design, supportability and best practices.

Each of these server roles can be hardware load balanced. One point that Microsoft highlighted has come up in prior Ignite sessions is -- You can't load balance a consolidated single server (all three Edge roles) configuration – I found that quite funny, because this would be one server and that defeats the purpose of load balancing. While Load Balancing in a consolidated Edge topology maybe a little bit funny, in most large scale deployments you will be looking to scale out the Edge server role and a hardware load balancer will need to be incorporated (ie. Scaled Single-Site Edge Topology / Multiple Site with a Remote Site Edge Topology / Multiple Site with a Scaled Remote Site Edge Topology).

This link has some further information about the supported Edge topologies.

<http://technet.microsoft.com/en-us/library/bb663789.aspx>

In Day 5 we talk a little about sizing an Edge Topology according to a Usage model. The usage model we used in our fictitious MakeItReal Lab (I can’t stress the word fictitious more) should NOT be used. However it will help reveal some calculations for Edge sizing.

Access Edge Server role

ISA is important.

While a reverse proxy (such as ISA) is not a required part of the whole remote access deployment, without it you will lose functionality from external clients that aren't using a VPN connection. Some of this functionality loss includes:

· Expanding AD groups and get their memberships

· Downloading the address book

· Download meeting content in Live Meeting conferences.

By reverse proxy, think something like ISA 2006 (recommended) or other equivalent applications or appliances.

More info...<http://technet.microsoft.com/en-us/library/bb803627.aspx>

The Access Edge server does not perform authentication of incoming remote connections. It does provide validation of incoming SIP requests (filtering out requests to invalid SIP URIs, etc.), but not authentication. Authentication happens either by the OCS Standard Edition server, the OCS Enterprise Edition Front-End pool, or the optional (but highly recommended) Director role. In my mind, the Director role is just a way to off-load authentication responsibilities from the Pool. Director roles can be load balanced for greater reliability. (source http://technet.microsoft.com/en-us/library/bb663752.aspx)

When using an Access edge server role, its best practise to use a certificate from an approved Public X.509 certification authority. If you want find the latest and greatest list of UC-compatible certificates, Exchange 2007 inclusive, check out <http://support.microsoft.com/kb/929395>. This site is a good starting point when you are trying to gather information about certificates.

I thought I should just comment on some Edge Server Security Deployment best practises such as; to Deploy Edge servers in their own subnet and control routing to and from this Edge subnet. Provide physical separation of internal and external networks. Edge servers do not need to be a member of the domain so deploy them in a workgroup. Also try to follow Microsoft’s server hardening best practises, such as remove/disable unnecessary services.

What a nice transition to security J

Security

Office Communications Server 2007 is Security & Trustworthy by:

Design – Developed under the Security Development Lifecycle

Default – Communications – signalling and media – are encrypted by default (except between the mediation server and basic media gateway)

Deployment – Security best practices are provided in planning and deployment guides.

Threats to OCS 2007 Communications certainly exist, however a combination of the 3 D’s (above) and Microsoft’s best practises result in most of these threats being a non-issue. Just a few of the threats I’m referring to are:

· Comprised-key attack

· Network denial of service attack

· Eavesdropping

· ID spoofing

· IP spoofing

· Viruses & worms

The edge server roles are the potential front line against most of these threats so it’s very important to follow the security best practise guide - <www.microsoft.com/downloads/thankyou.aspx?familyId=2d1ea693-25e0-43d9-8c5c-0822ef83955a&displayLang=en>

I’ll leave you today, with an image that shows the ports and firewall requirements for OCS, it’s very busy but I like it.

Day 2 - Unified Communications (UC) Voice Ignite Program - Voice Design

simonfr — Mon, 11 Feb 2008 11:05:00 GMT

Day 2. (Day1 blog is here)

Today’s focus is all around Voice Design. First cab off the ranks is the telephony lingo & then dialling requirements.

Microsoft gave a really good description of E.164 -- it's a format for manipulating phone numbers to become globally unique. When designing an OCS infrastructure substantial time needs to go into a plan for normalising dialled numbers (and extensions) into E.164 format so that the call commonly understood and can be routed outside of the organisation to a PSTN.

Exchange 2007 RTM didn't support E.164 dial plans, but SP1 does.

<http://technet.microsoft.com/en-us/library/bb803637.aspx and http://technet.microsoft.com/en-us/library/bb676323.aspx>

The new codec with OCS 2007 is RTAudio. This codec can be both wide or narrow band (WB/NB), and the WB codec used on average 45Kbps bandwidth per channel. This figure doesn't take into account the various network overhead components. For planning it’s more accurate to use 57Kbps as your average planning number for each one-way channel -- 57Kbps send and 57Kbps receive for each endpoint. While this may seem like a lot, in a typical conference 80% of the time only 1 person speaks (57kbps), 7% of the time 2 people speak (74kbps) and 13% of the time nobody speaks (almost 0kbps – empty RTP). However, be sure to plan on 57kbps, especially if you have different upstream/downstream capabilities! The estimations for signalling traffic are not included in the figures we were given, hence this will affect the estimation in a constrained network environment. <http://forums.microsoft.com/unifiedcommunications/ShowPost.aspx?PostID=2697675&SiteID=57> -- this is not an “official“ guide, but the calculations are there and include the overhead so check it out; the official planning guide still has the numbers that don’t account for overhead, and the overhead can change based on network conditions. These numbers can be reduced further if you use silence suppression, however this can affect the end user experience.

CODEC	MIN	MAX	PLANNING
RTAudio (conf)	24kbps	74kbps	57kbps
Siren (conf)	22kbps	48kbps	48kbps
RTVideo (Video – VBR mode)	50kbps	320kbps	320kbps

E.164 is an ITU standard for normalizing phone number, as mentioned before. However, RFC 3966 defines the tel: URI scheme, which is basically a superset of E.164. E.164 applies only to public numbers; RFC 3966 applies to private numbers as well. Anytime you see a tel: prefix on a number in OCS, you're dealing with RFC 3966. <http://www.ietf.org/rfc/rfc3966.txt, http://en.wikipedia.org/wiki/Telephone_number, and http://en.wikipedia.org/wiki/URI_scheme>

OCS 2007 normalization rules use .NET regular expressions, the OCS 2007 Resource Kit provides some great tools for this job – the main gun in the arsenal is the Enterprise Voice Route Helper, which includes a normalization tool that helps you build your regular expressions. It also allows you to input other organisations configuration to assist them remotely with normalisation and routing issues. *very nice* <http://www.microsoft.com/downloads/details.aspx?FamilyID=b9bf4f71-fb0b-4de9-962f-c56b70a8aecd&displaylang=en>

PSTN breakout is a cool process -- use VoIP across your network, then break out the call to the PSTN at your location closest to the destination so you reduce or eliminate long-distance costs. OCS achieves this through the use of strategically placed mediation servers. However, in some cases the countries laws prevent you from doing so -- in India, for example, you must be registered as an ISP in order to switch calls back onto the PSTN from VoIP; point to point Communicator calls are just fine. <http://www.microsoft.com/downloads/details.aspx?FamilyId=24E72DAC-2B26-4F43-BBA2-60488F2ACA8D&displaylang=en and http://www.ilocus.com/2008/01/bsnls_voip_will_kill_the_grey.html>

This fact reminds me of something....If your OCS 2007 infrastructure spans regions be very clear on the laws and regulations that are enforced in each country – Do your research !

The labs that were constructed allowed us to further familiarise ourselves with Dial Plans, and call routing. Also we get to look at how to configure a dial plan to break-out to a PSTN – which in our case is just an analog FXS port on a Audiocode MP-114 gateway. *easy peasy*

For Day 3 blogs go here -> Day 3 - UC Voice Ignite conference – OCS 2007 Voice Architecture, Topologies and Infrastructure

Day 1 - Welcome and Overview of Unified Communications (UC) Voice Ignite Program

simonfr — Wed, 06 Feb 2008 23:06:00 GMT

Day 1 (Intro is here)

At 9am the session begins and we received a nicely articulated overview of Unified Communications (UC) Voice focused on 3 segments of UC:

Exchange Server 2007 Service Pack 1, Unified Messaging (UM)
Office Communications Server 2007 Voice
Office Communications Server 2007 Conferencing

During the aforementioned segments I learned that the Exchange UM role cannot detect a fax tone of an incoming call, this was left to the IP-Gateway to differentiate the calls and route to the UM where it would renegotiate to T.38. Since the release of SP1 for Exchange 2007 this has changed and the UM role will detect fax tone, but is off by default. http://technet.microsoft.com/en-us/library/bb691398(EXCHG.80).aspx

Unified Messaging doesn't support IPv6 in any version of Exchange 2007. Unfortunately even now with SP1, despite the impressive list of improvements in Exchange 2007 Service Pack 1. This is primarily due to limitations with existing PBX and VoIP standards.

Here is another valuable link that contains information about the improvements included in Exchange 2007 SP1 pertaining to IPv6. http://technet.microsoft.com/en-us/library/bb629624(EXCHG.80).aspx

Labs:

I was quite impressed with the performance of the lab environments, I don’t think we have had any mishaps that I was aware of. From memory each lab consisted of 2 x HP Laptops with approx 3GB of RAM, and a zippy internal drive, AudioCode MP-114 (FXS-FXO) VoIP Gateway, and a Gigabit Switch.

The FXS ports in the VoIP gateway were used to emulate an outbound PSTN connection or PBX etc.. To perform some promiscuous mode network monitoring we used X-Lite Softphone registered to a OnDO Sip Server, this way we could saved us some time by evaluating the SIP traffic without reconfiguring OCS to use TCP rather than TLS.

Next segments were based on:

UC Vision and Deployment Scenario
UM Architecture and Technologies
UM Deployment and Configurations

Next segments were based on:

UM SP1 and SIP

Dial Plans

Troubleshooting

VoIP Gateway selection is critical when planning a deployment for both Exchange 2007 UM and OCS 2007. Careful consideration needs to go into VoIP Gateway selection, and certification should be checked prior to acquisition. Dialogic provides, at present, the only gateway certified for both applications. Looking forward to future devices being available in which can cater for this need.

In formation surrounding these devices and compatibility can be found here: http://www.microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx and http://technet.microsoft.com/en-us/office/bb735838.aspx#qualified

This guide is also useful if you need to research a particular type of IP-PBX for compatibilities and/or limitations. It’s hard to state anything factually in a blog about compatibility due to the speed in which these guides are being updated.

Hint: Keep your finger on the pulse of those sites.

Afternoon SIP Protocol Hands-on Labs

SIP and UM Hands-on-Labs
Voice Deployment Scenarios

Four Scenarios

Telephony Interoperability (Gateways and PBXs)

Mediation Server

Day 1 was a ripper looking forward to posting the content about Day 2.

For Day 2 blogs - see here -> Day 2 - Unified Communications (UC) Voice Ignite Program - Voice Design

Microsoft Voice Ignite in Sydney

simonfr — Wed, 06 Feb 2008 20:33:00 GMT

I have been lucky enough to attend the Microsoft's Voice Ignite on behalf of Avanade at the Sydney Convention Centre. The event entails 5 hard core technical days on Office Communication's Server and the voice component. A huge range of topics presented by great individual presenters such as Rafael Reyes, Byron Spurlock, Doug Lawty and Brendan Carius to name a few brilliantly talented OCS guru’s. Microsoft's OCS team have done a stunning job with this training, and so far I have been very impressed with the content in the presentations and the labs.

Seeing as I'm one of four Avanade people to attend the conference I thought it would be an injustice not to compose my first ever blog, and try to enlighten you to some of the more interesting tid-bits that have come into fruition.

Just to clarify, I will not be posting anything that can't be verified from publicly available material from Microsoft, there was a very clear message from Microsoft about the NDA’s associated. *Respected*

Also please be aware there were strict training pre-requisite if you were attending this advanced technical workshop, in fact Microsoft estimated approximately 15 hours in total to complete all courses :

• OCS Ignite HOLOs - 8 hands-on-labs online, all need to be completed to meet the pre-requisites. Allow about 8 hours (1 hour per lab). Additional presentations to support the labs can be found here under Training.

• UM Power Up HOLOs and Online Tutorials – 3 labs and 4 tutorials, all need to be completed to meet the pre-requisites. Allow about 7 hours (.5 hour per lab, 1-2 hours per tutorial).

I will try to keep the blog atuned to all levels, however if I have to keep changing down gears I'll be blogging all day, so please forgive me if you get lost. --BTW, the above courses are all available through the Microsoft Partner program, see the associated links - or <here> under training.

Let the blogs begin - Day 1 - Welcome and Overview of Unified Communications (UC) Voice Ignite Program