Welcome back!
Recently, I had an interesting opportunity with a local University. They have been using Cisco CUCM for about 5 years, but a couple years ago they migrated away from Cisco Unity for their Unified Messaging and instead started using Exchange 2007. Everything was working just fine.
Until.
They tried to get Exchange 2010 UM working as well in a coexistence situation with 2007 UM.
Rather than focusing on the easy part – you can read the really great document that already exists discussing how to configure Exchange 2010 & CUCM for Direct SIP.
This part was already done and working for the customer. If a user already had their mailbox on exchange 2010, and you dialed the voicemail pilot for CUCM->Exchange2010 – it was great.
The real issue here was when the customer wanted to migrate the voicemail pilot to Exchange 2010, yet the user mailboxes still lived on Exchange 2007.
In that case, when you dialed the Exchange 2010 Voicemail Pilot, the call simply failed. It didn’t ring. It just failed. That’s not helpful. Let’s get some advanced logging in play.
On Exchange 2010 – Unified Messaging – we enabled Expert level Diagnostic Logging.
Also on Exchange 2007 – Unified Messaging – we did the same thing.
Let’s look at the log files.
So, the user at 8815 calls 8699 which is the voicemail pilot for Exchange 2010. You can see this is going to Exchange 2010 which is “sv-ad-max-exch4”
Exchange 2010 knows that 8805 belongs to our “DPierce” user. It also knows that the mailbox for DPierce belongs on Exchange 2007 which is “sv-ad-xod-exch1”
Now, Exchange 2010 starts to end the call
And this is the SIP REFER / Diversion. Exchange 2010 sends the call back to Call Manager to send it back to Exchange 2007.
Then the call fails. Something is broken and not working properly.
If we look a little more closely at the Cisco / Exchange 2010 document linked above, we see the following useful tidbit of information.
It looks like there is a DNS / FQDN requirement here. This is different because if you’ve ready through my previous Exchange 2010 / CUCM posts, you’ll notice that IP based SIP trunks work just fine. And, in fact, in this situation, both the Exchange 2010 and 2007 SIP trunks were IP based.
So, we change both 2010 and 2007 SIP Trunks to use FQDN, but no joy.
So we login to CUCM via the CLI and make sure DNS works. It does.
Weird. So I spent a ton of time trying to figure it out, talk to a lot of smart people including @amyengineer who gives me some reasonable pointers. None of them work. Deep in my gut I’m positive this is a missing Enterprise Parameter from CUCM.
So, we open a TAC case. But, before TAC responds, my customer asks me what my gut feel is. I tell her i believe it’s a domain based (DNS based) Parameter. So, we begin googling and googling and googling and run across this post by another really smart guy @voipnorm. What’s funny is that that post is CUCM / Lync… but it has this really important information.
Read that last sentence again. SIP 404. This sounds like our issue.
So, we add those parameters.
This requires service restarts, so, we restart the Call Manager service on both the CUCM Publisher and Subscriber.
Then we try again. It’s been weeks now, so, we’re hopeful 🙂
And it works! WHAT?
8805 is our test user this time. This is the same.
Yup, 8805 is “khanlon” here. This is the same.
Call starts to disconnect. This is the same.
SIP REFER / Diversion goes back to CUCM. This is the same.
But the call works. Let’s take note of our call information / hash.
b0222400-f2c13cd1-9bb-205010a is what we’re keeping track of.
So, let’s look at Exchange 2007.
Wow. Check that out. We’re definitely on the Exchange 2007 server here. Notice the Computer name in the log file. Also notice the “Diversion Information” came from Exchange 2010 (sv-ad-max-exch4) and notice the Call ID is the same “b0222” number we noted from above.
Yup, UM takes the call, the CALL ID matches. All is well.
All of this was a simple missing Enterprise Parameter in CUCM.
Hope this helps someone else in the future.
Thanks again Amy & Chris – you guys are uber smart!
How does this same scenario work between 2 different AD forests? We are in the process of migrating 2007 UM mailboxes to 2010 but 2010 is in a different trusted forest. We need to maintain 1 voice mail pilot between both Exchange environments and would prefer to move the pilot to Exchange 2010. Is it possible that if Exchange 2010 does not recognize the extension, it can re-route the call to Exchange 2007?