atcomsystems.ca/forum Forums TDM Business Telephone Systems Toshiba Telephones & Systems IP Phones Don't Work After Reconfiguring Routers

Weird stuff.

Here's our current scenario:
We run a CIX670 and digital phones at our main building and Toshiba ip phones at our other facility. We have a T1 between the buildings and a Cisco 1721 on each end. The routers are currently configured as transparent bridges. Both buildings share the 192.168.2.x network. Everything works fine. No problems.

When we put in the phone system a couple months ago, we now have an extra T1 that the old phone system used. I'd like to put that extra T1 to use and bond the two T1's together for more bandwidth between the buildings. To do that I need to route ip. So I changed our other facility to a 192.168.4.x network and reconfigured the routers to route ip instead of bridge it. I haven't added the extra T1 into the mix yet. I did update the gateway the CIX uses with the 192.168.4.x network. The CIX is still on the 192.168.2.x network.

Here is where it gets weird:
The ip phones startup fine and get a 192.168.4.x address and find the CIX670. They show the station number/date time/message waiting. BUT the ip phones can only make ONE outside call or ONE call to a digital phone at our facility. After that calls have no sound either way. If I get a call from an ip phone, I can see who is calling me but when I pick up I can't hear them and they can't hear me. Likewise if I call them. Now if they call me and I let it ring to my voice mail, they can leave me a message just fine. I put an ip phone on our network at our building (192.168.2.x) and there are no problems at all with the ip phone here calling the ip phones at the other building and them calling our ip phone. It works fine everytime. They also can call each other at their building just fine.

Computerwise, there are no issues, all servers and printers are accessible between buildings. Just the phone system is giving us problems.

Our installer came out to look at it and they didn't see anything wrong. They had us check under eManager for 250-16, IPT NAT/No Peer to Peer but it didn't make any difference.

Any ideas?

Thanks!!

In your case, you should keep IPT NAT/ NO Per to Per Disabled. This allows IP phones to talk directly to each other, which will cut down bndwidth for the IPT to IPT calls.

In a case where you have IPT phone outside the Local network, and behind a NAT router, you would enable it so that all calls are routed through the phone switch. This setting will have no effect with any other type of IP calls, IE.. IPT to DKT, or IPT to outside call.

The odd thing is the fact that you can get one call through, and that IP phone in building A can talk to IP phone in building B, which makes it look like an IPT to LIPU (or BIPU) problem. The IPU cards handle all the IP phone connections. Look at the Gateway setting for the IPU (LIPU or BIPU, or the newer MIPU). The phones obviously are getting DHCP.

I would also start with disabling all QOS settings in eManager, diffserv, 802.11Q, etc. That commonly can block audio. You can enable diffserv later if this is not the problem, but they will only work if your router is also configured with QOS.

I helped setup a network exaclly like your case. The company bought a building down the street and connected all 20+ IP phones in the remote site through a T-1. They had 2 different subnets, one for the main site with the CIX670, and another for the remote site with the IP phones. All calls worked fine.

Thanks for the tips, I appreciate that.

I was playing with it today but still no luck. Weird how I can be at the "IP phone only" building and call our back door number with my cell phone. Then transfer myself to an IP phone extension, see my cell phone number coming in and when I pick it up there is no voice either way. Then when I hit the hold button on the ip phone, I get our music on hold in my cell phone.

I'm gonna take a closer look at our routers. Something just doesn't seem right. Weeeee.

So the installer came out and looked at it and didn't see anything wrong, but it still doesn't work?

The on-hold music is put on the line at the switch, just like if you transfered the cal to a DKT phone, the sound will also work fine.

The problem seems to be that the audio path from the switch to the IP phones are being block, but all the call control ports are passing through ok.

You have access to eManager? Have you looked for QOS settings in the CIX and/or the cisco? Do you need to know where to look? Will a list of ports used by the IP phones help you?

I did check the QoS settings. Nothing made any difference.

I was playing with the default gateway on the LIPU and set the ip address to the cisco router's ip address. That seemed to do the trick. We were able to make multiple in/out/voicemail calls with no problems at all with the ip phones.

Not sure why our main gateway wasn't doing the trick. I had a static route in there pointing to the cisco router. In fact when you'd initially put a call thru the ip phone it'd work. Just not after. Yet voicemail worked fine everytime.... as did ip phone <-> ip phone conversations between buildings.

Weird.... I'm satisfied with the fix I guess. I haven't implemented it yet but we'll see how it goes next weekend.

A list of ports used by the phone might be useful in the future if you have one handy.

Thanks again!

Here's a copy and paste from a post someone left me once a while ago.

The LIPU cards have their own IP information separate from the phone system processor - they actually have a version of Linux on them (or so it seems to me from what I've seen) and need to be configured separately from the processor. I'm suprised it worked - the phones have their own addressing information so they can get to the IPU, but the IPU doesn't know how to respond to them since it has no gateway. How were they able to register themselves without the IPU being able to respond? It does make sense why they can call the other IP phones - it's a phone-phone call and it's not going through the phone system.

Connection Request
StrataNet (QSIG)
4029
TCP

Call Control Channel
StrataNet (QSIG)
6400-8191
TCP

Registering IPT
RAS (H.225)
1718, 1719
UDP

IPT
RTP/RTCP
1500-1503
UDP

IPT
RAS/MEGACO
45152 and 45153 (default)
UDP

Call Control Channel
MEGACO+
2944
TCP

Media Channel for TDM
RTP/RTCP
16384-16511
UDP

Medial Channel for NAT
RTP
20480-20991
UDP

Medial Channel for IP QSIG
RTP/RTCP
20992-24575
UDP

The ones for QSIG are not used for IP phones.

Thanks for the info!

Well the IPU did have a gateway address. It was the address of our main gateway (a SonicWall appliance). Our main gateway had a static route to the Cisco router. It'd work for the first call but not after that.... but fine for ip-ip conversations. After changing it to the Cisco router's ip address it worked much much better. I must've flipped it back and forth between the Sonicwall and Cisco about 4 times testing it. I wasn't sure what the Sonicwall was doing that was interfering but apparently it's doing something?

Really? They don't use the phone system at all? I figured there would be some initial handshake (dnd, ip address of the other phone, etc) with the phone system and then it'd just hand off the rest of the conversation to the phones themselves. But I'm definitely no expert here!

For IP phone to IP phone calls, after the phone system creates the call, the phones talk directly to each other without passing audio traffic through the switch, as long as they are on the same network. There is still call control and keep-alive from the phone switch to the phones.

That is what the setting 250-16, IPT NAT/No Peer to Peer controls. It should be disabled in your case (allow per to per). If you had a remote phone outside the LAN, you would want it enabled for that phone only.

It seems as though the call control signals from LIPU to phones were working, or else the phones would not even come up at all. The phone registration proccess reqires 2 way communication. The audio, RTP traffic was not being routed correctly. I am not a router expert so I'm not sure why some data could pass and the RTP audio could not.