Has anyone encountered a problem with MS UM (2010, with I think service pack 3) where in an auto attendant you can't press an option to transfer to an extension back on the Cisco UCM? I'm at version 10.5 for CUCM. I can press 0 to transfer back to the operator number I define for the auto attendant (it rings back to CUCM just fine), but if I use that same number or any other number I know should ring on CUCM mapped to a key in the auto attendant, like Press 1 for Sales and it should go to ext 4500 for example...that doesn't work. Also, I can't transfer to a person by saying their name or manually dialing their ext from the auto attendant. I keep hearing "Sorry, I was unable to transfer your call". I've already double checked the UM dial plan, auto attendant, etc and made sure transfers are allowed and also compared the auto attendant to an older working auto attendant used for an Avaya system. I checked the UM server's application event log and there are no errors at all related to my trying to transfer out of the auto attendant. It's as if it's not even trying, but I guess it is. In the event viewer I do see an information event logged, showing my original call to the UM server's auto attendant number. So far I see no other problems with MS UM and Cisco other thank this transfer problem in the auto attendant.
I'm stumped. Any ideas?
What does work:
I used this Microsoft guide to configure the CUCM side: https://www.microsoft.com/en-us/download/details.aspx?id=13591
You should really trace the SIP messaging between CUCM and MS to see whether MS is attempting the transfer back to CUCM; and see the rejection from CUCM if that's what is happening.
However - a quick check would be to verify you have configured the 'rerouting' and '
I did a trace (network capture) on CUCM yesterday and when I searched though the capture in Wireshark, I didn't see any attempt to call the number it was supposed to be transferring to. Also, in the Exchange server's event viewer, I didn't see a call to the number I wanted to transfer to or even a failure for the call attempt.
I'm beginning to think this is really a problem on the Exchange side. I'm not sure yet.
I'm using +e164 numbers on CUCM also with an 11 digit EAN assigned to my DN as a test. So for example, my DN might be +18585551111 and my EAN would be 18585551111. Either would a good number to call. I see the calls logged in Exchange with my +E164 number when a call to my number is diverted to voice mail. For the successful calls back to CUCM from Exchange UM by pressing 0 from the auto attendant, I see that Exchange is inserting the + before it sends it to CUCM. In the auto attendant properties, it won't allow you to enter the +, it only lets me put in a number, like 18585553434. When it sends that blind transfer back to CUCM (transfer out of the auto attendant by pressing 0), it sends it as +18585553434.
Exchange UM is a little weird. Some places it'll let you enter the +, but in other places it won't.
Anyway, whatever it is, it honestly seems like it's an Exchange issue. I just wish I could see some event logged when it won't transfer to my ext or won't transfer out of the auto attendant by pressing digit 1 for example.
I did also verify the CSS for the items you mentioned on the SIP trunk group. Those are ok.
Ok, I think I have this solved. It's an issue on Exchange UM. We've always been using a traditional non-E164 dial plan in the past. I figured out that I had to configure a new entry for the 'dial rule groups' on the Exchange UM dial plan I'm using. I wish it would have at least given me an error in the event viewer so it would give me an idea of where to look. Eventually I figured it out. Since everything else seemed to be working ok, I thought it had to be something with the E164 dial plan on MS UM and how it was trying to dial the numbers.
would you mind posting what the solution was? I am having the same issue with +E.164 UM dial plan.
I was thinking to try creating dial rules but it just didn't make sense when the UM dialplan type is +E.164 to require dialing rules.