temos um problema complicado em nosso servidor Asterisk, que estamos lutando para resolver. Espero que alguém com mais conhecimento do que eu possa ajudar.
Estamos executando o Asterisk 1.8.23.0 no Centos 6.4 e nossos telefones e servidor Asterisk estão dentro de um firewall e nossos provedores de serviços VoIP estão do lado de fora. O firewall é configurado e gerenciado por uma empresa externa.
Atualmente, temos dois provedores de serviços VoIP, A
que lidam com a maior parte do tráfego de entrada e todo o nosso tráfego de saída, e B
que lida com parte do nosso tráfego de entrada, que é roteado para nossa central de atendimento por meio de um IVR externo.
Em uma auditoria de segurança recente, fomos informados de que deveríamos ter todo o nosso tráfego VoIP passando por um firewall, e foi decidido que deveríamos fazer isso em duas fases.
A primeira fase é colocar o tráfego de entrada que recebemos B
através de um firewall e, em seguida, na fase dois, enviar o tráfego de entrada e saída A
também através do firewall. No momento, estamos presos na fase um.
Inicialmente, tentamos configurar externip
e localnet
na [general]
seção de nosso sip.conf
arquivo, mas isso interrompeu o tráfego VoIP em nosso provedor de serviços VoIP primário A
, então tentamos configurá-los na entrada específica em nosso sip.conf
arquivo para nosso provedor de serviços VoIP secundário, B
assim :
[A]
type=friend
disallow=all
allow=alaw
allow=g729
context=fromneotel
host=aaa.aaaa.aaa.aaa
insecure=port,invite
nat=no
directmedia=no
[B]
type=friend
disallow=all
allow=g711
allow=g729
allow=alaw
context=fromis1
host=bbb.bbb.bbb.bbb
insecure=port,invite
nat=yes
directmedia=no
externip=ccc.ccc.ccc.ccc
localnet=192.68.20.0/255.255.252.0
onde aaa.aaa.aaa.aaa
está o ip de A
e bbb.bbb.bbb.bbb
é o ip de B
e ccc.ccc.ccc.ccc
é o ip externo do firewall.
Com essas configurações definidas, a central de atendimento pode receber chamadas por meio do IVR, mas assim que as chamadas forem conectadas, o chamador externo poderá ouvir o agente da central de atendimento, mas o agente da central de atendimento não poderá ouvir o chamador.
Nosso provedor de serviços VoIP nos informa que na 200 OK SIP
resposta da ccc.ccc.ccc.ccc
parte SDP está fornecendo o ddd.ddd.ddd.ddd
endereço IP para o qual enviar mídia.
ddd.ddd.ddd.ddd
é o ip do nosso servidor asterisk ao qual B
normalmente se conectaria quando não estamos tentando passar o tráfego pelo firewall. esta é a informação que recebemos deles:
Via: SIP/2.0/UDP bbb.bbb.bbb.bbb:5060;branch=z9hG4bKmm63qe00d8ogcio100k0.1;received=bbb.bbb.bbb.bbb
From: "Anonymous"<sip:<originating number from IVR>@bbb.bbb.bbb.bbb:5060;user=phone>;tag=1641833502-1377756054727-
To: "<call centre number>"<sip:<call centre number>@ccc.ccc.ccc.ccc:5060>;tag=as43201e45
Call-ID: [email protected]
CSeq: 609518180 INVITE
Server: Asterisk PBX 1.8.23.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:<call centre number>@ccc.ccc.ccc.ccc>
Content-Type: application/sdp
Content-Length: 260
v=0
o=root 1148542603 1148542603 IN IP4 ddd.ddd.ddd.ddd
s=Asterisk PBX 1.8.23.0
c=IN IP4 ddd.ddd.ddd.ddd
t=0 0
m=audio 11064 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
de acordo com B
nosso provedor de serviços VoIP secundário, esta é a linha que está causando o problema:o=root 1148542603 1148542603 IN IP4 ddd.ddd.ddd.ddd
eee.eee.eee.eee
é um endereço IP que não reconheço e sobre o qual não sei nada.
Qualquer ajuda é muito apreciada.
Responder1
Chamadas sem áudio ou unidirecionais são um problema comum durante o NAT VOIP. Obviamente você já localizou a origem do problema: que os pacotes que transportam voz estão sendo enviados para o endereço incorreto.
Primeiro, eu verificaria com as pessoas que mantêm seu firewall. Se o firewall vale a pena, sem dúvida há algo que eles podem fazer para resolver o problema ou facilitar o diagnóstico.
Caso contrário, pergunte aos seus provedores se eles suportam troncos IAX2. IAX2 não sofre dos problemas de NAT do SIP.
Boa sorte.