[AsteriskBrasil] Invalid Multi Frequency Tone

[Marcio - Google]

Se a placa é original, 50% é aterramento e 50% é operadora!


[...]'s

Marcio

========================================
########### Campanha Ajude o Marcio! ###########
http://sosmarcio.blogspot.com.br/
http://www.vakinha.com.br/VaquinhaP.aspx?e=195793
========================================


Em 9 de agosto de 2013 12:02, Bruno Pavan <brunopavan em grupolink.com.br>escreveu:

> Estava com um problena deste em alphavile e era na operadora, erro de
> frame, trocaram a tecnologia dos modens e resolveu.
> Em 09/08/2013 12:06, "Hudson Cardoso" <hudsoncardoso em hotmail.com>
> escreveu:
>
>    Isso é característica de aterramento, tente melhorá-lho, ou entre em
>> contato com
>> a operadora, e tente convencê-los de que eles têm um problema.
>>
>>
>> Hudson
>> (048) 8413-7000
>> Para quem nao cre, nenhuma prova converte,Para aquele que cre, nenhuma prova precisa.
>>
>>
>>
>> > Date: Fri, 9 Aug 2013 12:03:04 -0300
>> > From: pedro.alves em g1telecom.com.br
>> > To: asteriskbrasil em listas.asteriskbrasil.org
>> > Subject: [AsteriskBrasil] Invalid Multi Frequency Tone
>> >
>> > Bom dia Galera.
>> >
>> > Estou com um problema que começou há alguns dias e agora começou a
>> > generalizar.
>> > Tenho alguns servidores rodando em clientes com placas E1 da digium,
>> > acontece que um servidor começou a apresentar a seguinte mensagem:
>> >
>> > Invalid Multi Frequency Tone, R2 State = Seize ACK Transmitted, MF
>> state
>> > = DNIS Request Transmitted, MF Group = Backward Group A, CAS = 0x00
>> > DNIS = 01938738438, ANI = , MF = 0x46
>> > [2013-08-09 11:50:13] ERROR[3205]: chan_dahdi.c:1789
>> > dahdi_r2_on_protocol_error: MFC/R2 protocol error on chan 38: Invalid
>> > Multi Frequency Tone
>> >
>> > Já me deparei com este problema antes em algumas ocasiões, mas
>> > geralmente resolvia com aterramento, mudança de tomada, ou então
>> > desfazendo conflito de IRQ, também fiz algumas variações no chan_dahdi,
>> > para resolver em alguns clientes, sempre alcançando sucesso, mas desta
>> > vez não achei uma solução, o fato é que ao ligar o DDR direto na
>> central
>> > telefonica, as ligações completam normalmente, com o passar dos dias
>> > apareceu outro cliente com o mesmo problema e hoje um terceiro, o fato
>> > comum é que os DDR, são da Sercomtel, mas as centrais são de
>> fabricantes
>> > diferentes(panasonic, intelbras, siemens).
>> >
>> > Segue meu chan_dahdi:
>> >
>> > [channels]
>> > usecallerid=yes
>> > callwaiting=yes
>> > usecallingpres=yes
>> > callwaitingcallerid=yes
>> > threewaycalling=yes
>> > transfer=yes
>> > canpark=yes
>> > cancallforward=yes
>> > callreturn=yes
>> >
>> > group=0
>> > callgroup=0
>> > pickupgroup=0
>> > signalling=mfcr2
>> >
>> > mfcr2_variant=br
>> > mfcr2_get_ani_first=no
>> > mfcr2_max_ani=20
>> > mfcr2_max_dnis=4
>> > mfcr2_logdir=span1
>> > mfcr2_logging=all
>> > echocancel=yes
>> > echocancelwhenbridged=yes
>> > rxgain=0.0
>> > txgain=0.0
>> >
>> > context=contexto-entrada
>> > channel => 1-15
>> > channel => 17-31
>> >
>> >
>> > group=1
>> > callgroup=1
>> > pickupgroup=1
>> > signalling=mfcr2
>> >
>> > mfcr2_variant=br
>> > mfcr2_get_ani_first=no
>> > mfcr2_max_ani=8
>> > mfcr2_max_dnis=15
>> > mfcr2_logdir=span1
>> > mfcr2_logging=all
>> > ;mfcr2_metering_pulse_timeout=4000 EVITAR BLOQUEIO DE LIGACAO A COBRAR
>> >
>> > echocancel=yes
>> > echocancelwhenbridged=yes
>> > rxgain=-1.0
>> > txgain=0.0
>> >
>> > context=contexto-pabx
>> > channel => 32-46
>> > channel => 48-62
>> >
>> > Agora o System.conf:
>> >
>> > span=1,1,0,cas,hdb3
>> > cas=1-15:1101
>> > dchan=16
>> > cas=17-31:1101
>> > loadzone=br
>> > defaultzone=br
>> >
>> > span=2,0,0,cas,hdb3
>> > cas=32-46:1101
>> > dchan=47
>> > cas=48-62:1101
>> > loadzone=br
>> > defaultzone=br
>> >
>> > Agradeço desde já a ajuda galera.
>> >
>> >
>> > _______________________________________________
>> > KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
>> > Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
>> > Intercomunicadores para acesso remoto via rede IP. Conheça em
>> www.Khomp.com.
>> > _______________________________________________
>> > ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
>> > Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
>> > Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
>> > _______________________________________________
>> > Para remover seu email desta lista, basta enviar um email em branco
>> para asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>>
>> _______________________________________________
>> KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
>> Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
>> Intercomunicadores para acesso remoto via rede IP. Conheça em
>> www.Khomp.com.
>> _______________________________________________
>> ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
>> Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
>> Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
>> _______________________________________________
>> Para remover seu email desta lista, basta enviar um email em branco para
>> asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>>
>
> _______________________________________________
> KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
> Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
> Intercomunicadores para acesso remoto via rede IP. Conheça em
> www.Khomp.com.
> _______________________________________________
> ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
> Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
> Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
> _______________________________________________
> Para remover seu email desta lista, basta enviar um email em branco para
> asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://listas.asteriskbrasil.org/pipermail/asteriskbrasil/attachments/20130809/51f4d1f9/attachment-0001.htm