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 bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Avaya IP Office -IP phone issue. 1

TnPtech

Programmer
Aug 18, 2009
6
US
I have an Avaya IP Office newly installed, and I'm having an issue getting the J179 IP phones to register to the network. So here goes, The client has a very secure network, and the IT staff says all the ports and routes are in order for the IP phones to work properly. The IP phones have been programmed in the configuration and once installed on the network are not coming up. They are asking for a SIP Server which we aren't using. The firmware has been updated on the J179 phones, the 179's have also been defaulted, and restarted. I have had a 3rd party Avaya technical support tech go through the IP Office config, and he stated everything is correct, and crossed referenced the documents provided by the IT staff. With that said the issue is still outstanding, and I'm not sure where to go from here.

Any input and/or suggestions appreciated.
 
Silly question, but have you connected the IPO and phones just on their own switch to isolate the customer network?
 
Silly question, but have you connected the IPO and phones just on their own switch to isolate the customer network?
HI, Yes we did connect the phones to a POE switch connected to the IP Office WAN port and the phones did work. I would think if they worked like that they should on the LAN port, but they will not. The IT staff swears their network is good, but I have no real way to prove it otherwise.
 
Good idea of codys64 this would prove your setup and clearly point it to the IT configuration.
 
What do you mean by "They are asking for a SIP Server which we aren't using"?
Hi, We have the SIP server IP already in place and the phones keeping asking for them on the display. We have went round and round trying to figure out why.
 
Sound either like a misconfigured DHCP server or some kind of LLDP configuration on the switch that forces the phone to connect tobte Wein SIP server or a bad 46xxsettings.txt or 46xxspecials.txt. Do you see the phones load those files?
 
HI, Yes we did connect the phones to a POE switch connected to the IP Office WAN port and the phones did work. I would think if they worked like that they should on the LAN port, but they will not. The IT staff swears their network is good, but I have no real way to prove it otherwise.
Actually, you did prove it by providing your own switch and plugging them in direct. Take in your switch, bypassed their network and show them that they work.

There is always some little tick box or wrong configuration that has not been checked on the network side….
 
Sysmon will show you if the registration requests (assuming the aforementioned SIP server address is correct - although this is a bit weird, the J's generally sit on "acquiring service" if there's a network issue) are hitting the IPO. If they are, then check if there's a NAT issue (pure guesswork, knowing nothing of your network topology, but it sounds like they might have a router or firewall on the end of the fibre, given their "very secure" network), or if a SIP ALG/Helper is molesting the packets, changing IP's/ports on the return traffic.
A wireshark at the handset may also help to show traffic returning.
We've had to do multiple wiresharks at various points on networks to prove the IPO's working correctly and the client had stuffed up their network config. We have little 1-in-2-out port replicators, and run a wireshark off a laptop for situations like this.
 
I have not had this issue on a LAN but multiple times when trying to get phones to work remotely I would get random issues and the IT guys would swear it wasn't the firewall/port forwarding. As a quick test I would have them open everything on the firewall/port forwarding and magically the phones start working. That proves to the IT guys that it is the firewall and now they have to figure it out.
I don't know if this is something they can do on the setup they have but it is worth a shot to ask.
Remember IT guys are like the carriers, it isn't their problem until you prove it is.
 

Part and Inventory Search

Sponsor

Back
Top