[AsteriskBrasil] 'Enquete' sobre um possível bug

[Marcelo/Porks]

Bom, eu ia mandar esse email apenas para o Caio Begotti (que está me
ajudando a tentar descobrir algo sobre o que reportei), mas resolvi
mandar o email para a lista, caso alguém se interesse em lê-lo e,
principalmente em **ajudar**. Afinal, não se pode culpar um homem por
tentar (hahaha essa é para o anonymouz666).

Fiz uns 'patches' para o asterisk.. para tentar encontrar o motivo
disso tudo. Descobri algumas coisas... Nada conclusivo:

- descobri que se você ligar do ramal_sip1 para o ramal_sip2 e
- fizer atxfer para o ramal_sip3 (desligar ramal_sip2 antes do
ramal_sip3 atender), quando o ramal_sip3 atender vai ocorrer o
"subclass -1" no channel.c. (linha 234 http://pastebin.com/f12963bec )
- se não ocorrer o subclass -1, faça atxfer para o ramal_sip2 (e
desligue o ramal_sip3 antes do ramal_sip2 atender), quando o
ramal_sip2 atender vai ocorrer o subclass -1 no channel.c
- se não ocorrer o subclass -1 fique repetindo as duas linhas acima
até que aconteça.

Na verdade, se você aplicar o patch do link
http://pastebin.com/f12963bec você verá que algumas vezes ocorre o
'subclass -1' em outros pontos (diferente da linha 234, como por
exemplo nas linhas: 176, 164)

No exemplo que dei acima.. Só ocorre o 'subclass -1' no channel.c e a
ligação não fica muda (pelo menos no teste que fiz agora não ficou).
O problema maior é quando ocorre no file.c, ai a ligação fica muda
(comigo sempre que ocorreu no file.c a ligação SEMPRE ficou muda).

No caso só ocorreu no file.c quando: alguém liga de fora (da PSTN), o
ramal_sip1 atende e faz axtfer para ramal_sip2, o ramal_sip1 desliga
antes do ramal_sip2 atender, quando o ramal_sip2 atende, ele não ouve
o que a PSTN fala, mas a PSTN ouve o ramal_sip2.
(Lembrando que isso não ocorre toda vez, em 20, ou mais, tentativas é
capaz de ocorrer apenas 1 vez!)

Eu desconfio que o problema está na variavel 'ms' que é passada para a
função ast_waitfor_nandfds() (linha 222, por exemplo). 'ms' é um
número inteiro que representa uma quantidade de milissegundos. A
função ast_waitfor_nandfds() espera 'ms' milissegundos para haver
dados para ler em uma 'stream' (no caso o canal, ou seja, o audio!),
se não houver dados em 'ms' milissegundos acontece o "subclass -1"
(pelo o que deduzi).

Como deduzi isso?
Bom, se vocês aplicarem o meu patch --> http://pastebin.com/f12963bec
<-- e fizer os atxfer que descrevi no começo do email, vão reparar
(pelo /var/log/asterisk/full) que as vezes cai no 'if' da linha '163',
ou seja, na linha 157 (antes de chamar ast_waitfor_nandfds()) o
frTRACE->subclass não era -1 (ou com muito azar o frTRACE era nulo).

Essa duvida "se é o ast_waitfor_nandfds() que torna o 'subclass -1' e
isso gera a 'falta' de audio" poderia ser resolvida com as linhas 217
até 227, mas se vocês repararem eu as comentei, pois essas linhas
faziam com que o atxfer não conseguisse ler o ramal que o usuário
digitou. Ou seja, se eu as descomentar nenhum atxfer vai funcionar e
vai aparecer no log do asterisk algo como:
[Sep 30 19:49:03] WARNING[9484] res_features.c: Did not read data.

Isso ocorre porque o ast_read(CANAL) modifica o canal. O pessoal do
#asterisk-dev da irc.freenode.net me disse que a solução seria usar a
função ast_peek, pois ela não modifica o canal. O problema é que a
função ast_peek não existe ainda (eles mesmo falaram isso).
Minha conversa com eles está a seguir, mas meu inglês de "pedreiro"
não colaborou muito. Se alguém tiver alguma idéia entre em contato
comigo...

<Porks> hey, guys. I made this patch (asterisk 1.4.21.2) to test
ast_frame->subclass http://pastebin.com/fe9da98a
<Porks> but ast_read() at line 42 causes the atxfer to does not read
data. Can somebody tell me a better way to check the
ast_frame->subclass without call ast_read()?
<Qwell> Corydon76-dig: ping?
<putnopvut> Porks: you need to ast_read in order to actually have a
frame to check the subclass of.
<Qwell> maybe we need an ast_peek, heh
<Porks> ast_peek?
<seanbright> yes, an ast_read that doesn't consume the frame
<seanbright> (it doesn't exist, he was posturing)
<Porks> I didn't find 'ast_peek' in source of 1.4.21.2 :(
<Porks> ahh
<Porks> thanks...
<Porks> I'm investigating that in a call from peer1 to peer2.. if
peer2 atxfer to peer3 and peer2 hang up before peer3 answer then peer1
can listen peer3, but peer3 can not listem peer1...
<Porks> at /var/log/asterisk/full i can see [Sep 30 19:11:17]
WARNING[9384] channel.c: Unexpected control subclass '-1'
<Porks> i think this occours because 'ms' at line 46
(http://pastebin.com/d1a2c784a) is too small
<Porks> this 'subclass -1' doesn't happen all times..
<Porks> and at some cases the peer1 listen peer3 and peer3 don't
listen peer1.. and there's no 'subclass -1' at log/asterisk/full

A partir dai ninguém me respondeu mais :(

-- 
Marcelo Rossi
"This e-mail is provided "AS IS" with no warranties, and confers no rights."