1. Home
  2. Voice-Over-IP
  3. Avaya Emergency - Any ideas?

Avaya Emergency - Any ideas?

Well, Avaya has gotten me into a bind. Maybe somebody out there has run into this before, it's worth a shot :)

We have an internal outsourcer running Avaya IP phones and an S8300 with SLP. In the states, we have an S8700 that we need to use to run the IP phones (the S8300 is failover). Unfortunately and unavoidably we are getting latency times of about 315ms roundtrip to the remote site. This seems to be on the verge of acceptable, because the IP phones can sometimes register, but other times we are receiving an error "2011 IP FURQ-NoQ931 msg rcvd Force Unregistration Request". It seems to be extremely random. We called Avaya and it they said the registration confirmation is not getting from the phone back to the

8700 in a timely mannger. There are absolutely no firewall restrictions of any kind between the phone and the 8700.

So what I'm left with is either finding a way to MAKE this work, or putting a bunch of really expensive equipment up on eBay :( We are looking for a way to override this behavior, either by extending the timeout or forcing the phone to register somehow. By the way, I'm willing to pay for advice that works...

Thanks for any help you can offer!!

Jason Kolb jason.kolb at gmail dot com

Reply to
Jason Kolb
Loading thread data ...

Talk to your ISPs on each end. Improve the network latency between them. If you're expecting to get by on the cheap using the internet then you're not going to get it to work reliably. If you're outsourcing overseas then you'll have to deal with increased networking costs. Possibly even going so far as dedicated virtual circuits.

It's not the equipment that's at fault here, its the network you're putting it on.

Reply to
wkearney99

it is worth working out what the "inherent" latency is between the locations - if you are close to that then you need to alter the topology.

if you cant fix it, then you will need a more local call processor - maybe you can make the local 8300 the default and fall back to the remote processor?

well sort of - but good network gear should not have built in limiting assumptions about bounded delay. (or at least if it does there should be something in the documentation).

>
Reply to
stephen

Given the nature of the application it's not like operating in a high-latency, or worse yet an inconsistent latency, situation is going to work reliably. Shifting from circuit-switched to packet-switched doesn't change the underlying need to reliable delivery of the data. If the underlying network can't deliver then no devices are going to work reliably.

Reply to
wkearney99

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.