tag:blogger.com,1999:blog-2158853543793456735.post1158324962056745751..comments2023-10-02T04:50:01.667-07:00Comments on VoIPNorm's Collaboration Blog: New OCS 2007 R2 Cisco UBE Interop DocumentChris Normanhttp://www.blogger.com/profile/07200178774058910421noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-2158853543793456735.post-67092733057197020912013-03-04T14:33:56.834-08:002013-03-04T14:33:56.834-08:00Hello Chris,
Just a follow-up.we were able to get ...Hello Chris,<br />Just 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.<br />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.<br />yesshttps://www.blogger.com/profile/12716789342360659977noreply@blogger.comtag:blogger.com,1999:blog-2158853543793456735.post-89815448468739714712013-02-15T08:06:30.450-08:002013-02-15T08:06:30.450-08:00http://www.cisco.com/en/US/solutions/collateral/ns...http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns833/1197443.pdf<br /><br />I 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?Chris Normanhttps://www.blogger.com/profile/07200178774058910421noreply@blogger.comtag:blogger.com,1999:blog-2158853543793456735.post-22692930031572049752013-02-15T05:13:48.492-08:002013-02-15T05:13:48.492-08:00Hello Chris,
I am a Lync/Cisco voice implementer a...Hello Chris,<br />I 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:<br />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?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2158853543793456735.post-87086799792729327562010-08-22T22:31:22.408-07:002010-08-22T22:31:22.408-07:00Very informative Post on CISCO.
Thanks
Excel Comp...Very informative Post on CISCO.<br /><br />Thanks<br /><a href="http://www.litera.com/products/change-pro_for_excel.html" rel="nofollow"><b>Excel Comparison</b></a>Pdf Comparisonhttp://www.litera.com/products/litera_document_factory.htmlnoreply@blogger.comtag:blogger.com,1999:blog-2158853543793456735.post-21252612455915376632010-04-16T23:42:31.625-07:002010-04-16T23:42:31.625-07:00Hi LuisR,
Thanks for your comment. I don’t think ...Hi LuisR,<br /><br />Thanks 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.Chris Normanhttps://www.blogger.com/profile/07200178774058910421noreply@blogger.comtag:blogger.com,1999:blog-2158853543793456735.post-91043330607905738762010-04-16T23:02:03.950-07:002010-04-16T23:02:03.950-07:00Hi Ancient One,
Thanks for the comment. I certain...Hi Ancient One,<br /><br />Thanks 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.<br /><br />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.<br /><br />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.<br /><br />Again thanks for your comment, hope you still found something useful in the blog post and keep reading.Chris Normanhttps://www.blogger.com/profile/07200178774058910421noreply@blogger.comtag:blogger.com,1999:blog-2158853543793456735.post-53128020642293438642010-04-16T20:57:36.793-07:002010-04-16T20:57:36.793-07:00Quote "Cisco have a work around for Unity wit...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."<br /><br />FWIW, 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.Jason Wonghttps://www.blogger.com/profile/09436333509143029220noreply@blogger.comtag:blogger.com,1999:blog-2158853543793456735.post-70561949200610159162010-04-14T16:52:15.504-07:002010-04-14T16:52:15.504-07:00I agree with the lack of interest on these two par...I agree with the lack of interest on these two particular vendors in showing how to interoperate.<br />I 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.<br />This resource will be valuable for some projects I have.<br /><br />Another great post Chris ;)LuisRhttp://pt.linkedin.com/in/luismramosnoreply@blogger.comtag:blogger.com,1999:blog-2158853543793456735.post-82323607894587212010-04-14T15:36:47.735-07:002010-04-14T15:36:47.735-07:00To your point about who writes what is interesting...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.<br /><br />To 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.<br /><br />Thanks for your feedback.<br /><br />Cheers<br />ChrisChris Normanhttps://www.blogger.com/profile/07200178774058910421noreply@blogger.comtag:blogger.com,1999:blog-2158853543793456735.post-9435334359487930322010-04-14T15:00:54.061-07:002010-04-14T15:00:54.061-07:00I worked on some cisco-OCS integrations in the pas...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.<br /><br />30 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.Anonymousnoreply@blogger.com