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!

avaya IP phones used successsfully ??

Status
Not open for further replies.

jopling

Technical User
Sep 21, 2005
1
US
Does anyone have an avaya IP office setup that is SUCCESSFULLY using the IP phones in home offices utilizing cable & DSL connections ????

By successful we mean the remote IP Phones do not drop calls, lose the ability to hear the other person, and then drop the connection and go into discovery mode and require rebooting ????
 
I have many. What is needed is a good adsl carrier and something like the draytek or cisco routers for the vpn.

Cable can sometimes be unreliable because of its nature.

Again with the right router and vpn it can work well. 3.0 (59) seems to be the best version so far but then again many other versions before have also worked well.
 
Works perfect for our sites. I even have a mail order company with multiple showrooms all across the UK which link to a CCC call centre at head office using VPN and IP Phones - all remote sites use ADSL.

It's all about choosing the right pipe for head office, the correct VPN equipment (we use Watchguard at head office and Drayteks for remote sites), and making sure you have the best compression for your links.

I even have this going on a 50:1 contended ADSL connection, but I always stress that you should go for 20:1 or better.

Your ping response times are a way to check things out. Aim for something better than 200ms round trip - most of our ADSL's are 48ms on idle with a call active. No doubt when you begin a download of a file, things get shakey, but if you use a phone with a built switch or a Draytek which supports QoS (voice priority), everything runs nicely.

If you need any advice on your settings, let me know.
 
...and then drop the connection and go into discovery mode and require rebooting ????..."

I think I know what you are talking about jopling.

I'm running a 406 IP Office 2.1(15) and the remote IP Phones will go into "discovering" and stay like that for a long time. Sometimes they come back after hours, sometimes they don't come back at all. The only way to reliably get them back is to change the IP address on the phone or reboot the 406 IP Office head end.

It seems to me this is something related to the H323 RAS or a Gatekeeper type of registration issue.

Through monitoring I can see H323 registration traffic, but I'm not sure what to look for.

I found threads talking about "Auto create extensions", and turned mine off. The trouble is still there.

Maybe someone more experienced can shed some light on the issue.

I must be doing something wrong because I can see JeSTeROCK and mytelecoms have had success with remote IP Phones.

 
if it works fine , if not tough this is What Avaya say.
My advise is to use isdn for a home/office solution.
 
The only thing I can say is that our sites have worked fine. The reason for this is just chance. You take a chance with ADSL and cable because they are both densely populated networks which are shared by thousands of users. Latency, contention, lack of QoS, the list goes on.

All we can do is get the best lines which our budgets can afford, put in a solid VPN, and hope it works.

The Avaya solution itself is great. JeSTeROCK and I have spoke about it before and we both have sites which even use G711 over ADSL, which is almost toll quality voice. Neither of us get any problems. It all depends on you ISP and their network.
 
mytelecoms, I work with jopling, and he asked me to touch base with you, because of your success with IP Office.

I'm doing this in the open forum in the hopes this can help other IP Office users.

Could you please let us know the exact software version you are running?

You also expressed a valid concern with the connectivity piece, density, etc... in jopling's case we constantly monitor round trip time and realtime bandwidth utilization (every 1 second) on both ends of our pipe and we find no over-subscription of any kind in the links. In reality the links are for the most part idle. Our round trip times are between 40 to 60 ms for traffic piped through the vpn tunnels.

I deem the links very good given they are not dedicated and very cost effective. This 40 to 60 ms RTT could be misleading if the service providers were prioritizing ICMP in favor of everything else, but I do not believe this to be the case.

Because most of the remote sites are SOHO offices, we also have a PC installed at the remote location. The PC is a member of the active-directory domain, and the PC works great!

I have seen and worked with similar implementations with Cisco CallManager and Asterisk and they work flawlessly from a remote IP Phone perspective.

The IP Office works well, when it works. Unfortunately the IP Phones will eventually go into a loop and we need to manually intervene for the IP Phones to come back up.

We are running 2.1.(44)

 
I have a feeling that JeSTeROCK might agree with me here - I feel the best software level for VoIP is version 3. Our most complex site which works perfectly is on 3.0(44) simply because we've not had a chance to roll out 3.0(59).

My expriences have shown that 44 and 59 are the best builds.

2.1(44) and 3.0(44) are similar in terms of bug fixes and things like that, but version 3 has new features which version 2 doesn't. The other good thing about version 3 is that it allowed for the new 56xx series of IP phones, which work really well.

My remote offices and home users use Draytek 2600 routers for their ADSL VPN link, which allow me to give priority to voice traffic over data, which is great when remote workers are using web applications or downloads. Fair enough, I can't extend the QoS over the links, but it works well. You could also do the same with the switch on the back of the 5610 and 5620.

Your codec is also important. You have to play about until you find the one to suit. Usually, it's G729(a) but occassionally if your link allows it, you can run G711 for perfect voice without any problems.

Have a play with things like Silent Surpression, Out of Band DTMF, and H450 support to further improve things.

What IP Phones and which IP Office platform are you using?

You seem to know a fair bit about the networking side of things which is good, so perhaps we can look are your IP Office hardware and some of your settings in a little more detail.
 
We have 3 x 4602 connected to a 406. VPN routers are Linksys BEFSX41 at remote sites on 1.5mbit adsl and BEFVP41 of 2mbit shdsl at 406 end. No QOS, all works well.
 
must be that your oz shdsl connection eric! and the fact that you love the gold coast, me too
 
mytelecoms, thank you so much for your reply.

To answer your question we have 4602s and, I believe, two 4612 connected to a 406 IP Office. The phone loads are the IP Office loads that came with the 2.1(44) software. All the phones experience the same problem.

Codec is G729a, Silence Suprssion is OFF, Out of Band DTMF is ON.

We have one IP Phone connected via VPN right outside the same internet router we have all the other VPNs and the problem exists there too! No carrier is involved there.

I have a feeling I'm experiencing the same problem c1fd2g is experiencing, because I just tried to change the IP address of the phone and the phone works immediately.

I hear 3.0(44) has a caller ID bug.

What are the IP Phone models you are using? What is the version of load in your IP Phones?

I wish I could blame this on the DSL, QOS, etc. I can't. Everything works great and all the sudden stops. We change the IP Phone IP address and it works great again.

Nothing is keeping track of the IP Phones IP addresses but the head end 406 IP Office. I suspect there is some kind of keepalive or something else the IP Office is loosing track of and then it rejects further signaling from the IP Phone until we start over with a new IP address.

Is it possible to change the IP Phones to work with the 406 IP Office via SIP, instead of H323?


 
Whilst I think about this a little more, just a quick one for you.

You say nothing is keeping track of the phones IP addresses. This points to two things.

Firstly, I always enter the IP of the phone on the VoIP extn properties.

Secondly, you must always have Gatekeeper enabled for things to work well for VoIP. I prefer to disable Auto Create and do things manually too, but that's just preference.

Let me know if you have both of these covered.

BTW, as I said, we find most success on 56xx rather than 46xx sets, but 46xx should not be as bad as you describe.
 
We have had Gatekeeper ON before. Just now is OFF. I can switch it back to ON.

As far as the IP address in the VoIP properties we tried both ways. Because we have been relying on changing the IP address of the IP Phones to get them back up, we now have a empty field right there.

The idea was, let's avoid any kind of "intelligency" or auto detection from the IP Office software, as best we can.

I can follow your advice and re-evaluate. Sincerely, we tried so many different things.

I'll change the Gatekeeper and match the IP address in advanced properties for one IP Phone and monitor it.

I'll keep you and the list posted

 
I hear the Linksys boxes drop H.323 header information in the packets. I actually read that on another post in this forum. Maybe try a Cisco PIX or Avaya SG VPN box?
 
Did you guys use 3.0.59 and the latest firmware for 46xx IP extensions? Using the default setings works best unless you have a very good reason not to do that.

You also mention to use VPN, best way to use 46xx/56xx extensions is with a DHCP server, read the manuals ( LAN Manager ) Get the right software
Excuse me for the cryptic links, they come from Avaya.
 
Well fellows, after a week or so we are still experiencing the trouble every now and then. We are still running 2.1(44)

Things I learned:

1)If we "hard code" the IP Phone IP address under VoIP tab, the trick of changing the IP address to bring the phone back up doesn't work anymore. It makes sense though.

2)Reenabling the gatekeeper seemed to have increased the frequency of the problem, instead of fixing it. Switched to OFF again.

On another note I found out that the MTU for the IP Phones is 1412 and the MTU for the IP Office is 1472. In our environment we don't need the IP Office to account for any headers or anything else, because the VPN tunnels terminate elsewhere.

Does anyone know how to change the MTU on the IP Office?

Maybe we can change the MTU for the IP Phones via .cfg file?

 
next01,

1) Why do you want to change the max MTU ? Voice packets will always be much smaller then the max MTU.

2) Gatekeeper should be on, otherwise an IP Phone cannot register. If you can use IP Phones without the gatekeeper setting turned ON I would call this a bug.

3) Did you try to swap your 4602 phones ? Some have problems because they get hot. Apart from that the Avaya IP Phones work great but only on CM.

4) My personal opinion is that IP Office is not usable as a real IP Platform. I would only connect a very low number of IP Phones to the IPO and certainly not install an 100% IP Only solution.

 
This scenario reminds of the time we sold Draytek-routers!

We had the exact same problems:
Phones disconnecting, that could only reconnect when their IP-adress was changed, or the routers restarted.

After a quick change to ZyXEL ZyWall, the customers are SO MUCH happier!!!
 
bsmo,

Thank you very much for your input.

I agree with you as far as the voice packet size goes, for the media streaming aspect of it, but I was wondering if the H323 registration process or packets to some kind of keep alive the IP Office sends was not being blocked.

For the current IPSec solution we have in place, the IP Phone MTU of 1412 seems OK, but the IP Office MTU of 1472 could be reduced.

I don't think it can hurt, but I don't know if we can configure this on the IP Office.


 
It seems we finally got this to work as expected with 2.1(44) with some caveats.

Caveat 1: 2.1(44) has a Calller ID bug - Avaya is working to fix it.

Caveat 2: Must use G711, you can't compress the call - If you have the bandwidth you'll be fine. Compressed call quality is inconsistent while the network remains the same at all times.

We are using IPSec tunnels with Linksys RV042. They are easy to deal with and cost effective. We had VSU-100 and VSU-5x. The VSU-100 was the most cumbersome with it's management console, etc. (if you came accross this unit and it's successors you know what I'm talking about) The VSU-5x was easier, but it doesn't like dynamic ip addresses, requires user authentication, etc. If you want to keep things simple VSU is not the way to go.

Things are working very well with Linksys anyway.

Settings required to achieve this:
A-IP OFFICE
A.1-SYSTEM CONFIGURATION - GATEKEEPER TAB
- Gatekeeper - ON
- AutoCreateExtension - OFF

A.2-IP EXTENSION - VOIP TAB
- Do not specify the IP Address
- Use G711
- Do not specify MAC Address
- Silence Suppression - OFF
- Enable Fast Start - OFF (If this is ON the phones won't register)
- Fax Support - OFF
- Local Hold - OFF
- Local Tones - OFF
- Out of Band DTMF - ON
- Allow Direct Media Path - OFF

B- IP PHONE
- Hard coded IP and settings. Not using DHCP.
- 802.1Q - OFF (Important)

I hope this helps other people.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top