Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

IP phone problem

Status
Not open for further replies.

BMBurkhardt

IS-IT--Management
May 10, 2010
18
US
We have about 20 offices using IP Office 4.2(24). Recently set up another and everything seemed OK exect that office can't seem to call one of our offices that is using IP phones. The IP phone office can call THEM but not the other way around. The "affected office" can place the call to the IP phone office and it rings, but when end-user pick up handset, it's "dead air." I set up another office about a month ago using identical settings, and THAT office can call our IP phone office without any problems.

I'm open for suggestions!!!
 
Yes, it is....but, all of our other office can call without a hitch. In fact, I believe all of our IP phones have that box checked (default) I will try unchecking the box on one of the IP phone extensions and test it, but because these phones are located at our main office I won't be able to test it until later this afternnon since it will require a system reboot. Will let you know...Thanks
 
Not necessarily the issue but anytime this issue is happening with IP Phones I verify this first. 75% of the time it fixes this issue.
 
So much for "Allow direct media path"...unchecking box didn't make any difference. Open for more suggestions.
 
Do you have another Offices using IP phones that you can call or is that the only one?
Almost sounds like a firewall issue at one of the sites

 
We do have another office and yes then CAN call there. The other office is going thru a different PRI for there calls. The weird thing is, about a month ago I set up another office configured exactly the same as the office that is having issues and it works fine.
 
it is most likely a routing issue, make sure that the IP route in both systems points to their correct default gateway and also make sure that there are routes in the router to go directly to the other site.
compare the router settings of a working site with the non working site.

Joe W.

FHandw, ACSS

Google it you damn kids
 
The affected office can call our main office (which is where PRI is located. The can call any of the Avaya 4412D+ phones, but I hooked up an IP hone in the same building, off the same switch as the phone system in our main office and no go. The IP phone can call the affected office but the affected office cannot call the IP phone...it rings, but dead air on pick up.
 
Is it the same firewall in the affected office as the others that work? Is it configured the same as others that work?

 
I am the network engineer for the company BMBURKHARDT works for. I have been looking into the issue with these phones and I have been sniffing traffic on the network to analyze what is going on to no avail.

There are no (zero) firewalls between these systems.

The issue is very likely NOT a routing issue. Routing is a TCP/IP thing, and packet sniffing shows tcp-ip traffic getting to and from the ip office phone systems and IP phones involved in this issue.

I believe it is a higher levle protocol abpve TCP/IP that is failing here.

Any thoughts?
 
>The issue is very likely NOT a routing issue

I tend to agree, but the symptoms *do* sound like there is a route issue.

Can you confirm
1) That station to station calls to this bad site fail?
2) Do all other sites have teh same issue ringing this site?
3) can the bad site call station to station to all other sites or does the same thing happen?

If the answer is yes, then likely something is screwing the UDP streams.

Quick test - take an IP handset on the bad site and register it back to an extension on a good site and see if you can make calls to and from it from all otehr sites. I'd reckon it will fail...

You now need to fess up a bit about your network config

1) are the handsets in a separate VLAN or are they all on 1 (this can hide routing issues)

2) What sort of connection is there between sites? Is there any possibility that the provder is blocking ports? Are they prviding you with a EF CAR? I've had cases where the prvider provides a EF CAR by default of 1 or 2Kbps which effectively drops the speech paths, but allows signalling

3) What sort of NAT is happening

4) Are you using CISCO routers? Are the H323 transformations on or off. Cisco H323 inspections screw Avaya Voip (it rewrites teh packets...)


Where did you take the packet sniff from?

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.
 
Quick answers

Station to station calls to the bad site all work, whether from IP phone or Digital phone, even from the site that the bad site cannot call, the calls from that site to bad site work.

No other site has the issue with calling the IP phones that the bad site does, bad site can even call other IP phones at other sites.

3, the bad site can call any other site including IP phones.

FESSING UP

The handsets are on VLAN 0, or no VLAN. They are on there own separate network segment. I am 99% sure of this but will check.

The connection between all sites is a 1.54mbps T1 on Verizons MPLS

Provider is not blocking ports, plus the packets to all the correct ports are leaving and arriving at each end.

We do have EF CAR, but it is the same at all sites that work.

No NAT anywhere

All routers are cisco, no H323 transforms anywhere.

We will do the phone test.
 
Ok

Summary - cos I am unclear (bit thick sorry!)
You have many sites.
2 sites of many have difficulty speaking to one another (we shall call these Bad 1 and Bad 2) The rest are good

Bad 1 can ring Bad 2 (phone at bad 2 alerts) but does not establish 2 way speech path
Bad 2 can ring Bad 1 (phone at bad 1 alerts)and does establish 2 way speech

Bad 1 can ring any other site without issue.
Bad 2 can also ring any other site without issue.

Are all of these true?





Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.
 
OK, so we set up an IP phone at the bad site, connected to the hub sites system.

When you dial the IP phone from a digital phone it rings and shows the calling extension, but you get dead air when you try to talk.

So, the result is the same as if the phone is off site.

So, with direct media path turned on, the call should be going directly between the phone and the system we are having trouble with, RULING OUT THE WAN AND THE OTHER SYSTEM.

AGREE ANYBODY?
 
So, with direct media path turned on, the call should be going directly between the phone and the system we are having trouble with, RULING OUT THE WAN AND THE OTHER SYSTEM.

AGREE ANYBODY?

No, it only rules out the system that you have just "bypassed" and the IP trunk that links the systems.

It puts either the WAN, central system or the handset in the frame!

Now register a handset at the central site to the bad site and carry out the same test


Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.
 
Sure sounds like a firewall at the bad site, when making outgoing calls the UDP stream(s) initiate from inside the firewall and that opens the port for return traffic, when initiated from outside the UDP port(s) are remaining blocked and only RTP traffic is getting through, this fits the issue you are describing (I don't care what the provider says, they lie):)

NTE-wave-logo-for-a4-header.jpg
 
Mystery Solved!!! The compression mode setting for the line going to the "affected" branch had been set to G.723.1 6K3 MP-MLQ instead of G.711 ULAW 64k like all our other branch lines. Made the change, rebooted system, and ALL IS WELL! Thanks to everyone here on the forum for all your suggestions.
 
Glad you've got there!

I was thinking of a codec mismatch somewhere, but didn't quite have enough confidence in it as a solution to suggest it.

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top