Eco con una A800P

techchip

Joined
Aug 10, 2010
Messages
25
Likes
0
Points
0
#1
Hola todos:

Estoy teniendo un problema de eco al generar o recibir llamadas desde elastx 2.0.3 a la PSTN.

Estoy utilizando una tarjeta Opnevox A800P y no se que parámetros le puedo cambiar para reducir este efecto de eco.

Si se realizan llamadas entre las extensiones internas o por un trocal AIX2, no se escucha eco, solo se escucha con la PSTN.

El eco al comunicarse con la PSN solo se escucha desde los telefonos VOIP, al otro lado desde la PSTN no se escucha eco de ningún tipo.

alguien me puede ayudar?

Saludos,

Mauricio F.
 

jgutierrez

Joined
Feb 28, 2008
Messages
5,737
Likes
0
Points
0
#2
Lo que haría es lo siguiente:

1. amportal stop
service asterisk stop (hasta que salga failed)
fxotune -i 4 (esperar hasta que termine)
amportal start
probar nuevamente

2. Editar el archivo /etc/asterisk/chan_dahdi.conf
Y modificar los valores de rxgain y de txgain (en el caso que estén en 0.0, ponerle -1.0)
Ejecutar:
asterisk -rx "module reload"

Yo primero intentaría la opción #1, de no funcionar, me iría por la #2
 

netaires

Joined
Apr 13, 2010
Messages
218
Likes
1
Points
0
#3
Hola, te cuento que yo tengo la misma tarjeta.

Tengo ECO y siempre me fue dificil eliminarlo.

No se si es por esta tarjeta porque no tengo otra para probar.

Incluso los valores de RX y TX los tengo en 10 y 2 respectivamente, porque sinó se escuchaba bajo y al subirlo se aumenta el eco.
El tema es que no me queda otra, tengo que subirlo y soportar el eco un poco a no poder escuchar la conversación.

No estoy seguro, pero creo que hay que recargar los valores del FXOTune por cada inicio del sistema. Tengo entendido que debés agregar a tu /etc/rc.local lo siguiente: fxotune -s

Acá hay más data al respecto: http://www.voip-info.org/wiki/view/Asterisk+fxotune

Aguardo tus comentarios a ver si vos la podés configurar mejor.
 

fmvillares

Joined
Sep 8, 2007
Messages
1,785
Likes
0
Points
0
#4
podes probar cambiar de oslec a mg2 el cancelador de eco o como yo recomiendo usar hardware de calidad o sea digium sangoma o gateways externos...
lo barato muchas veces sale caro...y openvox es un simple clon chino de digium por mas certificaciones que tenga de elastix
 

techchip

Joined
Aug 10, 2010
Messages
25
Likes
0
Points
0
#5
Perdona la ignorancia: en que archivo de configuración o como se cambia el algortimo de cancelación de eco de oslec a mg2?
 

techchip

Joined
Aug 10, 2010
Messages
25
Likes
0
Points
0
#6
El primer punto ya lo probe y no dio resultado y de paso ejectue el comando que memuestra el valor numerico del eco y esta alrededor de 0.053 - 0.065. voy a probar la segunda alternativa.

En el Wiki que recomendo netaires no me queda claro despues de ejecutar el fxotune como hago para ejecutar fxotune -s cada vez que arracna el asterisk para que siempre tome los nuevos parametros. Tu sabes?
 

netaires

Joined
Apr 13, 2010
Messages
218
Likes
1
Points
0
#7
Agregar la siguiente linea al archivo: /etc/rc.local

/usr/sbin/ fxotune-s

y debe estar colocada antes de amportal start_fop amportal

En versiones anteriores de Elastix tengo entendido que en la parte de Hardware se podía cambiar el algoritmo de cancelación o por lo menos anular el OSLEC, pero ahora veo que despues de bajar actualizaciones ya no lo encuentro, es nueva esa parte. Me estoy refiriendo al Elastix en la sección de Hardware.
 

techchip

Joined
Aug 10, 2010
Messages
25
Likes
0
Points
0
#8
Hola todos:

Les tengo la maravillosa noticia que ya lo solucione, no mas ECO y quiero compartir con todos el procedimiento como lo hice. Aclaro que no fue fácil para mi porque no tengo dominio de linux y menos asterisk (que hago aqui?, jejeje).

Primero pude evidenciar que el problema radica en que la auto detección de hardware de la distro 2.0.3 no esta funcionando correctamente, porque no estaba creando ni el archivo dahdi-channels.conf y tampoco el system.conf y por ende no estaban activos los canceladores de eco.

Basicamente:

1. utilizando el putty ingrese como root al linux
2. Una vez alli, ejecute el script dahdi_genconf quien si creo ambos archivos correctamente.
3. Luego ejecute el script dahdi_cfg -vvv
4. Reinice el dahdi con /etc/init.d/dahdi restart
4. Manualmente con con el comando cat y el vi visualice y edite los dos archivos /etc/dahdi/system.conf and /etc/asterisk/dahdi-channels.conf por ejemplo para cmbair los grupos de mis troncales.
5. No tuve necesidad de cambiar el cancelar por defecto para cada canal y lo deje en Oslec.
6. Detuve el asterisk con amportal stop.
7. ejecute la calibración con fxotune -i 4
8. verifique que cada canal me hubiese quedado calibrado por debajo de 0.1 con fxotune -d -b 1 , luego fxotune -d -b 2 , y asi sucesivamente con cada canal conectado a PSTN.
9. me asegure que de la linea /usr/sbin/ fxotune-s estuviera en el archivo /etc/rc.local (en mi caso ya estaba).
10. reinicie con amportal start.
11 asterisk -r para entrar al cli
12 alli para verificar ejecute dahdi show channels

Listo!!!

Saludes a todos,

Mauricio F.
 

fmvillares

Joined
Sep 8, 2007
Messages
1,785
Likes
0
Points
0
#9
que bueno ...hubo como 7 u 8 posts de problemas con openvox en la ultima semana ya estoy sospechando que el driver5 de elsatix tiene un error de cmopilacion del modulo
 

netaires

Joined
Apr 13, 2010
Messages
218
Likes
1
Points
0
#10
Hola Techchip:

Disculpame la consulta. Te cuento que tengo la misma placa, pero suelo sentir algo de eco en algunas extensiones.
Generalmente el eco las siento en las extensiones remotas, es decir que están en otra IP externa u otra red que donde está el Elastix.
´
Tengo dos módulos en la placa, pero sólo tengo conectado una linea PSTN en el módulo dos. Están bien lo valores que obtengo del módulo 2?

fxotune -d -b 1
Dumping module /dev/dahdi/1
echo ratio = 0.6592 (3004.0 / 4557.0)

fxotune -d -b 2
Dumping module /dev/dahdi/2
echo ratio = 0.0263 (120.0 / 4557.0)

Si es posible, podrás copiar y pegar tus archivos:
/etc/dahdi/system.conf
/etc/asterisk/dahdi-channels.conf
 

techchip

Joined
Aug 10, 2010
Messages
25
Likes
0
Points
0
#11
Hola Netaires:

Yo tengo esta PBx conectada con otrea remota en otra ciudad usando IAX2 y cuando tenia eco en la extensiones locales tambien lo tenia cuando tomaba un linea PSTN local desde la PBX remota. Sin embargo, apenas logre arreglar el eco local se arreglo remotamente como era de esperarse.

Si solo tienes un PSTN conectada en el segundo modulo FXO de tu tarjeta, entonces tus numeros estan OK. El 0.6592 en el primer canal lo que te esta diciendo es que no hay linea conectada alli y el 0.0263 es un numero relativamente bajo de eco que fue canceladores por software deberian ser capaces de eliminar sin problema, salvo que no esten activos como me estaba pasando a mi.

chan_dahdi.conf

; Auto-generated by /usr/sbin/hardware_detector
[trunkgroups]

[channels]
language=es
context=from-pstn
signalling=fxs_ks
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
faxdetect=incoming
echotraining=800
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1

;Uncomment these lines if you have problems with the disconection of your analog lines
;busydetect=yes
;busycount=3

immediate=no

#include dahdi-channels.conf
#include chan_dahdi_additional.conf

dahdi-channels.conf

; Span 1: OPVXA1200/12 "OpenVox A1200P/A800P Board 13" (MASTER)
;;; line="1 OPVXA1200/12/0 FXSKS (In use)"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 1
callerid=
group=
context=default

;;; line="2 OPVXA1200/12/1 FXSKS (In use)"
signalling=fxs_ks
callerid=asreceived
group=1
context=from-pstn
channel => 2
callerid=
group=
context=default

;;; line="3 OPVXA1200/12/2 FXSKS (In use)"
signalling=fxs_ks
callerid=asreceived
group=2
context=from-pstn
channel => 3
callerid=
group=
context=default

;;; line="4 OPVXA1200/12/3 FXSKS (In use)"
signalling=fxs_ks
callerid=asreceived
group=3
context=from-pstn
channel => 4
callerid=
group=
context=default

;;; line="5 OPVXA1200/12/4 FXSKS (In use)"
signalling=fxs_ks
callerid=asreceived
group=4
context=from-pstn
channel => 5
callerid=
group=
context=default

;;; line="6 OPVXA1200/12/5 FXSKS"
signalling=fxs_ks
callerid=asreceived
group=5
context=from-pstn
channel => 6
callerid=
group=
context=default

;;; line="7 OPVXA1200/12/6 FXSKS"
signalling=fxs_ks
callerid=asreceived
group=6
context=from-pstn
channel => 7
callerid=
group=
context=default

;;; line="8 OPVXA1200/12/7 FXOKS"
signalling=fxo_ks
callerid="Channel 8" <650>
mailbox=650
group=7
context=from-internal
channel => 8
callerid=
mailbox=
group=
context=default

system.conf

[root@Elastix dahdi]# cat system.conf
# Autogenerated by /usr/sbin/dahdi_genconf on Sat Feb 19 15:00:22 2011
# If you edit this file and execute /usr/sbin/dahdi_genconf again,
# your manual changes will be LOST.
# Dahdi Configuration File
#
# This file is parsed by the Dahdi Configurator, dahdi_cfg
#
# Span 1: OPVXA1200/12 "OpenVox A1200P/A800P Board 13" (MASTER)
fxsks=1
echocanceller=oslec,1
fxsks=2
echocanceller=oslec,2
fxsks=3
echocanceller=oslec,3
fxsks=4
echocanceller=oslec,4
fxsks=5
echocanceller=oslec,5
fxsks=6
echocanceller=oslec,6
fxsks=7
echocanceller=oslec,7
fxoks=8
echocanceller=oslec,8
# channel 9, OPVXA1200/12/8, no module.
# channel 10, OPVXA1200/12/9, no module.
# channel 11, OPVXA1200/12/10, no module.
# channel 12, OPVXA1200/12/11, no module.

# Global data

loadzone = us
defaultzone = us

PD: Recuerda que cada vez que conectes un linea PSNT debe volver a realizar el tunning y a mi me gusta reiniciar la maquina completa.

amportal stop
fxotune -i
amportal start

Espero te ayude, saludos,

Mauricio F.
 

netaires

Joined
Apr 13, 2010
Messages
218
Likes
1
Points
0
#12
Hola Mauricio:

Gracias por tus copy-paste

Bueno, voy a comentar mis diferencias.

En chan_dahdi.conf tengo lo siguiente porque sinó no escuchaba:
rxgain=10.0
txgain=2.0

Bueno, ahora el tema es que la gran diferencia la encontré en system.conf

Recuerdo haber visto el system.conf como lo postea Mauricio, pero parece que luego de alguna actualización ahora me encuentro con el system.conf cambiado. Y ahora la gran duda es que en la parte de ayuda comentada de este archivo no se sugiere el cancelador OSLEC que tenía entendido como ser el más popular.

Aca lo voy a postear para que lo vean:
(ahora como dice este archivo le agregué el mg2 y voy a ver que pasa, tengo que recibir algunas llamadas para notar si ha mejorado).

#
# DAHDI Configuration File
#
# This file is parsed by the DAHDI Configurator, dahdi_cfg
#
# Span Configuration
# ^^^^^^^^^^^^^^^^^^
# First come the span definitions, in the format
#
# span=<span num>,<timing source>,<line build out (LBO)>,<framing>,<coding>[,yellow]
#
# All T1/E1/BRI spans generate a clock signal on their transmit side. The
# <timing source> parameter determines whether the clock signal from the far
# end of the T1/E1/BRI is used as the master source of clock timing. If it is, our
# own clock will synchronise to it. T1/E1/BRI connected directly or indirectly to
# a PSTN provider (telco) should generally be the first choice to sync to. The
# PSTN will never be a slave to you. You must be a slave to it.
#
# Choose 1 to make the equipment at the far end of the E1/T1/BRI link the preferred
# source of the master clock. Choose 2 to make it the second choice for the master
# clock, if the first choice port fails (the far end dies, a cable breaks, or
# whatever). Choose 3 to make a port the third choice, and so on. If you have, say,
# 2 ports connected to the PSTN, mark those as 1 and 2. The number used for each
# port should be different.
#
# If you choose 0, the port will never be used as a source of timing. This is
# appropriate when you know the far end should always be a slave to you. If
# the port is connected to a channel bank, for example, you should always be
# its master. Likewise, BRI TE ports should always be configured as a slave.
# Any number of ports can be marked as 0.
#
# Incorrect timing sync may cause clicks/noise in the audio, poor quality or failed
# faxes, unreliable modem operation, and is a general all round bad thing.
#
# The line build-out (or LBO) is an integer, from the following table:
#
# 0: 0 db (CSU) / 0-133 feet (DSX-1)
# 1: 133-266 feet (DSX-1)
# 2: 266-399 feet (DSX-1)
# 3: 399-533 feet (DSX-1)
# 4: 533-655 feet (DSX-1)
# 5: -7.5db (CSU)
# 6: -15db (CSU)
# 7: -22.5db (CSU)
#
# If the span is a BRI port the line build-out is not used and should be set
# to 0.
#
# framing::
# one of 'd4' or 'esf' for T1 or 'cas' or 'ccs' for E1. Use 'ccs' for BRI.
# 'd4' could be referred to as 'sf' or 'superframe'
#
# coding::
# one of 'ami' or 'b8zs' for T1 or 'ami' or 'hdb3' for E1. Use 'ami' for
# BRI.
#
# * For E1 there is the optional keyword 'crc4' to enable CRC4 checking.
# * If the keyword 'yellow' follows, yellow alarm is transmitted when no
# channels are open.
#
#span=1,0,0,esf,b8zs
#span=2,1,0,esf,b8zs
#span=3,0,0,ccs,hdb3,crc4
#
# Dynamic Spans
# ^^^^^^^^^^^^^
# Next come the dynamic span definitions, in the form:
#
# dynamic=<driver>,<address>,<numchans>,<timing>
#
# Where <driver> is the name of the driver (e.g. eth), <address> is the
# driver specific address (like a MAC for eth), <numchans> is the number
# of channels, and <timing> is a timing priority, like for a normal span.
# use "0" to not use this as a timing source, or prioritize them as
# primary, secondard, etc. Note that you MUST have a REAL DAHDI device
# if you are not using external timing.
#
# dynamic=eth,eth0/00:02:b3:35:43:9c,24,0
#
# If a non-zero timing value is used, as above, only the last span should
# have the non-zero value.
#
# Channel Configuration
# ^^^^^^^^^^^^^^^^^^^^^
# Next come the definitions for using the channels. The format is:
# <device>=<channel list>
#
# Valid devices are:
#
# e&m::
# Channel(s) are signalled using E&M signalling (specific
# implementation, such as Immediate, Wink, or Feature Group D
# are handled by the userspace library).
# fxsls::
# Channel(s) are signalled using FXS Loopstart protocol.
# fxsgs::
# Channel(s) are signalled using FXS Groundstart protocol.
# fxsks::
# Channel(s) are signalled using FXS Koolstart protocol.
# fxols::
# Channel(s) are signalled using FXO Loopstart protocol.
# fxogs::
# Channel(s) are signalled using FXO Groundstart protocol.
# fxoks::
# Channel(s) are signalled using FXO Koolstart protocol.
# sf::
# Channel(s) are signalled using in-band single freq tone.
# Syntax as follows:
#
# channel# => sf:<rxfreq>,<rxbw>,<rxflag>,<txfreq>,<txlevel>,<txflag>
#
# rxfreq is rx tone freq in Hz, rxbw is rx notch (and decode)
# bandwith in hz (typically 10.0), rxflag is either 'normal' or
# 'inverted', txfreq is tx tone freq in hz, txlevel is tx tone
# level in dbm, txflag is either 'normal' or 'inverted'. Set
# rxfreq or txfreq to 0.0 if that tone is not desired.
#
# unused::
# No signalling is performed, each channel in the list remains idle
# clear::
# Channel(s) are bundled into a single span. No conversion or
# signalling is performed, and raw data is available on the master.
# bchan::
# Like 'clear' except all channels are treated individually and
# are not bundled. 'inclear' is an alias for this.
# rawhdlc::
# The DAHDI driver performs HDLC encoding and decoding on the
# bundle, and the resulting data is communicated via the master
# device.
# dchan::
# The DAHDI driver performs HDLC encoding and decoding on the
# bundle and also performs incoming and outgoing FCS insertion
# and verification. 'fcshdlc' is an alias for this.
# hardhdlc::
# The hardware driver performs HDLC encoding and decoding on the
# bundle and also performs incoming and outgoing FCS insertion
# and verification. Is subject to limitations and support of underlying
# hardware. BRI spans serviced by the wcb4xxp driver must use hardhdlc
# channels for the signalling channels.
# nethdlc::
# The DAHDI driver bundles the channels together into an
# hdlc network device, which in turn can be configured with
# sethdlc (available separately). In 2.6.x kernels you can also optionally
# pass the name for the network interface after the channel list.
# Syntax:
#
# nethdlc=<channel list>[:interface name]
# Use original names, don't use the names which have been already registered
# in system e.g eth.
#
# dacs::
# The DAHDI driver cross connects the channels starting at
# the channel number listed at the end, after a colon
# dacsrbs::
# The DAHDI driver cross connects the channels starting at
# the channel number listed at the end, after a colon and
# also performs the DACSing of RBS bits
#
# The channel list is a comma-separated list of channels or ranges, for
# example:
#
# 1,3,5 (channels one, three, and five)
# 16-23, 29 (channels 16 through 23, as well as channel 29)
#
# So, some complete examples are:
#
# e&m=1-12
# nethdlc=13-24
# fxsls=25,26,27,28
# fxols=29-32
#
# An example of BRI port:
#
# span=1,1,0,ccs,ami
# bchan=1,2
# hardhdlc=3
#
# NOTE: When using BRI channels in asterisk, use the bri_cpe, bri_net, or
# bri_cpe_ptmp (for point to multipoint mode). libpri does not currently
# support point to multipoint when in NT mode. Otherwise, the bearer channel
# are configured identically to other DAHDI channels.
#
#fxoks=1-24
#bchan=25-47
#dchan=48
#fxols=1-12
#fxols=13-24
#e&m=25-29
#nethdlc=30-33
#clear=44
#clear=45
#clear=46
#clear=47
#fcshdlc=48
#dacs=1-24:48
#dacsrbs=1-24:48
#
# Tone Zone Data
# ^^^^^^^^^^^^^^
# Finally, you can preload some tone zones, to prevent them from getting
# overwritten by other users (if you allow non-root users to open /dev/dahdi/*
# interfaces anyway. Also this means they won't have to be loaded at runtime.
# The format is "loadzone=<zone>" where the zone is a two letter country code.
#
# You may also specify a default zone with "defaultzone=<zone>" where zone
# is a two letter country code.
#
# An up-to-date list of the zones can be found in the file zonedata.c
#
loadzone = us
#loadzone = us-old
#loadzone=gr
#loadzone=it
#loadzone=fr
#loadzone=de
#loadzone=uk
#loadzone=fi
#loadzone=jp
#loadzone=sp
#loadzone=no
#loadzone=hu
#loadzone=lt
#loadzone=pl
defaultzone=us
#
# PCI Radio Interface
# ^^^^^^^^^^^^^^^^^^^
# (see http://www.zapatatelephony.org/app_rpt.html)
#
# The PCI Radio Interface card interfaces up to 4 two-way radios (either
# a base/mobile radio or repeater system) to DAHDI channels. The driver
# may work either independent of an application, or with it, through
# the driver;s ioctl() interface. This file gives you access to specify
# load-time parameters for Radio channels, so that the driver may run
# by itself, and just act like a generic DAHDI radio interface.
#
# Unlike the rest of this file, you specify a block of parameters, and
# then the channel(s) to which they apply. CTCSS is specified as a frequency
# in tenths of hertz, for example 131.8 HZ is specified as 1318. DCS
# for receive is specified as the code directly, for example 223. DCS for
# transmit is specified as D and then the code, for example D223.
#
# The hardware supports a "community" CTCSS decoder system that has
# arbitrary transmit CTCSS or DCS codes associated with them, unlike
# traditional "community" systems that encode the same tone they decode.
#
# this example is a single tone DCS transmit and receive
#
# specify the transmit tone (in DCS mode this stays constant):
#tx=D371
#
# specify the receive DCS code:
#dcsrx=223
#
# this example is a "community" CTCSS (if you only want a single tone, then
# only specify 1 in the ctcss list)
#
# specify the default transmit tone (when not receiving):
#tx=1000
#
# Specify the receive freq, the tag (use 0 if none), and the transmit code.
# The tag may be used by applications to determine classification of tones.
# The tones are to be specified in order of presedence, most important first.
# Currently, 15 tones may be specified..
#
#ctcss=1318,1,1318
#ctcss=1862,1,1862
#
# The following parameters may be omitted if their default value is acceptible
#
# Set the receive debounce time in milliseconds:
#debouncetime=123
#
# set the transmit quiet dropoff burst time in milliseconds:
#bursttime=234
#
# set the COR level threshold (specified in tenths of millivolts)
# valid values are {3125,6250,9375,12500,15625,18750,21875,25000}
#corthresh=12500
#
# Invert COR signal {y,n}
#invertcor=y
# Set the external tone mode; yes, no, internal {y,n,i}
#exttone=y
#
# Now apply the configuration to the specified channels:
#
# We are all done with our channel parameters, so now we specify what
# channels they apply to
#channels=1-4
#
# Overiding PCM encoding
# ^^^^^^^^^^^^^^^^^^^^^^
# Usually the channel driver sets the encoding of the PCM for the
# channel (mulaw / alaw. That is: g711u or g711a). However there are
# some cases where you would like to override that. 'mulaw' and 'alaw'
# set different such encoding. Use them for channels you have already
# defined with e.g. 'bchan' or 'fxoks'.
#mulaw=1-4
#alaw=1-4
#
# 'deflaw' is similar, but resets the encoding to the channel driver's
# default. It must be useful for something, I guess.
#mulaw=1-10
#deflaw=5
#
# Echo Cancellers
# ^^^^^^^^^^^^^^^
# DAHDI uses modular echo cancellers that are configured per channel. The echo
# cancellers are compiled and installed as part of the dahdi-linux package.
# You can specify in this file the echo canceller to be used for each
# channel. The default behavior is for there to be NO echo canceller on any
# channel, so it is very important that you specify one here if you do
# not have hardware echo cancellers and need echo cancellation.
#
# Valid echo cancellers are: mg2, kb1, sec2, and sec.
# If compiled, 'hpec' is also a valid echo canceller.
#
# To configure the default echo cancellers, use the format:
# echocanceller=<echocanceller name>,<channel(s)>
#
# Example:
# Configure channels 1 through 8 to use the mg2 echo canceller
#echocanceller=mg2,1-8
#
# And change channel 2 to use the kb1 echo canceller.
#echocanceller=kb1,2
#
 

techchip

Joined
Aug 10, 2010
Messages
25
Likes
0
Points
0
#13
yo de tu ejecutaría urgente el Dahdi_genconf para que el script vuelva y genere el archivo system.conf

Ningún archivo que he visto posteado tiene el contenido del tuyo por lo que eso es lo que te puede estar generando los problemas de eco.

Corre el script y te debe quedar como el mio.

Saludos,

Mauricio
 

netaires

Joined
Apr 13, 2010
Messages
218
Likes
1
Points
0
#14
Hola. Simplemente como había comentado hace unos días, quería decirles que con el archivo posteado he resuelto al 100% los problemas de eco.

Lo he probado durante varios días y con la recepción de distintos tipos de llamadas.

Ahora si, pude lograr una calidad excelente de conversación sin nada de eco y con el algoritmo de cancelación propuesto en mis anteriores post en este hilo del foro.

Si alguien necesita que postee el archivo entero sólo me lo pide.

Gracias y suerte.
 

siptellnet

Joined
Dec 18, 2009
Messages
47
Likes
0
Points
0
#15
Acabo de instalar la version Elastix 2.0.3, en principio reconoció la tarjeta A800P, pero despues de un yum -y update, la tarjeta desapareció.
He probado varios procediemientos para que reconozca la tarjeta pero ninguno funciona.

Cualquier sugerencia sera bienvenida
 

fmvillares

Joined
Sep 8, 2007
Messages
1,785
Likes
0
Points
0
#16
hay que aprender a compilar dahdi a mano desde el instructivo que te dice openvox en su pagina ya que se actualiza el kernel...
 

siptellnet

Joined
Dec 18, 2009
Messages
47
Likes
0
Points
0
#17
Hola y gracias.
Segui las instrucciones paso a paso de estos dos instructivos que son casi similares:

wiki.openvox.cn/index.php/OpenVox_A800P_Dahdi_en

downloads.openvox.cn/pub/manuals/eng/Ins...A800P_with_Dahdi.pdf

Copie tambien el archivo opvxa1200.c

TOdo se ejecuto bien, hasta :

modprobe dahdi ok
modprobe opvxa1200 FATAL: Module opvxa1200 not found

alguna sugerencia??
 

fmvillares

Joined
Sep 8, 2007
Messages
1,785
Likes
0
Points
0
#18
y vos los compilaste al driver???? aplicaste el patch?
 

siptellnet

Joined
Dec 18, 2009
Messages
47
Likes
0
Points
0
#19
Pero por supuesto que lo compile, como indica el manual, pero del patch no indica nada el fabricante.!!!!
 

fmvillares

Joined
Sep 8, 2007
Messages
1,785
Likes
0
Points
0
#20

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,902
Messages
130,887
Members
17,565
Latest member
omarmenichetti
Top