Trixbox não aceita chamadas recebidas no tronco IAX

Question

algum especialista em trixbox / asterisk por aí?

Eu tenho uma instalação de trixbox que se recusa a receber chamadas via IAX2 de um determinado provedor de VoIP. Inicialmente, pensei que era um problema de firewall, mas acho que já estabeleci agora que não é o caso. Eu tentei tudo o que posso pensar (e eu não sou especialista nesta área) sem sucesso. Eis o que estabeleci:

Outra TrixBox em um site separado pode se comunicar (através de IAX2) com esta instalação. Esta é uma maneira que eu sei que não é um problema de firewall e isso parece sugerir um problema com o provedor de VoIP, mas ...

O provedor de VoIP é capaz de trabalhar com sucesso com uma instalação do SwitchVox, sugerindo que o problema não é inteiramente com o provedor de VoIP também. Mas ...

Essa mesma instalação do SwitchVox também pode se comunicar com o meu 'problema' Trixbox - sugerindo novamente que não há nada de errado com o Trixbox.

Em face de resultados conflitantes, eu mudei para o asterisco de depuração, ativando a depuração IAX2 revela que a tentativa de conexão está sendo recebida - aqui está um exemplo de uma nova mensagem vindo do provedor:

 Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW
   Timestamp: 00004ms  SCall: 00043  DCall: 00000 [x.x.x.x:4569]
   VERSION         : 2
   CALLED NUMBER   : 0845[obfuscated]
   CODEC_PREFS     : ()
   CALLING NUMBER  : anonymous
   CALLING PRESNTN : 0
   CALLING TYPEOFN : 0
   CALLING TRANSIT : 0
   CALLING NAME    :
   LANGUAGE        : en
   USERNAME        : [obfuscated]
   FORMAT          : 8
   CAPABILITY      : 65407
   ADSICPE         : 2
   DATE TIME       : 2010-12-03  12:18:58

Aqui é onde a diferença ocorre. Em uma chamada bem-sucedida, vejo em seguida um handshake de autenticação, um AUTHREQ é enviado seguido por uma resposta AUTHREP. Para as conexões que não estão funcionando, eu nunca vejo esse handshake de autenticação (nem o AUTHREQ nem o AUTHREP).

O fato de que a NOVA mensagem está passando pelo firewall e sendo corretamente recebido pelo Trixbox confirma minha opinião de que isso não é um problema de firewall. Então eu acho que o ponto crucial do problema é que, por alguma razão, meu Trixbox está decidindo que não gosta da chamada recebida e não está nem pedindo que a caixa remota autentique . O que causaria isso? Como posso resolver isso mais? Qualquer sugestão recebida com gratidão neste momento, porque eu bati em uma parede de tijolos.

    

Answer 1

OK, eu acabei de fazer isso acontecer entre uma caixa PiaF (1.4) mais antiga e uma nova executando o asterisco 1.6.

O asterisco mais recente adicionou alguns recursos de segurança que precisam ser desativados para serem compatíveis. Na verdade, as mensagens estavam no arquivo de log do asterisco, embora eu tenha perdido duas horas antes de vê-las:

[2011-01-18 02:39:01] ERROR [15257] chan_iax2.c: Chamada rejeitada, é necessário o suporte a CallToken. Se for inesperado, resolva colocando o endereço XXXXXXX na lista calltokenoptional ou configurando o usuário XYZ requirecalltoken = no

Então eu adicionei requirecalltoken = no à seção DETALHES DO USUÁRIO no servidor asterisco 1.6 e tudo foi corrigido. Hmm, eu vejo que eu tinha um requirecalltoken = auto na seção de saída do outro lado, mas eu não acredito que seja necessário. Vou ter que agendar o tempo de inatividade para ver sobre isso.

Existe um pdf sobre isso em: link