Desperate Help Needed - One Way Audio (Unity 3.1)

[LardMonster]

This is the story from beginning too the story so far.

The working system consisted of CallManager 3.1(4) SP-B, Unity 3.1(3) running CMTSP 7.0.1.

CallManager was upgraded to version 3.3(2) SP-C and upgraded TSP version 7.0.2.

Since then we are only getting one way voice. For example when a user tries to go into there subscriber account to modify there voicemail greeting they can hear the prompts but when they try to leave a greeting it doesn’t record anything.

Assuming it was the TSP that was causing the issue I uninstalled version 7.0.2 and installed 7.0.3 to no avail. I manually removed TSP (i.e. registry entries, audio driver etc.) and reinstalled version 7.0.3 to no avail.

The CallManager sits on a different subnet to the Unity server. A 3550 Layered Switch separates the 2 subnets and to test the connection we connected an IP phone to the CallManager's subnet and tested. Because the CallManager & the Unity Server are on separate subnets we changed them to be on the same subnet and again the problem still persists. The call stats reported the TxCnt as nil so it was receiving but not sending. One of the suggestions in the one way audio troubleshooting guide was that if there’s no TxCnt data streaming then RTP needs enabling. RPT data streaming is working because it is accepting DTMP tones. DTMP streams over RTP (even though it uses a different path to the audio) so that’s working to an extent. We can ping the CallManager & gateway from the Unity box and visa versa.

The system is a MCS 7800 and I am unable to remove the second network card because it’s attached to the systemboard ;) but the second network card is disabled.

I got the customer to test record a message through the Media Master and as soon as he pressed the record button he received a message "Unknown problems are preventing the connection to the server". This must mean that calls coming into the Unity system are being accepted but can't contact CallManager to ring to phone.

I attended site Friday to re-build the Unity Server to rule out any TSP issues to no avail.... the problem still existed.

After testing the system some more we found out that only external calls can be recorded and internal calls just record dead noise.

I've noticed other posts with other people with the same problem but no resolution.

Any feed back would be gratefully accepted.

Regards

Mark Mckone

[LardMonster]

Sorry.... I meant DTMF Tones but I guess you got the gist of what I was talking about ;)

[kechambe]

There are several things that can cause this. If it is urgent you should open a TAC case.

Check out this URL:

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_tech_note09186a0080093c11.shtml

Also check out this defect. It has been seen several times:

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCec60226

Hope these help...

Keith

[LardMonster]

Thanks for the reply

I've had a TAC case open since the 8th October and the only resolution I've been given is disable the network card. I've studied the above links but still haven't found a resolution yet.

Kindest Regards

Mark Mckone

[Ginger Dillon]

Hi Keith -

I've been trying to find out where the CallManager OS 2000.2.5 (Win2K SP4) upgrade disables Path MTU discovery. I checked the release notes for the Microsoft service pack and did find Knowledge Base article 326926 - "Dynamic Host Routes Are Not Removed if EnablePMTUDiscovery Is Set to Zero", but not sure if this is the one that applies. I haven't been able to find a similar bug reference point documented for CallManager and it does not appear to have been addressed in the OS 2000.2.5sr3 release either. We were unable to apply the CCM OS upgrade until an IPCC Express bug was resolved, which it has been in the sr3 version. Also our Unity server is on the same subnet as CCM, which reduces the risk of seeing this error. But if you could point me towards additional reference material, I would appreciate it :-)

Thanks, Ginger

[trevor.hanekamp]

We have seen this under two conditions: 1. When a 2nd network interface on the Unity server in enabled.

2. When trying to communicate through the firewall directly as it does not allow two way traffic. We introduced a VPN concentrator to resolve the problem.

[dofink]

I recently experienced the identical symptom at a customer site. Unity was and still is on a separate subnet than the CallManagers. I applied the following H323 bind statement to the Voice VLAN router interface (i.e., the CallManager's default gateway interface).

interface Ethernet3/0

description Voice Default Gateway

ip address 192.168.100.1 255.255.255.0

h323-gateway voip bind srcaddr 192.168.100.1

This corrected the problem immediately. Hope this helps!