This was a interesting project I completed recently but in the end it was pretty simple. Using the group mailbox as the voicemail deposit for a response group is great when multiple people need access to the information. My requirement was when different people are on call and need access to off hour’s voicemails to meet their SLA. There are a couple of steps but its no different than setting up a user in OCS and enabling them for Unified Messaging in Exchange 2007.
Step 1. Enable the group mailbox Active Directory account for OCS and enterprise voice. Since you are not going to be directly routing calls to the OCS user there is no need to use a PSTN DID. I like the fake number range 555-555-0100 to 0199 as it will never be used on the PSTN.
Step 2. Enable group mailbox for unified messaging. Again with the fake number as the subscriber extension. I also like to use the response group PSTN DID as a second extension for the user as this means that the fake number isn’t required to be advertised for those that need to call into Outlook Voice Access to check voicemail. They only need to know the extension of the response group.
Step 3. Add the group mailbox SIP URI to the response group for queue timeout and overflow to go to voicemail.
Step 4. Setup the voicemail greeting message for the group mailbox.
Pretty simple but very effective. I am sure there are a few variations to this configuration that I just haven’t tried but this worked well and the customer was happy which makes me happy.
Response groups are something that aren’t talked about much as far as flexibility and different things you can do with them. So if you have an interesting configuration please let me know.
OC Phone Edition Upgrade Resources
Recently I had the job of upgrading some very early beta versions of the Tanjay from Polycom and LG-Nortel. This was a trying process but there were some very valuable blog resources that I used to help get me through it. The new update service is really a blessing as these devices had been left the way they were because frankly the old way of upgrading them with the SharePoint server was a pain and I never committed enough time to get it working. With the new upgrade service available, I felt it was time to take a look at both the R2 update service and the new R2 OC Phone Edition software.
I won’t go through my process blow by blow but I really want people to be aware of these great resources for upgrading beta software for the phone edition if you hadn’t seen them before. First off is Rui Silvas Blog "UCspotting" and in particular three entries that pertain to upgrading beta software:
The OCPhone Update Wars: The Return of the LG-Nortel 1.0.199
http://blogs.technet.com/ucspotting/archive/2009/05/23/3244869.aspx
Note: One thing I noted that wasn’t mentioned in Rui’s post was when the LG-Nortel phone was at the interim upgrade point the phone went to the initial configuration screen where you calibrate the screen. Not until after you do this does the upgrade process continue to the latest version you have released. This may have been an issue that only I have experienced, but it happened on all the LG-Nortel phones I upgraded.
How to upgrade Polycom CX700 1.0.452.0 using the OCS 2007 R2 Device Update Service
http://blogs.technet.com/ucspotting/archive/2009/04/16/how-to-upgrade-polycom-cx700-1-0-452-0-using-the-ocs-2007-r2-device-update-service.aspx
Note: Rui mentions in this entry that he didn’t require WINS to perform the upgrade but I certainly found I needed to have the UCUpdates entry available in WINS for it to work.
Troubleshooting OCS 2007 R2 Device Update Service for Communicator Phone Edition
http://blogs.technet.com/ucspotting/archive/2009/03/11/troubleshooting-ocs-2007-r2-device-update-service-for-communicator-phone-edition.aspx
Three great blog posts that without I would have been truly stuck in the weeds.
The last one is from the OCS team on OC phone edition error codes.
http://communicationsserverteam.com/archive/2008/07/22/228.aspx
Another handy resource.
You may have noticed in my blog entries I point to the work of others that have helped me a great deal rather than just reprint it here. I find sometimes in the blogosphere people reprint the work of others without giving credit or direction to where they found it. For me its not about the credit or reprinting the material that I could just link to but helping others find the right resources that are worthy of a mention. My2cents.
Anyway, as I always sign off on TechNet. I hope this helps:)
I won’t go through my process blow by blow but I really want people to be aware of these great resources for upgrading beta software for the phone edition if you hadn’t seen them before. First off is Rui Silvas Blog "UCspotting" and in particular three entries that pertain to upgrading beta software:
The OCPhone Update Wars: The Return of the LG-Nortel 1.0.199
http://blogs.technet.com/ucspotting/archive/2009/05/23/3244869.aspx
Note: One thing I noted that wasn’t mentioned in Rui’s post was when the LG-Nortel phone was at the interim upgrade point the phone went to the initial configuration screen where you calibrate the screen. Not until after you do this does the upgrade process continue to the latest version you have released. This may have been an issue that only I have experienced, but it happened on all the LG-Nortel phones I upgraded.
How to upgrade Polycom CX700 1.0.452.0 using the OCS 2007 R2 Device Update Service
http://blogs.technet.com/ucspotting/archive/2009/04/16/how-to-upgrade-polycom-cx700-1-0-452-0-using-the-ocs-2007-r2-device-update-service.aspx
Note: Rui mentions in this entry that he didn’t require WINS to perform the upgrade but I certainly found I needed to have the UCUpdates entry available in WINS for it to work.
Troubleshooting OCS 2007 R2 Device Update Service for Communicator Phone Edition
http://blogs.technet.com/ucspotting/archive/2009/03/11/troubleshooting-ocs-2007-r2-device-update-service-for-communicator-phone-edition.aspx
Three great blog posts that without I would have been truly stuck in the weeds.
The last one is from the OCS team on OC phone edition error codes.
http://communicationsserverteam.com/archive/2008/07/22/228.aspx
Another handy resource.
You may have noticed in my blog entries I point to the work of others that have helped me a great deal rather than just reprint it here. I find sometimes in the blogosphere people reprint the work of others without giving credit or direction to where they found it. For me its not about the credit or reprinting the material that I could just link to but helping others find the right resources that are worthy of a mention. My2cents.
Anyway, as I always sign off on TechNet. I hope this helps:)
CUCiMOC the Final say
Early on I posted about “CUCiMOC is it too late”. I got some interesting feedback from a couple of people that are either in the process of deploying or are deployed. One thing I have noticed is that anything about CUCiMOC received the most hits on my blog this month. So people are certainly interested in what it has to offer and what others have to say about it.
So I did a little looking around on the web and come across a few other bloggers that have some interesting views on this piece of software. Adam’s UC blog is a fairly impartial view of CUCiMOC and he really does a great job describing and weighing up some of the pro’s and con’s. The second one I found interesting and a little amusing was Jason Shaves blog post titled, “CUCiMOC …what a crock”. I think the title alludes somewhat to Jason’s opinion of CUCiMOC.
Having looked and tried the software I have come to my own opinion. CUCiMOC is a good telephony product for the small to midsized enterprise that aren’t all that fused with UC and have the desktop power available (it certainly ran pretty sadly on my Dell Latitude D600). To me CUCiMOC breaks the UC model and is only slightly better than running Cisco IP Communicator and Microsoft Office Communicator on the same laptop with RCC tying them together(to me this isn’t real UC either). At least if you did the later you could still run Cisco Video Advantage and have video. The only major benefit in my opinion is the changes to RCC. I think Cisco needed to do this so that CUPS wasn’t necessary and to ensure the continuation of the feature after Microsoft sunset the current RCC integration. Other benefits like one dial plan etc, to me are minor and are balanced out by what you lose by not using OCS as your UC platform.
In my opinion, CUCiMOC in its current form has too many short falls for a company looking to take real advantage of UC, especially if you are already paying for the enterprise cal for OCS. I could probably go into all of the shortfalls here but if you have already read Jason’s blog I think you are well aware of what they are. I think in the longer term this is more of a hold over till they fully integrate Jabber into their portfolio and make it part of the workspace license agreement with customers. I think the Webex Connect integration is just the start to a much larger effort to take advantage of what they purchased with Jabber. In the end this is just my educated guess at their product roadmap by piecing together their purchases and product releases but it certainly makes sense to me anyway and probably most Cisco observers.
CUCiMOC (with some improvements) has the potential to make Microsoft sit up and pay attention especially if customers stall OCS Enterprise voice with what I consider a workaround to what could be a bigger Cisco plan. The downfall of stalling of course is missing out on the benefits from what OCS and Microsoft UC has to offer especially if you have already purchased the license:-)
So I did a little looking around on the web and come across a few other bloggers that have some interesting views on this piece of software. Adam’s UC blog is a fairly impartial view of CUCiMOC and he really does a great job describing and weighing up some of the pro’s and con’s. The second one I found interesting and a little amusing was Jason Shaves blog post titled, “CUCiMOC …what a crock”. I think the title alludes somewhat to Jason’s opinion of CUCiMOC.
Having looked and tried the software I have come to my own opinion. CUCiMOC is a good telephony product for the small to midsized enterprise that aren’t all that fused with UC and have the desktop power available (it certainly ran pretty sadly on my Dell Latitude D600). To me CUCiMOC breaks the UC model and is only slightly better than running Cisco IP Communicator and Microsoft Office Communicator on the same laptop with RCC tying them together(to me this isn’t real UC either). At least if you did the later you could still run Cisco Video Advantage and have video. The only major benefit in my opinion is the changes to RCC. I think Cisco needed to do this so that CUPS wasn’t necessary and to ensure the continuation of the feature after Microsoft sunset the current RCC integration. Other benefits like one dial plan etc, to me are minor and are balanced out by what you lose by not using OCS as your UC platform.
In my opinion, CUCiMOC in its current form has too many short falls for a company looking to take real advantage of UC, especially if you are already paying for the enterprise cal for OCS. I could probably go into all of the shortfalls here but if you have already read Jason’s blog I think you are well aware of what they are. I think in the longer term this is more of a hold over till they fully integrate Jabber into their portfolio and make it part of the workspace license agreement with customers. I think the Webex Connect integration is just the start to a much larger effort to take advantage of what they purchased with Jabber. In the end this is just my educated guess at their product roadmap by piecing together their purchases and product releases but it certainly makes sense to me anyway and probably most Cisco observers.
CUCiMOC (with some improvements) has the potential to make Microsoft sit up and pay attention especially if customers stall OCS Enterprise voice with what I consider a workaround to what could be a bigger Cisco plan. The downfall of stalling of course is missing out on the benefits from what OCS and Microsoft UC has to offer especially if you have already purchased the license:-)
Cisco Gateway Ring Back OCS R2 issue update, take two:
Back in June I reported on what Cisco claimed was a fix for Cisco ISR gateways for a ringback issue that people deploying OCS R2 were experiencing.Inbound calls traversing a Cisco ISR gateway to OCS users were not receiving ring back on the caller endpoint. This included Cisco IP Phones and PSTN users.
I was told a new IOS version that in the long run didn’t seem to do anything but what was really needed was a command on the dial peer that pointed at the mediation server for inbound calls to OCS. This is best used with the certified IOS version c2800nm-advipservicesk9-mz.124-24.T.bin for interoperability for OCS R2. This command makes the router generate ring tone locally rather than rely on early media from OCS.
no voice call send-alert
dial-peer voice x voip
tone ringback alert-no-pi
This is a pretty easy fix and also works for IP-IP GW scenarios. Thanks to Jared on the Technet forums for sticking with the issue and finding the solution.
I was told a new IOS version that in the long run didn’t seem to do anything but what was really needed was a command on the dial peer that pointed at the mediation server for inbound calls to OCS. This is best used with the certified IOS version c2800nm-advipservicesk9-mz.124-24.T.bin for interoperability for OCS R2. This command makes the router generate ring tone locally rather than rely on early media from OCS.
no voice call send-alert
dial-peer voice x voip
tone ringback alert-no-pi
This is a pretty easy fix and also works for IP-IP GW scenarios. Thanks to Jared on the Technet forums for sticking with the issue and finding the solution.
OCS Response Groups not being able to dial an external extension
My main man Doug is back at it again with another quick fix to an OCS problem. This time it’s to do with response groups. I had an issue a few weeks back that required a response group to forward a call to our Enterprise help desk that is external to OCS, but for some reason I could not get the timeout function of the queue to forward to an external number. As I have mentioned before Doug is a pretty bright dude so I bugged him about it. With a bit of investigative work Doug was able to narrow down the issue in pretty short order. Here is Doug’s blog entry that describes the issue and solution, as well as the process to narrow down the issue.
The problem is based around the response group’s use of the default voice policy. Basically if you have no routes for the default policy, forwarding to external PSTN or other numbers is not going to work. After reviewing Doug’s work I went for the simple solution and added a restrictive route to the default phone usage record to allow outbound routing from the response group. Seeing as response groups is the only object that will ever use the default I felt it was a pretty safe bet.
The problem is based around the response group’s use of the default voice policy. Basically if you have no routes for the default policy, forwarding to external PSTN or other numbers is not going to work. After reviewing Doug’s work I went for the simple solution and added a restrictive route to the default phone usage record to allow outbound routing from the response group. Seeing as response groups is the only object that will ever use the default I felt it was a pretty safe bet.
OCS Mediation Server serving up Caller Name
This has been a popular topic on the TechNet forums.The OCS mediation server previously stripped out the caller name from inbound and outbound calls that pass through it. Now with the latest OCS R2 patches, this feature has been implemented and I am here to testify that caller name is now passed inbound and outbound. Even though the Kb article outlining the changes to the mediation server do not mention the feature, the changes are certainly in there. Inbound the caller name appears in the toast that appears on the inbound call but it is not displayed in the call window.
The mediation server requires upgrading with the patches. This will automatically enable inbound caller name. Outbound caller name requires a .conf file. See the KB article here for creating the required file. The file creation and insertion is simple but it is required on every mediation server in your network you require caller name.
The mediation server requires upgrading with the patches. This will automatically enable inbound caller name. Outbound caller name requires a .conf file. See the KB article here for creating the required file. The file creation and insertion is simple but it is required on every mediation server in your network you require caller name.
Nesting OCS Response Group Workflows
This is an interesting case from the Technet forums that resulted in a workable solution. The question raised was “After having worked with OCS for several months, one thing is especially frustrating. How are we supposed to build factored, meaningful, maintainable workflows without the ability to chain them together?” This got me thinking about some recent testing I had done using the timeout value for queues. If we create a low timeout value for the queue then we could push the call to another contact object without interuption and hence a new response group workflow.
I know that I wouldn’t be the first to think of this but using the queue in this manner gives several benefits. First, it creates contact object for the branches in the ACD so it allows the contacts to be used directly since they now have a Tel URI associated with them. It allows users to transfer people directly to another queue rather than at the beginning of the ACD and having to go through the menu. Jon from Data Balance threw together this diagram to show what he did. This could really open up some quite complex scenarios.
Jon did point out a pitfall with his testing though. The caller will hear ringing instead of MOH. Not everyone will be happy with that so it may only be suitable in some instances.
Thanks to Jon from Data Balance for sharing his diagram with me and the hard work he did testing to ensure the idea worked. I really enjoy this type of adhoc design thinking, especially when it works :-)
I know that I wouldn’t be the first to think of this but using the queue in this manner gives several benefits. First, it creates contact object for the branches in the ACD so it allows the contacts to be used directly since they now have a Tel URI associated with them. It allows users to transfer people directly to another queue rather than at the beginning of the ACD and having to go through the menu. Jon from Data Balance threw together this diagram to show what he did. This could really open up some quite complex scenarios.
Jon did point out a pitfall with his testing though. The caller will hear ringing instead of MOH. Not everyone will be happy with that so it may only be suitable in some instances.
Thanks to Jon from Data Balance for sharing his diagram with me and the hard work he did testing to ensure the idea worked. I really enjoy this type of adhoc design thinking, especially when it works :-)