Telecommuter, Cisco 7940 & VPN

[tomahawk72]

I am stumped!
Here's the deal...
We have telecommuters that use Cisco 7940s at home via a VPN connection back to the main office where we have a VoIP system in place using Cisco.
If a telecommuter calls someone in the office by dialing an extension (i.e. x5909) there is audio in both directions. This is also the case if a person in the office dials a telecommuters extension.
However, if a telecommuter dials another telecommuters extension the phone rings but there is no audio. But if a telecommuter dials the main company phone number then enters the other telecommuters extension the call goes through and there is audio in both directions.

We've tried everything from changing codecs and whatnot.

The only thing I find on the internet relates to NAT problems. But I feel if it was a NAT problem then it would never work. Why would NAT be a problem only when they are dialing by extensions?

We're stumped. Any advice would be appreciated.

 

[rtfmdude]

tomahawk,

This is a VPN concentrator problem. I've dealt with these in the past, and can't remember the specific 'feature' or phrase used to define this.

Think about it this way, the signaling for the phones all are like this, right:


phone<-->vpn<--->concentrator<--->callmanager

When phones 'ring' each other, the callmanager 'proxies' the signaling for the phones to alert each other:

phone<-->vpn<--->concentrator<--->callmanager
phone<-->vpn<--->concentrator<---/

When the phones actually CONNNECT, however, they start transmitting audio DIRECTLY to each other, like this:

phone--->vpn--->concentrator
phone<--vpn<----/

So, you need to make sure the VPN devices can talk to each other. If the laptops/PCs at home can't ping another VPN endpoint, there's your problem!

Hope that helps! THIS IS NOT NAT, I GUARANTEE IT.

 

[Sympology]

I'm not familiar at all with Cisco kit, but on ours, it defaults to Off bus routing, which does the behaviour you outline.
We have an option for On bus (TDM) routing, which forces all RTP through the PBX and back out again.
Hopefully Cisco has a similar feature.

Only the truly stupid believe they know everything.
Stu.. 2004

 

[rtfmdude]

Sympology,

Yeah, Cisco kit normally keeps it all 'off bus,' meaning the IP endpoints stream audio to each other directly, except for when/if the server is doing software conferencing. There are some security products that can be used to 'proxy' the streams (I think the ASA, for example) if necessary.

 

[tomahawk72]

Thanks for all the great info.
Do you know where I could find info on using ASA to proxy the stream?

 

[BuckWeet]

Are you using a Concentrator or ASA for your VPN server?

 

[tomahawk72]

We're using a Cisco Concentrator.

Does anyone know hy the audio works if they call in through the main number then dial the remote users extension?

 

[rtfmdude]

Tomahawk,

The ASA feature to proxy the stream is going to be released as part of the new code due out this month. I think it's version 8.0(4).

You shouldn't need this though - talk to TAC and get the firewall issue worked out. I bet it's like 1 command

the audio works when the users call into the main number because the audio stream has left the network via the main voice gateway, looped back in again via whatever circuit is there, and then was sent back out to the 2nd remote user. The difference here is that the traffic from vpn user 1 is being sent straight to the voice gateway, where it is changed to tdm audio and sent to the telco. The telco loops the call back (to the main number) and a 2nd audio stream is created going back to the operator, whom i'm assuming is transferring the call to vpn user 2 (or you have a shared line).

working: 2 audio streams going straight from vpn users to voice gateway
non-working: 1 audio stream going straight from vpn user to vpn user

I'm totally confident that this is a vpn concentrator issue; fix that and you'll be good to go. One way to test this would be to call directly from vpn user 1 to 2, noting that it will fail. while keeping that call up, conference some people in from the main site - that will force the audio streams to all go to a central conference bridge and everyone should hear each othker, notably vpn user 1 and 2.

 

[tomahawk72]

I really appreciate all the tips. You guys are great.

I finally figured it out.

In the corporate office we have 1 network (192.168.x.x) for data and another for voice (10.10.x.x).

The remote users NetGear VPN routers were configured to assign 192.168 address to the devices connected to them, i.e. the phone.
I suggested that we change that to 10.10.x.x and everything started working.