Cisco Support Community
Community Member


Hi all:

I have one way audio on a vpn connection between remote officers and my central cisco ASA by internet, in a fourum we found that the following line can be the problem on the 5500:


policy-map global_policy

 class inspection_default <<<<<<<<<<<<<<< removing this line

  inspect h323 h225

  inspect h323 ras


What do you think about?



Community Member

There are many possible

There are many possible reasons for one-way audio, for example routing problems, incorrect classification of traffic intended for the VPN  and so on. It is possible that the inspect H323 feature could break something too but it would mostly depend on whether your are intending to NAT the  traffic between the two offices (normally inter-office traffic is not NATed).


If it is not a major change for your organisation to change inspection rules then you could quickly rule it in or out by disabling but I would only disable the specific application, or in other words:

class inspection_default 

inspect h323 h225 <<<<<<<<<<<<<<< removing this line

  inspect h323 ras <<<<<<<<<<<<<<< removing this line

All of this assumes you are using  H.323 for audio of course.


Another approach is to start troubleshooting at the beginning, something like below:

1) In which direction is the audio traffic failing?

2) Capture the audio RTP stream, unencrypted , nearest  the source and confirm the destination IP address. Is it correct?

3) confirm the unencrypted traffic is permitted by ACLs on the Firewall.

4) On reaching the firewall confirm the VPN process is correctly classifiying the unencrypted traffic and encrypting it / tunneling through the VPN

5) confirm the traffic is correctly decrypting and egressing at the far.


And of course all of this assumes that basic checks have been done, such as testing the far-end microphones, far-end mute etc. Apologies if you have already tested this but if I had a dollar for everytime the really basic stuff gets overlooked I'd be a wealthy man :)




Routing would be a good bet. 

Routing would be a good bet.  Remember, you have to be able to initiate a path in both directions, both to the telephony device and all primary/secondary call managers, but ALSO to the voice gateways.  Since you can initiate the call, verify what voice gateways will be assigned for that site, and that the end devices AND gateways both have correct routing to device AND to assigned loopback addresses if they are used.

CreatePlease to create content