Avaya Emergency - Any ideas?

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

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

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

> 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...

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.

 

[Stephen]

Archived from groups: comp.dcom.voice-over-ip (More info?)

"wkearney99" <wkearney99@hotmail.com> wrote in message
news😱L2dnbMd7pc03xzfRVn-vQ@speakeasy.net...
> > 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...
>
> 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 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?
>
> It's not the equipment that's at fault here, its the network you're
putting
> it on.

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).
>
--
Regards

Stephen Hope - return address needs fewer xxs

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

> 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).

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.