Tenemos un problema un poco complicado en nuestro servidor Asterisk, que estamos luchando por resolver. Espero que alguien con más conocimientos que yo pueda ayudar.
Estamos ejecutando Asterisk 1.8.23.0 en Centos 6.4 y nuestros teléfonos y servidor Asterisk están ubicados en el interior de un firewall y nuestros proveedores de servicios VoIP están en el exterior. El firewall lo configura y administra una empresa externa.
Actualmente tenemos dos proveedores de servicios VoIP, Aque manejan la mayor parte del tráfico entrante y todo nuestro tráfico saliente, y Bque maneja parte de nuestro tráfico entrante, que se enruta a nuestro centro de llamadas a través de un IVR externo.
En una auditoría de seguridad reciente, nos dijeron que deberíamos tener todo nuestro tráfico VoIP a través de un firewall, y se decidió que deberíamos hacerlo en dos fases.
La primera fase es pasar el tráfico entrante que recibimos a Btravés de un firewall y luego, en la fase dos, enviar Atambién el tráfico entrante y saliente a través del firewall. Actualmente estamos atrapados en la fase uno.
Inicialmente intentamos configurar externipy localneten la [general]sección de nuestro sip.confarchivo, pero eso interrumpió el tráfico VoIP en nuestro proveedor de servicios VoIP principal A, por lo que intentamos configurarlos en la entrada específica en nuestro sip.confarchivo para nuestro proveedor de servicios VoIP secundario, Basí. :
[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
donde aaa.aaa.aaa.aaaestá la ip de A
y bbb.bbb.bbb.bbbes la ip de B
y ccc.ccc.ccc.ccces la ip externa del firewall.
Con estas configuraciones implementadas, el centro de llamadas puede recibir llamadas telefónicas a través del IVR, pero una vez que las llamadas están conectadas, la persona que llama externa puede escuchar al agente del centro de llamadas, pero el agente del centro de llamadas no puede escuchar a la persona que llama.
Nuestro proveedor de servicios VoIP nos dice que en la 200 OK SIPrespuesta de ccc.ccc.ccc.cccla parte SDP les está dando la ddd.ddd.ddd.ddddirección IP a la que enviar medios.
ddd.ddd.ddd.dddes la IP de nuestro servidor Asterisk al que Bnormalmente nos conectaríamos cuando no estamos intentando pasar tráfico a través del firewall. esta es la información que recibimos de ellos:
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
Según B, nuestro proveedor secundario de servicios VoIP, esta es la línea que causa el problema:o=root 1148542603 1148542603 IN IP4 ddd.ddd.ddd.ddd
eee.eee.eee.eeees una dirección IP que no reconozco y de la que no sé nada.
Cualquier ayuda es muy apreciada.
Respuesta1
Las llamadas sin audio o con audio unidireccional son un problema común cuando se utiliza NAT en VOIP. Obviamente ya tienes localizado el origen del problema: Que los paquetes que transportan voz se están enviando a la dirección incorrecta.
Primero, consultaría con las personas que mantienen su firewall. Si el firewall vale la pena, sin duda hay algo que pueden hacer para resolver el problema o facilitar el diagnóstico.
En su defecto, pregunte a sus proveedores si admiten troncales IAX2. IAX2 no sufre los problemas de NATing de SIP.
Buena suerte.