Besides the format change to make it easier to read, the OIP certification page has had two important updates. First is the edition of Verizon as a certified SIP trunking service provider and second is the addition of Avaya as a supported IP-PBX with the use of the Communications Manager SIP Enablement Server. The software version tested is 4.0 which does carry some known limitations but some of these are resolved with 5.x. See below
Known Limitations:
Configuration requires setting "Alternate Route Timer(sec)" value from default of 10 sec to 30 sec. The configuration should show "Alternate Route Timer(sec): 30" in the corresponding SIP signaling group.
When an call is ringing to the Office Communicator user, the caller (either on an Avaya station or a PSTN line routed through the PBX) will not get ring back tone. This issue has been resolved by Avaya with the 5.x software releases.
Quality of Experience reports will not contain information regarding jitter and packet loss.
Comfort noise generation is not supported. As a result, comfort noise is not played on Office Communicator.
ISDN Failover is not supported from an OCS perspective. If the Avaya PBX is being used for PSTN connectivity and multiple T1's are being utilized, an OC client will not retry a call based on a T1 being unavailable. It may be possible to configure the Avaya to not assign outbound calls from OCS to an unavailable T1, but this configuration was not tested.
Look for more posts on Avaya interop coming soon.
5 Most Popular Posts
I keep a pretty good track of what’s being viewed on the blog and the most viewed topics. There is a good mix of topics that are the most popular but the ones below even though some have been on the blog for quite a while keep coming to the top.
The first post has been at the top and stayed at the top since I first published it. Communicator integration with third party VoIP applications is a topic that continues to be of intense interest as more company’s release these types of plugins. Writen in collaberation with other Microsoft technical experts this is one of the few blog posts out there that go into this kind of detail around replacing native features of Communicator.
http://voipnorm.blogspot.com/2010/01/microsoft-communicator-native-versus.html
This next post is more technical in nature and is a quick post about lighting up the MWI feature in Exchange 2010 when integrating with Cisco UCM 5.x and beyond.
http://voipnorm.blogspot.com/2009/11/exchange-2010-um-mwi-enablement-for.html
While at my previous position I wrote a few articles on CUCiMOC that just keep creeping to the top of my most popular posts. The first is related to installing and configuration experience. CUCiMOC either has a lot of interest out there or not very clear documentation for installation because folks keep coming back.
http://voipnorm.blogspot.com/2009/07/cucimoc-install-and-configuration.html
The second article about CUCiMOC that has kept coming up is more a conversational piece on some of the things to consider with CUCiMOC. This was close to first release of the product and not to much was known on the how to as far as integration goes. Still an interesting look back at first impressions.
http://voipnorm.blogspot.com/2009/05/cucimoc-is-it-too-late.html
This last one is bug related with Cisco MS interoperability and ISR gateways. Although it hits the top of my list there is a related post that will help with this issues below the first link that people seem to miss.
http://voipnorm.blogspot.com/2009/06/cisco-gateway-ringback-issue-with-ocs.html
http://voipnorm.blogspot.com/2009/07/ring-back-workaround-by-doug.html
I hope this has been informative and helpful. Sometimes getting to older posts that are important and helpful can be hard as search engines don’t always pickup on key words.
VoIPNorm
The first post has been at the top and stayed at the top since I first published it. Communicator integration with third party VoIP applications is a topic that continues to be of intense interest as more company’s release these types of plugins. Writen in collaberation with other Microsoft technical experts this is one of the few blog posts out there that go into this kind of detail around replacing native features of Communicator.
http://voipnorm.blogspot.com/2010/01/microsoft-communicator-native-versus.html
This next post is more technical in nature and is a quick post about lighting up the MWI feature in Exchange 2010 when integrating with Cisco UCM 5.x and beyond.
http://voipnorm.blogspot.com/2009/11/exchange-2010-um-mwi-enablement-for.html
While at my previous position I wrote a few articles on CUCiMOC that just keep creeping to the top of my most popular posts. The first is related to installing and configuration experience. CUCiMOC either has a lot of interest out there or not very clear documentation for installation because folks keep coming back.
http://voipnorm.blogspot.com/2009/07/cucimoc-install-and-configuration.html
The second article about CUCiMOC that has kept coming up is more a conversational piece on some of the things to consider with CUCiMOC. This was close to first release of the product and not to much was known on the how to as far as integration goes. Still an interesting look back at first impressions.
http://voipnorm.blogspot.com/2009/05/cucimoc-is-it-too-late.html
This last one is bug related with Cisco MS interoperability and ISR gateways. Although it hits the top of my list there is a related post that will help with this issues below the first link that people seem to miss.
http://voipnorm.blogspot.com/2009/06/cisco-gateway-ringback-issue-with-ocs.html
http://voipnorm.blogspot.com/2009/07/ring-back-workaround-by-doug.html
I hope this has been informative and helpful. Sometimes getting to older posts that are important and helpful can be hard as search engines don’t always pickup on key words.
VoIPNorm
What is Blocking you?
Whats blocking your organization from deploying OCS R2 Enterprise Voice?
Be open and honest all comments are welcome.
Be open and honest all comments are welcome.
Microsoft Communicator Native versus Integrated Part 2: Remote Scenarios
This is the second part in the series that focus’s in on voice capabilities and how removing native functionality from Microsoft Office Communicator can have an adverse effect on a deployment. This post I plan to discuss remote access scenarios. I think this really is a major differentiator between native and third party application for VoIP but enough of me waffling on let’s get to the first diagram.
Remote user scenario with third party application for VoIP integration…
Products and Features
Office Communicator – IM, Presence, desktop sharing
Third Party Application for VoIP – Telephony and video if available
As you can see in this diagram we are forced to run the third party VoIP application over either a hardware or software VPN separate from edge services that are available with OCS. We now have a more complex VPN setup having to spilt tunnel communication services and in some cases VPN services may not be designed to take large amounts of real time media traffic. I always think back to the classic example of where I live when it snows. When no one is capable of actually being on site and the VPN services are carrying a significant load now voice service may be effected even though data services may be working fine. Meanwhile services over the OCS access edge are unaffected due to having purpose built access on the perimeter. This setup also removes the use of RT Audio codec which is specifically designed for uncontrolled networks like the Internet to improve the user’s voice experience. With this setup they are more than like only able to complete calls using G.711 or G.729 which are affected by network degradation of more than 1% whereas RTAudio will work acceptably with up to 10% packet loss.
In some circumstance company’s do not allow the OCS edge forcing all services through a VPN. In this case using RTAudio which is native with Communicator would still be beneficial due to its ability to handle packet loss and jitter. From my own personal experience and also from talking with customers using more traditional codecs, i.e. G.711 and G.729, audio quality over VPN tends to suffer.
Remote worker with Native Communicator Features…
Products and Features
Office Communicator – IM, Presence, desktop sharing, voice and video
Looking at the native solution we begin to see some immediate benefits. First is an access edge specifically designed for real time communication traffic including voice, video, IM, presence and desktop sharing. The second point is that we no longer need to route media traffic back to our internal resources consuming vital Internet bandwidth when both users are remote to our internal network. If one of our users were internal the media would in fact flow through the access edge and not over a VPN service limiting reliance and lowering bandwidth consumption on VPN services. Lastly we have now removed the reliance on the desktop to complete our integration and instead have chosen interoperability at a server level. Of course there are more reasons to enable edge services with OCS than just telephony. To me the most compelling reason to use the edge has always been federation with business partners to better enable collaboration and lower communication costs.
Just to recap. OCS remote scenarios are designed to be secure and leverage the internet to allow peer to peer connections reducing bandwidth requirements and allowing OCS to scale to large enterprise needs. By removing the native functionality and replacing with a plugin not only have you increased desktop reliance but also made telephone dependent on VPN services to allow functionality. So when you consider what it takes to keep telephony control on a separate system through desktop integration there is much more to consider than just licensing.
Hopefully this has been an interesting series. Please feel free to post comments or email me your feedback. For more on this subject please check out the following post:
http://voipnorm.blogspot.com/2010/01/microsoft-communicator-native-versus.html
Remote user scenario with third party application for VoIP integration…
Products and Features
Office Communicator – IM, Presence, desktop sharing
Third Party Application for VoIP – Telephony and video if available
As you can see in this diagram we are forced to run the third party VoIP application over either a hardware or software VPN separate from edge services that are available with OCS. We now have a more complex VPN setup having to spilt tunnel communication services and in some cases VPN services may not be designed to take large amounts of real time media traffic. I always think back to the classic example of where I live when it snows. When no one is capable of actually being on site and the VPN services are carrying a significant load now voice service may be effected even though data services may be working fine. Meanwhile services over the OCS access edge are unaffected due to having purpose built access on the perimeter. This setup also removes the use of RT Audio codec which is specifically designed for uncontrolled networks like the Internet to improve the user’s voice experience. With this setup they are more than like only able to complete calls using G.711 or G.729 which are affected by network degradation of more than 1% whereas RTAudio will work acceptably with up to 10% packet loss.
In some circumstance company’s do not allow the OCS edge forcing all services through a VPN. In this case using RTAudio which is native with Communicator would still be beneficial due to its ability to handle packet loss and jitter. From my own personal experience and also from talking with customers using more traditional codecs, i.e. G.711 and G.729, audio quality over VPN tends to suffer.
Remote worker with Native Communicator Features…
Products and Features
Office Communicator – IM, Presence, desktop sharing, voice and video
Looking at the native solution we begin to see some immediate benefits. First is an access edge specifically designed for real time communication traffic including voice, video, IM, presence and desktop sharing. The second point is that we no longer need to route media traffic back to our internal resources consuming vital Internet bandwidth when both users are remote to our internal network. If one of our users were internal the media would in fact flow through the access edge and not over a VPN service limiting reliance and lowering bandwidth consumption on VPN services. Lastly we have now removed the reliance on the desktop to complete our integration and instead have chosen interoperability at a server level. Of course there are more reasons to enable edge services with OCS than just telephony. To me the most compelling reason to use the edge has always been federation with business partners to better enable collaboration and lower communication costs.
Just to recap. OCS remote scenarios are designed to be secure and leverage the internet to allow peer to peer connections reducing bandwidth requirements and allowing OCS to scale to large enterprise needs. By removing the native functionality and replacing with a plugin not only have you increased desktop reliance but also made telephone dependent on VPN services to allow functionality. So when you consider what it takes to keep telephony control on a separate system through desktop integration there is much more to consider than just licensing.
Hopefully this has been an interesting series. Please feel free to post comments or email me your feedback. For more on this subject please check out the following post:
http://voipnorm.blogspot.com/2010/01/microsoft-communicator-native-versus.html
Tanjay Appears on NBC's "The Office"
Okay, so maybe not the real "Office" on NBC but for now two bobbleheads is the best we could do.
Enjoy:)
Enjoy:)
CUCM and OCS Ringing Dual Device Tips
Recently in the TechNet Forums I have seen a number of questions regarding using simultaneous ringing from CUCM or OCS to ring both a Cisco IP phone and Microsoft Communicator at the same time. Not to get this confused with dual call forking which this is not, I plan to use the term dual ringing devices. The Nortel CS1000 is the only OIP certified PBX that is capable of dual call forking. Cisco and Microsoft can both dual ring devices using different but similar methods . Due to this not being true dual call forking which has feedback mechanisms to avoid call loops the configuration between OCS and CUCM does not. Which means if configured incorrectly could cause some significant issues.
I don’t want to go in to the actual configuration but want to give some tips on what can help when doing this type of configuration and deciding if its right for your organization.
Tip 1. Where are my incoming PSTN DID’s terminating? Most likely calls from the PSTN may be the most critical. So having both devices ring when this occurs will be something you want. If you do not have both systems with direct PSTN access the best place to do dual ringing devices will be the system that is configured for the gateway that is terminating PSTN calls.
Tip 2. Choose one system that will do the dual ringing devices and live with it. Take the good with the bad and pick one system that will be configured to ring both endpoints. This falls into keeping it simple to avoid call loops.
Tips 3. Make sure you let users know what will work and what wont. Depending on where you ring from sometimes both devices will ring and sometimes it won’t but all incoming PSTN calls will, as an example.
Tip 4. If it’s not the right fit for an organization don’t do it because you can. For large enterprises this could be just too much work to keep a track of. Some people have it, some don’t, we have it on this cluster and not one that etc, etc. All in all it ends in much confusion and may be some mistakes which can leave a bad taste in a user’s mouth. So evaluate the value of doing this before committing to rolling it out everywhere.
Tip 5. Make this a server side configuration don’t leave it in the hands of your users. There are a couple of options to make this server side only configuration and if you plan on doing this it would be my recommendation to make it server side rather than user configured.
I hope these tips help in making the right choices for your organization.
I don’t want to go in to the actual configuration but want to give some tips on what can help when doing this type of configuration and deciding if its right for your organization.
Tip 1. Where are my incoming PSTN DID’s terminating? Most likely calls from the PSTN may be the most critical. So having both devices ring when this occurs will be something you want. If you do not have both systems with direct PSTN access the best place to do dual ringing devices will be the system that is configured for the gateway that is terminating PSTN calls.
Tip 2. Choose one system that will do the dual ringing devices and live with it. Take the good with the bad and pick one system that will be configured to ring both endpoints. This falls into keeping it simple to avoid call loops.
Tips 3. Make sure you let users know what will work and what wont. Depending on where you ring from sometimes both devices will ring and sometimes it won’t but all incoming PSTN calls will, as an example.
Tip 4. If it’s not the right fit for an organization don’t do it because you can. For large enterprises this could be just too much work to keep a track of. Some people have it, some don’t, we have it on this cluster and not one that etc, etc. All in all it ends in much confusion and may be some mistakes which can leave a bad taste in a user’s mouth. So evaluate the value of doing this before committing to rolling it out everywhere.
Tip 5. Make this a server side configuration don’t leave it in the hands of your users. There are a couple of options to make this server side only configuration and if you plan on doing this it would be my recommendation to make it server side rather than user configured.
I hope these tips help in making the right choices for your organization.
Review- Savi Office WO201 Wireless Headset System
This is my first review for 2010. I was recently using the Savi Office at my previous job but had to give it up when I left my position to work for Microsoft. Well this week I had the fortune to get a new one. I say fortune because I really like this device. At my home work station I am lucky enough to have Tanjay (OC phone edition) along with Communicator on my PC so really the best of both worlds and the Savi office is a great compliment to my setup. I have my Tanjay setup for phone control and the Savi Office has a normal telephone jack along with USB to use with Communicator on the PC.
To write the review I set up the Savi Office plugged into my PC and desk phone just to go through all the features. One thing I did find is that the PerSono Call software was really a requirement in this situation to make sure that I could setup the Savi Office base station to my liking. Although if I had just plugged it into the PC only it would have been fine and I dare say the PerSono Call software wouldn’t have been required.
Windows 7 detected the Savi Office no problems and it worked well without issues. As I had said this is a device I had used before and from experience the sound quality is great. This is a DECT device so it has a good range of about 350ft so not quite enough to make it to my mailbox but pretty close. The headset controls are pretty easy to work out with the up and down volume buttons being multifunction. For base station device selection for up and mute being the down volume button.
The ear piece design I received is very similar to that of the Voyager UC which I talked about in my favorite devices entry. Extremely comfortable and you forget you have it on after a while.
If anyone is to have an issue with this device it would be the price. It is in the high end at $375 retail but it is also a very high quality and comparable to other headsets of this type currently on the market. If you can justify the price it is a great office headset.
To write the review I set up the Savi Office plugged into my PC and desk phone just to go through all the features. One thing I did find is that the PerSono Call software was really a requirement in this situation to make sure that I could setup the Savi Office base station to my liking. Although if I had just plugged it into the PC only it would have been fine and I dare say the PerSono Call software wouldn’t have been required.
Windows 7 detected the Savi Office no problems and it worked well without issues. As I had said this is a device I had used before and from experience the sound quality is great. This is a DECT device so it has a good range of about 350ft so not quite enough to make it to my mailbox but pretty close. The headset controls are pretty easy to work out with the up and down volume buttons being multifunction. For base station device selection for up and mute being the down volume button.
The ear piece design I received is very similar to that of the Voyager UC which I talked about in my favorite devices entry. Extremely comfortable and you forget you have it on after a while.
If anyone is to have an issue with this device it would be the price. It is in the high end at $375 retail but it is also a very high quality and comparable to other headsets of this type currently on the market. If you can justify the price it is a great office headset.
Microsoft Communicator Native Versus Integrated Part 1: Server Versus Client Side Telephony Integration
I am hoping this makes an interesting read, and gives some food for thought. This particular post is describing all third party Microsoft Office Communicator plugin applications that aim to remove native functionality from Office Communicator and replace it with their own. Often this is to avoid paying for the E-Cal but more often than not you are losing much more than just telephony by dropping down to the Standard-cal. When you look at UC platforms it’s important to consider what you are buying as a whole and not just one portion. Often when moving a portion of functionality to another system you are adding more complexity than first realized and in the long run more cost both in licensing and manageability.
The published API’s have opened up OCS and OC to the developer world and allowed developers to extend the value of OCS. Even the development of the third party applications for VoIP are indeed proof of the flexibility OCS provides as a development platform. But in the same vein replacing elements of native features even though it is possible can raise questions of the value of doing so.
“We believe that the native functionality in Office Communicator provides a much better and more complete user experience …… is a less complex and more cost-effective integration technique than adding additional software to every desktop”. BJ Haberkorn, OCS Senior Product Manager.
BJ makes some interesting comments but what’s really going on in the back ground that makes adding a third party application for VoIP more complex than native OC features?
Let’s take a look at the third party application for VoIP integration…
Products and features in diagram
Office Communicator – IM and presence
Integrated softphone/video -Telephony and video (if available)
I wanted to paint a complete picture of what’s happening with this type of integration from a generic point of view. Depending on which vendor you choose the features may change somewhat and may even look more or less complex than is presented here. Remote call control has been omitted as most vendors are not providing it through this integration but through a separate CSTA gateway that is unrelated to the third party application for VoIP (see diagram 2). So from the top as per the diagram:
1) LDAP information in some circumstance comes from direct integration from the client plugin.
2) SIP/TLS for IM and presence. Some vendors are recommending turning off all Communicator features other than IM and presence.
3) Call signaling flowing from the third party softphone integration to control call( either a soft switch or IP PBX)
4) API integration to pass presence and other desktop level integration
5) Video integration if available. This may or may not be the same application that provides telephony integration so it may require additional signaling depending on the manner in which it is deployed.
There is a lot going on in this diagram and most of it at the desktop. This is purely from separating out one service (telephony), two if you count video as well if it is supported by the plugin. If video is not supported then you are back to doing it with Microsoft Communicator or another application.
So this presents an interesting scenario but what if we compare this to Enterprise voice. To be fair the next diagram shows Microsoft Communicator and non-native remote call control integration to show a complete feature comparison as some third party VoIP plugins do offer this capability. Rather than enable these features as desktop integration how does it compare to server side integration.
Office Communicator enabled for Enterprise Voice with Remote Call Control of an IP Phone…
Products and features in diagram
Office Communicator - IM, Presence, Video Telephony and RCC client
CSTA Gateway – CSTA to CTI conversion
IP phone- Telephony and RCC endpoint
Even though this does add to the manageability of the solution with some work being required to get the SIP/CSTA Gateway to work, it is still a simpler solution than our first diagram. This is because there is no desktop integration. All integration is being done server side for both enterprise voice and RCC. By leveraging SIP/CSTA OCS now has the capability to control a PBX phone with the help of a CSTA Gateway.
Breaking down each of the components by numbers..
1) SIP/TLS encrypted signaling
2) SIP/CSTA – protocol used to talk to traditional or IP PBX’s for Remote call control
3) Direct SIP Trunk to IP PBX/Soft switch much like any traditional tie trunk between two PBX’s to enable enterprise voice PSTN calls
4) CTI conversion completed by SIP/CSTA Gateway for click to call
5) SIP signaling to the IP phone
6) RTP/Audio – RTP media stream. In this case audio only. I have included it this last slide to show how the RTP streams would flow between the two scenarios while both enabled. This shows that even with both these technologies deployed the RTP stream is no different from the straight EV integration to a PBX. We have just layered on RCC server side integration.
The main down side of Remote Call Control is it is a lot of work with added server and licensing costs by the SIP/CSTA gateway vendor, this makes proving an ROI for this feature much harder. By including the softphone capability of OC with RCC we now have the potential of enabling remote workers and improved OCS A/V conferencing experience without being tied to the desktop phone. The setup is fairly clean just by looking at the diagram even with Enterprise Voice still available via a direct SIP trunk. I would certainly recommend deploying enterprise voice if you are going to deploy RCC so users are able to choose which system to use as their telephony device. This also allows the advantage of remote user scenarios when enterprise voice is deployed without the need for a VPN solution which third party integrations would require as they are not support by OCS edge and similarly do not generally have an edge solution of their own except for VPN.
Next is Office Communicator and OC Phone edition…
Products and features in diagram
Communicator – IM and presence, video, telephony and Phone control with OC phone Edition
OC Phone Edition – Telephony, presence and phone control endpoint
In this diagram I have included Phone Control as a feature with the OC Phone edition (or Tanjay). I wanted to present the complete Microsoft native solution. I have not included dual call forking (in the true OIP sense). Using OCS simultaneous ring to ring additional phones is supported but there is no additional signaling paths than what has been described. Whether it is a PBX IP phone or cell phone it really doesn’t matter both function in the same manner when passing signaling through a direct SIP trunk deployment.
So stepping through each point:
1) SIP TLS encrypted call signaling when using Office Communicator for IM, Presence , Voice and video
2) SIP TLS encrypted call signaling OC phone edition for voice and presence
3) SIP Trunk to IP PBX or Soft switch much like any traditional tie trunk between two PBX’s
4) SIP call signaling to the IP phone
5) USB cable to enable Phone Control function of the OC Phone Edition device with Office Communicator
Things are significantly different between the three diagrams. This diagram presents a clearly server side integration. Using the SIP trunk between the two systems now allows Office Communicator to be used as softphone. This removes the burden from desktop administration of the integration displayed in the third party application for VoIP diagram. Even with including Phone Control in the native solution we have been able to greatly simplify not only the signaling required but also the deployment scenarios. Removing the second application from the desktop (third party softphone) has reduced software deployment dependencies and removed the need to disable native Office Communicator features to avoid end user confusion.
In conclusion, when you break down each scenario you begin to see how OCS Enterprise Voice can simplify the desktop environment. Adding RCC in conjunction with Enterprise Voice does enable a user to control a PBX phone with Communicator but does add complexity which may have a low ROI for RCC. Third party applications for VoIP add more complexity at the desktop which in the end could affect security, manageability, upgrade roadmaps and ROI especially in large organizations. Finally, OCS enterprise voice with native phone control has the potential to simplify and secure both audio, signaling and phone control natively without complex integrations.
This post, besides being quite lenthy, has really focused in on Voice scenarios but there is more that make up the complete MS UC experience. Look for more comparison posts coming soon. Please feel free to comment.
The published API’s have opened up OCS and OC to the developer world and allowed developers to extend the value of OCS. Even the development of the third party applications for VoIP are indeed proof of the flexibility OCS provides as a development platform. But in the same vein replacing elements of native features even though it is possible can raise questions of the value of doing so.
“We believe that the native functionality in Office Communicator provides a much better and more complete user experience …… is a less complex and more cost-effective integration technique than adding additional software to every desktop”. BJ Haberkorn, OCS Senior Product Manager.
BJ makes some interesting comments but what’s really going on in the back ground that makes adding a third party application for VoIP more complex than native OC features?
Let’s take a look at the third party application for VoIP integration…
Products and features in diagram
Office Communicator – IM and presence
Integrated softphone/video -Telephony and video (if available)
I wanted to paint a complete picture of what’s happening with this type of integration from a generic point of view. Depending on which vendor you choose the features may change somewhat and may even look more or less complex than is presented here. Remote call control has been omitted as most vendors are not providing it through this integration but through a separate CSTA gateway that is unrelated to the third party application for VoIP (see diagram 2). So from the top as per the diagram:
1) LDAP information in some circumstance comes from direct integration from the client plugin.
2) SIP/TLS for IM and presence. Some vendors are recommending turning off all Communicator features other than IM and presence.
3) Call signaling flowing from the third party softphone integration to control call( either a soft switch or IP PBX)
4) API integration to pass presence and other desktop level integration
5) Video integration if available. This may or may not be the same application that provides telephony integration so it may require additional signaling depending on the manner in which it is deployed.
There is a lot going on in this diagram and most of it at the desktop. This is purely from separating out one service (telephony), two if you count video as well if it is supported by the plugin. If video is not supported then you are back to doing it with Microsoft Communicator or another application.
So this presents an interesting scenario but what if we compare this to Enterprise voice. To be fair the next diagram shows Microsoft Communicator and non-native remote call control integration to show a complete feature comparison as some third party VoIP plugins do offer this capability. Rather than enable these features as desktop integration how does it compare to server side integration.
Office Communicator enabled for Enterprise Voice with Remote Call Control of an IP Phone…
Products and features in diagram
Office Communicator - IM, Presence, Video Telephony and RCC client
CSTA Gateway – CSTA to CTI conversion
IP phone- Telephony and RCC endpoint
Even though this does add to the manageability of the solution with some work being required to get the SIP/CSTA Gateway to work, it is still a simpler solution than our first diagram. This is because there is no desktop integration. All integration is being done server side for both enterprise voice and RCC. By leveraging SIP/CSTA OCS now has the capability to control a PBX phone with the help of a CSTA Gateway.
Breaking down each of the components by numbers..
1) SIP/TLS encrypted signaling
2) SIP/CSTA – protocol used to talk to traditional or IP PBX’s for Remote call control
3) Direct SIP Trunk to IP PBX/Soft switch much like any traditional tie trunk between two PBX’s to enable enterprise voice PSTN calls
4) CTI conversion completed by SIP/CSTA Gateway for click to call
5) SIP signaling to the IP phone
6) RTP/Audio – RTP media stream. In this case audio only. I have included it this last slide to show how the RTP streams would flow between the two scenarios while both enabled. This shows that even with both these technologies deployed the RTP stream is no different from the straight EV integration to a PBX. We have just layered on RCC server side integration.
The main down side of Remote Call Control is it is a lot of work with added server and licensing costs by the SIP/CSTA gateway vendor, this makes proving an ROI for this feature much harder. By including the softphone capability of OC with RCC we now have the potential of enabling remote workers and improved OCS A/V conferencing experience without being tied to the desktop phone. The setup is fairly clean just by looking at the diagram even with Enterprise Voice still available via a direct SIP trunk. I would certainly recommend deploying enterprise voice if you are going to deploy RCC so users are able to choose which system to use as their telephony device. This also allows the advantage of remote user scenarios when enterprise voice is deployed without the need for a VPN solution which third party integrations would require as they are not support by OCS edge and similarly do not generally have an edge solution of their own except for VPN.
Next is Office Communicator and OC Phone edition…
Products and features in diagram
Communicator – IM and presence, video, telephony and Phone control with OC phone Edition
OC Phone Edition – Telephony, presence and phone control endpoint
In this diagram I have included Phone Control as a feature with the OC Phone edition (or Tanjay). I wanted to present the complete Microsoft native solution. I have not included dual call forking (in the true OIP sense). Using OCS simultaneous ring to ring additional phones is supported but there is no additional signaling paths than what has been described. Whether it is a PBX IP phone or cell phone it really doesn’t matter both function in the same manner when passing signaling through a direct SIP trunk deployment.
So stepping through each point:
1) SIP TLS encrypted call signaling when using Office Communicator for IM, Presence , Voice and video
2) SIP TLS encrypted call signaling OC phone edition for voice and presence
3) SIP Trunk to IP PBX or Soft switch much like any traditional tie trunk between two PBX’s
4) SIP call signaling to the IP phone
5) USB cable to enable Phone Control function of the OC Phone Edition device with Office Communicator
Things are significantly different between the three diagrams. This diagram presents a clearly server side integration. Using the SIP trunk between the two systems now allows Office Communicator to be used as softphone. This removes the burden from desktop administration of the integration displayed in the third party application for VoIP diagram. Even with including Phone Control in the native solution we have been able to greatly simplify not only the signaling required but also the deployment scenarios. Removing the second application from the desktop (third party softphone) has reduced software deployment dependencies and removed the need to disable native Office Communicator features to avoid end user confusion.
In conclusion, when you break down each scenario you begin to see how OCS Enterprise Voice can simplify the desktop environment. Adding RCC in conjunction with Enterprise Voice does enable a user to control a PBX phone with Communicator but does add complexity which may have a low ROI for RCC. Third party applications for VoIP add more complexity at the desktop which in the end could affect security, manageability, upgrade roadmaps and ROI especially in large organizations. Finally, OCS enterprise voice with native phone control has the potential to simplify and secure both audio, signaling and phone control natively without complex integrations.
This post, besides being quite lenthy, has really focused in on Voice scenarios but there is more that make up the complete MS UC experience. Look for more comparison posts coming soon. Please feel free to comment.
Using VirtualBox for OCS R2 Test Bed
Just a quick entry to talk about VirtualBox. I am currently building an OCS R2 test environment at home and I wanted to keep my Windows 7 home box in tact without reloading it with Windows 2008 to get hyper-V features. One problem. Windows Virtual PC doesn’t support 64bit guest OS’s. Bummer. So looking around I discovered VirtualBox from Sun. An open source free virtualization tool. It seems to work well in Windows 7 and has allowed me to build 64 bit guest OS’s to build my OCS R2 test environment. A great way to keep the advantages of Windows 7 and build my virtual environment for testing.
Originally I was going to use VMware player but come across a snag when it stopped my Windows Live Messenger video from working. Last issue now is how can I build a virtual CUCM platform when it only supports VMware drivers. My quest continues….
Originally I was going to use VMware player but come across a snag when it stopped my Windows Live Messenger video from working. Last issue now is how can I build a virtual CUCM platform when it only supports VMware drivers. My quest continues….
Subscribe to:
Posts (Atom)