As the OCS development team is hardening the next version of OCS, the planning team is looking ahead to the version which will follow. In this version we’d like to take a step back and verify what are the core everyday challenges and perspectives of those of you who use our product. To do this we have created a survey to capture information about your daily needs and your thoughts on how you would like the features in OCS to be organized. We are looking to collect input from all of you and would greatly appreciate hearing your input.

Please use this link to access the survey and share your perspectives with the team OCS Survey. This survey will be available until 8/25.

The survey should take about 15 minutes to fill out. Please send any feedback about the survey to Kathy.Fraser@microsoft.com.

The July 2008 update for Communicator 2007 has been released -

http://support.microsoft.com/?kbid=954439

NOTE: This update replaces the following update: 951662 (http://support.microsoft.com/kb/951662/) Description of the update for Communicator 2007: April 30, 2008

UC-RTC Sustained Engineering

Unisys recently put out a press release announcing the UC Hosted Trial, and I wanted to give some additional behind-the-scenes information on what we’re doing here.  This is a system managed by Unisys that lets Microsoft and Unisys field sales sign up our customers for a trial of Microsoft’s unified communications technologies, including Microsoft Exchange Server 2007 and Microsoft Office Communications Server 2007.  We’ve been using the trial both internally and externally for several months now, and it’s gotten some great feedback and customer usage – nearly 800 30-day accounts have been created.  In this post, I’m going to talk about what the trial is in a bit more detail and how it all works.

The UC hosted trial is designed to give customers the ability to experience firsthand the power of Microsoft’s UC products without having to download or install a trial version of the server software in a lab environment.  All the end-user features available from Exchange Server 2007 and Office Communications Server 2007 that we could possibly offer are available in the trial.  Participants in the trial use Outlook 2007 for mail, calendaring and unified messaging and Office Communicator 2007 for instant messaging, web conferencing, and voice calling, with everything working against Microsoft software running in Unisys’ Reston, VA datacenter.  Participants can have up to 20 accounts on the trial and the trial lasts for 30 days.

All this is made possible through the great remote access capabilities of Exchange Server and Office Communications Server.  Both products fully enable users connecting remotely from the server infrastructure.  In a typical company, this may be people working from home or on the road.  We use the same elements in the hosted trial, as without them we would either have our total user pool be limited to those working in the Unisys data center or all participants would need VPN access – neither are particularly compelling options for a trial designed to be both easy to use and worldwide in scope.  Unisys has ‘edge’ components for Exchange and Office Communications Server deployed in their data center’s DMZ, and that allows anyone with an account to connect up from anywhere in the world.  Even better, when companies deploy Microsoft’s UC products, they’ll have the same great remote experience – it just works, on the LAN at corporate or on the Wi-Fi network from your hotel in Taipei.

Moving on with the deployment, Unisys has these systems running on their ES-7000 line of servers, with one cell dedicated to Exchange, one to Office Communications Server, and others to the variety of ancillary products (SharePoint Server, System Management Server, Reporting, etc.) that are use for other services, administration and maintenance.  The solution is conservatively sized for about 5,000 concurrent users, and essentially we’re way over-provisioned on the hardware front – the Unisys servers are designed for scale and it handles the workloads like a champ.  And of course, reliability hasn’t been an issue for us at all.

What really matters though is how this translates into the trial participant experience.  This begins with provisioning, or when a Microsoft or Unisys sales person creates the accounts on the hosted trial using a web form.  The sales person enters in the names of the participants and optionally their work phone numbers, or uploads a simple spreadsheet with the same information.  A custom workflow process developed by Unisys then kicks off and creates all the user accounts, their mailboxes and their settings for Office Communicator.  This single process to create a user in our “faux enterprise” is one of the great benefits of Microsoft’s UC products for real enterprises as well.  One can quickly link Exchange and Office Communications Server with other business processes such that automating the creation of a user’s communications resources is linked right into Active Directory and can be automated along with account creation.  So no more waiting to get a new employees phone turned on!

The provisioning for our trial also creates a “sandbox” in Active Directory, ensuring that while there are many trials going on in the server at once, participants can only see accounts created for their company.  Because Office Communications Server 2007 doesn’t support multi-tenant hosting capability, this required some pretty fancy Active Directory footwork - once again a statement to the power of the platform, but more so to Unisys’ excellent custom coding work.

So now that there are accounts provisioned on the trial, the Microsoft or Unisys sponsor gets an email from the provisioning system with all the account information for the newly created users.  The sponsor just forwards those mails to the participants who then download and install the client software - Outlook 2007 and Office Communicator 2007, both of which are available in 120 day trial downloads.   After signing in, they get a fully functional messaging and communications environment.  They can send email, instant message, make voice and video calls, collaborate and much more….

Connectivity to the phone system is one part of the trial that we’re quite proud of because it lends a lot to the experience.  In the trial we offer inbound calling to trial users using Exchange Unified Messaging’s Auto-Attendant feature – by dialing a single number you can reach anyone in the trial just by speaking their name.  Then for US-based customers, we also have enabled making outbound phone calls to any phone number in the US.  This is done using SIP-PSTN Gateways from Quintum Technologies LLC, a subsidiary of Network Equipment Technologies – their press release on the hosted trial can be found here.  Since the Quintum Tenor gateways are qualified in the Microsoft Open Interoperability Program, it was a snap to plug them into PRI lines from the carrier serving the data center and connect the gateway into the OCS deployment.  In addition, voice quality is consistently great – whether listening to messages over Exchange UM or forwarding calls to your cell phone.

So now the participants are up and running on the trial and doing things like using Exchange Server’s smart calendaring capabilities to schedule conference calls on Office Communications Server.  The Microsoft or Unisys sponsor can now communicate with them in a totally different way – using Federation.  The Hosted UC Trial is federated with our corporate deployments of Office Communications Server, so sponsors can add their trial participants to their Office Communicator “buddy list”, see when they are online, and communicate with them using an encrypted connection through the internet.  Even better, these calls use the same great sounding wideband audio codec as internal calls, and can include video as well.  So now an audio-only conference call that used to be run on a bridge can now include IM, video and web collaboration.

While we certainly are happy that the trial shows off our products quite well, this really highlights the great work our partners do.  The expertise at Unisys and Quintum made this trial possible, building on our UC platform and turning it into a great solution - just like our hundreds of UC & voice partners do every day for deployments worldwide.

So if you have had any interest in Exchange Server 2007 or Office Communications Server 2007 but the issues of finding lab space, hardware or time to install the server software has prevented you from checking it out, then definitely ask your Microsoft or Unisys sales person about the Hosted UC Trial.  In less than a day, you and your colleagues can experience all the great end-user features that Microsoft’s unified communications products have to offer.  And once you do, use that federated link to send me an IM or make a video call and let me know what we can do to make the trial better!  I’m at sip:jastark@microsoft.com

Jamie Stark
Sr. Technical Product Manager
Microsoft Unified Communications

Update for Communicator 2007 Phone Edition - July 2008 (KB952693) has been released to the Microsoft download center. http://www.microsoft.com/downloads/details.aspx?FamilyID=eeb1b339-df7e-486f-a47a-23d7ed8be6fd&DisplayLang=en

Description of the Communicator 2007 Phone Edition update: July 2008 http://support.microsoft.com/?kbid=952693

Note:  Released for English as well as all the other localized languages (Dutch, French, German, Italian, Japanese, Korean and Spanish)

UC-RTC Sustained Engineering

Determining Health and Wellness of an OCS Deployment – Web Conferencing and MCUs

Multi-point Control Units for Web Conferencing and Audio & Video.. How do IT Admins determine if these servers are staying healthy? As I explained in my previous blog in order to implement a comprehensive monitoring plan, the real trick is how to tell proactively when MCU server health is starting to decay. MCUs can be collocated on OCS 2007 Standard Edition servers and most large Enterprise Edition customer deployments have several dedicated Audio/Video MCUs, Data Conferencing MCUs and may have IMMCU services running on multiple Frontend servers which I’ve already covered in the post for IM and Presence.

What new information am I covering here?
In addition to listing a good mix of Performance Monitor counters as recommended by the product team below, I’m covering new ground by identifying certain Microsoft Operations Manager thresholds to watch for as MCU health degrades to know exactly when to take remedial actions. Also below are a set of perf counters for A/V and Web Conferencing MCU server roles, some with thresholds that if reached, should trigger action on the part of an Administrator. The resource utilization, user load and server health counters below are directly applicable to Web Conferencing and A/V MCU functionality. As I said in Part 1, IT Admins will need to run resource utilization and user load baseline tests first to determine what is “normal” for their specific deployments. Then once baseline numbers are known for each server role, they’d add applicable health monitoring counters to the overall monitoring scheme and proceed from there.

“Snooping” on your MCUs can be very helpful to enhance a complete strategic monitoring plan.

I was surprised to find out you can run the Snooper tool in the OCS 2007 Resource Kit to perform a diagnostic report on MCUs to determine the state of server health and to identify diagnostic events. Among other useful things it does, Snooper can be used for error analysis. Information can be retrieved about all MCUs in the deployment and a complete diagnostic overview can be obtained. The MCU Health report can be particularly useful because including showing ID, media type, URL and heartbeat status, this report also shows server statistics that can be used to determine MCU load using of number of assigned conferences per MCU and number of connected participants. Snooper’s a great tool but it’s always a good idea to first review event logs and the MMC overviews for all MCUs for clues before starting an in-depth troubleshooting investigation using tools like Snooper.

Figure 1: Screenshot of Snooper UI
From the ‘Reports’ menu select, ‘Conferencing and Presence Reports’ and then from the ‘Report’ drop down list (as below) select, ‘MCU Health’.

Recommended baseline counters to test and monitor resource utilization:

Processor; % Processor Time (_Total) [should operate at less than 80% during peak load] (run on each MCU)

Network Interface; Bytes Total/sec ([your NIC]) [should operate at less than 80% capacity of the NIC] (run on each MCU)

*Memory; Pages/sec (---) (run on each MCU)
*Process; % Processor Time (DataMCUSvc)

*Process; % Processor Time (AVMCUSvc)

*Process; Private Bytes (DataMCUSvc) ([peak])

*Process; Private Bytes (AVMCUSvc) ([peak])

· Physical Disk counters are not applicable to MCU functionality

· Pages/sec indicates total “pressure” on the server’s available memory

· No documented baseline rules for individual process or memory utilization

· Network Interface example: 100Mbit/sec NIC should be <80%x12.5Mbytes/sec ~ <10Mbytes/sec

 

Recommended baseline counters to test and monitor user load:

Audio/Video and Web Conferencing MCU: (monitor on each MCU)

AVMCU – 00 - Operations; AVMCU – 000 – Number of Conferences ----

AVMCU – 00 - Operations; AVMCU – 001 – Number of Users ----

LC:DATAMCU – 00 – DataMCU Conferences; DATAMCU – 000 – Conferences ----

LC:DATAMCU – 00 – DataMCU Conferences; DATAMCU – 002 – Connected Users ----

LC:SipEps – 01 – SipEps Transactions; SipEps – 002 – Incoming Transactions Processed ----

LC:SipEps – 01 – SipEps Transactions; SipEps – 003 – Incoming Transactions Processed/sec ----

 

Recommended counters to monitor for server health:

Audio/Video Conferencing MCU: (monitor on the AV MCU)

MEDIA – 00 - Operations; MEDIA – 000 – Global Health ----

MEDIA – 00 - Operations; MEDIA – 001 – TCP disconnects because remote out of sync ----

MEDIA – 00 - Operations; MEDIA – 002 – Relay allocation failures ----

MEDIA – 00 - Operations; MEDIA – 003 – Number of packets dropped by Secure RTP/sec ----

MEDIA – 01 - Planning; MEDIA – 003 – Number of conferences with NORMAL health ----

MEDIA – 01 - Planning; MEDIA – 004 – Number of conferences with OVERLOADED health ----

MEDIA – 01 - Planning; MEDIA – 005 – Number of packets dropped in flow control ----

MEDIA – 01 - Planning; MEDIA – 006 – Number of failed end to end connectivity checks ----

MEDIA – 02 - Informational; MEDIA – 006 – Average time spent in processing audio packets ----

MEDIA – 02 - Informational; MEDIA – 009 – Conference process rate ----

AVMCU – 04 – MCU Health and Performance; AVMCU – 003 – Thread Pool Health State ----

AVMCU – 04 – MCU Health and Performance; AVMCU – 005 – MCU Health State ----

Web Conferencing MCU: (monitor on the Data MCU)

LC:DATAMCU – 02 – MCU Health and Performance; DATAMCU – 002 – Thread Pool Load ----

LC:DATAMCU – 02 – MCU Health and Performance; DATAMCU – 003 – Thread Pool Health State ----

LC:DATAMCU – 02 – MCU Health and Performance; DATAMCU – 005 – MCU Health State ----

LC:DATAMCU – 02 – MCU Health and Performance; DATAMCU – 006 – MCU Draining State ----

Peers/HTTPS Transport/Focus Factory/Focus: (monitor on the Frontend servers)

LC:SIP – 01 - Peers; SIP - 024 – Flow-controlled Connections Dropped (_Total)

LC:SIP – 01 - Peers; SIP - 025 – Average Flow-Control Delay (_Total)

LC:USrv– 20 – Https Transport; USrv – 002 – Number of failed connection attempts ----

LC:USrv– 20 – Https Transport; USrv – 003 – Number of failed connection attempts / Sec ----

LC:USrv– 20 – Https Transport; USrv – 015 – Number of outgoing requests that timed out ----

LC:USrv– 20 – Https Transport; USrv – 016– Number of outgoing requests that timed out / Sec ----

LC:USrv– 22 – Conference Focus Factory; USrv – 000 – Add Conference requests ----

LC:USrv– 22 – Conference Focus Factory; USrv – 007 – Add Conference requests succeeded ----

LC:USrv– 23 – Conference Control; USrv – 018 – Local C3P success responses ----

LC:USrv– 23 – Conference Control; USrv – 019 – Local C3P pending responses ----

LC:USrv– 25 – Conference Mcu Allocator; USrv – 009 – Factory Unreachable Failures ----

LC:USrv– 25 – Conference Mcu Allocator; USrv – 010 – Factory Calls Timed-Out ----

LC:USrv– 25 – Conference Mcu Allocator; USrv – 016 – Create Conference Mcu Unreachable Failures ----

LC:USrv– 25 – Conference Mcu Allocator; USrv – 017 – Create Conference Requests Timed-Out ----

OCS 2007 MOM Pack thresholds from the documentation:

AVMCU - 000 - Number of Conferences [t1] (Warning) (Threshold) (The number of active conferences on the A/V Conferencing Server)

Numeric Threshold Rule triggered when the sampled value is greater than 5001

Causes: The number of active conferences has far exceeded the expected usage and new conferences cannot be created.
Resolutions: If this high number of active conferences persists then the service should be restarted and logging enabled to identify if the rate of conference creation is in line with expected usage.
AVMCU - 004 - Total Picture Freeze/Fast Update Request Sent (Sample)

Numeric Threshold Rule triggered when the sampled value is greater than 1

The current health of the MCU. 0 = Normal. 1 = Loaded. 2 = Full. 3 = Unavailable.

Causes: MCU is overloaded.
Resolutions: This could happen if too many conferences are assigned to this MCU.

(Sample Intervals for all performance counters listed above is: 15 minutes)

DATAMCU - 041 - Session queues state (Warning) (Threshold) (The state of the session queues)

Numeric Threshold Rule triggered when the sampled value is greater than 2

Causes: Data MCU is over loaded.
Resolutions: This should be a temporary condition. If this condition persists, please provision more Data MCU machines to handle the load.

DATAMCU - 041 - Session queues state (Sample) (The state of the session queues)

Numeric Threshold Rule triggered when the sampled value is greater than 1

Causes: MCU is overloaded.
Resolutions: This could happen if too many conferences are assigned to this MCU.
(Sample Intervals for all performance counters listed above is: 15 minutes)

USrv - 004 - Outstanding C3P transactions (Sample) (Per-second rate of CCCP requests sent to MCU that timed out)
Numeric Threshold Rule triggered when the changes in values over 2 samples is greater than 100

Causes: This can happen if the Server and/or one or more MCU(s) in the Pool are overloaded. This can also happen due to Load Balancer and Network connectivity issues.
Resolutions: This might be a temporary condition. If the problem persists, please ensure that hardware and software requirements of the Pool meet the usage characteristics and that the network is functioning correctly.

USrv - 004 - Notifications in processing (Sample) (The average time [in milliseconds] taken to complete a MCU factory call)

Numeric Threshold Rule triggered when the sampled value is greater than 5000

Causes: The Mcu factory might be busy and may not respond immediately.
Resolutions: This might be a temporary condition. If the problem persists please ensure that the hardware and software requirements meet the user usage characteristics.
USrv - 011 - Factory Call Latency (msec) (Error) (Threshold) (The average time [in milliseconds] taken to complete a MCU factory call)

Causes: The Mcu factory might be busy and may not respond immediately.
Resolutions: This might be a temporary condition. If the problem persists please ensure that the hardware and software requirements meet the user usage characteristics.

USrv - 011 - Factory Call Latency (msec) (Sample) (The average time [in milliseconds] taken to complete a create conference call)

Numeric Threshold Rule triggered when the sampled value is greater than 5000

Causes: The Mcu or Backend might be busy and may not respond immediately.
Resolutions: This might be a temporary condition. If the problem persists please ensure that the hardware and software requirements meet the user usage characteristics.

USrv - 013 - Average Outgoing Queue Delay (ms) (Sample) ( Number of C3P transactions currently in processing)

Numeric Threshold Rule triggered when the changes in values over 2 samples is greater than 1000

Causes: This can typically happen if the Server and/or one or more MCU(s) in the Pool are overloaded.
Resolutions: This might be a temporary condition. If the problem persists, please ensure that hardware and software requirements of the Pool meet the usage characteristics

USrv - 019 - Create Conference Latency (msec) (Error) (Threshold) (The average time [in milliseconds] taken to complete a create conference call)

Causes: The Mcu or Backend might be busy and may not respond immediately.
Resolutions: This might be a temporary condition. If the problem persists please ensure that the hardware and software requirements meet the user usage characteristics.

USrv - 019 - Create Conference Latency (msec) (Sample) (The average time [in milliseconds] taken to complete a full Mcu allocation request)
Numeric Threshold Rule triggered when the sampled value is greater than 10000

Causes: The Mcu factory or Mcu or Backend might be busy and may not respond immediately.
Resolutions: This might be a temporary condition. If the problem persists please ensure that the hardware and software requirements meet the user usage characteristics.

USrv - 021 - Allocation Latency (msec) (Error) (Threshold) (The average time [in milliseconds] taken to complete a full Mcu allocation request)

Causes: The Mcu factory or Mcu or Backend might be busy and may not respond immediately.
Resolutions: This might be a temporary condition. If the problem persists please ensure that the hardware and software requirements meet the user usage characteristics.

USrv - 029 - Transactions Timed-Out / sec (Warning) (Threshold) (Per-second rate of requests sent to MCU that timed out)

Causes: This can happen if the Server and/or one or more MCU(s) in the Pool are overloaded. This can also happen due to Load Balancer and Network connectivity issues.
Resolutions: This might be a temporary condition. If the problem persists, please ensure that hardware and software requirements of the Pool meet the usage characteristics and that the network is functioning correctly.
(Sample Intervals for all performance counters listed above is: 15 minutes)

MCU Health is monitored internally by the Pool itself so unhealthy or overloaded MCUs will not be used.

In OCS 2007 the ‘MCU Factory’ component running on the Frontends is responsible for monitoring MCU “health status” and supplying the best available MCU for use during conference creation, whether it is for audio/video conferencing or web conferencing. When an MCU service starts up, it begins sending “health notifications” every 15 seconds to the ‘MCU Factory’ to advertise its ability to take on new conferences or not. So the ‘MCU Factory’ actually keeps a dynamic list of available MCU’s for the corresponding modality (A/V, Data Conferencing) for use in servicing requests and chooses between available MCUs when Conferences are created.
When a request comes in, the actual selection criteria for an MCU is based partly on the overall health of the MCU. (e.g. Normal= healthy; Loaded=marginal; Unavailable=maximum reached or server down) But selecting an MCU is not based solely on its health but randomness is introduced into the selection algorithm to minimize the risk of repeated selection of a single MCU to host most of the conferences.

TechNet resources and whitepapers with more information on MCUs:

· TechNet Virtual Lab: Deploying and Configuring Microsoft Office Communications Server 2007
More detailed information on the proper deployment of Web Conferencing and Audio/Video MCUs.

· TechNet Labcast On-Demand: Configuring and Using Conferencing in Microsoft Office Communications Server 2007

More detailed information on configuration, usage and administration of Web Conferencing.

· TechNet Webcast: Implementing Instant Messaging/Presence and Conferencing in Microsoft Office Communications Server 2007 (Level 200)

More in-depth information on the proper deployment of Web Conferencing and Audio/Video MCUs.

· TechNet Virtual Training On-Demand: Module 3- Configuring and Using Conferencing in Microsoft Office Communications Server 2007

More detailed information on Conferencing configuration and usage.

· Designing for Adoption: Real-Time Audio in the Real World, Media Technologies for VoIP Applications
Detailed design document for real-time audio in OCS 2007 Voice deployments.

For an in-depth resource on Office Communications Server 2007, including detailed troubleshooting tips, refer to the Office Communications Server 2007 Resource Kit, especially Chapter 13: “Monitoring,” available from MS Press at: http://www.microsoft.com/MSPress/books/10482.aspx.]

Stu Osborn. Stu prepared the content for this post prior to transferring to Unify²

Determining Health and Wellness of an OCS Deployment – IM and Presence

As an IT Admin, how do you know when end user experience will start to suffer and which Performance Monitor counters should you be monitoring to ensure your users continue to have a quality experience? Also, how would you predict degradation of user experience proactively?

My colleague Pauline already has an excellent UC blog on this subject. Great stuff... She concentrates on the Front end server role and its interaction with the pool’s SQL Back end server. But there are hundreds and hundreds of separate Performance Monitor counters for Office Communications Server 2007 and most deployments include several other server roles besides Front end and Back end. Current guidance on this subject from the product team includes: administration guides, deployment guides, planning guides, technical reference guides and the like..
But what am I offering new here?

Well, this blog has new information about how to determine server health. In addition to listing Perfmon counters as recommended by the product team, I identify certain thresholds so you can see when health is degrading and exactly when to take action! I also recommend a three-pronged approach to this task by “polling”, “monitoring” and taking “remedial actions”.
Below are the recommended perf counters with thresholds that should trigger action on the part of an Administrator. The resource utilization, user load and server health counters below are directly applicable to IM/Presence functionality. But you as an IT Admin will need to run resource utilization and user load baseline tests during medium load first to determine what is “normal” for your deployment. Then once you have your baseline numbers, you can add health monitoring counters to your overall monitoring scheme and go from there.

Recommended baseline counters to test and monitor resource utilization:

Processor; % Processor Time (_Total) [should operate at less than 80% during peak load]

Process; % Processor Time (RtcSrv)

Process; % Processor Time (IMMcuSvc)

Memory; Pages/sec ---

Network Interface; Bytes Total/sec ([your NIC]) [should operate at less than 80% capacity of the NIC]

(No baseline rules for individual process or memory utilization)
Pages/sec - indicates total “pressure” on the server’s available memory
Network Interface example: 100Mbit/sec NIC should be <80%x12.5Mbytes/sec ~ <10Mbytes/sec

Recommended baseline counters to test and monitor user load:

LC:SIP – 01 - Peers; SIP - 028 - Incoming Requests/sec (_Total)
LC:SIP - 01 – Peers; SIP – 001 – TLS Connections Active (_Total)
LC:SIP – 01 – Peers; SIP – 000 – Connections Active (_Total) [should be less than 15,000 connections per Front end]
LC:SIP – 02 – Protocol; SIP - 001 - Incoming Messages/sec ----
LC:ImMcu – 00 - IMMcuSvc Conferences; IMMCU – 000 - Active Conferences ----

LC:ImMcu – 00 - IMMcuSvc Conferences; IMMCU – 001 – Connected Users ----

LC:USrv – 00 – DBStore; Usrv – 002 – Queue Latency (msec) [healthy is less than 100 msec]
(server health decreases as latency increases to 12 sec when server throttling begins)

LC:USrv – 00 – DBStore; Usrv – 004 – Sproc (Stored Procedure) Latency (msec) [healthy is less than 100 msec]
(server health decreases as latency increases to 12 sec when server throttling begins)
Queue Latency=the time a request spent in the queue to the Back end server
Sproc Latency= the time it took the Back end server to process the request

Recommended counters to monitor for server health:

(These counters will indicate negative trends as well as overall server health)
LC:SIP – 01 - Peers; SIP - 024 – Flow-controlled Connections Dropped (_Total)

LC:SIP – 01 - Peers; SIP - 025 – Average Flow-Control Delay (_Total)

LC:SIP – 07 – Load Management; SIP – 000 – Average Holding Time For Incoming Messages ----

LC:ImMcu – 02 – MCU Health And Performance; IMMCU – 005 – MCU Health State ----

LC:USrv – 20 – Https Transport; USrv – 002 – Number of failed connection attempts ----

LC:USrv – 20 – Https Transport; USrv – 002 – Number of failed connection attempts / Sec ----

OCS 2007 MOM Pack thresholds from the documentation:

IMMCU - 020 - Throttled Sip Connections (Sample) (number of connections at which new SIP requests are refused)
Sample Interval is 15 minutes. The current health of the MCU. 0 = Normal. 1 = Loaded. 2 = Full. 3 = Unavailable.
Causes: MCU is overloaded, backend server is slow to respond, net problem
Resolutions: This could happen if too many conferences are assigned to this MCU. [should be no more than 500 maximum
sessions per MCU]
(Normal= healthy; Loaded=marginal; Unavailable=maximum reached)

IMMCU - 020 - Throttled Sip Connections (Warning) (Error) (number of throttled Sip connections total)
Sample Interval is 15 minutes
Numeric Threshold Rule triggered when the sampled value is greater than 10.
Causes: Peer is not processing requests in a timely fashion.
Resolutions: This can happen if the peer machine is overloaded.
(“Peer”=connected servers or adjacent Front end servers or MCUs in the same EE Pool – the same set of counters apply)

There are three phases of determining overall deployment health and wellness in a strategic monitoring plan:

Phase I: Start by polling your environment

· Run OCS Best Practice Analyzer (BPA) to perform a comprehensive inventory of servers and server-side settings. Among other things, BPA will flag incorrect settings and unsupported collocation of server roles and will even tell you if all the required hot fixes are installed, per server role.

· After performing your server inventory, compare your topology to recommended guidelines by using the Planning Tool for Office Communications Server 2007. This new tool can be very useful if used as a companion with the OCS Planning Guide. It’s an OCS deployment planning tool that uses a wizard to ask questions and then shows a graphical representation of the recommended topology based on profiles originated from the PG (5,000 users; 5-30K; 30-50K; 50-125K) using the recommended hardware.

· Review OCS Setup logs and OCS Application logs upon first run of the servers just after setup completes. Make a point of checking Application Logs regularly. But also make it a routine practice to check, “Show Logs” after OCS setup finishes. HTML-based hierarchical logs can then be expanded to show errors and the resulting cascading effect on the services.

· Run Validation Wizards for each server role as they are deployed to diagnose issues upon first run and to review informational and error messages relating to missing configurations or services not started. Those expandable HTML-based logs are very useful and handy to trace down exactly what’s wrong.

· Plan to repeat these on a rotating schedule:

1. BPA – run every month; update BPA every week

2. Planning Tool – run for major topology changes

3. Application logs – check logs on all servers every day

4. Validation wizards – run for every new server deployed

Phase II: Follow a comprehensive plan to monitor your environment

· Think about downtime optimization and use proactive thinking to catch and fix issues before they interrupt the services. Use Microsoft Operations Manager (MOM) 2005. You can install the OCS 2007 MOM Pack to monitor and create alerts and implement thresholds that trigger those alerts while monitoring an operation over time, using reporting to graph out weekly, monthly and seasonal usage! IT Admins worth their salt have already determined baselines for average usage and peak usage periods to ensure there is enough server headroom remaining during predictable usage spikes and they constantly update this information.

· Consider using Performance Monitor or MOM Alerts set to page IT Administrators. MOM calls attention to critical events that require administrator intervention. MOM offers info about root causes and suggests solutions from its knowledge database. Guarding SQL against over-usage of CPU, Disk, and Memory and understanding when to add a Front end server is critical to being proactive as your user base grows.

· Use the Admin tools. OCS has some good out-of-the-box tools for monitoring servers. In the status pane of the Microsoft Management Console, you’ll see status for ‘General Settings’, an Event Log tab and some of the recommended Performance Monitor counters already loaded up.

· Employ SQL Performance Dashboard to monitor SQL. That veteran team has worked long and hard developing this tool. For the Back end server, it’s likely to boil down to over-using the resources of the machine (disk, CPU or memory) and with all the information out there about SQL Server and which performance monitor counters to watch, you can likely solve any over usage problem if you know what to look for.

· Use Archiving and Call Detail Records to capture data for all sessions on your servers. Then use this information to monitor usage across your entire environment, including usage of specific functionalities, duration of specific sessions and per-user usage of specific features. Then you will understand how your end-users are making use of which OCS features and when. Using Archiving/CDR, you can capture details about how many users are sending IM to whom, when and how often. This will provide more insight about baseline usage of your deployment, not only for IM and multi-party IM but for other functionalities too. Determine usage spikes by analyzing the reports.

Phase III: Take quick and decisive remedial actions

· Take the proper steps to remedy the most common OCS issues seen because of decaying health of the servers before services are interrupted. Being PROACTIVE is really what you want but if you have to be REACTIVE, you want to strike at the heart of the developing issue. Take advantage of the OCS 2007 Resource Kit and its great set of troubleshooting tools to react properly.

· Develop an action plan using the OCS Administration Guide and follow it consistently. Even better, change it over time as your user base grows and usage changes. Train and encourage users to gather and upload their logs. For troubleshooting an OCS Director, ask the user to manually populate their server logon with the pool FQDN to rule out operator error or other client issues. Once you’ve confirmed there are no issues logging in directly to the pool, have the user set the logon back to automatic and gather Communicator logs. Generally, those logs are enough to find out what’s happening without going server side.

· OCS Logger is the tool to do server-side logging. It is documented in the Admin Guide. Network Monitor is also a very useful tool. Armed with both server-side and client side traces, you’ll know what’s up and more importantly, what’s down!

· Consider adding another Front end server in an expanded topology as thresholds are approached during peak load, but realize there will be declining return on hardware investment especially in a consolidated topology. Adding another server will definitely help, but scaling will not be linear. So would a new Front end facilitate an additional 5000 active users? It’s not out of the question that another server will spread the load, but it’s a false expectation to assume that you can facilitate another 15-20,000 active users every time another Front end is added.

TechNet resources on Troubleshooting IM and Presence issues:

· TechNet Labcast On-Demand: Configuring and Using Conferencing in Microsoft Office Communications Server 2007
More detailed information on proper configuration of OCS 2007

· TechNet Virtual Lab: Using the Management and Troubleshooting Tools in Office Communications Server 2007
More detailed information on troubleshooting and administration of OCS 2007

· TechNet Virtual Training On-Demand: Module 4- Using the Management and Troubleshooting Tools in Office Communications Server 2007
More detailed information on using the Validation Wizard in OCS 2007

· Microsoft Office Communications Server 2007 Administration Guide
More detailed information on the administration of OCS 2007

· Office Communications Server 2007 Technical Reference Guide
More detailed technical overview of server architecture and new features of OCS 2007

For an in-depth resource on Office Communications Server 2007, including detailed troubleshooting tips, refer to the Office Communications Server 2007 Resource Kit, especially Chapter 13: “Monitoring,” available from MS Press at: http://www.microsoft.com/MSPress/books/10482.aspx.

Stu Osborn. Stu prepared the content for this post prior to transferring to Unify²

This information is also cross-posted at http://www.ucblogs.net/blogs/ocs

On the About screen you'll see:

           Last Update Status: (0x####/0x#####)

The two hexadecimal numeric codes are for the benefit of debugging an issue when the Phone Edition can't contact
the Update Server. The normal state is (0x00/0). If the Phone Edition can't update, the user will read these
codes to the Administrator.

The first field is a WinInet error code. An error here would indicate a problem contacting the server.

The list of possible values can be found at:
http://support.microsoft.com/kb/193625

The commonly occurring values are

   Code        Error Message and Description
   -----       -----------------------------
   12002       ERROR_INTERNET_TIMEOUT
   (0x2ee2)    The request has timed out.

   12005       ERROR_INTERNET_INVALID_URL
   (0x2ee5)    The URL is invalid.

   12007       ERROR_INTERNET_NAME_NOT_RESOLVED
   (0x2ee7)    The server name could not be resolved.

   12028       ERROR_INTERNET_ITEM_NOT_FOUND
   (0x2efc)    The requested item could not be located.

   12029       ERROR_INTERNET_CANNOT_CONNECT
   (0x2efd)    The attempt to connect to the server failed.

   12030       ERROR_INTERNET_CONNECTION_ABORTED
   (0x2efe)    The connection with the server has been terminated.

   12031       ERROR_INTERNET_CONNECTION_RESET
   (0x2eff)    The connection with the server has been reset.

The second field is an HTTP status code: An error here would indicate that the server was contacted,
but failed to handle our request. The list of possible values can be found at:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

The commonly occurring values are

10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].

10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

10.5.1 500 Internal Server Error
The server encountered an unexpected condition which prevented it from fulfilling the request.

10.5.2 501 Not Implemented
The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

10.5.3 502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.

10.5.4 503 Service Unavailable
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.

      Note: The existence of the 503 status code does not imply that a
      server must use it when becoming overloaded. Some servers may wish
      to simply refuse the connection.

Below are the articles for released updates during the month of June 2008

952579  Description of the Windows-based Live Meeting 2007 client update package: June 4, 2008

952578  Description of the update for the Live Meeting Conferencing Add-in for Outlook: June 4, 2008

950559  Description of the update for the Unified Communications Client API SDK

953907  Description of the update package for Communications Server 2007: June 2008

UC-RTC Sustained Engineering

Microsoft Resource Kits are typically released as-is and do not receive fixes but every once in a while you encounter a problem that prevents one from even using the tool at all and so the ABS Configuration Tool receives an update for two problems.

This is the Knowledge Base article that documents the problems and fixes along with the process to obtain the fix - http://support.microsoft.com/Default.aspx?kbid=954749

The resource kit can be found with our other tools and resources on Microsoft Technet here - http://technet.microsoft.com/en-us/office/bb676081.aspx

The description of the tool from the OCS Resource Kit Tools Readme -

ABS Configuration Tool is a graphical user interface application that enables administrators to configure AD attributes and WMI settings, related to ABS.

The primary scenarios for the tool are:

1. To enable administrators to map attributes in the AD to the attributes for Office Communicator.
2. To enable administrators to specify the list of attributes to be included in the ABS files.
3. To enable administrators to configure WMI settings and thereby all common tasks related to ABS files.

UC-RTC Sustained Engineering

Generically, SIP can use (at least) 3 types of transport. Office Communications Server supports TCP and TLS, with the latter being the default (actually, TLS runs on TCP).

Various interactions with some partners and customers of late of have posed the question: "Why doesn’t OCS support SIP over UDP?" Their belief is that UDP is the ‘lowest common denominator’ SIP transport that is supported by "everyone" and that, by not supporting it, OCS is out of step with the mainstream of SIP implementation and interoperability.

Let’s evaluate that proposition on its merits.

Why doesn’t OCS support UDP?

There are three issues with UDP:

1) It is not encrypted, so you can’t ensure end to end security of SIP messages. There is no shortage of opinions on the security, or the lack thereof, of SIP (e.g. Cert® Advisory, ). As a text based protocol that is human readable (if ‘readable’ is the right word…it is not exactly prose…) there are privacy/security issues of sending SIP ‘in clear’. Furthermore, UDP allows for easier spoofing of packets since connection state doesn’t need to be maintained (remember Slammer?....UDP). This is why OCS customers are strongly recommended to accept TLS over TCP as the default SIP transport within the OCS network.

2) UDP has a fundamental flaw for large SIP messages: the size of the UDP datagram is limited to 1500 bytes, so a SIP message larger than that will be broken into two or more packets. The application layer (client or server) can receive the fragments out of order or a fragment could be lost (see 3 below). Since OCS SIP messages tend to contain various XML bodies, machine generated unique IDs (e.g. GRUUs), ICE candidate attributes, (etc.) they will normally span multiple packets.

3) UDP is a "fire and forget" protocol: this is to say that the transport layer does not consider lost or delayed packets. The onus of tracking messages for which no response has been received (and the generation of new requests) is left to the application layer: this leaves the application (the client or the server) vulnerable to overload situations. In bad network conditions, the best case scenario is a call setup delay. The worst case scenario is that the SIP network can reach a tipping point where the session timers are tripping for every transaction because the network elements are busy generating, or responding to, "retries" – a so-called "retry storm".

A commercially deployable enterprise communications solution must, at the very least, be secure, reliable and scalable. UDP presents challenges in all of these areas and the SIP RFCs (see below) allow us to choose from alternative SIP transports. Within the OCS network we use TLS, and at the edge of the network we can interoperate over TCP.

Why do people object to TCP or TLS as a SIP transport?

The fundamental objection to SIP over TCP or TLS is that it they are computationally expensive relative to UDP. There are several parameters at the transport, session and application layers that affect transaction performance:

· Stateful vs. Stateless

· Authentication vs. no Authentication

· Encryption vs. no Encryption

An IBM Research article "Evaluating SIP Proxy Server Performance" examined, among other things, the impact of the choice of SIP transport protocol on SIP transaction throughput. The authors found clear evidence that stateless UDP with no authentication (and therefore no encryption) has, by far, the highest throughput. However, this modality is completely incompatible with a reliable and secure commercial communications service. Stateful transaction processing with authentication yielded a 43% transaction degradation when using TCP compared with UDP. However, the authors were using an open source proxy server and brought to light various performance issues that were implementation specific.

An IEEE Article "SIP Security Issues: The SIP Authentication Procedure and its Processing Load" further examines the security and authentication overhead issue and found only a 5.5% overhead to TCP vs. UDP. Their summary includes the comment:

Another interesting finding is that the TCP processing introduces a small increase [in processing overhead] with respect to UDP and that the additional increase due to TLS is almost negligible.

Therefore, if you compare UDP to TCP and TLS in a commercially deployable solution, it is hard to defend the argument that the overhead of TCP and TLS outweigh the reliability and security advantages that they provide.

The debate regarding whether or not TCP is inefficient/expensive has been going on for many years. An IEEE Landmark Article "An Analysis of TCP Processing Overhead" published in June 1989 disproves the notion that TCP (by then a 15 year old protocol) is an inefficient protocol. The fact that it is still in use nearly 20 years later suggests that the authors were correct and that current anti-TCP sentiment is based upon "techno-urban legend", rather than scientific analysis.

Is UDP more standard than TCP or TLS?

There is a belief among certain constituencies that UDP is "more standard" than TCP or TLS.

From a historical perspective, the original SIP spec, RFC 2543 (published in March 1999), states:

User agents SHOULD implement both UDP and TCP transport. Proxy, registrar, and redirect servers MUST implement both UDP and TCP transport.

Note that equal priority was given to TCP and UDP. If you take a look at the current SIP spec, RFC 3261 (published in June 2002), you will see in section 18 the following statements related to SIP transport:

All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols.

Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them.

While it is true that OCS does not comply with RFC 3261 by not offering or accepting UDP, the assumption that all SIP messages will exceed the UDP datagram size limit provides an implied waiver on this requirement. Furthermore, TCP is the base transport for TLS, which we strongly recommend for security reasons; note that TLS does not run on UDP. Therefore, the conjunction of the security, fragmentation and reliability/scalability issues has lead us to the conclusion that UDP is not a useful transport for the transmission of SIP messages.

Is UDP the preferred SIP transport?

In order to verify the notion that SIP over UDP is supported by everyone, and yet TCP/TLS is supported by no-one, let’s examine the SIP offerings of the (overwhelming) majority market share vendors:

Vendor	UDP	TCP	TLS	Reference
Microsoft	N	Y	Y	http://download.microsoft.com/download/d/b/6/db641148-427b-41d3-9f20-7ffbddaf65b8/OCS_VoIP_Guide.doc
Cisco	Y	Y	Y	http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/FeatTLS.html#wp1092137
IBM	N	Y	Y	http://download.boulder.ibm.com/ibmdl/pub/software/dw/lotus/sametime-sip.pdf
Nortel	Y	Y	Y	http://www142.nortelnetworks.com/techdocs/CS1K_5_0/pdf/NN43001-564_01.05_NRS.pdf
Avaya	Y	Y	Y	http://www.avaya.com/gcm/master-usa/en-us/products/offers/sip_enablement_services.htm&View=ProdTechSpec
Alcatel-Lucent	Y	Y	N	http://www1.alcatel-lucent.com/doctypes/articlepaperlibrary/pdf/ATR2002Q4/T0212-SIP_Technology-EN.pdf
Siemens	Y	Y	Y	http://www.enterprise-communications.siemens.com/Products/Phones%20Clients/Desktop%20Phones/~/media/6DAA007008EB4A5CA0212A6D12A49770.ashx
AudioCodes	Y	Y	Y	http://www.audiocodes.com/objects/sbc/nCite_4000.pdf
Nextpoint	Y	Y	Y	http://www.nextpointnetworks.com/files/NextPoint_SBC_USLTR_2008_hirez.pdf
Acme Packet	Y	Y	Y	http://www.acmepacket.com/html/page.asp?PageID={06E4AEBC-24E2-46CC-BA95-7C74288FA45B}
Covergence	Y	Y	Y	http://www.covergence.com/stuff/contentmgr/files/4adf40f79f81482fff714c46d8e06832/misc/ssesb.pdf

Based on this small, but statistically significant sample – there is a strong argument that TCP is actually the lowest common denominator SIP transport. Certainly, the notion that vendors do not support, and customers can not deploy, SIP over TCP is thoroughly debunked.

Conclusion

We have examined the myth that UDP is the best choice SIP transport:

· We have evaluated whether or not UDP is a good protocol for a commercially reliable, secure and scalable communications service

· We have examined the evidence that TCP, with stateful transaction processing and authentication, is significantly less performant than UDP

· We have determined whether there is any basis for a bias towards UDP in the SIP standards

· We have also examined the support of UDP, TCP and TLS in the majority of enterprise and service provider SIP deployments

As Adam and Jamie say on the Discovery Channel’s ‘Mythbusters’: I think we are ready to make a call on this myth….and it is definitely ‘busted’.

Russell Bennett

Lead Program Manager

Recently, there have been some server changes made by two of our Public IM Connectivity partners Yahoo! Inc. and MSN (Windows Live). These changes will affect only those Microsoft Office Communications Server 2007 and Microsoft Office Live Communications Server 2005 customers whose external firewalls accept traffic on TCP port 5061 only from known IP addresses.

On May 22, 2008, Yahoo! Inc. moved their servers that provide instant messaging (IM) federation with Microsoft Office Communications Server 2007 and with Microsoft Office Live Communications Server 2005. As a result, The fully qualified domain names (FQDNs) and IP addresses for the Yahoo! gateway servers have changed. However, Yahoo! will not change the name of the service provider for instant messaging, which is configured in Microsoft Office Live Communications Server 2005 Access Proxy and Microsoft Office Communications Server 2007 Access Edge Server. This name will remain lcsap.msg.yahoo.com.

Meanwhile, MSN (Windows Live) has also changed the IP address for its LCS and OCS gateway. The name of the service provider for instant messaging will also remain the same, which is federation.messenger.msn.com.

As documented in the documentation for Live Communications Server 2005 SP1 and for Office Communications Server 2007, the recommended firewall configuration when federating with public IM providers is to allow any IP address to connect to port 5061 on the Access Proxy. However, certain enterprises prefer to enforce stricter firewall rules and restrict incoming connections to specific IP addresses. For those customers, the IP addresses that are used by the public IM networks need to be specifically allowed on the enterprise firewall. The following lists contain the new IP addresses that are currently used by each service provider:

IP address that is used by MSN (Windows Live)
• 65.54.227.249

IP addresses that are used by Yahoo!
• 76.13.22.8
 
• 76.13.22.9
 
• 76.13.22.10
 
• 76.13.22.11
 
• 98.136.47.8
 
• 98.136.47.9
 
• 98.136.47.10
 
• 98.136.47.11
 
IP addresses that are used by AOL (unchanged)
• 64.12.162.248
 
• 205.188.153.55
 
For further information about the Yahoo! Change, please refer to the following Microsoft KB article:

http://support.microsoft.com/kb/952209

For other Known issues that occur with public IM connectivity, please refer to the following Microsoft KB article:

http://support.microsoft.com/kb/897567

Hao Yan
Sr. Program Manager

 What is Enhanced Presence?

OCS 2007 allows its client applications to publish and subscribe to Enhanced Presence information. The enhanced presence infrastructure includes categories and containers. State, note, contact information, or calendar data (e.g. Free/Busy) are examples of categories. Containers are logical buckets into which the clients publish the categories of presence information.

A user can control what presence information other users see.  For example, if userA@fabrikam.com places userB@fabrikam.com in his Public container, userB can see only userA's name, e-mail address, and basic contact information. If userA places userB in his Personal container, userB can see detailed information like additional phone numbers, location etc.

OCS 2007 notifies watchers of presence changes for the container they have permission to access.  OCS 2007 supports this functionality through the use of Access Control Lists (ACLs) that map a user’s contacts into Containers.  Each end user can configure their ACLs via the “Access Level” or “Access Levels Management” view in the Office Communicator client.  ACL’s can define the set of users which can access a container based on a number of different criteria:

URI list (e.g. “userA@fabrikam.com”)

Domain List (e.g.“fabrikam.com”)

Same Enterprise

Federated Users

Public Cloud Users

 

 

 
Enhance Presence Feature Set
The main features of the enhanced presence model are as follows:
• Enhanced presence status
• Automatic sensing of activity
• Access levels
• Interruption management
• Multiple points of presence (MPOP)
• Extensible presence status
• Integration with Office applications

 

 

 

 

To enable enhanced presence for a single user

1. Click Start, click Control Panel, click Administrative Tools, and then click Office Communications Server 2007.
2. In the console tree, expand Communications Enterprise Edition Pools.
3. Expand the pool that contains the user you want to enable for enhanced presence, and then click Users.
4. In the details pane, right-click the user, and then Properties.
5. In the Properties dialog box, click Configure.
6. In the User Options dialog box, select the Enable enhanced presence check box.
7. When the enabling enhanced presence message is displayed, read the information, and then click Yes to complete the enabling of enhanced presence for the user.

 

What happens when a user is enabled for enhanced presence?

After you have enabled your users for enhanced presence, deploy Office Communicator 2007 to all client computers for these users. After a user is enabled for enhanced presence, the user can no longer sign in to previous versions of Office Communicator, Communicator Web Access, or Communicator Mobile.

Note: When you do enable Enhanced Presence on the user object following the migration, the user is still able to sign-in using legacy clients. When the EH aware client signs-in, the database information is upgraded to include EH information. From this point forward, the legacy client does not function.

Any user created in OCS 2007 pool\server already has enhanced presence enabled and cannot be changed.

An example of user activity category publication in Enhanced Presence

 
For more information regarding Enhanced Presence, please see:  http://communicatorteam.com/archive/2008/03/06/103.aspx
Important links:
OCS Enhanced Presence Model: http://www.microsoft.com/downloads/details.aspx?FamilyID=df0ba247-3884-43c7-a1e1-791d64b8bfa8&displaylang=en
OCS Resource kit: http://www.microsoft.com/MSPress/books/10482.aspx

Ram Ojha

Support Engineer

OCS 2007 Voice Connectivity

In Office Communications Server 2007 (OCS) there are 3 modes of voice calling:

1. OCS point to point: User A calls User B – call is VoIP end to end.

·         The endpoint could be Office Communicator (OC) or an IP phone (e.g. Polycom CX700)

·         Users could be either inside the network or roaming

·         Applies equally to multi-modal communications (i.e. IM, Video, Collaboration)

 2.OCS Federation-a User in domain A calls a User in domain B -   the call is  VoIP end to end over the public internet.

         ·    Federated calls still carry the same capabilities as point to point  calls described above – roaming, video, etc.

 3. PSTN to OC: a telephony user (PSTN, mobile, PBX) calls an OC user (or vice versa).

         ·    OCS Co-existence – PBX phone and OC are integrated via “dual-forking” mechanism between PBX and OCS, such as Nortel’s Converged Office

         ·         OCS Stand-alone – OC accesses telephony via integration using the PBX or a Media Gateway

         ·         Remote Call Control – OC applies 3^rd Party Call Control to a PBX phone

 

As previously stated, direct interoperability via SIP/RTP with Telephony Service Providers: aka “SIP Trunking” is not supported in OCS 2007.

What is “SIP Trunking”?

What do we mean by “SIP Trunking”?  OCG’s definition was laid out in the white paper referenced above.  The very fact that we needed to define it shows that there are many interpretations of this term.  To further complicate matters, OCG is not the only Microsoft Business Unit engaged in offering this feature – the ResponsePoint group (see: http://www.microsoft.com/responsepoint/default.aspx) is also shipping a SIP Trunk feature in their product and that has a slightly different technical specification to the one we are considering.

 

Jonathan Rosenberg has formally defined a “SIP Trunk” here: (http://tools.ietf.org/id/draft-rosenberg-sipping-siptrunk-00.txt ) in at least 4 different guises (and who am I to dispute that ?)  However, as a vendor of equipment that at some time in the future will support this function, it is incumbent on OCG to define what that function might be.

 

 

For Microsoft OCG, “SIP Trunking” is the use of SIP and RTP to pass telephony traffic from the enterprise network edge to a network service provider over an IP connection (i.e. without traversing TDM or circuit networks).  For cases where OCS is connecting to a Gateway or IP-PBX, as we qualify through the Unified Communications Open Interoperability Program (http://technet.microsoft.com/UCOIP), we use the term “Direct SIP”

 

 

 

 

 

Why SIP Trunking?

The value proposition of SIP Trunking for an OCS customer is:

1.       Not having to deploy, maintain, and operate IP-PSTN gateways on-premise either regionally or at remote offices

2.       Consolidation of data/voice networks (recurring costs)

3.       Reduction of call degradation by reducing the number of conversions of the call from IP to TDM (and back): note that most calls today are carried on a long distance network over IP transports.

The benefit of providing a SIP Trunking feature for Microsoft OCG is:

·         In the short term, offering OCS customers the choice of how to connect to the PSTN

·         The long term value of SIP Trunking is ultimately about creating a roadmap of federated multi-media communications via managed networks

 

The value proposition of SIP Trunking for Telephony Service Provider is to bring new value to their IP customers and to define a services-based UC value-proposition.  IP-centric service providers, on the other hand, are hoping to access a new channel for their services. 

Is SIP Trunking defined in a standard?

 

A technical recommendation for “IP PBX / Service Provider Interoperability” was created by the SIPconnect technical working group of the SIP Forum in 2006.  In many ways, this was a useful document, but it has not been broadly supported by equipment vendors or the network service providers.  Indeed, the actual uptake of SIP Trunking services has lagged far behind the apparent demand for such a service: the voice traffic traversing a SIP Trunk is currently a tiny proportion of total global trunked traffic.

 

In an attempt to address the adoption issue, the SIP Forum has launched a new initiative to revise the SIPconnect specification.  The Board of the SIP Forum recognized that Microsoft, as a leading vendor of unified communications solutions, could be a positive proponent of this effort.  In parallel, we realized that the number of service providers (wireline, IP and mobile) around the world was significantly greater than the number of PBX vendors.  We also came to realize that a minority of these Service Providers were currently offering SIP Trunking, and those who did were not necessarily compliant with the SIP RFCs.  Thus, the easiest way for us to address the issue of there being no defacto standard was to work with the SIP Forum to help define a standard that all vendors and service providers can support.

 

 The natural outcome of this mutual realization was that, at the invitation of the Board of the SIP Forum, Microsoft OCG has submitted a base specification for SIPconnect 1.1 (see: http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,45/Itemid,75/ ) and, at the time of writing, the document has been downloaded 300 times.  As of May 7^th, the Technical Working Group has started work on the effort, lead by Rich Shockey of Neustar.  The timelines for completion have not been finalized, but we hope that a final draft of SIPconnect 1.1 will be ready by the end of the year. 

 

Russell Bennett

Lead Program Manager