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.
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
Subscribe to:
Posts (Atom)