I have been testing OC compatible devices for quite some time and in my new position at Microsoft I get the chance to use demo devices on a regular basis. So I have pretty much used or tested nearly every device available. These are a few of my favorites:
Plantronics Voyager Pro UC - In my opinion probably the best USB Bluetooth wireless headset on the market right now that is OC certified. Wireless range is pretty good but not as good as some DECT headsets I have tried but still pretty good. Voice quality and everything else about this headset is pretty solid. It can also be paired with your cell phone but this isn’t something I have tried. Very portable and compact.
Plantronics MCD100-M USB Speakerphone – This is a nice piece of equipment that I use quite often. A solid device that has a 360 degree microphone. Although the shape seems a bit awkward to fit in a computer bag it is indestructible to travel. It goes with me everywhere and is a great device.
Jabra BIZ 2400 – This is my favorite wired headset but it does come with a higher price tag. Nearly indestructible, this device is probably one of the best made devices out there. Great for call center workers or high use workers that spend all day with a headset on.
Microsoft LifeCam Cinema – A solid HD camera without the high price tag. Even though it is HD compatible for Communicator you are going to need a pretty beefy quad core machine to enable HD. The picture quality without HD is still great and it is a solid device that can travel pretty well.
Polycom CX100 – another conferencing phone and a great item for travelers that is slim for the computer bag and solid construction. Voice quality is good and like the Plantronics device, under $100.
Two devices I haven’t had a chance to test but really want to:
Polycom CX300 – This is a USB device that a lot of enterprise customer have been asking about, for one reason. A dial pad. I haven’t had my chance to get my hands on one but when I do I will post my experience.
Jabra PRO 9400 - This device is a multitasking headset with base station that can control a softphone or cell phone simultaneously. Has a nice look with a touch screen display. Coolness factor is way up there. Hopefully I can see one in the flesh really soon.
The list of compatible hardware just keeps growing and the quality improving while the prices are coming down. Sub $50 dollar certified headsets are now available from Plantronics and Jabra giving companies’ great competitive choices.
Happy Holidays from the staff at VoIPNorm
Okay, so when I say staff I mean me. I thought I would finish off the year with my top five most useful blogs I have used or seen this year. This is a based on my biases and perception on how much useful information I think I obtained or is on the blog.
VoIPNorms TOP 5 UC blogs for 2009
5. Unified Communications Group Team Blog – This is Microsoft centric blog but loads of useful information from member of the OCS product group.
4. DTMF – Doug Lawty is a MCS consultant with great OCS voice experience. He has some great information on his blog that is well written. He would have been higher on the list but we need Doug to contribute more often to his blog.
3. Matt McGillen’s blog – Another consultant that has a great perspective on getting things done and working through the issues.
2.UCspotting – Rui Silva is a UC TSP at Microsoft and has a great blog worth checking out. What he doesn’t know about OCS isn’t worth knowing.
1. VoIPNorm – What else did you expect me to say. I said it was based on my biases :)
Anyway, thanks to everyone that has contributed to the content, commented or read the blog this year. Look for more articles on interop, OCS, Wave 14, competitions and a whole bunch of other stuff in 2010.
If you have a blog you think is list worthy please let me know. Leave a comment or email me at voipnorm@live.com.
VoIPNorms TOP 5 UC blogs for 2009
5. Unified Communications Group Team Blog – This is Microsoft centric blog but loads of useful information from member of the OCS product group.
4. DTMF – Doug Lawty is a MCS consultant with great OCS voice experience. He has some great information on his blog that is well written. He would have been higher on the list but we need Doug to contribute more often to his blog.
3. Matt McGillen’s blog – Another consultant that has a great perspective on getting things done and working through the issues.
2.UCspotting – Rui Silva is a UC TSP at Microsoft and has a great blog worth checking out. What he doesn’t know about OCS isn’t worth knowing.
1. VoIPNorm – What else did you expect me to say. I said it was based on my biases :)
Anyway, thanks to everyone that has contributed to the content, commented or read the blog this year. Look for more articles on interop, OCS, Wave 14, competitions and a whole bunch of other stuff in 2010.
If you have a blog you think is list worthy please let me know. Leave a comment or email me at voipnorm@live.com.
New CUCM 6.1/OCS Interop document
Hot off the press from Microsoft. Direct SIP interop document for OCS to CUCM 6.1.
http://technet.microsoft.com/en-us/ee862409.aspx
http://technet.microsoft.com/en-us/ee862409.aspx
User Group Updates
This week was a really popular week for user group meetings. First off was the Unified Communications Virtual User Group. I actually presented OCS Response Groups. I have to admit, I am not the greatest online presenter so my apologies to those on the call. I get more nervous doing online presentation than in person. Weird. Going virtual for these types of things is a strange occurrence to me as the really value of user groups is the interaction so this was more of a webinar type feel to it. Which is fine, but still not quite the same if you know what I mean.
Next meeting I attended was the Pacific North West UC Doers. Time to celebrate the Exchange 2010 launch. It was an interesting meeting with Yesim Koman from the Exchange product group presenting Exchange IRM - RMS integration. This was an in person meeting held on the Microsoft Redmond Campus. There was a good mix of people from different companies attending. Plenty of swag for those that attended including software, t-shirts and webcams donated by a couple of the different Microsoft sales and marketing groups. UC Doers is a free User Group that receives strong support from Microsoft, partners and regular customer attendees. Look for meeting announcements on my blog for the next quarterly meeting. Thanks to Josh Maher for organizing and hanging in there with the group.
Lastly was the Pacific North West Chapter of the International Nortel Networks User Association. This is something quite different to the other user groups I attended early in the week and was a well-attended event by end users, Nortel and other vendors. This was my first time at a Nortel User Group meeting. It was great to see so many folks working together from different arms of industry and government trying to help each other. This was their annual Christmas get together so I am guessing a little less formal than a regular meeting but everyone was warm and welcoming and I thoroughly enjoyed attending. The Nortel User group chapters are going through some particularly challenging times since the Avaya acquisition. Hopefully this doesn’t end up an amalgamation of Avaya and Nortel user groups just yet as there is still plenty of support for Nortel among customers concerned about where the product lines and support is headed.
I have a unique opportunity in my job that attending user group meetings is beneficial to my position and it also helps me to keep up to date with what’s happening in the industry. Whether you work in the telecom or network sector there is more than likely an end user group out there for you. Since I have worked in the IT industry I have been to Cisco, Linux, Microsoft and Nortel user groups and all had something to offer. It really doesn’t take much effort to attend one of these meetings so I encourage everyone to get out there, network and support your local user groups.
Next meeting I attended was the Pacific North West UC Doers. Time to celebrate the Exchange 2010 launch. It was an interesting meeting with Yesim Koman from the Exchange product group presenting Exchange IRM - RMS integration. This was an in person meeting held on the Microsoft Redmond Campus. There was a good mix of people from different companies attending. Plenty of swag for those that attended including software, t-shirts and webcams donated by a couple of the different Microsoft sales and marketing groups. UC Doers is a free User Group that receives strong support from Microsoft, partners and regular customer attendees. Look for meeting announcements on my blog for the next quarterly meeting. Thanks to Josh Maher for organizing and hanging in there with the group.
Lastly was the Pacific North West Chapter of the International Nortel Networks User Association. This is something quite different to the other user groups I attended early in the week and was a well-attended event by end users, Nortel and other vendors. This was my first time at a Nortel User Group meeting. It was great to see so many folks working together from different arms of industry and government trying to help each other. This was their annual Christmas get together so I am guessing a little less formal than a regular meeting but everyone was warm and welcoming and I thoroughly enjoyed attending. The Nortel User group chapters are going through some particularly challenging times since the Avaya acquisition. Hopefully this doesn’t end up an amalgamation of Avaya and Nortel user groups just yet as there is still plenty of support for Nortel among customers concerned about where the product lines and support is headed.
I have a unique opportunity in my job that attending user group meetings is beneficial to my position and it also helps me to keep up to date with what’s happening in the industry. Whether you work in the telecom or network sector there is more than likely an end user group out there for you. Since I have worked in the IT industry I have been to Cisco, Linux, Microsoft and Nortel user groups and all had something to offer. It really doesn’t take much effort to attend one of these meetings so I encourage everyone to get out there, network and support your local user groups.
Why using the same SIP domain for Tandberg OCS interop can be hazardous to your health
An interesting point came up this week while in a discussion about using the same SIP domain when doing interop between OCS and Tandberg, it can be a bad idea in a large environments. This is of course related to using the Tandberg VCS. If you are registering Tandberg endpoints directly to OCS this is not an issue. When you start looking at the configuration of OCS for VCS interop you will understand why this has the potential to be an issue.
When you add a static route, as I have like in my screen shot, this is a blanket static route that has no filtering etc so when I send an invite with the domain VCS.domain it goes to the intended VCS specified in the IP address portion. Now if this domain is the same as my OCS domain, guess what, every invite generated by OCS has the potential to get sent to the VCS and not just to the intended system registered to OCS. In a small environment this is not such a problem and the VCS will work just fine but in a larger environment this could create a significant load on the VCS. I have not tested for this behavior myself but it certainly makes sense that this would indeed happen.
This also brings up another couple of points. When dealing with larger environment, rarely are the VTC and OCS team the same group of people. So it makes good sense to have separation virtually between the two environments using different SIP domains. Although this doesn’t quite fit in the UC model of unifying your environment this does ease things like troubleshooting and help create a demarcation point. You may think I am crazy saying that the same organization requires a demarcation point between teams but it’s an unfortunate reality. I have seen this quite a few times now in organization where they want to deploy UC but instead of the telecom, VTC and collaboration teams coming together to work jointly on a project they create a third silo for UC and another team is born. I have heard a telecom manager say, “You have to talk to our UC guy we (telecom) don’t deal with that stuff”.
So anyway, till next week.
When you add a static route, as I have like in my screen shot, this is a blanket static route that has no filtering etc so when I send an invite with the domain VCS.domain it goes to the intended VCS specified in the IP address portion. Now if this domain is the same as my OCS domain, guess what, every invite generated by OCS has the potential to get sent to the VCS and not just to the intended system registered to OCS. In a small environment this is not such a problem and the VCS will work just fine but in a larger environment this could create a significant load on the VCS. I have not tested for this behavior myself but it certainly makes sense that this would indeed happen.
This also brings up another couple of points. When dealing with larger environment, rarely are the VTC and OCS team the same group of people. So it makes good sense to have separation virtually between the two environments using different SIP domains. Although this doesn’t quite fit in the UC model of unifying your environment this does ease things like troubleshooting and help create a demarcation point. You may think I am crazy saying that the same organization requires a demarcation point between teams but it’s an unfortunate reality. I have seen this quite a few times now in organization where they want to deploy UC but instead of the telecom, VTC and collaboration teams coming together to work jointly on a project they create a third silo for UC and another team is born. I have heard a telecom manager say, “You have to talk to our UC guy we (telecom) don’t deal with that stuff”.
So anyway, till next week.
Office Communications Server Cumulative Server Update Installer
Installing updates on OCS if you were not running the Windows update service was quite a task especially if you have over 30 OCS servers. Well there is a new method called the Cumulative Server Update Installer that was release with October’s cumulative updates. Rui Silva has done a great job describing the three methods available to do OCS updates at his blog.
Also there is a new update location for OCS well worth checking out that has the latest patches available for OCS and associated platforms.
Also there is a new update location for OCS well worth checking out that has the latest patches available for OCS and associated platforms.
Exchange 2010 UM MWI enablement for CUCM
So we have all heard that Message Waiting Indicator(MWI) is now a native feature of Exchange 2010 Unified Messaging offering. To enable it on a Cisco IP phone there is a step that needs to be completed before it will work. Exchange UM uses a SIP Notify message to let Cisco Unified Communications Manager know that it needs to light the MWI on the phone. This means that Accept Unsolicited Notification needs to be enabled on the SIP trunk within CUCM.
It is also important to be aware of ensuring your line number in CUCM and the Exchange UM dial plan are using the same extension length. So if you line number on your CUCM Ip phone is 5 digits and your using translation patterns to send and receive calls to normalize to the 5 digits then your Exchange dial plan also needs to be 5 digits.
Below is an example of the SIP notify used by Exchange to signal the MWI is to be enabled:
NOTIFY from ExchangeUM
NOTIFY sip:50001@10.1.100.3:5060;user=phone SIP/2.0
FROM:;epid=9B33E64896;tag=5d4cd46f51
TO:
CSEQ: 10 NOTIFY
CALL-ID: cfeb9356f91a40108d58483fb3ad94e5
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 172.16.100.11:40227;branch=z9hG4bK7936d53c
CONTACT:
CONTENT-LENGTH: 98
EVENT: message-summary
SUBSCRIPTION-STATE: terminated
USER-AGENT: RTCC/3.1.0.0
CONTENT-TYPE: application/simple-message-summary
Messages-Waiting: yes
Message-Account: sip:50001@10.1.100.3:5060;user=phone
Voice-Message: 2/0
200 OK Response from CUCM
SIP/2.0 200 OK
Date: Thu, 19 Nov 2009 08:30:46 GMT
FROM:;epid=9B33E64896;tag=5d4cd46f51
Content-Length: 0
TO: sip:50001@10.1.100.3:5060;user=phone;tag=1584108481
CALL-ID: cfeb9356f91a40108d58483fb3ad94e5
VIA: SIP/2.0/TCP 172.16.100.11:40227;branch=z9hG4bK7936d53c
CSeq: 10 NOTIFY
To enable MWI…
1)Open Cisco Unified CM Administration
2)Click System > Security Profile > SIP Trunk Security Profile
3)At the Find and List SIP Trunk Security Profiles screen, click the FIND button
4)You’ll likely then see at least two SIP Trunk Security profiles (i.e. Non Secure, Secure). Select the profile used by your SIP trunk with Ex2010UM.
5)From the SIP Trunk Security Profile Configuration menu, verify that Accept Unsolicited Notification is enabled.
Note: If your SIP trunk to UM is configured to use Digest Authentication, also be sure to select the option Enable Application Level Authorization.
6)Commit changes by clicking Save (this will restart all trunks associated with the security profile)
Thanks to Dave Howe from MS support for the great information. Check out Dave’s blog here: http://blogs.technet.com/daveh
It is also important to be aware of ensuring your line number in CUCM and the Exchange UM dial plan are using the same extension length. So if you line number on your CUCM Ip phone is 5 digits and your using translation patterns to send and receive calls to normalize to the 5 digits then your Exchange dial plan also needs to be 5 digits.
Below is an example of the SIP notify used by Exchange to signal the MWI is to be enabled:
NOTIFY from ExchangeUM
NOTIFY sip:50001@10.1.100.3:5060;user=phone SIP/2.0
FROM:
TO:
CSEQ: 10 NOTIFY
CALL-ID: cfeb9356f91a40108d58483fb3ad94e5
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 172.16.100.11:40227;branch=z9hG4bK7936d53c
CONTACT:
CONTENT-LENGTH: 98
EVENT: message-summary
SUBSCRIPTION-STATE: terminated
USER-AGENT: RTCC/3.1.0.0
CONTENT-TYPE: application/simple-message-summary
Messages-Waiting: yes
Message-Account: sip:50001@10.1.100.3:5060;user=phone
Voice-Message: 2/0
200 OK Response from CUCM
SIP/2.0 200 OK
Date: Thu, 19 Nov 2009 08:30:46 GMT
FROM:
Content-Length: 0
TO: sip:50001@10.1.100.3:5060;user=phone;tag=1584108481
CALL-ID: cfeb9356f91a40108d58483fb3ad94e5
VIA: SIP/2.0/TCP 172.16.100.11:40227;branch=z9hG4bK7936d53c
CSeq: 10 NOTIFY
To enable MWI…
1)Open Cisco Unified CM Administration
2)Click System > Security Profile > SIP Trunk Security Profile
3)At the Find and List SIP Trunk Security Profiles screen, click the FIND button
4)You’ll likely then see at least two SIP Trunk Security profiles (i.e. Non Secure, Secure). Select the profile used by your SIP trunk with Ex2010UM.
5)From the SIP Trunk Security Profile Configuration menu, verify that Accept Unsolicited Notification is enabled.
Note: If your SIP trunk to UM is configured to use Digest Authentication, also be sure to select the option Enable Application Level Authorization.
6)Commit changes by clicking Save (this will restart all trunks associated with the security profile)
Thanks to Dave Howe from MS support for the great information. Check out Dave’s blog here: http://blogs.technet.com/daveh
Transitioning DID’s from CUCM to OCS
What is a DID?
Direct-inward-dialing (DID) is when a carrier provides a range of PSTN numbers for a customer’s PBX that is sent over a T1, analog or other service provided by the carrier.
The solution…
This is a complex subject at the best of times and I am sure that there are plenty of ways to get this done. Over the last few weeks I have been looking at effective ways to achieve this that doesn’t involve routing calls through a Cisco Unified Communications Manager (CUCM) first and still only use one Mediation server. Seems like it could be difficult but I think I have the answer. First step here is assuming you have a CUCM environment you are also using the ISR platform as your gateway (other gateways such as NET or audio codes may also perform the same function). Unfortunately my plan doesn’t work with MGCP as the gateway protocol on the CUCM sude but certainly H323 and SIP will work for talking to CUCM and OCS respectively. This way of transitioning is really aimed at smaller customers although a much larger Enterprise could utilize this idea to either share or transition DID’s from one system to another using multiple mediations servers.
One part of this solution is relying on the mediation server to receive inbound calls from a gateway not defined in its configuration. Inbound, a mediation server will accept SIP invites from any gateway. Outbound is where the limitations begin. Only one gateway can be configured for outbound calls, in this case it would be a direct SIP trunk to a CUCM server and not the gateway. So all outbound calls would still route through a CUCM before either calling a Cisco IP Phone or the PSTN. Once your cutover is complete you can swing the configuration in the mediation server to point to the gateway and not CUCM server if you have removed all the Cisco IP phones and no longer require outbound calls to CUCM or if the balance of OCS users compared to Cisco IP phones becomes weight more towards one over the other.
Diagram
The solution I have really relies on OCS’s behavior of call rejection when you send a call to it that uses a DID that is not associated to an OCS user or application. What does OCS do in this case? SIP/2.0 404 Not Found.
I have also used this behave to route calls to an announcement server for unallocated DID’s when you have a dedicated range but in this case we are sharing with a CUCM system. What’s important here is that the call is rejected by OCS to the gateway which gives the gateway a chance to route the call elsewhere. In CUCM this behavior is a little different in that CUCM would try to route the call out another trunk rather than reject the call back to the gateway. Once the call is rejected by OCS the gateway sends the call to CUCM where CUCM will first lookup to see if the call is destined to any of its own endpoints. It may be a case where it may then try to send the call to OCS again and this is where having an a announcement setup in CUCM will play a critical part in avoiding any looping behavior when OCS rejects the call back to CUCM.
Below is ISR configuration (OCS/SIP and CUCM/H323) to make this work.
voice translation-rule 103
rule 1 /^\(120655555..\)/ /+\1/
!
voice translation-profile AddPlusOne
translate called 103
!
dial-peer voice 555 voip
description to OCS mediation server
preference 1
translation-profile outgoing AddPlusOne
destination-pattern 120655555..
session protocol sipv2
session target ipv4:X.X.X.X
session transport tcp
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 5552 voip
description to CUCM XX
preference 2
destination-pattern 120655555..
session target ipv4:X.X.X.X
dtmf-relay h245-alphanumeric
codec g711ulaw
!
Why using OCS Sim Ring to ring the Cisco IP phone is better than using Cisco Unified Mobility to ring OC.
One word. Licensing. It limits the requirement for a Cisco Device License Unit to turn on Mobility for a user if you haven’t subscribed to the CUWL (Cisco Unified Workspace License). One word of caution though if using simultanoues ringing on OCS to perform this. The numbers cannot be the same. So either a different DID ranges for each system or they somehow need to be different, otherwise OCS will not route the call out to CUCM. Maybe the full E164 for OCS and abbreviate 5 digit line number on CUCM would most likely work but would take a little thought to avoid routing loops.
Why this is better than other solutions that require a customer to forward calls from CUCM.
Forwarding calls from a Cisco phone to OCS is in my opinion a pain in the you know what. The results can be unpredictable and if there is an issue in CUCM system your OC client no longer receives the call. Sharing DID’s at the gateway makes a whole lot more sense than just forwarding or relying on CUCM for call control of an OCS inbound call just because we can make OCS take full control of the call and utilize Sim ring to help with ringing multiple devices.
Routing from CUCM to OCS for internal calls
This has two options but using the gateway to route between the two systems means turning on the IP-IP GW feature which Cisco has a license for. Best solution here is to route directly over a SIP trunk between the two systems.
I know some people may see this as complex and yes I guess it is but migration strategies are never simple when you want to ring multiple devices and share DID ranges. If you had a clean range for each system I would recommend more of a flash cut scenario but limiting CUCM extra licensing requirements and making the system more effective is my whole idea here. After spending three years using call forwarding techniques to achieve some of what I have written here I can tell you in all honesty which I would much prefer to do.
If you have tried other successful methods please feel free to share.
Direct-inward-dialing (DID) is when a carrier provides a range of PSTN numbers for a customer’s PBX that is sent over a T1, analog or other service provided by the carrier.
The solution…
This is a complex subject at the best of times and I am sure that there are plenty of ways to get this done. Over the last few weeks I have been looking at effective ways to achieve this that doesn’t involve routing calls through a Cisco Unified Communications Manager (CUCM) first and still only use one Mediation server. Seems like it could be difficult but I think I have the answer. First step here is assuming you have a CUCM environment you are also using the ISR platform as your gateway (other gateways such as NET or audio codes may also perform the same function). Unfortunately my plan doesn’t work with MGCP as the gateway protocol on the CUCM sude but certainly H323 and SIP will work for talking to CUCM and OCS respectively. This way of transitioning is really aimed at smaller customers although a much larger Enterprise could utilize this idea to either share or transition DID’s from one system to another using multiple mediations servers.
One part of this solution is relying on the mediation server to receive inbound calls from a gateway not defined in its configuration. Inbound, a mediation server will accept SIP invites from any gateway. Outbound is where the limitations begin. Only one gateway can be configured for outbound calls, in this case it would be a direct SIP trunk to a CUCM server and not the gateway. So all outbound calls would still route through a CUCM before either calling a Cisco IP Phone or the PSTN. Once your cutover is complete you can swing the configuration in the mediation server to point to the gateway and not CUCM server if you have removed all the Cisco IP phones and no longer require outbound calls to CUCM or if the balance of OCS users compared to Cisco IP phones becomes weight more towards one over the other.
Diagram
The solution I have really relies on OCS’s behavior of call rejection when you send a call to it that uses a DID that is not associated to an OCS user or application. What does OCS do in this case? SIP/2.0 404 Not Found.
I have also used this behave to route calls to an announcement server for unallocated DID’s when you have a dedicated range but in this case we are sharing with a CUCM system. What’s important here is that the call is rejected by OCS to the gateway which gives the gateway a chance to route the call elsewhere. In CUCM this behavior is a little different in that CUCM would try to route the call out another trunk rather than reject the call back to the gateway. Once the call is rejected by OCS the gateway sends the call to CUCM where CUCM will first lookup to see if the call is destined to any of its own endpoints. It may be a case where it may then try to send the call to OCS again and this is where having an a announcement setup in CUCM will play a critical part in avoiding any looping behavior when OCS rejects the call back to CUCM.
Below is ISR configuration (OCS/SIP and CUCM/H323) to make this work.
voice translation-rule 103
rule 1 /^\(120655555..\)/ /+\1/
!
voice translation-profile AddPlusOne
translate called 103
!
dial-peer voice 555 voip
description to OCS mediation server
preference 1
translation-profile outgoing AddPlusOne
destination-pattern 120655555..
session protocol sipv2
session target ipv4:X.X.X.X
session transport tcp
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 5552 voip
description to CUCM XX
preference 2
destination-pattern 120655555..
session target ipv4:X.X.X.X
dtmf-relay h245-alphanumeric
codec g711ulaw
!
Why using OCS Sim Ring to ring the Cisco IP phone is better than using Cisco Unified Mobility to ring OC.
One word. Licensing. It limits the requirement for a Cisco Device License Unit to turn on Mobility for a user if you haven’t subscribed to the CUWL (Cisco Unified Workspace License). One word of caution though if using simultanoues ringing on OCS to perform this. The numbers cannot be the same. So either a different DID ranges for each system or they somehow need to be different, otherwise OCS will not route the call out to CUCM. Maybe the full E164 for OCS and abbreviate 5 digit line number on CUCM would most likely work but would take a little thought to avoid routing loops.
Why this is better than other solutions that require a customer to forward calls from CUCM.
Forwarding calls from a Cisco phone to OCS is in my opinion a pain in the you know what. The results can be unpredictable and if there is an issue in CUCM system your OC client no longer receives the call. Sharing DID’s at the gateway makes a whole lot more sense than just forwarding or relying on CUCM for call control of an OCS inbound call just because we can make OCS take full control of the call and utilize Sim ring to help with ringing multiple devices.
Routing from CUCM to OCS for internal calls
This has two options but using the gateway to route between the two systems means turning on the IP-IP GW feature which Cisco has a license for. Best solution here is to route directly over a SIP trunk between the two systems.
I know some people may see this as complex and yes I guess it is but migration strategies are never simple when you want to ring multiple devices and share DID ranges. If you had a clean range for each system I would recommend more of a flash cut scenario but limiting CUCM extra licensing requirements and making the system more effective is my whole idea here. After spending three years using call forwarding techniques to achieve some of what I have written here I can tell you in all honesty which I would much prefer to do.
If you have tried other successful methods please feel free to share.
NorthWest UCDoers Exchange 2010 Launch
It's been way too long since we all got together, we've been busy getting our hands dirty with Exchange 2010 with a few customers and the folks at MS have been busy making the product.
Before we get too busy eating holiday food and taking vacations, let's get together to prepare for next year and chat about what we've learned this year.
Date:
December 9th, 2009, 4:30pm - 8:30pm
Location:
Microsoft Campus
Address:
Conf Room Studio B/4519.
15101 ND 40th Street
Redmond, WA 98052
RSVP:
http://event.pingg.com/UCDoers-1209
Before we get too busy eating holiday food and taking vacations, let's get together to prepare for next year and chat about what we've learned this year.
Date:
December 9th, 2009, 4:30pm - 8:30pm
Location:
Microsoft Campus
Address:
Conf Room Studio B/4519.
15101 ND 40th Street
Redmond, WA 98052
RSVP:
http://event.pingg.com/UCDoers-1209
Why isn’t CUCiMOC supported by Microsoft?
Something I do pretty regularly is look up what people are search for when they reach my blog. CUCiMOC is the top topic for hits. This week while looking over the keyword analysis I came across the CUCiMOC Microsoft support question. This is really a loaded question that causes contention in some of the discussions I have seen when Cisco is presenting their sales material. When looking at this situation or any that involves the use of Microsoft’s APIs to create LOB application integration, the reason Microsoft has stated that CUCiMOC is not supported by Microsoft is pretty clear.
CUCiMOC makes extensive use of two areas of integration within Microsoft Office Communicator. The Communicator client API and the Custom Tab. The client API provides the functionality and the custom tab provides the presentation of the CUCiMOC client to put it in simple terms. Both of these Communicator features (the API and Custom Tabs) are fully supported by Microsoft and I have worked with other vendors and internal staff who have developed applications that use both of these features. In these cases (as is the case with CUCiMOC) they were independently developed and supported by either the vendor of the product or internal support staff. The key to all this is “independently developed”. There is no joint roadmap and no cooperation in development unlike other areas of innovation that Microsoft does do with some of its partners.
What can we take away from this question? Well, the first thing is that both Communicators APIs offer a great deal of potential to developers to integrate both at a client and server level. Second is that avenues for developers to get support for Microsoft API’s are available at http://msdn.microsoft.com/en-us/aa570318.aspx.
For a comprehensive look at third party plugins for VoIP and Microsoft Communicator: http://voipnorm.blogspot.com/2010/01/microsoft-communicator-native-versus.html
CUCiMOC makes extensive use of two areas of integration within Microsoft Office Communicator. The Communicator client API and the Custom Tab. The client API provides the functionality and the custom tab provides the presentation of the CUCiMOC client to put it in simple terms. Both of these Communicator features (the API and Custom Tabs) are fully supported by Microsoft and I have worked with other vendors and internal staff who have developed applications that use both of these features. In these cases (as is the case with CUCiMOC) they were independently developed and supported by either the vendor of the product or internal support staff. The key to all this is “independently developed”. There is no joint roadmap and no cooperation in development unlike other areas of innovation that Microsoft does do with some of its partners.
What can we take away from this question? Well, the first thing is that both Communicators APIs offer a great deal of potential to developers to integrate both at a client and server level. Second is that avenues for developers to get support for Microsoft API’s are available at http://msdn.microsoft.com/en-us/aa570318.aspx.
For a comprehensive look at third party plugins for VoIP and Microsoft Communicator: http://voipnorm.blogspot.com/2010/01/microsoft-communicator-native-versus.html
The Future of VoIP
Last week I traveled down to DuPont to the Intel campus to attend the CIPTUG Tech Forum. It really was a great event run and hosted by the NW chapter of CIPTUG. Seeing as I am no longer the president of the NW chapter I can’t take any credit for the day which is a pity because it was very successful single day event.
One interesting question that was asked during the ask the experts panel was, “what’s the future of the hard phone?” Of course seeing as this was a Cisco conference the answer was hard phones aren’t going away and why would they want one of the largest revenue drivers in the company to go any where. With VoIP hard phone sales driving switch and router upgrades it makes perfect sense to keep that momentum going.
I kind of agree that there will be hard phone requirements but only to an extent. I think the form factor of the phone will change as we move more mobile and dedicated desk space is less common to more cellular services ( that one is kind of obvious, I know). Even though a few companies have tried to bring back virtual workers back into the office I think the trend is more in the other direction. Of course information workers have slightly different work profile than that of other workers so how these other cross section of workers take up different form factors for business purposes may be more influential than just information workers alone. The person cutting your sandwich at Subway or a factory worker still has a use for a business phone of some description even if it is very seldom. So making all our assumptions based on information workers can be a false one.
The Senior Voice Architect where I used to work pushed the idea of mobile VoIP was the direction and that eventually we wouldn’t need carrier voice service. I am not sure how fast we will get there but AT&T’s recent change of heart on iphone VoIP applications over their wireless network certainly pushes the bounds on what the industry able to do. Whether voice quality will be good enough with the use of 3G when uptake increases we will see but it certainly heading in the right direction to see my former co-workers vision come true. Maybe AT&T just doesn’t see this as a threat yet and they have certainly made no guarantees on quality to date which may be the reason why they have allowed it to happen. “Poor quality, put people off early adoption, keep the cellular revenue rolling in, keep searching for new hosted markets to fill the gap when it finally happens in the advent of G4 or other cellular bandwidth break through”. I am just guessing here but they are the thoughts that come to my mind anyway.
So whether you want to believe it or not cellular VoIP is just around the corner in a big way and moving in on us fast. Lets just hope its well thought out before it explodes on enterprises everywhere.
Finally there was also plenty of talk about CUCiMOC while I was at Intel (this is still at the top of my blog hit list notching around 40% of all hits) but I will leave that subject for another post. The interest is there but I think it’s for all the wrong reasons.
One interesting question that was asked during the ask the experts panel was, “what’s the future of the hard phone?” Of course seeing as this was a Cisco conference the answer was hard phones aren’t going away and why would they want one of the largest revenue drivers in the company to go any where. With VoIP hard phone sales driving switch and router upgrades it makes perfect sense to keep that momentum going.
I kind of agree that there will be hard phone requirements but only to an extent. I think the form factor of the phone will change as we move more mobile and dedicated desk space is less common to more cellular services ( that one is kind of obvious, I know). Even though a few companies have tried to bring back virtual workers back into the office I think the trend is more in the other direction. Of course information workers have slightly different work profile than that of other workers so how these other cross section of workers take up different form factors for business purposes may be more influential than just information workers alone. The person cutting your sandwich at Subway or a factory worker still has a use for a business phone of some description even if it is very seldom. So making all our assumptions based on information workers can be a false one.
The Senior Voice Architect where I used to work pushed the idea of mobile VoIP was the direction and that eventually we wouldn’t need carrier voice service. I am not sure how fast we will get there but AT&T’s recent change of heart on iphone VoIP applications over their wireless network certainly pushes the bounds on what the industry able to do. Whether voice quality will be good enough with the use of 3G when uptake increases we will see but it certainly heading in the right direction to see my former co-workers vision come true. Maybe AT&T just doesn’t see this as a threat yet and they have certainly made no guarantees on quality to date which may be the reason why they have allowed it to happen. “Poor quality, put people off early adoption, keep the cellular revenue rolling in, keep searching for new hosted markets to fill the gap when it finally happens in the advent of G4 or other cellular bandwidth break through”. I am just guessing here but they are the thoughts that come to my mind anyway.
So whether you want to believe it or not cellular VoIP is just around the corner in a big way and moving in on us fast. Lets just hope its well thought out before it explodes on enterprises everywhere.
Finally there was also plenty of talk about CUCiMOC while I was at Intel (this is still at the top of my blog hit list notching around 40% of all hits) but I will leave that subject for another post. The interest is there but I think it’s for all the wrong reasons.
Using MTP’s for interop for CUCM to OCS
I have been on the path of interop for Office communications Server and Cisco Unified Communication Manager for some time. Lots of experimenting, successes and some failures. Microsoft even used some of the documentation I have written to pass on to some of their customers. But one thing that never really gets talked about is the best way to use and deploy Media termination points in the Cisco environment for this interop story. With this post I am going to try and shed some light on some of the best ways to make best use of MTP’s for interop.
What are MTP’s, how do I configure them and what’s the best combination to ensure I get the best bang for my buck?
Media Termination Point (MTP)
MTP’s are a required option on the CUCM (h323 or SIP) trunk/gateway that connects to your OCS environment whether you are doing direct connect or through a gateway with H323 as the trunking protocol. They form an important part of the interop environment for different reasons depending on what protocols you are using. In the case of H323 its required for extended services (hold, transfer etc) and SIP its for compliance with RFC 2833. As an example of the first with H323, nearly all functions will work without MTP’s except ad-hoc conferencing from a Cisco IP Phone that has a Communicator user as the first participant. The communicator user is dropped due to the conference going on hold as the first step in the process.
Depending on the version of CUCM you are using it can make a difference as to your choices whether you are using some intermediate gateway to interop between the two environments. If you’re like a lot of companies and are stalled on CUCM 4.X you may have chosen not to do direct trunking between the two environments.
Cisco link to more information on MTP configuration and use:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_1_1/ccmsys/a05mtp.html#wp1030050
Software MTP’s CUCM Server
One thing I haven’t mentioned so far is locating MTPS on the CUCM subscribers. This is a great idea for a single site with limited users, low traffic volumes and the easiest option. MTP’s are much less resource intensive than other CUCM services like transcoding and conferencing. This can have its limitations though such as not being able to locate the MTP’s locally and if your subscriber is heavily loaded it may cause some issues with call quality as the RTP stream will pass through the server.
CUCM 4.x Enhanced MTP’s (on a Cisco ISR)
CUCM 4.x can have some limitations with SIP, so H323 is a safe option and with the IP-IP GW it works pretty well (depending on IOS on your gateway version of course). I have settled on the IOS version 12.4.22yb4 currently while running MTPS onboard the router in software(this uses the router CPU). You can run MTP’s in DSP hardware on an ISR but I believe this to be a waste of resources unless your router is under significant load. DSP’s are very costly and can significantly increase the cost of router hardware. My advice is save these resources for transcoding or conferencing for which DSP’s are a requirement in your Cisco environment. The MTP configuration is below for an IOS router. Take note that although you can name your MTP anything you want there is a 15 character limit. In my case I have called it MTPOCSRouter1. The name must be unique for registration in CUCM. Whats also important is that you have the priority of the of your CUCM subscribers that same as the preference of you dial peers. I have seen one way audio occurrence because this wasn’t set correctly.
sccp local FastEthernet0/0
sccp ccm XX.XX.XX.XX identifier 1 version 4.1
sccp ccm XX.XX.XX.XX identifier 2 version 4.1
sccp
!
sccp ccm group 1
description SCCP CCM group
bind interface FastEthernet0/0
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 101 register MTPOCSRouter1
!
!
dspfarm profile 101 mtp
codec g711ulaw
maximum sessions software 200
associate application SCCP
Below is a diagram to show the full configuration. MTP’s located on the ISR router as well as traffic to the OCS environment passing through the ISR working as an IP-IP GW. This is for a single site like a datacenter where call volumes may be high and you need redundancy. You can also apply the same logic to a branch where you may also have a ISR located for local PSTN access for your Cisco deployment. Placing a mediation server and MTP local will stop tromboning calls across the WAN which is what would happen is both the mediation server and MTP’s where located in a central site and a OC user at a remote site calling a Cisco user at the same remote site. So not much point having one without the other.
In the diagram it shows the MTP as separate entities bound to just one trunk. You could have pooled the MTP resources in to one media resource group but what this could lead to is media traffic having to flow through two device before reaching the medaiton server. Not a desired behaviour and has no benefit. Best bet is to only allow the MTP’s on each gateway only be used for that gateway. One to one if you would like to consider that way.
Although not shown in the first diagram the MTP’s are controlled using Skinny similar to the Cisco IP phone. Skinny is a Cisco propritiory protocol.
CUCM 5.x,6.x and 7.x
The use of MTPs looks somewhat different as you do not have RTP flows having to transition through the ISR for any other reason than the MTP’s themselves. The ISR is now removed from the call signaling flow and the MTP’s are pooled together as a single resource rather than for just one connection.
MTP’s are an unfortunate evil in the interop story between these two infrastructures. If for instance your entire infrastructure was SIP on the Cisco side MTP’s would be much less of a problem but since most Cisco deployments have a mix of control protocols (SCCP, H323 and MGCP) they are a requirement.
What are MTP’s, how do I configure them and what’s the best combination to ensure I get the best bang for my buck?
Media Termination Point (MTP)
MTP’s are a required option on the CUCM (h323 or SIP) trunk/gateway that connects to your OCS environment whether you are doing direct connect or through a gateway with H323 as the trunking protocol. They form an important part of the interop environment for different reasons depending on what protocols you are using. In the case of H323 its required for extended services (hold, transfer etc) and SIP its for compliance with RFC 2833. As an example of the first with H323, nearly all functions will work without MTP’s except ad-hoc conferencing from a Cisco IP Phone that has a Communicator user as the first participant. The communicator user is dropped due to the conference going on hold as the first step in the process.
Depending on the version of CUCM you are using it can make a difference as to your choices whether you are using some intermediate gateway to interop between the two environments. If you’re like a lot of companies and are stalled on CUCM 4.X you may have chosen not to do direct trunking between the two environments.
Cisco link to more information on MTP configuration and use:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_1_1/ccmsys/a05mtp.html#wp1030050
Software MTP’s CUCM Server
One thing I haven’t mentioned so far is locating MTPS on the CUCM subscribers. This is a great idea for a single site with limited users, low traffic volumes and the easiest option. MTP’s are much less resource intensive than other CUCM services like transcoding and conferencing. This can have its limitations though such as not being able to locate the MTP’s locally and if your subscriber is heavily loaded it may cause some issues with call quality as the RTP stream will pass through the server.
CUCM 4.x Enhanced MTP’s (on a Cisco ISR)
CUCM 4.x can have some limitations with SIP, so H323 is a safe option and with the IP-IP GW it works pretty well (depending on IOS on your gateway version of course). I have settled on the IOS version 12.4.22yb4 currently while running MTPS onboard the router in software(this uses the router CPU). You can run MTP’s in DSP hardware on an ISR but I believe this to be a waste of resources unless your router is under significant load. DSP’s are very costly and can significantly increase the cost of router hardware. My advice is save these resources for transcoding or conferencing for which DSP’s are a requirement in your Cisco environment. The MTP configuration is below for an IOS router. Take note that although you can name your MTP anything you want there is a 15 character limit. In my case I have called it MTPOCSRouter1. The name must be unique for registration in CUCM. Whats also important is that you have the priority of the of your CUCM subscribers that same as the preference of you dial peers. I have seen one way audio occurrence because this wasn’t set correctly.
sccp local FastEthernet0/0
sccp ccm XX.XX.XX.XX identifier 1 version 4.1
sccp ccm XX.XX.XX.XX identifier 2 version 4.1
sccp
!
sccp ccm group 1
description SCCP CCM group
bind interface FastEthernet0/0
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 101 register MTPOCSRouter1
!
!
dspfarm profile 101 mtp
codec g711ulaw
maximum sessions software 200
associate application SCCP
Below is a diagram to show the full configuration. MTP’s located on the ISR router as well as traffic to the OCS environment passing through the ISR working as an IP-IP GW. This is for a single site like a datacenter where call volumes may be high and you need redundancy. You can also apply the same logic to a branch where you may also have a ISR located for local PSTN access for your Cisco deployment. Placing a mediation server and MTP local will stop tromboning calls across the WAN which is what would happen is both the mediation server and MTP’s where located in a central site and a OC user at a remote site calling a Cisco user at the same remote site. So not much point having one without the other.
In the diagram it shows the MTP as separate entities bound to just one trunk. You could have pooled the MTP resources in to one media resource group but what this could lead to is media traffic having to flow through two device before reaching the medaiton server. Not a desired behaviour and has no benefit. Best bet is to only allow the MTP’s on each gateway only be used for that gateway. One to one if you would like to consider that way.
Although not shown in the first diagram the MTP’s are controlled using Skinny similar to the Cisco IP phone. Skinny is a Cisco propritiory protocol.
CUCM 5.x,6.x and 7.x
The use of MTPs looks somewhat different as you do not have RTP flows having to transition through the ISR for any other reason than the MTP’s themselves. The ISR is now removed from the call signaling flow and the MTP’s are pooled together as a single resource rather than for just one connection.
MTP’s are an unfortunate evil in the interop story between these two infrastructures. If for instance your entire infrastructure was SIP on the Cisco side MTP’s would be much less of a problem but since most Cisco deployments have a mix of control protocols (SCCP, H323 and MGCP) they are a requirement.
Message to UC Marketers and Sales
Dear Marketing and Sales for UC vendors everywhere,
I am writing today in a bid to help you avoid misnomers with your customers, although they don’t complain about it to your face they are in fact saying it to each other. Below are some of the ones I have encountered that later made me question the value of a product or person:
-Over use of the word “Unified”. Placing unified in front of every product you sell is not going to help you sell more stuff. The screw that holds the server rack in place is not a “Unified mounting device”.
-Distracting us with a competitors supposed downfalls because your own product is lacking in a product presentation. The fact is that your market research on your competitors product is more than likely incorrect or over exaggerated to the point it is never actually deployed the way you say it is, is just annoying.
-Use of the term “Best of Breed”. Unless you are selling me a horse this term is meaningless. Unless your product fits nicely in my environment and meets my cost expectations based on ROI the likely hood I will deploy because it is best of breed is zero. This term has passed its due date.
-Learning a new dial plan or product is not a reason not to go with the competitor’s product. We are IT pro’s and learning new systems and products is our job. If I didn’t want to learn new stuff I would be a bikini barrister (now that would be a sight).
-Don’t tell me, “Upgrading the OS or application on 50 servers is easy”. I have heard a similar sentence from a consultant who was lucky to be able to walk out of the room alive after he said it. In large enterprise environments where there is a different group controlling every piece of the collective IT environment anything beyond changing settings in an application can be considered time consuming and challenging. Application packaging and bundling for deployment can help a great deal but nowhere near close to easy.
So here ends my advice. Continue on in your endeavors but don’t say you haven’t been warned next time you use one of these on a customer.
VoipNorm
I am writing today in a bid to help you avoid misnomers with your customers, although they don’t complain about it to your face they are in fact saying it to each other. Below are some of the ones I have encountered that later made me question the value of a product or person:
-Over use of the word “Unified”. Placing unified in front of every product you sell is not going to help you sell more stuff. The screw that holds the server rack in place is not a “Unified mounting device”.
-Distracting us with a competitors supposed downfalls because your own product is lacking in a product presentation. The fact is that your market research on your competitors product is more than likely incorrect or over exaggerated to the point it is never actually deployed the way you say it is, is just annoying.
-Use of the term “Best of Breed”. Unless you are selling me a horse this term is meaningless. Unless your product fits nicely in my environment and meets my cost expectations based on ROI the likely hood I will deploy because it is best of breed is zero. This term has passed its due date.
-Learning a new dial plan or product is not a reason not to go with the competitor’s product. We are IT pro’s and learning new systems and products is our job. If I didn’t want to learn new stuff I would be a bikini barrister (now that would be a sight).
-Don’t tell me, “Upgrading the OS or application on 50 servers is easy”. I have heard a similar sentence from a consultant who was lucky to be able to walk out of the room alive after he said it. In large enterprise environments where there is a different group controlling every piece of the collective IT environment anything beyond changing settings in an application can be considered time consuming and challenging. Application packaging and bundling for deployment can help a great deal but nowhere near close to easy.
So here ends my advice. Continue on in your endeavors but don’t say you haven’t been warned next time you use one of these on a customer.
VoipNorm
Big Day for Technology Announcements, sort of
If you haven’t already heard the news, Cisco is out to buy video giant Tandberg for an estimated 3 billion dollars. Sounds like a good move for Cisco. Obviously, Tandberg offers Cisco some new market areas to enter and completes their video portfolio but part of me thinks this limits choice. So will Avaya buy Polycom to keep up with the Jones’s, who knows.
Second news is the release of the XMPP gateway by the OCS team. This is great step forward as XMPP gains more momentum. Certainly a smart move.
Third is the arrival of my Microsoft MVP award notice via email. The news just doesn’t stop coming.
Second news is the release of the XMPP gateway by the OCS team. This is great step forward as XMPP gains more momentum. Certainly a smart move.
Third is the arrival of my Microsoft MVP award notice via email. The news just doesn’t stop coming.
Exchange 2010 UM, first look at OCS integration
I am not going to go to deep into the features but more just wanted to comment on the experience with OCS integration. Not too much has changed since 07 as far as the setting up the integration goes and once we got it working it seems to be working well. One area that caught me out was a new setting available in the server setup where you assign the UM dial plan to the UM server. Server startup mode must be set to dual if you are integrating to OCS and PBX’s.
Since I am not an Exchange administrator in the organization I work for I was assigned the new UM management role. It is limited on what this role can do and you can’t complete the actual setups to fully setup a new UM dial plan as it does not allow you to assign the UM dial plan to a server. But still this is a step in the right direction and the more separation of duties in a large organization the better they will be allowed to manage work load among staff without giving full admin rights to a user who’s only responsibility is UM.
All in all it looks like some nice improvements have been made in Exchange 2010. Next steps for me is PBX integration and native MWI setup. Should be interesting.
Since I am not an Exchange administrator in the organization I work for I was assigned the new UM management role. It is limited on what this role can do and you can’t complete the actual setups to fully setup a new UM dial plan as it does not allow you to assign the UM dial plan to a server. But still this is a step in the right direction and the more separation of duties in a large organization the better they will be allowed to manage work load among staff without giving full admin rights to a user who’s only responsibility is UM.
All in all it looks like some nice improvements have been made in Exchange 2010. Next steps for me is PBX integration and native MWI setup. Should be interesting.
CIPTUG Technology Forums
This year due the economy, Cisco IP Telephony User Group is going local rather than a national conference. This year they are having one-day technology forums at Boston, Seattle and Atlanta. It only costs $75 for non-CIPTUG members to attend and $50 for current CIPTUG members. The agendas cover Cisco VoIP and partner technology. For an up to date agenda please refer to the website.
http://www.ciptug.org/technical_forum.php
I will be posting updates over the next few weeks. Seattle is due to have their forum on October the 21st at the Intel DuPont site.
Please feel free to email directly if you’re interested in knowing more at voipnorm@live.com.
http://www.ciptug.org/technical_forum.php
I will be posting updates over the next few weeks. Seattle is due to have their forum on October the 21st at the Intel DuPont site.
Please feel free to email directly if you’re interested in knowing more at voipnorm@live.com.
OCS Response Group in Action
I am a big fan of the response group application. Although this by no means replace a full blown call center application, what it does provide is a low cost replacement for ACD applications that are housed usually on messaging systems like Unity and Octel. In my case these ACD’s are housed on an Octel that is no longer manufacture supported and we need a replacement solution. Not only do response groups replace what was available on the Octel voicemail system but it extends the functionality by being able to use group mailboxes and presence to contact agents. It also allowed the employees to be free from the TDM system they were on and now they can work remotely.
This real life response group ties together a few things I have talked about here on the blog, such as nesting workflows and using a group mailbox for voicemail. The reason the second workflow was required is that if someone rings out of business hours (OOBH), customer support still wants the user to be able to make a choice of either calling the enterprise help desk that is supported 24x7 or just to leave a message for direct product support. Doing it this way opens more options down the road for the customer as far as routing out of hours.
The group was extremely happy with the outcome of this application because they see it reducing their response times to out of hour’s requests and better managing their workload between staff members without having to spend a lot of money on a more complex call center application.
This real life response group ties together a few things I have talked about here on the blog, such as nesting workflows and using a group mailbox for voicemail. The reason the second workflow was required is that if someone rings out of business hours (OOBH), customer support still wants the user to be able to make a choice of either calling the enterprise help desk that is supported 24x7 or just to leave a message for direct product support. Doing it this way opens more options down the road for the customer as far as routing out of hours.
The group was extremely happy with the outcome of this application because they see it reducing their response times to out of hour’s requests and better managing their workload between staff members without having to spend a lot of money on a more complex call center application.
We Provide Support for E911
Recently I received a comment about OCS E911 support from a vendor. He said that the company he represented now supported OCS and E911. So I thought I would go look at the website of not just his company but all the companies providing E911 solutions for VoIP. I found it interesting that most companies don’t list the PBX’s they support. Some did, like E911Enable. However, most wanted you to call them to talk about your solution requirements. For me this is a bad marketing strategy. I know that every enterprise solution is different and whether it’s because there is some cost in displaying the logo of a vendor you support is the question here I am not sure but if I were looking to a new E911 solution provider having what vendors you support on your webpage is what I consider pretty important.
As for OCS support. I found only one vendor mention Microsoft solution support although I know others are out there. So all in all I was somewhat disappointed by the strategy and don’t really understand it. Having to call to find out what vendors you support in my eye loses some of your credibility before I make that call. So if you’re a E911 vendor and read this post don’t be scared to show the vendors you support on your home page, whether you just list them or show a logo it’s nice to know before the call is made.
As for OCS support. I found only one vendor mention Microsoft solution support although I know others are out there. So all in all I was somewhat disappointed by the strategy and don’t really understand it. Having to call to find out what vendors you support in my eye loses some of your credibility before I make that call. So if you’re a E911 vendor and read this post don’t be scared to show the vendors you support on your home page, whether you just list them or show a logo it’s nice to know before the call is made.
Using a Group mail box voicemail with Response Groups
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.
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 :-)
Ring Back Workaround by Doug
Doug is one of the leading OCS consultants at Microsoft that I had the pleasure of working with on our OCS project where I work. I was fortunate to have Doug working with me, as he was able to create a MSPL script that solved one of our biggest issues regarding simultaneous ringing. The issue stemmed from a lack of call signaling that was coming from another IP PBX system that OCS was connected to via a gateway. I really like Doug’s blog entry on this subject because it shows the power of OCS’s development capabilities to overcome the issue of another platform it can interoperate with.
While on the subject of OCS, last night I had the opportunity to attend the NW UC Doers meeting. It was a great meeting with lots of open conversation about OCS development with representation from both Cisco and Microsoft at the same user group meeting. Something you do not see every day I am sure. Duncan Blake from Unify Square presented and talked about OCS development using MSPL . Any way, my thanks to Josh Maher for organizing another informative meeting.
While on the subject of OCS, last night I had the opportunity to attend the NW UC Doers meeting. It was a great meeting with lots of open conversation about OCS development with representation from both Cisco and Microsoft at the same user group meeting. Something you do not see every day I am sure. Duncan Blake from Unify Square presented and talked about OCS development using MSPL . Any way, my thanks to Josh Maher for organizing another informative meeting.
CUCiMOC First Call
I managed to squeeze in a few minutes today to work a little on the configuration and managed to make my first call. Unfortunately the PC I am using is not really suitable for anything but for test calls but I got the general feel for what Cisco are trying to achieve. I think they have achieved an interesting integration that will have some legs although after working through the documentation I think deploying this in a multi-cluster (CUCM) multi-pool (OCS) environment of large enterprises would have some challenges in regards to getting the registry settings to the right user. It would certainly take some good planning let’s put it that way.
The AD integration worked pretty well and I am pretty sure I could make some registry tweaks to improve the initial logon. My next biggest challenge will be setting up the correct dialing rules for CUCM. Should be interesting.
The AD integration worked pretty well and I am pretty sure I could make some registry tweaks to improve the initial logon. My next biggest challenge will be setting up the correct dialing rules for CUCM. Should be interesting.
UC Doers Upcoming Meeting
UC Doers User Group
Wednesday July 29, 2009 from 5:00pm - 7:00pm
SQLSoft+
1750 112th Ave. NE Suite B-101 (Hidden Valley Office Park)
Bellevue, Washington 98004 Get Directions
We are currently planning on getting a little more in-depth regarding OCS voice capabilities. There are lots of cool things we can enable for our employers and clients through OCS from voice, to presence, to custom applications. Since our group spans Exchange and OCS – we figured starting somewhere on the OCS side of things would be great for everyone. Next quarter, when we are next to the release of Exchange 2010, we’ll try to jump back into the Exchange stuff.
In terms of finding great speakers… We lucked out and got Duncan Blake from Unify Square to talk. He has a long history on the product team at Microsoft and is currently over at Unify Square helping customers implement this stuff in the real world. Of course the small other fact about Duncan is his status as an instructor in the OCS Ranger program. In other words teaching the best of the best in Microsoft’s opinion.
RSVP
Wednesday July 29, 2009 from 5:00pm - 7:00pm
SQLSoft+
1750 112th Ave. NE Suite B-101 (Hidden Valley Office Park)
Bellevue, Washington 98004 Get Directions
We are currently planning on getting a little more in-depth regarding OCS voice capabilities. There are lots of cool things we can enable for our employers and clients through OCS from voice, to presence, to custom applications. Since our group spans Exchange and OCS – we figured starting somewhere on the OCS side of things would be great for everyone. Next quarter, when we are next to the release of Exchange 2010, we’ll try to jump back into the Exchange stuff.
In terms of finding great speakers… We lucked out and got Duncan Blake from Unify Square to talk. He has a long history on the product team at Microsoft and is currently over at Unify Square helping customers implement this stuff in the real world. Of course the small other fact about Duncan is his status as an instructor in the OCS Ranger program. In other words teaching the best of the best in Microsoft’s opinion.
RSVP
CUCiMOC Install and Configuration
This is an interesting little project that I have started. So far, the configuration of the CUCM and the install of the software has been pretty simple. Not too much of a stretch I don’t think. Of course where would we be without having to perform some sort of an upgrade to CUCM to start with. There are a couple of options for version compatibility:
CUCM 6.1.3 with a COP file loaded with the Client Services Framework device type.
CUCM 6.1.4
CUCM 7.x
Not too bad as far as available versions go. I choose just to go to 6.1.4. I was already at 6.1.1 in our lab so the jump was painless with the Linux version upgrade (that and the fact someone else offered to do it for me, very painless:-)).
There are a couple of areas that may make deployment a little difficult if you have never done them before. First is integrating CUCM into LDAP/AD. For a large enterprise this can be a little time consuming getting the right settings and everything else but the overall CUCiMOC configuration will certainly benefit from having done this step and in general your CUCM deployment will benefit from LDAP integration regardless of CUCiMOC.
The second thing people may have issues with is using group policies to setup the parameters for CUCiMOC on the PC for mass deployment. In my lab I will just alter the registry settings but a much larger deployment may choose to either script this during install or use Group policy setting which Cisco provide a template for. This is where the client locates the all-important TFTP server to down load settings from CUCM. I was a little perplexed when I first read the documentation as I skipped this piece and was beginning to think that we had to rely on DHCP. But my worst fearers were placed at ease. This was not the case and I could relax. Not that it’s a big deal for a lab test but just thinking more along the lines of deployment having to add option 150 to the data VLAN scopes is probably not ideal.
So far I haven’t had a successful call across CUCiMOC but more just wanted to jot down impressions as I moved forward. One final note, although CUCiMOC supports CDP and CER it will be problematic for off campus users to provide location information in the case of Enhanced 911 (E911). Not sure if there are any third party providers out there set to support this product yet but there is no interface to enter E911 location information.
For a comprehensive look at third party plugins for VoIP and Microsoft Communicator:
http://voipnorm.blogspot.com/2010/01/microsoft-communicator-native-versus.html
CUCM 6.1.3 with a COP file loaded with the Client Services Framework device type.
CUCM 6.1.4
CUCM 7.x
Not too bad as far as available versions go. I choose just to go to 6.1.4. I was already at 6.1.1 in our lab so the jump was painless with the Linux version upgrade (that and the fact someone else offered to do it for me, very painless:-)).
There are a couple of areas that may make deployment a little difficult if you have never done them before. First is integrating CUCM into LDAP/AD. For a large enterprise this can be a little time consuming getting the right settings and everything else but the overall CUCiMOC configuration will certainly benefit from having done this step and in general your CUCM deployment will benefit from LDAP integration regardless of CUCiMOC.
The second thing people may have issues with is using group policies to setup the parameters for CUCiMOC on the PC for mass deployment. In my lab I will just alter the registry settings but a much larger deployment may choose to either script this during install or use Group policy setting which Cisco provide a template for. This is where the client locates the all-important TFTP server to down load settings from CUCM. I was a little perplexed when I first read the documentation as I skipped this piece and was beginning to think that we had to rely on DHCP. But my worst fearers were placed at ease. This was not the case and I could relax. Not that it’s a big deal for a lab test but just thinking more along the lines of deployment having to add option 150 to the data VLAN scopes is probably not ideal.
So far I haven’t had a successful call across CUCiMOC but more just wanted to jot down impressions as I moved forward. One final note, although CUCiMOC supports CDP and CER it will be problematic for off campus users to provide location information in the case of Enhanced 911 (E911). Not sure if there are any third party providers out there set to support this product yet but there is no interface to enter E911 location information.
For a comprehensive look at third party plugins for VoIP and Microsoft Communicator:
http://voipnorm.blogspot.com/2010/01/microsoft-communicator-native-versus.html
CUCiMOC Released
Over the next week or so I am going to be working on setting up CUCiMOC for the first time. I am very interested to see just how easy it will be. For those of you with an interest in this product here is the links to the CUCiMOC support documentation.
Since the product is now fully released I am sure there will be a number of bloggers out there getting their hands dirty with CUCiMOC. My first impressions after scouring the install documentation is there is more than meets the eye to the install. Only time will tell. I will report back here with my results.
Since the product is now fully released I am sure there will be a number of bloggers out there getting their hands dirty with CUCiMOC. My first impressions after scouring the install documentation is there is more than meets the eye to the install. Only time will tell. I will report back here with my results.
Live Meeting Failures and Permissions
This is an interesting issue we caught last week. For some reason permissions on the metadata share and application share were missing some key groups. Not sure why they weren’t configured or all of a sudden became un-configured but some key errors appeared when some one tried to initiate a live meeting session. Event ID 41038 reported an invalid metadata folder. Our main clue to resolve the issue.
Here is the link to permissions created during OCS pool creation in the metadata and application share.
So a quick tip is to check your permissions even if everything loads successfully during your OCS setup.
Here is the link to permissions created during OCS pool creation in the metadata and application share.
So a quick tip is to check your permissions even if everything loads successfully during your OCS setup.
VoipNorms Top Ten 2009 Predictions midyear recap:
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.
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.
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.
F5 configuration for OCS R2 Enterprise Edition
This has been somewhat of a trial and error situation for our OCS R2 deployment and at times very tiring trying to coordinate the OCS and F5 teams to be on the same path. Nevertheless, the information below will help other hapless soles on their path in getting this configuration working successfully. The table below should help anyone get the right settings to have all the different working parts of an OCS R2 deployment working when using an F5 to load balance multiple front end servers in a consolidated deployment.
To configure a health monitor for 5061 using the web F5 admin interface (information taken from F5 OCS R1 configuration document):
1. On the Main tab, expand Local Traffic, and then click Monitors. The Monitors screen opens.
2. Click the Create button. The New Monitor screen opens.
3. In the Name box, type a name for the Monitor.
4. From the Type list, select HTTPS.The TCP Monitor configuration options appear.
5. From the Configuration list, select Advanced. The advanced configuration options appear.
6. In the Configuration section, in the Interval and Timeout boxes, type an Interval and Timeout.
7. In the Alias Service Port box, type 5061.
8. Click the Finished button.
From the .conf file it will look something like this:
}
monitor ocs-frontend-sip-5061 {
defaults from https
interval 30
timeout 91
dest *:5061
}
Also, you will need to create a TCP profile with an Idle timeout of1200 seconds and enable TCP resets on idle timeout which will need to be applied to each of the F5 pools created.
Of course all this information is on the internet in various places. The following document is available from MSFT on load balancing requirements for OCS R2 but it’s a general document not specific for F5.
Hopefully this will help someone out there somewhere :-)
To configure a health monitor for 5061 using the web F5 admin interface (information taken from F5 OCS R1 configuration document):
1. On the Main tab, expand Local Traffic, and then click Monitors. The Monitors screen opens.
2. Click the Create button. The New Monitor screen opens.
3. In the Name box, type a name for the Monitor.
4. From the Type list, select HTTPS.The TCP Monitor configuration options appear.
5. From the Configuration list, select Advanced. The advanced configuration options appear.
6. In the Configuration section, in the Interval and Timeout boxes, type an Interval and Timeout.
7. In the Alias Service Port box, type 5061.
8. Click the Finished button.
From the .conf file it will look something like this:
}
monitor ocs-frontend-sip-5061 {
defaults from https
interval 30
timeout 91
dest *:5061
}
Also, you will need to create a TCP profile with an Idle timeout of1200 seconds and enable TCP resets on idle timeout which will need to be applied to each of the F5 pools created.
Of course all this information is on the internet in various places. The following document is available from MSFT on load balancing requirements for OCS R2 but it’s a general document not specific for F5.
Hopefully this will help someone out there somewhere :-)
CUCiMOC, is it too late?
I had a bit of hectic week last week, so coming up with ideas to write about fell a little to the side but I thought I would talk a little about Cisco’s upcoming integration to Microsoft Communicator. At the CIPTUG national conference last year CUCIMOC was announced during NDA sessions so now that they have released more information on Cisco.com I feel a little more comfortable talking about it on the Blogosphere.
Matt Mcgillen has written a bit about the functionality here in his blog so I am not going to cover all the technical details. I really wanted to talk more about where this may or may not fit into a enterprise and is it too late for some enterprises to take advantage of what CUCiMOC may have to offer. Matt’s blog by the way is an excellent source of information from a guy doing this stuff day in and day out. I highly recommend subscribing to it.
Once an enterprise commits to a deployment path it can be extremely difficult to turn the ship around and head in the other direct. So, I do not believe that Cisco were aiming this product at those that were already committed to OCS Enterprise voice. This product, I feel, is aimed at stopping enterprises from heading in that direction in the first place. There are a couple of things that I think are very beneficial and a few things that may need to be considered if looking at deploying CUCiMOC.
The benefits for an enterprise could be simplifying your environment and maybe, just maybe a reduction in licensing. Simplifying your environment is from a dial plan perspective and the ability to do RCC without CUPS. This is really from an infrastructure standpoint and not the desktop, which I will get to. Having one dial plan is a bit misleading though for a large enterprise that may have multiple clusters but it does mean not learning a new products dial plan. It does however provide a reduction in servers both for CUPS(RCC) and OCS mediation servers (OCS Enterprise voice). It also means not having to purchase the OCS license that includes voice features. Now depending on your current Cisco licensing this really may not amount to much anyway, so it’s all about crunching the numbers to see what comes out the best for your company.
Some things to consider would be a reliance on the desktop to provide the integration and a lack of collaboration between Cisco and Microsoft on development of this product. These two points are really intertwined. Let us just hang on the first point here for a second. This is what I consider a pretty complex integration happening at the desktop which unlike other desktop products like for example outlook where real time information is being exchanged to achieve a task. This is a complex task to achieve at a server level at times and now we are relying on the desktop to provide it. Not that I am questioning the ability of Cisco to provide a reliable integration but more of question of a user’s ability to break things through inadvertent activities, like installing an application they should not. I guess the comeback to this is users have been breaking stuff a long time we are used to that happening. This could be somewhat a of a benefit to, because if it does break it may only be the one user affected, unlike current RCC solutions where many could suffer.
On to my second point. When you look at the history in the UC space of the relationship between Cisco and MSFT it is rather contentious. This really comes through in the fact that MSFT has stated that it will not support this integration , which in essence may mean that when moving from one version of Communicator to the next, parts of or all of this integration may no longer work (RCC ring any bells out there). So, now we have a complex integration on the desktop that one company may refuse to help with should you deploy it and Cisco will have to ensure that they stay current with the latest version of MSFT Communicator to ensure it works. Which means it is quite possible your whole OCS deployment could become dependent on a plug-in being available for the version you want to deploy should your customers become reliant on it. Interesting scenario and a situation you may already be familiar with through other products, so may be not totally new.
I hope this didn’t seem to harsh on Cisco as this is a very innovative way to integrate the two environments and I know from experience, something customers using RCC products have been asking of Cisco for a long time. But at the same time I really feel the development of this is late and the uptake on it may be less than hoped. In the end only time will tell. If you have had experience with deploying CUCiMOC please feel free to post your thoughts, I would be interested to hear them.
For a comprehensive look at third party plugins for VoIP and Microsoft Communicator:
http://voipnorm.blogspot.com/2010/01/microsoft-communicator-native-versus.html
Matt Mcgillen has written a bit about the functionality here in his blog so I am not going to cover all the technical details. I really wanted to talk more about where this may or may not fit into a enterprise and is it too late for some enterprises to take advantage of what CUCiMOC may have to offer. Matt’s blog by the way is an excellent source of information from a guy doing this stuff day in and day out. I highly recommend subscribing to it.
Once an enterprise commits to a deployment path it can be extremely difficult to turn the ship around and head in the other direct. So, I do not believe that Cisco were aiming this product at those that were already committed to OCS Enterprise voice. This product, I feel, is aimed at stopping enterprises from heading in that direction in the first place. There are a couple of things that I think are very beneficial and a few things that may need to be considered if looking at deploying CUCiMOC.
The benefits for an enterprise could be simplifying your environment and maybe, just maybe a reduction in licensing. Simplifying your environment is from a dial plan perspective and the ability to do RCC without CUPS. This is really from an infrastructure standpoint and not the desktop, which I will get to. Having one dial plan is a bit misleading though for a large enterprise that may have multiple clusters but it does mean not learning a new products dial plan. It does however provide a reduction in servers both for CUPS(RCC) and OCS mediation servers (OCS Enterprise voice). It also means not having to purchase the OCS license that includes voice features. Now depending on your current Cisco licensing this really may not amount to much anyway, so it’s all about crunching the numbers to see what comes out the best for your company.
Some things to consider would be a reliance on the desktop to provide the integration and a lack of collaboration between Cisco and Microsoft on development of this product. These two points are really intertwined. Let us just hang on the first point here for a second. This is what I consider a pretty complex integration happening at the desktop which unlike other desktop products like for example outlook where real time information is being exchanged to achieve a task. This is a complex task to achieve at a server level at times and now we are relying on the desktop to provide it. Not that I am questioning the ability of Cisco to provide a reliable integration but more of question of a user’s ability to break things through inadvertent activities, like installing an application they should not. I guess the comeback to this is users have been breaking stuff a long time we are used to that happening. This could be somewhat a of a benefit to, because if it does break it may only be the one user affected, unlike current RCC solutions where many could suffer.
On to my second point. When you look at the history in the UC space of the relationship between Cisco and MSFT it is rather contentious. This really comes through in the fact that MSFT has stated that it will not support this integration , which in essence may mean that when moving from one version of Communicator to the next, parts of or all of this integration may no longer work (RCC ring any bells out there). So, now we have a complex integration on the desktop that one company may refuse to help with should you deploy it and Cisco will have to ensure that they stay current with the latest version of MSFT Communicator to ensure it works. Which means it is quite possible your whole OCS deployment could become dependent on a plug-in being available for the version you want to deploy should your customers become reliant on it. Interesting scenario and a situation you may already be familiar with through other products, so may be not totally new.
I hope this didn’t seem to harsh on Cisco as this is a very innovative way to integrate the two environments and I know from experience, something customers using RCC products have been asking of Cisco for a long time. But at the same time I really feel the development of this is late and the uptake on it may be less than hoped. In the end only time will tell. If you have had experience with deploying CUCiMOC please feel free to post your thoughts, I would be interested to hear them.
For a comprehensive look at third party plugins for VoIP and Microsoft Communicator:
http://voipnorm.blogspot.com/2010/01/microsoft-communicator-native-versus.html
Preserving P-Asserted Identity formats on a Cisco SBC
Not sure if this is really applies to anyone’s deployment out there but this is an issue I recently encountered with a Cisco Session Border Controller and P-Asserted Identity (PAI). When the SBC received a SIP packet from our application it changed the PAI format from tel: to sip:xxxxxx@xx.xx.xx.xx. Not that there is any rule that says this cannot be done, it was slightly annoying and breaking our application. Below is the code that fixed this issue.
The SIP profile should be applied to your outbound dial peers. Although this shows some flexibility of the CUBE to make this adjustment, it would not have been required if it had not changed the PAI in the first place!
Update: Our application developer informed me that some service providers my require the tel: format. Qwest only supports tel URI but XO supports SIP URI as examples. So having the ability to do either is a good thing.
For more information on PAI check out the IETF website and RFC 3325
!
voice service voip
sip
asserted-id pai
!
voice class sip-profiles 1
request INVITE sip-header P-Asserted-Identity modify "<sip:(.*)@.*>" "tel:\1"
!
dial-peer voice 811 voip
voice-class sip profiles 1
!
dial-peer voice 8112 voip
voice-class sip profiles 1
The SIP profile should be applied to your outbound dial peers. Although this shows some flexibility of the CUBE to make this adjustment, it would not have been required if it had not changed the PAI in the first place!
Update: Our application developer informed me that some service providers my require the tel: format. Qwest only supports tel URI but XO supports SIP URI as examples. So having the ability to do either is a good thing.
For more information on PAI check out the IETF website and RFC 3325
Response Group Part 4: Two-level Interactive Template
For the last installment in this series I had to break down the diagram into sections to make it more readable.The two-level interactive template is very similar to the one level but as you would expect, another level is added, duh. I will let the diagrams do the explaining.
Diagram one shows the entry point to the response group for the caller.
Diagram two takes us to the results of the first and second level IVR.
Diagram three represents the agent queues for all levels.
Diagram one shows the entry point to the response group for the caller.
Diagram two takes us to the results of the first and second level IVR.
Diagram three represents the agent queues for all levels.
Response Group Part 3: One-level Interactive Template
Third in this series of blog posts, we are really getting to the more complex scenarios. One level interactive RG’s add the IVR style menu options that can be a voice response to set questions. As the diagram shows, this is building on the enhanced hunt group. Sure, this will not cover every requirement you may have for IVR style ACD but then again it is not supposed to either. I know where I work this type of ACD is popular on the more traditional systems and this level of complexity would cover 80% of all our requirements. The more complex IVR and ACD requirements are best left on a specialized platform like OCS 2007 Speech Server or Cisco IPCC Express for example.
What I really like about the Response Group feature is the ease of setup. Too often with simple Hunt Group and ACD requirements the complexity to get things working and needing to know scripting languages can be painful when something with the website interface setup will do.
What I really like about the Response Group feature is the ease of setup. Too often with simple Hunt Group and ACD requirements the complexity to get things working and needing to know scripting languages can be painful when something with the website interface setup will do.
UC Doers Live
Usually I advertise in advance upcoming user group meetings, unfortunately this one slipped my mind. So to make amends I am blogging live from The Pacific Northwest Unified Communications User Group meeting. For anyone on the Seattle area interested in networking with your IT peers and learning something about Microsoft Unified Communications this is a great group which has moved its meetings on to the Redmond campus. The turnout for this meeting is about 25, which is no surprise as the topic is Exchange 2010. In future I will make sure to get the meeting on the blog a little earlier as I think user groups certainly hold value.
How to Avoid a Routing Loop Using Announcements
Sometimes it’s the unseen that consumes resources and takes a hold bringing everything to a raging holt. Sounds dramatic doesn’t it. Something like the start of a horror novel. But this is certainly one way to describe routing loops in voice networks. What happens to the call that doesn’t terminate anywhere? Well, a number of things. The most common is a time out that occurs which ends in the caller hearing a fast busy tone. Unsure whether they reached a wrong number or not they may call again.
When looking at network traffic though this could lead to a serious consumption of resources, particularly if there are a number of simultaneous calls to vacant numbers on a large internal network or in the case of a serious failure somewhere it could be your whole DID range. Unless loop prevention is part of the design in routing tables, a royal mess ensues and the possibility of call blockage becomes a big issue. If however you are directly connected via a gateway or SIP trunk to a service provider, they could be taking care of this for you.
One recent case I had was our interoperability environment between our Cisco and OCS deployment. It relies on a gateway between the two environments. When OCS would reject a call from a DID number range that was allocated to OCS the gateway would send the call back to Cisco Communication Manager (CUCM)which would then look up its routing tables to send the call back to our gateway and then the fun began. One call quickly looked like 50 on the gateway and did not seem like ending. There are also some ways to prevent this in CUCM but your design may be limited by using them.
There are a number of places where loop prevention can be deployed. Where I work we deployed loop prevention in a number of places. Using dial peers configured in a hunt group we have an unallocated number announcement provisioned for any rejected number coming back from OCS to the gateway. We also allocate an all circuits busy on Cisco Callmanager when circuits are down between the two environments. This stops Callmanager from routing calls destined for OCS elsewhere other than an announcement. Then finally, we have a mediation server dedicated to sending unallocated numbers directly to an announcement server. In my diagram, I have used OCS speech server 2007 but it could be any number of SIP enabled speech server type applications including a Cisco router setup for announcements.
The OCS dial plan plays an important part in successfully sending call to an announcement. An overlapping route pattern is required to get calls sent to the announcement that also includes the numbers allocated to users. For example 555-555-5xxx maybe your number range for allocating number in OCS to users. This is also the route pattern you would use for sending call to an announcement on speech server. Then in speech server for your announcement application you could use the * wildcard to indicate any inbound called number.
In the end you may be unaware of routing loops in your system if traffic volumes are low. In high traffic environments issues can arise when leaving things to their own devices so it’s best to have a plan in place for failing circuits and vacant DID’s. I realise with this post I haven't given the exact configuration because there are a million ways this could be achieved but hopefully the diagram and description help highlight what can be a not so obvious problem.
When looking at network traffic though this could lead to a serious consumption of resources, particularly if there are a number of simultaneous calls to vacant numbers on a large internal network or in the case of a serious failure somewhere it could be your whole DID range. Unless loop prevention is part of the design in routing tables, a royal mess ensues and the possibility of call blockage becomes a big issue. If however you are directly connected via a gateway or SIP trunk to a service provider, they could be taking care of this for you.
One recent case I had was our interoperability environment between our Cisco and OCS deployment. It relies on a gateway between the two environments. When OCS would reject a call from a DID number range that was allocated to OCS the gateway would send the call back to Cisco Communication Manager (CUCM)which would then look up its routing tables to send the call back to our gateway and then the fun began. One call quickly looked like 50 on the gateway and did not seem like ending. There are also some ways to prevent this in CUCM but your design may be limited by using them.
There are a number of places where loop prevention can be deployed. Where I work we deployed loop prevention in a number of places. Using dial peers configured in a hunt group we have an unallocated number announcement provisioned for any rejected number coming back from OCS to the gateway. We also allocate an all circuits busy on Cisco Callmanager when circuits are down between the two environments. This stops Callmanager from routing calls destined for OCS elsewhere other than an announcement. Then finally, we have a mediation server dedicated to sending unallocated numbers directly to an announcement server. In my diagram, I have used OCS speech server 2007 but it could be any number of SIP enabled speech server type applications including a Cisco router setup for announcements.
The OCS dial plan plays an important part in successfully sending call to an announcement. An overlapping route pattern is required to get calls sent to the announcement that also includes the numbers allocated to users. For example 555-555-5xxx maybe your number range for allocating number in OCS to users. This is also the route pattern you would use for sending call to an announcement on speech server. Then in speech server for your announcement application you could use the * wildcard to indicate any inbound called number.
In the end you may be unaware of routing loops in your system if traffic volumes are low. In high traffic environments issues can arise when leaving things to their own devices so it’s best to have a plan in place for failing circuits and vacant DID’s. I realise with this post I haven't given the exact configuration because there are a million ways this could be achieved but hopefully the diagram and description help highlight what can be a not so obvious problem.
Response Group Part 2: Enhanced Hunt Group
Well after a short break in this series, I am back onto Response Group in R2 and giving the diagrammatic version of what is possible. This entry will focus on enhanced hunt group.
Enhanced hunt groups are very similar to basic but with the added features of a welcome message and scheduling business hours. MOH makes its first appearance while waiting for a contact to answer. I will let the diagram tell the rest of the story.
Enhanced hunt groups are very similar to basic but with the added features of a welcome message and scheduling business hours. MOH makes its first appearance while waiting for a contact to answer. I will let the diagram tell the rest of the story.
CIPTUG Northwest Chapter Meeting
Cisco IP Telephony Users Group Northwest Chapter Meeting
Tuesday, April 14, 2009
11:00 am - 3:00 pm
The meeting is open to Cisco end users who are either CIPTUG Members or interested in becoming members and CIPTUG Vendor Members.
Interested?
Plan to attend the CIPTUG Northwest Chapter Meeting!
Who: CIPTUG Members and Cisco IPT users
What: CIPTUG Northwest Chapter Meeting
Agenda:
• 11:00 - 11:30 am
Welcome & Chapter Business
• 11:30 am - 12:00 pm
Cisco Roadmap - Chris Steffy
Cisco Unified Communications Portfolio
• 12:00 - 12:30 pm
Lunch Provided by Agito
• 12:30 - 1:30 pm
Cisco - Laura Smith
Cisco Mobile Unified Communications
• 1:30 - 2:30 pm
Agito Networks - Jim Alexander
Agito Networks RoamAnywhere Mobility Router
• 2:30 - 3:00 pm
Birds of a Feather/Open Mic
• 3:00 pm
Meeting Adjourns
When: Tuesday, April 14, 2009
11:00 am - 3:00 pm - Please RSVP - Lunch will be served
Where: Cisco Systems Bellevue WA Office
500 108th Ave. NE - 5th Floor
Bellevue, WA
RSVP:Click here to Register
Virtual details will be available to registered participants. Giveaways (in person participants only): Plantronics Bluetooth Headset, Cisco Books, CIPTUG Logo'd Merchandise.
Tuesday, April 14, 2009
11:00 am - 3:00 pm
The meeting is open to Cisco end users who are either CIPTUG Members or interested in becoming members and CIPTUG Vendor Members.
Interested?
Plan to attend the CIPTUG Northwest Chapter Meeting!
Who: CIPTUG Members and Cisco IPT users
What: CIPTUG Northwest Chapter Meeting
Agenda:
• 11:00 - 11:30 am
Welcome & Chapter Business
• 11:30 am - 12:00 pm
Cisco Roadmap - Chris Steffy
Cisco Unified Communications Portfolio
• 12:00 - 12:30 pm
Lunch Provided by Agito
• 12:30 - 1:30 pm
Cisco - Laura Smith
Cisco Mobile Unified Communications
• 1:30 - 2:30 pm
Agito Networks - Jim Alexander
Agito Networks RoamAnywhere Mobility Router
• 2:30 - 3:00 pm
Birds of a Feather/Open Mic
• 3:00 pm
Meeting Adjourns
When: Tuesday, April 14, 2009
11:00 am - 3:00 pm - Please RSVP - Lunch will be served
Where: Cisco Systems Bellevue WA Office
500 108th Ave. NE - 5th Floor
Bellevue, WA
RSVP:Click here to Register
Virtual details will be available to registered participants. Giveaways (in person participants only): Plantronics Bluetooth Headset, Cisco Books, CIPTUG Logo'd Merchandise.
Book Review: +Power of IP Video, The: Unleashing Productivity with Visual Networking
Thought I would do something a little different. This is my first book review here on the blog. Hopefully more will follow.
The Power of IP Video (ISBN: 158705342x) is certainly not for those looking for the technical details about IP video but more about how using IP video can improve business processes and how to better communicate with employees using IP video. The book was generally well laid out and easy to read and does provide some great business cases examples from Cisco and other companies that have invested in Cisco technology. A large part of the book concentrates on Cisco Telepresence which is Cisco’s flagship IP video solution and how it is being used to solve business problems and lower costs by reducing travel as an example.
While the authors have done a great job of covering a great business cross section they are a little light on the details such as how much a company actually saved other than Cisco’s own business case. I think this book could have sent a much more powerful message on cost savings if Cisco had been able to release a few more of the details from companies other than just Cisco. For me the highlight of the book were last chapter and appendixes which talk about the green case for IP Video and more details about the savings Cisco realized by using IP Video.
All in all this is a good IT reference for decision makers looking to invest in IP video. It has a lot of the right information even though some of the facts and figures are missing. 4 out of 5.
The Power of IP Video (ISBN: 158705342x) is certainly not for those looking for the technical details about IP video but more about how using IP video can improve business processes and how to better communicate with employees using IP video. The book was generally well laid out and easy to read and does provide some great business cases examples from Cisco and other companies that have invested in Cisco technology. A large part of the book concentrates on Cisco Telepresence which is Cisco’s flagship IP video solution and how it is being used to solve business problems and lower costs by reducing travel as an example.
While the authors have done a great job of covering a great business cross section they are a little light on the details such as how much a company actually saved other than Cisco’s own business case. I think this book could have sent a much more powerful message on cost savings if Cisco had been able to release a few more of the details from companies other than just Cisco. For me the highlight of the book were last chapter and appendixes which talk about the green case for IP Video and more details about the savings Cisco realized by using IP Video.
All in all this is a good IT reference for decision makers looking to invest in IP video. It has a lot of the right information even though some of the facts and figures are missing. 4 out of 5.
Response to comments by CK1
Thought I would just do a quick entry for an interesting comment I received.
CK1 asked some great questions that I wanted to respond to and maybe others might like to read without having to pour through the comments.
Question: What do you feel is the right combo (if any) of Cisco and Microsoft UC (voice, video, conferencing, presence, federation, etc...) products? We have Cisco CM 4.x now but my boss is a MS guy and wants to switch all Voice/UC to Microsoft.
Answer: Great question and one that a lot of companies are asking at the moment. I think to truly answer this you have to look at where you are going to get the best technology for the best price while still getting the return on your current investments. Just because your boss prefers MS does not mean this may be the best investment to rip and replace. The Cisco product line has been around for a lot longer and is the mature product with a big range of hardware, but MS have done a great job so far to make the right investments in the right places and have shown true innovation with OCS. I think if your company has heavy investments in both products, then I think using current interoperability options and using MS for mobile users and Cisco for the desk phone is a good choice.
From a technology stand point it’s hard to make a clear choice in either direction if you are to choose just one. Both have their strengths and weakness and what it comes down to then is your environment. Are you best served to favor the mobile crowed that would prefer a strong desktop integration or more of desk bound environment where your customer prefers a hard phone. This along with cost will tell you what solution will fit in your environment best.
Question: What are the pros/cons of having a pure MS solution (Costs (hw/sw), reliability, scalability, Performance, Hard Phones?
Answer: I think that MS have done a great job so far with the release of R2. In a relatively short time the product has matured very fast. R2 has been a big improvement over R1 in nearly all the areas you mention. With the consolidated topology OCS is very scalable and reliable and should easily fit in most environments without too much pain. Of course larger deployments will always have its difficulties but that really comes with any software and its not always the software that causes the issues.
Cost is a funny one because volume discounts vary greatly but in saying that I think no matter what size company Microsoft have positioned themselves to be extremely competitive.
Hard phones (stand alone device and not a usb device) is an area that MS really haven’t hit the mark yet. The Tanjay is quite expensive at recommended retail and is not really, what I call the most ergonomic device to use. Although having your IM contacts on the hard phone is cool I think this area could be a pain point for MS when customers hard press them for more options. There are some other companies like Snom that are starting to release OCS compatible products but none have yet to reach the quality or depth that Cisco are offering for CUCM. On the desktop USB side of the house, MS partners are producing some great products that are growing in number which is why I like OCS as a mobile user solution.
Question: Also, my understanding is Cisco is to release a OCS plug-in that will scale down the design efforts for presence.
Answer: Yes they are but I can’t delve into the exact details. I think sometime in the second half of the year they will release more details on this and for a Cisco centric environment, I think it will be a welcomed improvement that will greatly simplify not just presence but call control if you choose to do it all with CUCM.
Hopefully this helped answer some of CK1’s questions, although I am sure now you have a thousand more. Please feel free to comment.
CK1 asked some great questions that I wanted to respond to and maybe others might like to read without having to pour through the comments.
Question: What do you feel is the right combo (if any) of Cisco and Microsoft UC (voice, video, conferencing, presence, federation, etc...) products? We have Cisco CM 4.x now but my boss is a MS guy and wants to switch all Voice/UC to Microsoft.
Answer: Great question and one that a lot of companies are asking at the moment. I think to truly answer this you have to look at where you are going to get the best technology for the best price while still getting the return on your current investments. Just because your boss prefers MS does not mean this may be the best investment to rip and replace. The Cisco product line has been around for a lot longer and is the mature product with a big range of hardware, but MS have done a great job so far to make the right investments in the right places and have shown true innovation with OCS. I think if your company has heavy investments in both products, then I think using current interoperability options and using MS for mobile users and Cisco for the desk phone is a good choice.
From a technology stand point it’s hard to make a clear choice in either direction if you are to choose just one. Both have their strengths and weakness and what it comes down to then is your environment. Are you best served to favor the mobile crowed that would prefer a strong desktop integration or more of desk bound environment where your customer prefers a hard phone. This along with cost will tell you what solution will fit in your environment best.
Question: What are the pros/cons of having a pure MS solution (Costs (hw/sw), reliability, scalability, Performance, Hard Phones?
Answer: I think that MS have done a great job so far with the release of R2. In a relatively short time the product has matured very fast. R2 has been a big improvement over R1 in nearly all the areas you mention. With the consolidated topology OCS is very scalable and reliable and should easily fit in most environments without too much pain. Of course larger deployments will always have its difficulties but that really comes with any software and its not always the software that causes the issues.
Cost is a funny one because volume discounts vary greatly but in saying that I think no matter what size company Microsoft have positioned themselves to be extremely competitive.
Hard phones (stand alone device and not a usb device) is an area that MS really haven’t hit the mark yet. The Tanjay is quite expensive at recommended retail and is not really, what I call the most ergonomic device to use. Although having your IM contacts on the hard phone is cool I think this area could be a pain point for MS when customers hard press them for more options. There are some other companies like Snom that are starting to release OCS compatible products but none have yet to reach the quality or depth that Cisco are offering for CUCM. On the desktop USB side of the house, MS partners are producing some great products that are growing in number which is why I like OCS as a mobile user solution.
Question: Also, my understanding is Cisco is to release a OCS plug-in that will scale down the design efforts for presence.
Answer: Yes they are but I can’t delve into the exact details. I think sometime in the second half of the year they will release more details on this and for a Cisco centric environment, I think it will be a welcomed improvement that will greatly simplify not just presence but call control if you choose to do it all with CUCM.
Hopefully this helped answer some of CK1’s questions, although I am sure now you have a thousand more. Please feel free to comment.
Subscribe to:
Posts (Atom)