One way audio without conference bridge, 2-way with bridge

[fieryhail]

I'm having a rather strange issue.  I have CUCM 7, CUPS 7 up and running and everything is fine with local connections, also with most remote client connections from wither CIPC or CUPC.  However, I have a client who is running Windows 7 x64 with the Cisco VPN Client 5.0.7 and this is where the issue arises.  VPN is being handled by PIX 525 running PIX OS 8.02.  The vpn tunnel comes up fine, and user is able to access appropriate network resources perfectly.  CIPC or CUPC login and register perfectly.  Accurate presence is displayed with CUPC as well.  When the user tries to initiate or receives a phone call from another internal DN, the call connects as it should.  However there is one-way audio.  For example, my IP Phone 7970, DN 1001 and remote CUPC/CIPC DN is 1021.  1021 calls 1001, I answer, they hear me perfectly, using CIPC I see 2-way network traffic on DN-1021.  On my end (1001) I see Sender packets but no Rcvr packets so I can not hear the remote user at all.  However, when I join 2 separate calls together I now hear audio from 1021.  So to sum it up, it appears with a 1 to 1 call from 1021, there is only one-way audio, but full bi-directional audio when on a conference call.  I don't believe there to be an issue with the VPN (which is connected using UDP) because calls work as supposed to using a conference bridge.  Possibly something to do with MRG/MRL?  I'm not sure.  Other remote users who use the same IPSec profile do not exhibit this issue.  The same symptoms occur regardless of using UPC client or IPC client.  Any thoughts or suggestions where to narrow down this issue are much much appreciated!  Thanks in advance!

[asandborgh · Accepted solution]

Hi There,

One way audio is a classic sympton of an IP routing issue in the mix.  The signalling protocols to set up the call don't go between the endpoints, and it is likely that the endpoints can both see the CUCM,  but the voice RTP does go direct.  You should have the VPN user try to ping the IP address of the IP phone in question - I bet he can't.  The likely reason the conf bridge fixes it is that now the phone is not the destination of his RTP stream, the CFB is and he can likely ping that as you can too so it acts as a "relay".

HTH,

Art

[fieryhail]

Thanks for your response Art, I'm kicking myself for missing the obvious lol.  However, it gets a little more curious.  As

you thought, you're 100% correct, no ping from the remote user to my IP Phone or vice-versa.  It gets a little more curious though.  There are 3 networks that are given access to via the IPSec profile, one contains DNS servers, one contains the Unified Communications servers, and the other contains IP Phones/workstations running IP Telephony software such as UPC or IPC.  The first client has access to the first 2 networks listed as they ought to.  Split-DNS is active also.  I don't believe there to be anything wrong with my routing config as other remote users who need the same functionality use the same IPSec profile and from any remote location they login from all 3 networks are available and connections to all the UC services work as they should.  I realize that this may be edging away hard from IP Telephony so if I'm wrong in replying here I do apologize.

This user connects primarily from within a campus network, not too sure of the security setup there but I know they run Sophos as well as a MS ISA server setup as I noticed from a ROUTE PRINT frm the CLI on her system.  What I'm not sure of, is there a way that either Sophos or ISA would modify the networks that were allowed to come through the VPN?  Not sure if that is the correct way of putting it, I deal more with voice than IP Security.  But what would cause her to only be able to access 2 of the 3 networks the PIX is programmed to send out?  I checked and her windows firewall is disabled as well, so that's not causing the issue.  I see it's plainly an IP routing issue, but why sme networks and not all of them?  Any light to shed on this subject?  And thank you once again for your immediate response.  It was definitely something I should have realized earlier lol.

[asandborgh]

You're welcome.  Like you I'm not much of a security person either.  However there is obviously something different in how she is connecting.  Can you set her machine up next to one that works so you can check exactly how the clients are configured.  It would also be interesting to see a trace route to an IP phone to see where in the network her's fails.

Good Luck!

Art