asterisk users - Mar 2005 - Voice over Frame Relay & Asterisk

Has anyone done Voice Over Frame Relay with Asterisk. 
With Frame Relay work reliably with Asterisk?  Any
experiences?



	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

On Fri, 2005-03-04 at 12:44 -0800, asterisk phones
wrote:
> Has anyone done Voice Over Frame Relay with Asterisk. 
> With Frame Relay work reliably with Asterisk?  Any
> experiences?
Doesn't look like you visited google first. Nor did you bother to look
at the code.

channels/adtranvofr.h

critch@steven:/usr/src/asterisk/configs$ more adtranvofr.conf.sample 
;
; Voice over Frame Relay (Adtran style)
;
; Configuration file

[interfaces]
;
; Default language
;
;language=en
;
; Lines for which we are the user termination.  They accept incoming
; and outgoing calls.  We use the default context on the first 8 lines
; used by internal phones.
;
context=default
;user => voice00
;user => voice01

-- 
Steven Critchfield <critch@basesys.com>

> Has anyone done Voice Over Frame Relay with Asterisk. 
> With Frame Relay work reliably with Asterisk?  Any
> experiences?
If you're talking about transporting voip calls across a path that
includes frame relay links, yes it works just fine "if" you frame
network is not congested.

Frame relay networks can and _may_ drop packets if the traffic exceeds
the committed information rate (cir), depending upon exactly how your
provider has their frame switches configured. Dropped packets is less
of an issue now in frame networks then what they use to be, and the
primary reason for that is the abundance of inexpensive bandwidth
currently deployed between frame switches.

There is a pecking order in terms of which packets are candidates
for being dropped, with broadcast traffic being high on that list.
It is very difficult to determine exactly where packets are dropped
as you (the user) are never notified by the frame provider when/if
they dropped any in their switches. And, if they do drop packets
you won't be able to detemine whether those that were dropped were
in fact broadcast packets or tcp/udp packets, etc. The BECN and 
FECN counts can be used to determine if the frame provider is 
recognizing whether you exceeded your cir rate, however in most 
real world implementations a BECN or FECN does _not_ translate 
into a dropped packet (at least in the US).

You might want to download Qcheck (it was originally written by NetIQ
but spun off to another company now) to evaluate the end-to-end
bandwidth. Its a free utility that will help determine what is
actually available in terms of bandwidth.

If your frame network is congested, you might be able to implement
QoS at the border routers to give some preference to voip packets.

Rich