The first section covers the tools and testing procedures used. They also make mention that E.164 is used throughout the document which is also a plus. E.164 seems to be the direction Cisco is now heading with the release of IME which requires E.164. There is also a plug for CUCiMOC in this first section. For those of you that have read my blog for some time, you will already know how I feel about a plugin versus native features in Communicator but for those that haven’t please feel free to check it out.
The limitations section has a few points that have changed due to newly available updates that have resolved the issues noted. The first one is –
“OCS 2007 R2 does not support calling and connected name. Cisco UCM sends its calling name and number to mediation server/OCS, but the OC only displays the calling number. Name is not sent by Mediation Server.”
This has been available for some time with the update mentioned here.
Next is a recent topic here on VoIPNorm with the RTCP incompatibilities. –
“During a three-way conference initiated by an OC user the OC user is unable to “mute” any participant that is connected to the conference using a Cisco Unified IP phone. The issue is caused by the incompatibility between Microsoft OCS R2 media keepalive mechanism against Cisco Unified Communications solutions.”
This has been resolved with update mentioned here.
I understand that these things would appear in a Cisco document since they may not be tracking every update of OCS or the document was released after the fact.
The last section on known limitations has a couple of interesting lines that are in no way related to Direct SIP interoperability but I thought it would be good to mention them anyway. They are really generalized statements that had they been given some direction may have made sense in relation to the content but they were just sort of flopped out there. Some of these statements are correct and Microsoft are resolving them with Communication Server “14” and some are a little misleading.
“The Microsoft Mediation Server does not support video transcoding, thus video is not possible between OCS and UCM endpoints.”
This first comment is correct in that the mediation server cannot transcode video. But in saying that there are solutions out there today from Cisco (this is the funny part), that allow an OCS client to talk video with other video endpoints including Cisco endpoints. Here is the one from Cisco that describes using a Cisco MCU to do video interoperability with OCS and Communicator. Furthermore with the acquisition of Tandberg there are a couple of different ways to do video interoperability with what are soon to be Cisco endpoints to OCS through the VCS and Tandberg’s soon to be released UC gateway.
“ Call Admission Control (CAC) is available for UCM endpoints but not OCS endpoints”
This is a true statement, it’s also true if you substitute “OCS” for any other product or manufacturer besides Cisco. Further as some of the more frequent readers already know CAC has been announced in Communication Server “14” as a new feature. But this is a blanket statement from Cisco. Maybe they have had questions at the TAC over using Cisco CAC on OCS endpoints. If it had been defined better I think that would be more useful to customers.
“Survivable Remote Site Telephony (SRST) is available for UCM endpoints but not OCS endpoints”
Again another true statement. OCS users cannot use Cisco’s SRST. Again, feel free to play the ‘substitute your non-Cisco-product-here game – neither can Avaya, Siemens or Sametime clients. As announced at VoiceCon,with Communications Server “14” Microsoft will be Offering their own survivable branch solution called the Survivable Branch Appliance or SBA with Microsoft’s gateway partners. This is another blanket statement but again this may be something that has come up with the TAC.
“E.911 support is available for UCM endpoints but not OCS endpoints.”
This statement could have been correct had it been defined more clearly. Again, a blanket statement that doesn’t describe support by who. Certainly ambiguous. Had they said Cisco it would be correct. There are third party providers providing E.911 support for OCS 2007 R2 that I have talked about on my blog here. Had some due diligence been done they would have known that E911 Enable can in fact support OCS R2and CUCM endpoints on the same E911 Enable infrastructure. Its just so happens that E911 Enable (in addition to Intrado) have also announced support for Communications Server “14” in conjunction with native endpoint support being offer by Microsoft.
I do find it a little annoying that Cisco is calling out what another vendor supports in a configuration document, and as I have shown some of them are only partly correct statements anyway. So in the end it detracts from the intention of the document and hurts their credibility somewhat.. That being said, Call Admission Control, Branch Survivability and E911 are three key features coming in CS “14” – and Microsoft is super excited about being able to share them with everyone.
The bulk of the document is actually pretty standard for this style from Cisco. Even though it is mainly just screen shots they have done a good job at getting the configuration documented. In the end I think that people that have OCS and CUCM deployed already may find that this configuration is a little simpler than first thought. If you plan your OCS dial plan correctly it takes little to no management once implemented when used in conjunction with CUCM.
Finally, the following links are done by the Microsoft team to help with Direct SIP configuration for earlier versions of CUCM.
OCS to CUCM 4.x
OCS to CUCM 6.x
Hopefully this was a helpful post and some of the distracting things mentioned in Cisco’s documents get less attention than they really should.