[asterisk-r2] dtmf r2 Venezuela (Rabih Bou Orm) (Rafael Angulo)

[Rafael Angulo]

Saludos,

Estuve realizando mas pruebas con respecto a la interpretación del archivo
chan_dahdi.conf, si la definicion de los canales salientes 17-31 se coloca
primero en el archivo (chan_dahdi.conf) incluyendo el parametro "
mfcr2_immediate_accept+yes" y luego los entrantes 1-15 con el parametro "
mfcr2_immediate_accept = no" el comando mfcr2 show channels muestra a todos
los canales con "immediate = yes" y no recibe llamadas, adicionalmente solo
deja llamar a partir del canal 22. Si se cambia la definición de los
entrantes a los canales 1-10, igual mfcr2 show channels muestra todos
(1-31) en "immediate=yes" no deja recibir pero llama desde el canal 17 al
31.De esta prueba concluyo que la definición temprana del parámetro
mfcr2_immediate_accept=yes
afecta a todos los canales que se definan luego sin importar que se
redefina la variable a "no".

Si defino primero los entrantes del 1-15 (mfcr2_immediate_accept=no) y
luego los salientes 17-31 (mfcr2_immediate_accept=yes) mfcr2 show channels
muestra del canal 1 al 21 con "immediate = no" y del 22 al 31 con "immediate
= yes" solo llama saliente del 22 al 31.

Si defino primero los entrantes del 1-10 ( mfcr2_immediate_accept=no) y
luego los salientes 17-31 (mfcr2_immediate_accept=yes) mfcr2 show channels
muestra del canal 1 al 10 con (immediate = no) y del 17 al 31 con (immediate
= yes), las llamadas salen desde el 17 al 31.

Si defino primero los entrantes del 1-14 (mfcr2_immediate_accept=no)  y
luego los salientes 17-31 (mfcr2_immediate_accept=yes) mfcr2 show channels
muestra del canal 1 al 19 con ((immediate = no) y del 20 al 31 con (immediate
= yes), las llamadas salen desde el 20 al 31

Pareciera que la definición del canales entrantes superior al 10 inhabilita
los canales por encima del 17 y hasta el 22 para realizar llamadas
salientes. este problema esta confirmado en asterisk 10 con open r2 1.3.2 y
dahdi 2.6.1 así como con asterisk 1.8.15 y open r2 1.3.1.

Moises, si pudieras por favor darme un indicación para empezar a buscar en
los fuentes, quien hace el parseo del archivo chan_dahdi.conf?
donde debería estar el problema de interpretación?

Rafa


On Mon, Jan 21, 2013 at 5:27 PM, Rafael Angulo
<rafael.angulo at tarma.com.ve>wrote:

>
> Hola a todos,
>
> Yo experimente un problema similar, acá te adjunto el correo que envié en
> su momento:
>
> Hello everybody,
>>
>> I'm having a problem with the interpretation asterisk does of this
>> file(chan_dahdi.conf), the file itself contains the definition of an E1
>> link (fractional 1-15 for incoming calls and 17-31 to send calls) in
>> Venezuela with the well know ISP CANTV(incoming r2, outgoing dtmf). The
>> openr2 version is 1.3.2 (compiled),asterisk 10.9.0 (compiled), dahdi 2.6.1
>> (compiled), freepbx 2.10 (compiled). Almost everything is working fine, but
>> when I type the command "mfcr2 show channels" it shows  the 30 channels
>> without the 16, but as part of the info, the row named "Immediate Accept"
>> show channels from 1 to 21 in "no", and channels from 22 to 31 in "yes". As
>> long as I understand, this field is controlled by the parameter
>> mfcr2_immediate_accept in the chan_dahdi.conf file, but the file (attached
>> to this mail) indicates the first 15 channels(1-15) should be in
>> mfcr2_immediate_accept=no and the next 15 (17-31) should be in
>> mfcr2_immediate_accept=yes. As long as I have tested it, if the channel
>> indicates Immediate Accept = no in the CLI, it receives calls but not send
>> call, and if the channel indicates Immediate Accept = yes, it alow to send
>> call but not receive. So what I basically have is channels from 17-21
>> unable to send calls. I have done hundred of test, with many weird
>> behaviors, invert the channels definition, split the channels definitions,
>> etc. I don't know if its a bug or maybe my definition is wrong. I sending a
>> copy of the chan_dadhi.conf and the result of mfcr2 command in this email.
>>
>> Any help will be appreciated,
>>
>
> That sounds like some sort of bug. If you give me ssh (contact me
> off-list) I can take a look.
>
> Moisés me ofreció acceder a la maquina de forma remota para investigar,
> lamentablemente no era posible ya que era un sistema en producción. Yo
> particularmente creo que es un bug. El problema se soluciono cuando instale
> un apliance elastix que el cual actualice a la ultima versión de Asterisk
> para aprovecharme del patch que ellos colocaron de R2 en su branch de
> Asterisk 1.8 backported del que funcionaba en Asterisk 10 (
> http://bugs.elastix.org/view.php?id=1357).
>
> Ahora bien esta solución funciono perfectamente durante un tiempo, hace
> dos semanas después de apagar y prender el Elastix (asumo que se actualizo
> porque no estaba presente) y sin cambiar una linea del archivo
> de configuración comenzó de nuevo el problema. Mi solución temporal es
> configurar los primeros 15 entrantes (1-15) grupo 0  los siguiente 15
> salientes (17-31) en el grupo 1 y luego creo el grupo 2 configurando del 22
> al 31 saliente. Esta alternativa permite recibir todas las llamadas (1-15)
> ya que no te puedes dar el lujo de dejar de recibir las llamadas porque no
> sabes por que canal la operadora la va a enviar. Y puedes hacer llamadas
> del 22-31 colocando en la troncal al grupo 2 perdiendo 7 canales salientes.
> Tal vez si tu tienes oportunidad de darle acceso remoto a Moises el puede
> verificar si de verdad es un bug.
>
> De todas maneras estamos en el mismo barco, si solucionas o yo soluciono
> podemos publicar por acá para que todos se beneficien.
>
> Rafa
>
>
>
> --
> Rafael A Angulo R
> Director Gerente
> Tarma Consultores C.A.
> Cel. (58)(414)106.04.73
> Ofi. (58)(212)793.49.81
>
>


-- 
Rafael A Angulo R
Director Gerente
Tarma Consultores C.A.
Cel. (58)(414)106.04.73
Ofi. (58)(212)793.49.81
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20130204/efae9daa/attachment.htm>