Yes, it is nearly the middle of the year (hard to believe) and I thought I would recap the predictions so far and see what has come true and what’s still to come.
Starting at number 10...
10. There will be more prediction lists for 2010 than 2009. With the economy on the down side predictions for 09 are way down.
I think we all seen a drop in IT predictions this year, with company’s strapped for cash who wants to predict the number one thought on everyone’s mind – unemployment. Slam-dunk.
9. Apple will launch a UC application called the iUC. No one will care what it does but you know everyone will want it.
With Steve Jobs on the mend after surgery who know what Apple will do in the last half of the year, with the new iPhone launched recently the iUC is just around the corner I am sure.
8. The new US President will get to keep his Blackberry once he takes office even against advice from security personnel.
Last time I looked the tech-savvy President was still hooked to his BB. Slam-dunk.
7. Free Open Source software will be the only growth industry for anything as budgets tighten.
This one will be hard to quantify, so by admission of any true information to substantiate this claim another slam dunk I would say Just out of interest though here is a quick story on developers turning to open source as the platform of choice.
6. A company will somehow use an ATA, an analog phone and maybe some string to create the first UC enabled analog device.
I think I will take the honors here. Where I work we used an ATA, a Panasonic cordless phone to create what I call the UC AnWifPan (the string was to tie the phone to the users pants as a holder). Look for partners coming soon. Slam-dunk.
5. Due to the downward economy the traditional PBX will make a comeback as a UC enabler.
Okay so maybe a bit of a miss on this one so far, unless you of course count a drop of VoIP conversions as a TDM PBX come back. What the hell. Another slam-dunk.
4. Someone from Cisco will make the claim that Microsoft’s UC solution has to many servers and someone from Microsoft will claim Cisco’s UC solution has to many applications, all this will happen at VoiceCon.
I think this one is a given, I don’t even have to be there to know it happened. Slam dunk.
3. Microsoft and Cisco UC divisions will put their differences behind them after VoiceCon.
This one I think is a miss. Something lead me to believe they could work together in a harmonious way in the UC space. What was I thinking. Although, I didn’t say which VoiceCon. Look for the healing hands in San Francisco.
2. A hardware vendor will make the claim they are a software company.
I think we all know who this is, do I need to say it:-) Slam dunk.
and finally number ...
1. Someone somewhere is going to create a UC application that has nothing to do with UC at all.
This one is for the readers. If you know of a product that has nothing to do with UC but has been marketed as such, please send me an email or make a comment.
Collaboration and a whole bunch of other stuff. BTW I work @ Cisco Systems.
Cisco Gateway Ring Back OCS R2 issue update:
Today I got confirmation that this issue is fixed with 12.4.24T for SIP-TDM but not for CUBE images that allow H323-SIP or SIP-SIP. Hopefully a fix for this is on the way as the CUBE is a useful feature that can help to integrate Cisco’s and MSFT’s solutions together without introducing another vendor if you are a Cisco shop.
The Mediation Server, could it be the interoperability rock star of OCS?
I recently read an interesting post by Matt McGillen. Best of Breed is term that has been banned around by some vendors and analyst as the best approach to UC. Matt makes a great point in his blog about the amount of integration work that is required to make this work and the finger pointing that ensues when something isn’t working. It’s unfortunate but true and sometimes unavoidable when two or three companies are in strong competition with each other. Matt also went on to say the best approach is the platform that is most extensible to suit your company, another point that I agree with.
Unfortunately in reality, Matt’s conclusion is hard to achieve for large scale deployments where multivendor coexistence is more the norm than the exception. How do you magically convert 100,000 handsets to a new system without integration and interoperability? You can’t. In fact Microsoft relies on this fact with their extensive list of third party vendor gateways on offer. Microsoft has certainly provided a rich environment with an extensible platform rich with features which I know is going to hold its place in the market. But when you upgrade and your gateway of choice stops working because they are yet to reach certification or you are held back from upgrading because of this it certainly works in the favor of Cisco. Although for Cisco, this to may mean upgrading a gateway or two when upgrading Communications Manager but if you take the whole hog approach, Cisco more than likely has an IOS image to suit your Cisco gateway of choice already developed.
In the TDM world QSIG, ISDN and other protocols provide the means to interoperability but in the new world where RFC’s are all in the translation how do we reach the interoperability nirvana? Vendors in general have struggled with this universally and with the amount of testing and certification I have completed I am here to tell you they have a long way to go. Not to say they haven’t gone a long way already but it took the telecom industry 100 years to get where they are today.
So where does Microsoft go from here? I think maybe the answer is the mediation server. Do I think Microsoft needs to make their own TDM gateways? No I don’t. Instead I think that the mediation server should be an extensible flexible platform that can be used as an interoperability tool and not a hindrance to the interoperability story similar to what the ISR CUBE product has done for Cisco. I am of course not referring to TDM line cards of any sort but more the flexibility of IP and the protocols that surround it. Why not support H323 or SIP over UDP? The mediation server has the potential to be the interoperability rock star of the OCS platform with out the need for a lot of workarounds or third party solutions. Hopefully the development of the mediation server or what ever role Microsoft chooses to call this intermediate device continues to evolve creating a more flexible solution.
To finish off, this is just my opinion and the Microsoft’s and Cisco’s of the world will continue to do what ever they do to develop and push out their products for us to try and integrate successfully or otherwise. I just hope its gets a little easier:-)
PS. Thanks to Matt for providing such great insight and to the other bloggers on the PointBridge website for great content. It certainly got me thinking.
Unfortunately in reality, Matt’s conclusion is hard to achieve for large scale deployments where multivendor coexistence is more the norm than the exception. How do you magically convert 100,000 handsets to a new system without integration and interoperability? You can’t. In fact Microsoft relies on this fact with their extensive list of third party vendor gateways on offer. Microsoft has certainly provided a rich environment with an extensible platform rich with features which I know is going to hold its place in the market. But when you upgrade and your gateway of choice stops working because they are yet to reach certification or you are held back from upgrading because of this it certainly works in the favor of Cisco. Although for Cisco, this to may mean upgrading a gateway or two when upgrading Communications Manager but if you take the whole hog approach, Cisco more than likely has an IOS image to suit your Cisco gateway of choice already developed.
In the TDM world QSIG, ISDN and other protocols provide the means to interoperability but in the new world where RFC’s are all in the translation how do we reach the interoperability nirvana? Vendors in general have struggled with this universally and with the amount of testing and certification I have completed I am here to tell you they have a long way to go. Not to say they haven’t gone a long way already but it took the telecom industry 100 years to get where they are today.
So where does Microsoft go from here? I think maybe the answer is the mediation server. Do I think Microsoft needs to make their own TDM gateways? No I don’t. Instead I think that the mediation server should be an extensible flexible platform that can be used as an interoperability tool and not a hindrance to the interoperability story similar to what the ISR CUBE product has done for Cisco. I am of course not referring to TDM line cards of any sort but more the flexibility of IP and the protocols that surround it. Why not support H323 or SIP over UDP? The mediation server has the potential to be the interoperability rock star of the OCS platform with out the need for a lot of workarounds or third party solutions. Hopefully the development of the mediation server or what ever role Microsoft chooses to call this intermediate device continues to evolve creating a more flexible solution.
To finish off, this is just my opinion and the Microsoft’s and Cisco’s of the world will continue to do what ever they do to develop and push out their products for us to try and integrate successfully or otherwise. I just hope its gets a little easier:-)
PS. Thanks to Matt for providing such great insight and to the other bloggers on the PointBridge website for great content. It certainly got me thinking.
Cisco Gateway Ringback issue with OCS R2 Mediation server
Over the last few weeks I have been testing OCS R2 mediation server in the lab and I came across a curious problem. Inbound calls from our Cisco environment failed to generate ringback. We are currently deploying using the Cisco ISR setup as an IP-IP GW but this also affected direct SIP when inbound calls passed through the Cisco environment from the PSTN. Cisco have a bug identified (CSCsw34198) and hopefully this will be fixed soon.
The cause of the issue. Early media sort of. Or should I say the flow of messages that allow early media. Below is an excerpt from the bug.
Symptom:Once early media is cut-through in SIP-TDM Gateway using 183/Progress message and later followed by ALERT/180, then the VTSP SPI will suppress the packet as Gateway needs the play local ringback. And later again 183/Progress is received on the Gateway the media is not flowing through as the packets are suppressed in this state and the packets will be unsuppressed only when 200OK/Connect is received.
Conditions:
When first early media is cut-through and later followed by ALERT/180, which suppress the packet as to feed local ringback will reopen for packet only in 200OK/Connect. So any 183/Progress message again used to re-establish the early media between ALERT/180 and Connect/200OK fails.
This problem does not seem to be just limited to OCS R2 integration though, which means it may speed up the resolution.
The cause of the issue. Early media sort of. Or should I say the flow of messages that allow early media. Below is an excerpt from the bug.
Symptom:Once early media is cut-through in SIP-TDM Gateway using 183/Progress message and later followed by ALERT/180, then the VTSP SPI will suppress the packet as Gateway needs the play local ringback. And later again 183/Progress is received on the Gateway the media is not flowing through as the packets are suppressed in this state and the packets will be unsuppressed only when 200OK/Connect is received.
Conditions:
When first early media is cut-through and later followed by ALERT/180, which suppress the packet as to feed local ringback will reopen for packet only in 200OK/Connect. So any 183/Progress message again used to re-establish the early media between ALERT/180 and Connect/200OK fails.
This problem does not seem to be just limited to OCS R2 integration though, which means it may speed up the resolution.
Subscribe to:
Posts (Atom)