Pessoal do Disc-OS e usuários do chan_unicall em geral, já uso o chan_unicall a um bom tempo e sempre tive problemas de travamento e segfault do Asterisk com este mas devido a falta de opção (atualmente existem outras opções de placas com R2, antigamente não) sempre que o E1 tinha de ser MFC/R2 usei o chan_unicall (sempre que posso escolho ISDN/PRI).
A alguns dias comecei a testar as versões disponibilizadas pela disto Disc-OS que contêm algumas modificações na libmfcr2, libunicall e chan_unicall. Obtive os fontes de: http://disc-os.svn.sourceforge.net/viewvc/disc-os/disc-os/trunk/chan_unicall/ http://disc-os.svn.sourceforge.net/viewvc/disc-os/disc-os/trunk/srpms/ Testei em um Asterisk 1.2.25 com Fedora 5 e não na distro Disc-OS propriamente pois já tenho o servidor instalado. Montei um ambiente de teste de carga gerando até 30 chamadas de duração aleatória entre 2 E1s conectados entre si no mesmo servidor. O resultado após horas de testes e milhares de chamadas geradas é o mesmo que sempre obtive com a versão do UniCall que eu já usava: o Asterisk trava (deadlock) ou quebra (segfault). Como o Asterisk foi compilado com debug habilitado obtive informações no gdb do core dump após o segfault: #0 OneWordFind (tablePtr=0x9bb0678, key=0x80c2 <Address 0x80c2 out of bounds>) at hashtable.c:585 585 hashtable.c: Arquivo ou diretório não encontrado. in hashtable.c (gdb) bt full #0 OneWordFind (tablePtr=0x9bb0678, key=0x80c2 <Address 0x80c2 out of bounds>) at hashtable.c:585 hPtr = (hash_HashEntry_t *) 0xffffffff #1 0x0063affd in uc_createcall (uc=0x9bb0620, extra=0) at unicall/hashtable.h:144 crn = 32962 #2 0x001bb509 in call_control (uc=0x9bb0620, op=1, call=0x0, data=0xb72a1f8c) at mfcr2.c:3651 No locals. #3 0x0063bd71 in uc_call_control (uc=0x9bb0620, op=1, crn=0, data=0xb72a1f8c) at unicall.c:593 call = (uc_call_t *) 0x16 #4 0x0032a1a1 in unicall_call (ast=0xa3fb008, rdest=0xb66bb2c4 "g2/2090", timeout=0) at chan_unicall.c:1119 p = (struct unicall_pvt *) 0x9baf250 callparms = (uc_callparms_t *) 0xa457ab8 callerid = "1234", '\0' <repeats 251 times>, "\b" dest = "g2/2090", '\0' <repeats 248 times> s = 0x0 c = 0xb66bb2c7 "2090" n = 0x0 l = 0xb72a209c "1234" ret = 6681736 makecall = {callparms = 0xa457ab8, crn = 0} __PRETTY_FUNCTION__ = "unicall_call" #5 0x0806b58d in ast_call (chan=0xa3fb008, addr=0xb66bb2c4 "g2/2090", timeout=0) at channel.c:2638 res = -1 __PRETTY_FUNCTION__ = "ast_call" #6 0x0806ad44 in __ast_request_and_dial (type=0xb66bb1c4 "UniCall", format=64, data=0xb66bb2c4, timeout=30000, outstate=0xb72a244c, cid_num=0xb66bb7c8 "1234", cid_name=0xb66bb8c8 "", oh=0xb72a2394) at channel.c:2471 state = 0 cause = 0 chan = (struct ast_channel *) 0xa3fb008 f = (struct ast_frame *) 0x8135120 res = 0 __PRETTY_FUNCTION__ = "__ast_request_and_dial" #7 0x08098423 in ast_pbx_outgoing_exten (type=0xb66bb1c4 "UniCall", format=64, data=0xb66bb2c4, timeout=30000, context=0xb66bb6c4 "testes_ramal", exten=0xb66bb5c4 "*200", priority=1, reason=0xb72a244c, sync=2, cid_num=0xb66bb7c8 "1234", cid_name=0xb66bb8c8 "", vars=0x0, account=0xb66bb9c8 "", channel=0x0) at pbx.c:5019 chan = (struct ast_channel *) 0x9d6e080 as = (struct async_stat *) 0x0 res = -1 cdr_res = -1 oh = {context = 0xb66bb6c4 "testes_ramal", exten = 0xb66bb5c4 "*200", priority = 1, cid_num = 0xb66bb7c8 "1234", cid_name = 0xb66bb8c8 "", account = 0xb66bb9c8 "", vars = 0x0, parent_channel = 0x0} attr = {__size = "SIP/2055\000$*·È\217\213\000St\214\000å\001\000\000°\211\214\000½\211\214\000SIP/", __align = 793790803} __PRETTY_FUNCTION__ = "ast_pbx_outgoing_exten" #8 0x0065d09f in attempt_thread (data=0xb66bb0b0) at pbx_spool.c:266 o = (struct outgoing *) 0xb66bb0b0 res = 0 ---Type <return> to continue, or q <return> to quit--- reason = 10996712 __PRETTY_FUNCTION__ = "attempt_thread" #9 0x00a7d3b6 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #10 0x007f133e in clone () from /lib/libc.so.6 No symbol table info available. Este mesmo erro já foi reportado por outro usuário: http://lists.digium.com/pipermail/asterisk-users/2007-February/180020.html E também por mim: http://listas.asteriskbrasil.org/pipermail/asteriskbrasil/2007-June/015054.html Pergunta ao pessoal do Disc-OS: Vocês pretendem prestar manutenção no UniCall já que agora a Intelbrás vende uma placa de E1 que precisa dele ? Pretendem tentar corrigir erros desse tipo ? O que acham de integrar as melhorias que fizeram com a versões oficiais ? Quem sabe até assumir oficialmente a manutenção do chan_unicall no Asterisk já que o autor (Steve Underwood) está mais ligado ao Callweaver atualmente do que ao Asterisk ? A todos: alguém já teve esse erro antes ? Conseguiu resolver de algum modo ? Neste teste de carga o segfault ocorreu após 14 horas de teste mas nos PABX de produção com tráfego médio o segfault ocorre a cada 1 ou 2 semanas. O problema não é "extremamente" crítico mas é grave pois todas as ligações ativas no momento são desligadas. Para efeito de comparação: nos PABX que tem somente E1 ISDN/PRI o Asterisk tem uptime de meses e só é interrompido para manutenções programadas. Leonardo _______________________________________________ Compre uma camiseta da AsteriskBrasil.org! http://www.voipmania.com.br == VoIPMania.com.br == _______________________________________________ LIsta de discussões AsteriskBrasil.org AsteriskBrasil@listas.asteriskbrasil.org http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil