This week I am taking some time out from my schedule to catch up and do a bit of training. I am also taking a look at the new Cisco 8.x SRND as well as the new Cisco interoperability document on using the CUBE with OCS 2007 R2.
Cisco Unified Border Element and OCS 2007 R2 Interoperability Document
Get the document here.
There are some really good things about this documents that are well worth checking out but there also a few items to be aware of such as support from Microsoft for the IOS version and some of the CUCM setup used. The current Microsoft supported IOS version can be found here. If you are currently using the CUBE to do interoperability between OCS and CUCUM this offers some new commands in the IOS code (15.1.1T) that will help overcome some previously encountered issues . In saying that direct SIP to CUCM 7.1 is also supported by Microsoft so using the CUBE is not a requirement for interoperability.
First stop is a comment on page 5. “Some Microsoft Client endpoints require RTCP packets. If RTCP packets are not generated by all endpoints, additional features of the Cisco Unified Border Element can be used to resolve this issue. Contact your Cisco sales engineer for information.” If you read down the page, 5 bullet points down you get a better understanding about what they are talking about. Basically if you stop sending RTCP packets to Communicator or the conferencing service, they will hang up after 30 seconds under certain circumstances which are explained in the document. This behaviour has been seen with Cisco IP phones and Unity when they stop sending RTCP. Cisco have a work around for Unity with ISR's acting as MGCP gateways as well, so its an issue they have had to deal within their own ecosystem and not just with OCS.
There is one more point worthy of a mention in this first part of the document. The last bullet in this section talks about early media negotiation and ringback not working. It does not require a CUBE to solve this issue but having the IOS command suggested as a fix does simplify things if you have a CUBE deployed. This issue can be solved using a MSPL script on the front ends of your OCS deployment. Doug Lawty wrote a great blog post on this sometime ago if you’re experiencing this issue. For the CUBE, Cisco are recommending using the command “voice-class sip block 183 sdp present” on dial peers. This only allows 180 SIP ringing messages towards CUCM.
After skipping through the OCS configuration (beaware the screenshots showing the dialplan is not using Microsoft recommended E.164 best practices) on page 46 you get to the IOS configuration which is pretty helpful. If you are using an earlier version of Cisco UCM prior to 7.1 you may have to experiment a little with some of these commands to see if they work as expected.
The last half of the document is screen shots from CUCM configuration. Looking over the SIP trunk portion, one point to be aware of is this document does not show MTP as required selected. Now, for the SIP endpoints registered with CUCM this is not going to be an issue but for first generation Cisco SCCP IP phones this could cause a problem. 7940’s and 7960’s to be clear. Just something to keep in mind when you follow this document if you run into issues. With that you may also need to do some MTP planning which can be also run on the CUBE which is in flow though mode. The media is going to run through the CUBE regardless if the MTP is hosted there or not.
The last couple of areas worth mentioning is Appendix A which talks about earlier versions OF CUCM and removing the + sign and transcoding G.711 to G.729. Appendix A is handy if you plan to do it this way rather than remove the + at the mediation server itself. So again you do not need to use the CUBE to fix this issue. Then finally the transcoding section is handy if you implemented G.729 in areas of your Cisco network.
So overall this looks and feels like a lot of preceding documents Cisco have done on OCS integration. Something’s have provided a handy fix and other parts of the document are there for the sake of showing how it’s done with a sceenshot. Don't expect an in-depth analysis and I think you will be okay. Of course the main part of the document is the IOS configuration so its worth a look if for nothing else than that.
Comments welcomed.
VoIPNorm
I worked on some cisco-OCS integrations in the past (both EV and RCC) and I have to note, their documentation is useless if you have a system that is not 100% exactly the same as the lab, that was written in the docu. Yeah, here comes the 100$ question: who is responsible to provide the necessary documentation for an INTEGRATION, that depends on 2 opposing vendors.
ReplyDelete30 pages of screenshot-flow without a single word of clarification is not reaching the level of saying it is a document, from my point of view. It is just "something" that was thrown to the massses. I confirm I have no cisco certification, neither am I a cisco UC expert, but in fact I have a lot of real-world experience, and common sense about the technology. I dont have to be an expert of any actual product to do my work, but for this I need useful documentation, not pictures and 0 word.
To your point about who writes what is interesting. In this particular case the responsibility in my opinion falls on Cisco because this is an additional component that is not really required to do interoperability but Cisco is trying to provide additional value to their own architecture.
ReplyDeleteTo your comments on the screenshots, I tend to agree with you that if you going to do screenshots both an explaination and following the best practices of the other vendor make a much better document.
Thanks for your feedback.
Cheers
Chris
I agree with the lack of interest on these two particular vendors in showing how to interoperate.
ReplyDeleteI deal more with OCS and, as a Cisco self-paced study, I must say that at least Cisco released something... from MS i can only rely on their MVPs.
This resource will be valuable for some projects I have.
Another great post Chris ;)
Quote "Cisco have a work around for Unity with ISR's acting as MGCP gateways as well, so its an issue they have had to deal within their own ecosystem and not just with OCS."
ReplyDeleteFWIW, that was Unity4.0 , current version is 8.0 . That's sort of like a application developer finding a bug in his own software and then saying that the problem lies with MS because MS has to deal with the same problem in Windows 95.
Hi Ancient One,
ReplyDeleteThanks for the comment. I certainly didn’t want to inflame anyone with that comment. Couple of points though, this behavior was never changed for Unity 5.0 which is what I test against, which is deployed at a lot of customers and both Unity 5 and 4 are Cisco supported products. End of sale yes but still supported. Whether this is still the way Cisco treat RTCP in Unity 8.x which only became available recently I honestly don’t know. Their solution at the time was to turn off MGCP RTCP timers by default in following versions of IOS rather than change the behavior of Unity. So this is an issue of interoperability and what you described was not what I consider a fair comparison of the situation at hand although I do see what you’re trying to get at.
My point wasn’t a who is to blame as I don’t really care all that much. It was more about this isn’t new to Cisco to see this issue even within their own supported product portfolio even though there is an expectation that Microsoft make changes to accommodate Cisco’s implementation of RTCP (which if you read my next post is what Microsoft have in fact done). Cisco certainly made a point in that document to call out Microsoft as if it was their problem. Why Cisco implemented RTCP in this manner I don’t know and why it is implemented differently across products I don’t know either and to be completely frank with you I don’t really care and I don’t think most customers do either, they just want it fixed.
I could have referred to RFC’s and all that other stuff but in the end for every RFC one company has followed to the letter I am sure there are other RFC’s they have not (Microsoft and Cisco included I am sure) and although we would all like to live in a perfect IT world and everyone everywhere embraces RFC’s and follows them accordingly they are in fact open to interpretation. This is the reason I never mention someone who follows and other that don’t because in the end all they end up being is a guide for vendors, which they love to use as weapons against each other at times, but in reality all they really are is a guide. Sort of like reading a street map but sometimes you just want to cut through the park to make the trip shorter. In a competitive market such as we have today the only real rule makers are customers who demand better support for interop from their vendors like Microsoft and Cisco. Sometimes this means following RFC’s better and sometimes it means making adjustments to make things work, as is the case here.
Again thanks for your comment, hope you still found something useful in the blog post and keep reading.
Hi LuisR,
ReplyDeleteThanks for your comment. I don’t think there is a lack of interest as both MSFT and Cisco have produced their fair share of documents but I think some has to do with demand and others it’s a competitive motivation thing. Some documents have been released by MSFT like direct SIP to Exchange UM from CUCM and then there is the example we have here from Cisco and others. If you look at other partners that interop with OCS they have largely produced their own interop documents so one would assume the same expectation of Cisco but since they are also a competitor in the same space their motivation is somewhat driven by customer demand or desire to sell product through interop (CUPS for example)rather than the desire be an interop partner as other vendors like AudioCodes have. I am not trying to pick on Cisco by the way this is just the way it is for any company. Although Cisco and Microsoft absolutely support interop their relationship is not the same for obvious reasons as it is for say a gateway vendor like AC, and this is obvious for an outsider looking in and not just for an inside observer. It’s a strange competitive world right now and who documents what is part of that world as the competitors struggle for market share.
Very informative Post on CISCO.
ReplyDeleteThanks
Excel Comparison
Hello Chris,
ReplyDeleteI am a Lync/Cisco voice implementer and constantly refer to your blog for is in-depth perspective on these integrations. Thanks for the resource and I do have a question:
We have a Lync 2010 deployment. 2 mediations, 2 FE’s, single 3925 CUBE connected to a Verizon SIP trunk for PSTN. No CUCM. We have an issue where if a call comes from the PSTN, is answered in Lync, then put on hold, then resumed, in 8 out of 10 cases the call will resume but audio cannot be heard from the PSTN to the Lync client for up to 10 seconds. Then everything kicks in and is fine. During the “silent time” we see no SIP messages sent to the CUBE by Lync until the “kick in time” where we see Lync send a flurry of messages. We have a partner case open currently but they are asking about PRACK and MTP’s which is a little scary. I suspect we are having a delayed SDP issue but I can’t be sure. We have fiddled with the CUBE and Lync settings on both sides and can’t seem to get the right config in place. Any tips?
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns833/1197443.pdf
DeleteI would suggest start here with this document. Verizon may have some specific commands required on the CUBE so I would open a case with them also. Also is media bypass enabled?
Hello Chris,
ReplyDeleteJust a follow-up.we were able to get this fixed. Cisco TAC identified a bug in the software version that the CUBE was running. their notes below for anyone else hitting this.
After some further deep dive I examined the RTCP traffic present in the call. What I found was that in both good and bad calls, the CUBE is sending a RTCP BYE right after it gets the Reinvite to reestablish media from Lync. I believe that the difference between good and bad calls is how Lync is handling this RTCP BYE. However that is a moot point because the CUBE should not send that. I was able to find a bug on this very issue. The DDTS number is CSCtr54269. The IOS you are running now is susceptible to this defect. The CUBE Is currently running 15.2(1)T. The fix for this defect is in 15.2(1)T1 or later versions of that train. From my analysis if you change the IOS of the CUBE to a version that has this defect fixed, then it should resolve the problem you are hitting.