5610 to 5610 = cannot hear the other party

[tmckeown]

We ran into ths last year and never found a solution. I'm hoping something has changed and someone knows the answer.

We have some users in two locations that use 5610 IP Phones. They connect to the main system via an IPSEC tunnel through our firewalls. The 5610 phones can call our regular 5410 digital phones and visa-versa without a problem. But if a remote user (5610) calls another remote user (5610) neither can here the other party. The phone rings and you pick up, but all you get is silence. Here's the funny thing. If you intercom the other person it works fine; both people hear the other person. Pretty odd eh?

I know other people have run into this exact problem, but I did a search and can't find the solution. It seems to be a bug, but it has existed since at least 3.0. We are using 3.1 (65) currently.

Got any ideas?

 

[kristiandg]

I have this bug in the 3.2 trials...

Interesting. I have a tkt open for it, so when they fix it, I'll post what was up...

Kris G.

 

[tmckeown]

Thanks Kris,
I'm hoping you get an answer soon. I'm in maintenance agreement limbo now, I'm waiting for the new agreement to kick in, then I can call Avaya myself.

 

[1A2toIP]

Have you tried turning off Allow direct media path on the VOIP tab of the IP phones? I think I had the same problem and this may have fixed it. However every call seemed to use 2 VCMs.

 

[tmckeown]

Is there a limit on VCM channels? What happens when they are all in use?

thanks,

 

[tmckeown]

Also, is there a better compression mode? Ours is set for G.729(a) 8K CS-ACELP

 

[tmckeown]

Oh, another thing that we just found out. It appears that Ip phone to IP phone does work if they are behind the same firewall. That makes me think that there must be another port that need to be openned, though I'm not sure what it could be yet.

Example.
Our IP412 is in Chicago. We have 5 5610 phones in LA at one of our offices. They can make calls to each other but not to a 5610 in Chicago. That leads me to believe it's a firewall issue.

 

[sizbut]

There's a whole UDP port range that has to be open in both directions, the default is 49152 to 53247. And any NAT (often applied by firewall) will also break VoIP. This is not an Avaya thing, H323 and firewalls have never been a happy mix

 

[JayNEC]

It's not the ports, you need to allow IPSEC tunnel-to-tunnel traffic. (in a sonicall it's called "forward traffic to remote VPN's).
The IP Phones are trying to pass data directly to each other. The reason they ring, is that the signalling data is coming from the IP Office itself at the hub to each of the VPN remote subnets.
You could disallow direct IP, which would force the use of a VCM. Then the audio would be to/from the IP Office itself, just like the signalling data.

I'd be willing to bet that from one spoke, you can't ping any IP's on the other spoke. From the hub you can ping everything.

 

[tmckeown]

Thanks for the replies,
I started thinking about it a bit more. Now, I'm not completely sure about the firewall idea. Each location has a watchguard firebox. There is a IPSEC tunnel setup between the two firewalls and I have set those to allow all traffic through the tunnel; there are no filters stopping traffic. But still, the odd thing is that IP phones in the same office can call each other (ring and speak), while IP phones in different offices can ring but not speak.

Jay, you are correct that I can ping everything from either office. If I understand you correctly, "Allow direct media path" allows the phones to talk directly to each other without going through the IP412. Is that correct? If so, that would explain it a bit. If that assumption is correct, is there any way to cure that via a firewall setting or is that definately a need to use VCM instead of direct?

Thanks for the help

 

[JayNEC]

So,to clarify the remote office can ping the other remote office?

 

[tmckeown]

Yes, I can ping from the main office to the LA office andI can ping from the LA office to the main office. I'm going to do some more testing as soon as the LA people get in to the office. I may have a clearer picture then.

 

[SuperJenks]

OK, JayNec is correct.

When making an IP call from a 56xx to a 56xx via vpn connection when direct media path is on, the IPO system will set the call up initially using a vcm resource, but once the connection is established, it drops the VCM and IPO, and connects directly from phone to phone. Now, some vpn routers will allow routing from one vpn tunnel to another, and others will not. Its clearly a routing issue, or a limitation of the router itself. If the end user can ping the other end user, than this should work no problem. You need to determin if the router will allow such connectivity. If not, you may need a different vpn router, or possibly add a route in your switch or network to allow connectivity from remote user to remote user. If you turn direct media path off, the IPO system will bridge the connection between the two 56xx sets via a vcm resource until the call has ended. However, you need to make sure that you have static IP routes to all subnets so the call traffic knows how to get there. This can be done either via IPO IP route table or the network switch/router. Good luck!!

 

[tmckeown]

You hit it on the head. I just came to that conclusion before I read your post. All our firewalls have VPN tunnels back to the main office where the IP412 is. There is no tunnel between other sites. I'll need to see if I can setup some routing between tunnels. Is so, great. If not...

 

[tmckeown]

Just a recap,
After configuring our tunnels to route to each other, we got the IP phones working as expected. The proceedure for doing that with Watchguard firewalls was not an easy thing to figure out. I had to open a support case and still get some extra help from their forums before I got it going. Routing between tunnels in a Hub and Spke configuration is not a documented or supported feature from Watchguard.

Thanks to eveyone for your help.