Polycom não está registrando contra o asterisco

Question

Temos vários Polycom 301s no escritório, além dos 501s, 601s e SoundStation 4001s. Recentemente, vários dos 301 e um 4001 deixaram de poder se registrar no servidor Trixbox / Asterisk e telefones adicionais estão começando a exibir esse comportamento. Eles podem entrar em contato com o servidor para obter um endereço IP, entrar em contato com o servidor TFTP para provisionar e até carregar logs de depuração, mas o registro aparece para o tempo limite. Exceções de log estão abaixo. Alguma idéia?

Asterisk 1.4.22 Trixbox 2.8.0 Polycom 3.0.1

0724113935|sip |3|03|Retry send 281
0724113939|sip |3|03|SendMessageFail
0724113939|sip |3|03|CUser::NewWorkingServer 1 to 279772128
0724113939|sip |3|03|SipOnEvNewWorkingServer User 0, old 0, new 0, expire 0
0724113939|sip |3|03|SipOnEvRegistrarUpdate User 0, index 0, state 0, expire 0, working 1
0724113939|sip |1|03|Client State finished REGISTER
0724113939|sip |3|03|SipStartFailOver 0
0724114008|sip |1|03|CreateFailOverProxyList : Reg to Domain '192.168.1.110' nPort 5060
0724114008|sip |1|03|CreateFailOverProxyList : For REGISTER Request nPort 5060
0724114008|sip |1|03|doDnsListLookup(udp): doDnsSrvLookupForARecordList for '192.168.1.110' port 5060 returned 1 results
0724114008|sip |1|03|doDnsListLookup(udp): result 0 '192.168.1.110' port 5060
0724114008|sip |1|03|CreateFailOverProxyList : Not NAPTR for '192.168.1.110' port 5060 IP 0 is '192.168.1.110' on udp port 5060
0724114008|sip |2|03|CreateFailOverProxyList : Exit with 1 IP Addresses
0724114008|sip |2|03|CreateFailOverProxyList : IP 1 is '192.168.1.110' on udp port 5060
0724114008|sip |0|03|>>> Data Send to 192.168.1.110:5060
0724114008|sip |0|03| REGISTER sip:192.168.1.110:5060 SIP/2.0
0724114008|sip |0|03| Via: SIP/2.0/UDP 192.168.1.248;branch=z9hG4bKdc51d87E89D17EA
0724114008|sip |0|03| From: "Joe Blow" ;tag=2FC4C6AD-D293EB4E
0724114008|sip |0|03| To:
0724114008|sip |0|03| CSeq: 1 REGISTER
0724114008|sip |0|03| Call-ID: [email protected]
0724114008|sip |0|03| Contact: ;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE
0724114008|sip |0|03| , REFER"
0724114008|sip |0|03| User-Agent: PolycomSoundPointIP-SPIP_301-UA/3.0.1.0032
0724114008|sip |0|03| Max-Forwards: 70
0724114008|sip |0|03| Expires: 3600
0724114008|sip |0|03| Content-Length: 0
0724114008|sip |0|03|
0724114009|sip |0|03|>>> Data Send to 192.168.1.110:5060
0724114009|sip |0|03| REGISTER sip:192.168.1.110:5060 SIP/2.0
0724114009|sip |0|03| Via: SIP/2.0/UDP 192.168.1.248;branch=z9hG4bKdc51d87E89D17EA
0724114009|sip |0|03| From: "Joe Blow" ;tag=2FC4C6AD-D293EB4E
0724114009|sip |0|03| To:
0724114009|sip |0|03| CSeq: 1 REGISTER
0724114009|sip |0|03| Call-ID: [email protected]
0724114009|sip |0|03| Contact: ;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE
0724114009|sip |0|03| , REFER"
0724114009|sip |0|03| User-Agent: PolycomSoundPointIP-SPIP_301-UA/3.0.1.0032
0724114009|sip |0|03| Max-Forwards: 70
0724114009|sip |0|03| Expires: 3600
0724114009|sip |0|03| Content-Length: 0

    

Answer 1

Depois de várias semanas fazendo com que os telefones parassem de funcionar, contratamos uma empresa de consultoria que determinou que a configuração do firewall não permitia a porta 5060 UDP na LAN. A porta 5060 é a porta padrão usada pelo protocolo SIP do VoIP e, portanto, estava impedindo que alguns telefones se conectassem ao servidor. Por alguns motivos, os telefones que já estavam funcionando passaram pelo firewall e, portanto, conseguiram se conectar ao aplicativo Trixbox.

Eles adicionaram uma regra para permitir a porta 5060 UDP, mas apenas na eth0 (que é a interface da LAN). Nós salvamos as regras do iptables e elas permanecerão mesmo se o servidor for reinicializado. Aqui está o comando para essa regra que foi adicionada:

iptables -I INPUT 27 -p udp -m udp --dport 5060 -i eth0 -j ACCEPT

Para os interessados, recorremos aos serviços da Teliphone Orion para resolver isso. Eles identificaram e resolveram o problema em um curto espaço de tempo.

    

Answer 2

Abra um console do Asterisk ( asterisk -r ), ative a depuração do SIP ( sip set debug ip yourphonesip ) e tenha o registro do telefone. Verifique se você vê os pacotes REGISTER e se há alguma resposta e / ou mensagem de erro.

Isto é apenas uma rede comutada ou existem outros dispositivos entre o Asterisk e os telefones?

Editar após seus comentários: Neste ponto, gostaria de ter certeza de que o tráfego dos telefones realmente atinge o servidor Asterisk - execute o tcpdump no servidor e talvez também em algum lugar perto dos telefones. Se os pacotes REGISTER chegarem ao servidor mas não aparecerem no log do Asterisk (mais os telefones estão trabalhando com outro Asterisk, como você testou), então algo está errado no lado do Asterisk.

Se, por outro lado, você não puder ver as requisições REGISTER do telefone mesmo com o tcpdump, então você tem que descobrir onde elas se perdem - mais sniffing em diferentes pontos da rede.

Além disso, aqui está uma discussão sobre o não registro da Polycom, o último post tem as instruções para uma "redefinição de configuração local" - talvez essa seja a mágica de que você precisa.

    

Answer 3

Tivemos o mesmo problema em algum momento, mas acabou sendo nosso firewall Cisco ASA pensando que o servidor trixbox era um invasor. adicionando a LAN local à lista de permissões corrigida rapidamente.

    

Answer 4

O que você vê no console do Asterisk? Tente habilitar o verbose (set verbose 3) e procure erros de gotejamento para os pares do lado do Asterisk.

A caixa Asterisk ainda recebe mensagens SIP desses telefones? Se o telefone conseguir obter comunicação DHCP e TFTP, acho que podemos descartar problemas de rede.