CUPC over VPN - Audio Issues

[ecoen]

I can make an outside call through the CUPC/VPN and it works perfectly. If I call an internal extension (CUPC or IP Phone) from CUPC/VPN, then I have 2-way audio for a variable period of time, then it changes to 1-way audio (only I can hear).

Any ideas?

[Tommer Catlin]

Anytime you have one way audio, its going to be at your firewall or where NAT is taking place.

The call is using SIP back Presence. So 5060 or 5070 depending on how CUPS is configured, etc. Then the SIP invites/requests are sent to CUCM for processing of the call to/from your gateway.

Why it runs, then drops is a little odd. You can enable logging on the CUPC client, then check the logs on your local PC to see what the messages are saying. If you are getting nothing in the logs, check the RTMT on the CUPS server and watch the SIP Proxy to see possibly why it has dropped.

Ensure you have a clear path between CUPS, VPN and back to your client at the remote end. SIP is usually pretty good about keeping the connection open.

I have used CUPC over CheckPoint with no problems. I would keep looking over your VPN/Firewall

hope this helps

[j.mccartney]

We finally figured it out that the problem was we didn't include the voice vlan subnet in our split-tunnel configuration. I don't know why we didn't think of it before. The calls would connect but since there was no ACL to allow SIP devices (on 10.21.X.X) to talk with our IP Phones (10.90.X.X) the audio path would not setup. Once we added the 10.90.X.X ACL to our split tunnel cfg it started working. Glad we got that fixed.

[j.mccartney]

Did you ever get this resolved? I'm having a simialr situation but I get no audio at all both-ways when dialing internal 4-digit number but fine when doing 9+7digit local dial.

I've taken off inspect ras statements on my ASA (no inspect h323 h225; no inspect h323 ras) configured my voice interface on my VG with "h323-gateway voip bind srcadd" cmd but nothig works. Any ideas?

[ecoen]

Yes, I did get this resolved some time ago, but forgot to post the fix. TAC had me upgrade the VPN client to version 5.0+. The reason for the suggestion is a defect (CSCso83716) in the VPN client, which no longer exists in the 5.x+ train.

[Nicholas Matthews]

The symptom of audio coming up correctly and then dropping (usually after 30 seconds, 1 minute, 1:30, etc) is that stateful firewalls only allow the traffic in when there are updates.

You can try creating refreshes on whichever SIP application you're using, or increasing / removing the firewall timeout value.