01-21-2010 07:43 AM - edited 03-15-2019 09:09 PM
Hello everyone.
We're having a specific problem with voicemail being hosted on Exchange 2010. We're using Call Manager 7 that connects to Exchange 2010 over a SIP trunk (we're not using Unity cause it crapped out on us). For the most part this setup works fine for voicemail, mwi, etc.
The particular situation where it falls apart is when a call is transferred using the direct to voicemail pattern. At this point I begin to see RTP packets sent from Exchange to the CUCM router with invalid header checksums and on the user end they are prompted by Exchange with "Are you still there?" as they try to leave a message.
Occasionally calls made using the direct to voicemail pattern will go through but there is no discernable different between the calls that fail and the ones that succeed.
Exchange 2010 is running on server 2008 R2 with rollup 1 installed. The Windows Firewall is set to allow all connections on the domain network over which the SIP trunk is communicating. It is also running on a VMware WM though I don't know that this would make any difference.
Any suggestions would be appreciated and I can provide any debugs or traces that would help.
01-26-2010 09:25 AM
Hi -
I see you posted this on Technet forum back in October - http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/b5b84862-90f6-4ebd-88f5-06c094a8a908
I would be interested in Microsoft's take on the problem when you contacted them. Also, I just notified you mentioned Exchange 2010 is virtualized... is that for your UM server role? The UM server role is not supported for virtualization. Here is a link that mentions that - http://blogs.technet.com/ucedsg/archive/2010/01/12/can-i-virtualize-exchange-server-2010-and-be-supported.aspx
Thanks, Ginger
04-14-2010 07:00 AM
Ginger (and any other readers),
Sorry for the delayed response. I thought I had replied previously but apparently that post failed. I have heard nothing from either MS or Cisco on this issue.
I understand that there are issues with Exchange UM running virtualized but I am very certain this is not the issue and this is because the problem I run into is very specific.
Calls that go to the voicemail pilot (in this case dn 630) on a No Answer or Busy or CFWD All have no issues with one-way audio.
Calls that are directed with the direct to vm pattern, 7XXX, by a Call forward NA, Busy or All setting on the DN within Call Manager do so without any one-way audio issues.
It is ONLY calls that are transferred with the direct to VM pattern manually by a user on either an IP phone or a softphone that experience one way audio. I am not sure exactly what that means for me in terms of troubleshooting but it makes me doubt it's a UM performance issue due to virtualization.
04-14-2010 07:09 AM
Hi
Does it make any difference where the original caller (the one being transferred) is from? I.e. whether it's an IP phone, or a gateway, for example?
Have you tried enabling the 'MTP' option on the SIP trunk?
Aaron
04-14-2010 07:16 AM
Aaron,
It doesn't seem to matter. I've tested transferring calls originating externally, from other DNs, and calls from the same DN as the VM box i'm transferring too. I end up with the same result; perhaps one in every 15 calls will succeed, the rest get disconnected from Exchange because Exchange receives no input to its prompts due to the one way audio condition
The option "MTP Required" is currently enabled on the SIP trunk to exchange, I haven't tried with this option disabled.
Colin
04-14-2010 07:23 AM
Hi
OK... sounds like you need to start doing some packet traces to see where the problem lies.
Note down the IP addresses of:
Exchange
Originating phone
Transferring phone
CUCMs
Check that you have detailed tracing on the CCM service so you see the SIP traces in the logs.
Then do a packet capture.. start by doing this on your UCM:
Utils network capture count 100000 size all host ip file SIP
As soon as you enter that, the CCM will start capturing traffic.
Make the test, then press CTRL+C to stop the capture on the CCM server.
You can then retrieve the CCM trace logs and Packet capture file using RTMT. Post up the capture and log files... or go through them yourself. You'll be looking to see what IP addresses are being sent back and forth and whether these are correct amongst other things...
Aaron
04-14-2010 01:22 PM
Aaron,
The IPs involved are:
Exchange: 10.10.90.5
Call Manager: 10.10.90.2
Originating phone: 8282858882
Transferring phone:400
400 diverts the pattern 7261 to the voicemail pilot 630.
I'm not very familiar with RTMT but i've posted the most recent sdl and sdi in those directories when I browsed to the CCM node. Hopefully these are what you're looking for.
04-15-2010 12:35 AM
Hi
OK - here's one that comes up from time to time.. in the registry:
Check HKLM\System\CurrentControlSet\Control\lsa - see what lmcompatibilitylevel is set to.
Failing that, set logLevel = 3 in the ini file, and then post back the logs from an attempted connection. I generally find the logs a bit less than helpful for this app, so it would also be worth doing a packet cap of the attempt. This often shows up why the security negotiation with the DB fails.
Regards
Aaron
04-15-2010 12:41 AM
Hi
There's only one SDL file in that zip....
In RTMT, trace & log central, select 'collect files'. Check the 'CallManager' service on the first page, and the 'Packet Captures' on the second page. On the last page, specify the time of your test call and packet capture, and change the download directory to something easy to find.
Oh - and what does '400 diverts the pattern 7261 to the voicemail pilot 630' mean? 400 diverts to 630 (VM Pilot), what is 7261?
Regards
Aaron
04-15-2010 07:47 AM
Couple things to check:
On the SIP profile in CUCM, make sure Stutter Message waiting is checked
Security Profile, all are checked except the first option (enable application...)
On the Trunk itself to/from exchange
MTP is required!
check mark Redirecting Diversion headers on inbound and outbound
Destination port is 5060
select the Sip Profile and Sip Security profile
Create a second Trunk
Same settings as first trunk
Create a route group
Circular for the trunks
Create a route list
add the route group
ON Exchange to CUCM
New Dial Plan - Unsecure
create a UM gateway for each CUCM server in your cluster.
hope this helps
05-06-2010 08:29 AM
Hi,
We have an install that shows the same fault, although its Exchange 2007sp2. Other than than it's the same scenario, the failures are from an outside call being transfered direct to another extension's voicemail via a CTI RP. Packet captures show the RTP stream going to the Exchange server, but Exchange does not record the message but just gives that "are you still there" prompt.
In tests it appears that if the operator pauses after dialing, before pressing the final Transfer softkey, then everything works and Exchange will record the message.
If the transfer is completed quickly, then the fault occurs - but to be clear the transfer is still carried out after Exchange has picked up and started to play the mailbox greeting.
The sequence of events is the same in both cases but only the timing is different. In both cases the initial SIP call setup completes and RTP flows in both directions, then a SIP "Update" message is sent with an updated Remote-Party-ID.
I don't know yet what the resolution is, but it is a simple test to see whether you are seeing the same symptoms
05-06-2010 11:31 AM
Hey everyone. Sorry for the delayed response, I went on vacation and then got pulled away from this issue to another install.
Aaron,
I'll work on getting a trace with both SDL files up. And to clarify when I said "400 diverts the pattern 7261 to the voicemail pilot 630." I'm calling DN 400 from an external phone. I answer DN 400 on CIPC and transfer it to 7261 to perform the direct to vm transfer (the DN is 261; 7... is the pattern for direct to vm) and 630 is the voicemail pilot/route pattern for the route group with our SIP trunks.
Tcatlinins,
Thats exactly how I have it set up. The issue persists.
Tonyatinstalec,
Yes same issue. If i let the message from exchange play for 4-5 seconds before hitting transfer again, i always get 2 way audio
05-06-2010 02:06 PM
Tonyatinstalec,
I believe i've resolved this issue. I never thought to change this setting as I've always seen that it was required but I unchecked "Media Termination Point Required" box on the SIP trunk and we can now get two way audio even if the transfer is performed immediately (or if i use an 'unattended' or 'cold' transfer where the user hangs up immediately after pressing the transfer softkey and dialing the DN).
I was reviewing this document when I decided to change this setting:
The part in particular I found useful was this:
MTP requirements when using an H.323 trunk to Cisco Unified Communications Manager follow:
• If the Cisco Unified Border Element is handling H.323-to-H.323 calls, an MTP is not mandatory if the Cisco Unified Border Element release uses Cisco IOS Software Release 12.4(6)T or later and the Cisco Unified Communications Manager is Version 4.1 or later.
• An MTP can be co-resident on the same router as the Cisco Unified Border Element.
• Configure a SIP trunk without MTP if delayed media or an INVITE with no Secure Device Provisioning (SDP) is acceptable.
• Configure a SIP trunk with an MTP if early media or an INVITE with SDP is a requirement (G.711 calls only).
I figured the fact that the call had 2 way audio if the Exchange VM greeting was allowed to play for a while indicated there was an issue with call setup not completing properly. Since early media didn't seem to be working for me, delayed media seemed to be the way to go and my results would seem to bear this out.
Give it a try and let me know if this fixes it for you!
05-07-2010 02:59 AM
Thanks for the update. Removing "Media Termination Point Required" does not fix this installation.
Without MTP the call to voicemail initially establishes with RTP to/from the IP of the transferring phone as you'd expect. When the transfer is completed CM sends a new SIP/SDP invite but Connection information gives an IP address of 0.0.0.0 that invite gives a blank IP address instead of the correct IP which in this case should be the PSTN gateway. That looks like a SIP fault on the Cisco side and of course audio fails at that point.
We did a bit of messing around, ending up back with the original configuration which now appears to be working. There remains the vague possibility that it was the act of resetting the trunk which made the difference. Aside from that I will have to look in more detail at our saved traces, to try and find a difference between good (today) and bad (yesterday).
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide