[AsteriskBrasil] Unicall protocol error. Cause 32776

Luis Antonio Prata Barbosa luispratalistas em gmail.com
Sexta Dezembro 14 13:23:38 BRST 2007


Roger,

1) Verifique se o erro que passou a acontecer está associado com a forma
como as linhas são dispostas ou se é com o fato de ter ou não comentado a
linha "unused". Pode ser que a ordem não interfira nos resultados, mas se
interferir (mesmo que pra pior) vale a pena repassar a forma como o
zaptel.conf deve ser configurado.

2) Se o span 4 não está sendo usado, então, além de unused para seus canais,
acho que valeria a pena testar comentar essa linha que define o span 4. A
intenção é evitar que ele fique o tempo todo gerando ajustes de "timing".

3) Vc tem um cabo E1 em loop back ? Existe um arquivo chamado testcall , vc
já usou ? Pode gerar chamadas do asterisk para o asterisk e verificar se o
erro tb ocorre.

Valeu,

Luis A P Barbosa.

Em 14/12/07, Roger C. Beraldi Martins <rogerberaldi em gmail.com> escreveu:
>
> Olá Luis,
>
> Na verdade a libunicall está conseguindo criar o canal para discar, dentro
> da faixa de canais
> que está configurado no unicall.conf:
>
> channel=>1-15
> channel=>17-31
> channel=>32-46
> channel=>48-62
> channel=>63-77
> channel=>79-93
>
> Configurando o zaptel.conf da maneira sujerida por você, não é possível
> receber as ligações via E1.
> Na hora de ligar ai sim da um erro antes do processo de sinalização para
> realizar a ligação,
> o asterisk não consegue nem criar o canal.
>
> Quanto a questão do timing realmente as 3E1s estão conectadas a Brasil
> Telecom,
> para que não haja problema caso uma preca sinalização defini um timing
> diferente
> para cada uma. Assim não compromete as outras caso haja fala no
> sincronizmo em uma delas.
>
>
> Obrigado pelas sujestões !
>
>
> Em 13/12/07, Luis Antonio Prata Barbosa <luispratalistas em gmail.com>
> escreveu:
> >
> >  Oi Roger,
> >
> > Cara .. use o zttool para verificar se a configuração do zaptel está
> > correta.
> >
> > Eu acho que vc devia agrupar os canais... da seguinte maneira:
> > zaptel.conf
> >
> > # MFC/R2 does not normally use CRC4
> > loadzone        = br
> > defaultzone     = br
> >
> > span=1,1,0,cas,hdb3
> > cas=1-15:1101
> > cas=17-31:1101
> >
> > span=2,2,0,cas,hdb3
> > cas=32-46:1101
> > cas=48-62:1101
> >
> > span=3,3,0,cas,hdb3
> > cas=63-77:1101
> > cas=79-93:1101
> >
> > # Comente o que vc não vai usar.
> > #span=4,4,0,cas,hdb3
> > #unused=94-124
> >
> > *** Outra coisa... só faca o timing diferente de zero para links que
> > forem para a Operadora.
> >     Se o link for ligado a uma PABX ou banco de FXS é melhor deixa-lo
> > como span=<nro>,0,0,cas,hdb3.
> >
> > Luis A P Barbosa
> >
> > Em 13/12/07, Roger C. Beraldi Martins <rogerberaldi em gmail.com >
> > escreveu:
> > >
> > > Prezados membros da lista,
> > >
> > > Depois de ter configuardo uma TE420 com 3E1s, consigo receber ligações
> > > normalmente sem dificuldades. Como vocês podem observar no log abaixo
> > >
> > >
> > >   -- Executing [5908 em from-pstn :1] NoOp("UniCall/14-1", "Catch-All DID
> > > Match - Found 5908 - You probably want a DID for this.") in new stack
> > >     -- Executing [5908 em from-pstn:2] Goto("UniCall/14-1",
> > > "ext-did|s|1") in new stack
> > >     -- Goto (ext-did,s,1)
> > >     -- Executing [s em ext-did:1] Set("UniCall/14-1", "__FROM_DID=s") in
> > > new stack
> > >     -- Executing [s em ext-did:2] GotoIf("UniCall/14-1", "0 ?cidok") in
> > > new stack
> > >     -- Executing [s em ext-did:3] Set("UniCall/14-1",
> > > "CALLERID(name)=4133600000") in new stack
> > >     -- Executing [s em ext-did:4] NoOp("UniCall/14-1", "CallerID is
> > > "4133600000" <4133602900>") in new stack
> > >     -- Executing [s em ext-did:5] Goto("UniCall/14-1", "ivr-3|s|1") in
> > > new stack
> > >     -- Goto (ivr-3,s,1)
> > >     *snip*
> > >     -- Executing [s em ivr-3:10] BackGround("UniCall/14-1",
> > > "custom/celia") in new stack
> > >     -- <UniCall/14-1> Playing 'custom/celia' (language 'br')
> > >     -- Executing [h em ivr-3:1] Hangup("UniCall/14-1", "") in new stack
> > >     -- Hungup 'UniCall/14-1'
> > >     -- Unicall/14 released
> > >
> > >
> > > Mas agora estou com problemas para realizar as ligações utilizando a
> > > libunicall. O problema fica muito claro nesta linha do log:
> > >
> > >
> > > [Dec 13 10:03:54] ERROR[12935] chan_unicall.c: Unicall/1 protocol
> > > error. Cause 32776
> > >
> > > Pesquisando na internet descobri que trata-se de "Seize ack timed
> > > out", já tentei de várias formas contornar esta situação. As versões de
> > > software que estou utilizando são (http://www.voip-info.org/wiki/view/Asterisk+MFC+R2).
> > >
> > >
> > > asterisk-1.4.9
> > > spandsp-0.0.4
> > > unicall-0.0.5pre1
> > > zaptel-1.4.4
> > >
> > > Minhas alterativas para corrigir o problema já foram:
> > >
> > > Adicionar a linha:
> > > protocolvariant=br,20,4,x,max-seize-wait-ack=3000
> > >
> > > Confome orientações do Moises Silva:
> > >
> > > This deserves a little bit of more explanation.
> > >
> > > br = Brazil
> > > 20 = ANI digits
> > > 4 = DNIS digits
> > > x = this is just a hack to be able to work with defaults and specify
> > > the next value. protocolvariant expect here a mask of values ( an
> > > integer ), passing NOT an integer but a character x will cause the
> > > defaults to remain.
> > > max-seize-wait-ack = Number of milliseconds to wait for the ACK.
> > >
> > > Incrementei o valor do wait até 50000 (50 segundos) Realmente faz
> > > efeito, o valor passado é respeitado, mas após esgotar-se o tempo o mesmo
> > > erro
> > > é reportado.
> > >
> > > Alterei no código fonte (mfcr2.c) os defines:
> > >
> > > #define DEFAULT_T1                                         15000 para
> > > 25000
> > > #define DEFAULT_MAX_SEIZE_ACK_WAIT         2000 para 6000
> > >
> > >
> > > De fato alterar o define MAX_SEIZE_ACK_WAIT tem o mesmo efeito que
> > > passar o argumento max-seize-wait-ack=XXXX na linha da variável
> > > protocolvariant.
> > >
> > > Estou usando o FreePBX com um Custon Trunk (Custon String Dial:
> > > UniCall/g1), meu extensions_aditional tem as entradas "OUT_3 =
> > > AMP:UniCall/g1" e "OUTMAXCHANS_3 = 10".
> > >
> > > Alguem Já passou por um problema como esse ? Eu ficaria grato seu
> > > alguem me indicasse alternativas para resolve-lo.
> > >
> > >
> > > Configurações - Brasil Telecom:
> > >
> > > zaptel.conf
> > >
> > > # MFC/R2 does not normally use CRC4
> > > loadzone        = br
> > > defaultzone     = br
> > >
> > > span=1,1,0,cas,hdb3
> > > span=2,2,0,cas,hdb3
> > > span=3,3,0,cas,hdb3
> > > span=4,4,0,cas,hdb3
> > > #
> > > cas=1-15:1101
> > > cas=17-31:1101
> > >
> > > #
> > > cas=32-46:1101
> > > cas=48-62:1101
> > > #
> > > cas=63-77:1101
> > > cas=79-93:1101
> > > #
> > >
> > > unused=94-124
> > >
> > >
> > > unicall.conf
> > >
> > > [channels]
> > > language=br
> > > context=from-pstn
> > > usecallerid=yes
> > > hidecallerid=no
> > > immediate=no
> > > callwaitingcallerid=yes
> > > threewaycalling=yes
> > > transfer=yes
> > > cancallforward=yes
> > > callreturn=yes
> > > echocancel=yes
> > > echocancelwhenbridged=yes
> > > rxgain=0.0
> > > txgain=0.0
> > > faxdetect=both
> > > loglevel=0
> > > protocolclass=mfcr2
> > > protocolvariant=br,20,4
> > > protocolend=cpe
> > > group=1
> > > callerid=asreceived
> > > channel=>1-15
> > > channel=>17-31
> > > channel=>32-46
> > > channel=>48-62
> > > channel=>63-77
> > > channel=>79-93
> > > protocolclass=mfcr2
> > >
> > >
> > >
> > > Log Full:
> > >
> > > [Dec 11 10:03:51] VERBOSE[12935] logger.c:     -- Executing [
> > > s em macro-dialout-trunk :32] Dial("SIP/2290-09b18a68",
> > > "UniCall/g1|300|") in new stack
> > > [Dec 11 10:03:51] DEBUG[12935] chan_unicall.c: unicall_call called -
> > > 'g1'
> > > [Dec 11 10:03:51] DEBUG[12935] chan_unicall.c: unicall_call caller id
> > > - '2290'
> > > [Dec 11 10:03:51] VERBOSE[12935] logger.c:     -- Called g1
> > > [Dec 11 10:03:51] NOTICE[12935] chan_unicall.c: Unicall/1 event
> > > Dialing
> > > [Dec 11 10:03:54] NOTICE[12935] chan_unicall.c: Unicall/1 event
> > > Protocol failure
> > > [Dec 11 10:03:54] ERROR[12935] chan_unicall.c: Unicall/1 protocol
> > > error. Cause 32776
> > > [Dec 11 10:03:54] DEBUG[12935] chan_unicall.c: disabled echo
> > > cancellation on channel 1
> > > [Dec 11 10:03:54] WARNING[12935] app_dial.c: Unable to forward voice
> > > or dtmf
> > > [Dec 11 10:03:54] DEBUG[12935] chan_unicall.c: Hangup: channel: 1
> > > index = 0, normal = 10, callwait = -1, thirdcall = -1
> > > [Dec 11 10:03:54] DEBUG[12935] chan_unicall.c: Updated conferencing on
> > > 1, with 0 conference users
> > > [Dec 11 10:03:54] VERBOSE[12935] logger.c:     -- Hungup 'UniCall/1-1'
> > > [Dec 11 10:03:54] VERBOSE[12935] logger.c:   == Everyone is
> > > busy/congested at this time (1:0/0/1)
> > >
> > >
> > > whitout max-seize-wait-ack
> > >
> > > [Dec 13 08:32:09] VERBOSE[3798] logger.c:     -- Called g1
> > > [Dec 13 08:32:09] NOTICE[3798] chan_unicall.c: Unicall/1 event Dialing
> > > [Dec 13 08:32:11] NOTICE[3798] chan_unicall.c: Unicall/1 event
> > > Protocol failure
> > > [Dec 13 08:32:11] ERROR[3798] chan_unicall.c: Unicall/1 protocol
> > > error. Cause 32776
> > >
> > > max-seize-wait-ack = 5000
> > >
> > > [Dec 13 08:43:54] DEBUG[4845] chan_unicall.c: unicall_call called -
> > > 'g1'
> > > [Dec 13 08:43:54] NOTICE[4845] chan_unicall.c: Unicall/1 event Dialing
> > >
> > > [Dec 13 08:43:59] NOTICE[4845] chan_unicall.c: Unicall/1 event
> > > Protocolfailure
> > > [Dec 13 08:43:59] ERROR[4845] chan_unicall.c: Unicall/1 protocol
> > > error. Cause 32776
> > >
> > > max-seize-wait-ack = 10000
> > >
> > > [Dec 13 08:39:41] VERBOSE[4494] logger.c:     -- Called g1
> > > [Dec 13 08:39:41] NOTICE[4494] chan_unicall.c: Unicall/1 event Dialing
> > > [Dec 13 08:39:51] NOTICE[4494] chan_unicall.c: Unicall/1 event
> > > Protocol failure
> > > [Dec 13 08:39:51] ERROR[4494] chan_unicall.c: Unicall/1 protocol
> > > error. Cause 32776
> > >
> > > max-seize-wait-ack = 20000
> > >
> > > [Dec 13 08:36:18] VERBOSE[4145] logger.c:     -- Called g1
> > > [Dec 13 08:36:18] NOTICE[4145] chan_unicall.c: Unicall/1 event Dialing
> > > [Dec 13 08:36:38] NOTICE[4145] chan_unicall.c: Unicall/1 event
> > > Protocol failure
> > > [Dec 13 08:36:38] ERROR[4145] chan_unicall.c: Unicall/1 protocol
> > > error. Cause 32776
> > >
> > >
> > >
> > >
> > > --
> > > Atenciosamente,
> > >
> > > Roger C. Beraldi Martins
> > > Fone: 41-8828-7068
> > > _______________________________________________
> > > Compre uma camiseta da AsteriskBrasil.org!
> > >            http://www.voipmania.com.br
> > >                == VoIPMania.com.br <http://voipmania.com.br/> ==
> > >
> > > _______________________________________________
> > > LIsta de discussões AsteriskBrasil.org
> > > AsteriskBrasil em listas.asteriskbrasil.org
> > > http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil
> > >
> >
> >
> > _______________________________________________
> > Compre uma camiseta da AsteriskBrasil.org!
> >             http://www.voipmania.com.br
> >                == VoIPMania.com.br <http://voipmania.com.br/> ==
> >
> > _______________________________________________
> > LIsta de discussões AsteriskBrasil.org
> > AsteriskBrasil em listas.asteriskbrasil.org
> > http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil
> >
>
>
>
> --
> Atenciosamente,
>
> Roger C. Beraldi Martins
> Fone: 41-8828-7068
>
> _______________________________________________
> Compre uma camiseta da AsteriskBrasil.org!
>            http://www.voipmania.com.br
>                == VoIPMania.com.br <http://voipmania.com.br/> ==
>
> _______________________________________________
> LIsta de discussões AsteriskBrasil.org
> AsteriskBrasil em listas.asteriskbrasil.org
> http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://listas.asteriskbrasil.org/pipermail/asteriskbrasil/attachments/20071214/f0f27162/attachment-0001.htm 


More information about the AsteriskBrasil mailing list