Problema con SIP flow y RTP

681 views
Skip to first unread message

borjav...@gmail.com

unread,
Mar 29, 2012, 7:57:54 AM3/29/12
to asterisk-es
Hola gente!

Veréis, tengo un gran problema a la hora de que mi sistema funcione
correctamente. Ya no me voy a andar con "chiquitas" y voy a explicar e
intentar profundizar lo máximo posible para solucionarlo de una vez.
El motivo de que no lo haya hecho ya (meterme hasta la cocina) se debe
a que "de repente" funcionaba todo perfectamente y decía: "ahora a
avanzar y hacer algo productivo"...y justo cuando me ponía fallaba de
nuevo y vuelta a empezar.

La arquitecura de mi sistema es la siguiente:

Wan-->Firewall(Fortigate 60B)-->LAN
LAN: Asterisk; Softphones

El objetivo (de momento) es que puedan establecerse llamadas
normalmente entre diferentes clientes inter e intra.

El problema es la falta de audio. Tras ver diferentes escenarios y
toquetear en el firewall decidí tracear en todas las interfaces e
intentar detectar dónde estaba el fallo y por qué ocurría. He hecho
capturas en el Firewall (de ahora en adelante FGT) (interfaz de salida
a wan y en interna), en una máquina en WAN (de ahora en adelante
Roberto) (detrás de NAT), en una máquina local (de ahora en adelante
MAQ) y en el Asterisk.

Empezaré poco a poco y a ver si viendo algo raro con vuestra ayuda
puedo ver qué genera los problemas. Las capturas se han dividido en
dos: Llamada hecha por Roberto hacia MAQ; llamada hecha de MAQ a
Roberto

Direcciones:
- Firewall IP virtual: (B)
- Firewall IP de navegación: (E)
- Asterisk IP privada: (C)
- Roberto IP privada: (A)
- Roberto IP pública: (F)
- MAQ IP privada: (D)

1. R2M (Roberto to MAQ)

1.1. SIP session.

Ya para empezar el inicio de la sesión SIP no comienza con normalidad:

Si no me equivoco, al iniciar la llamada y teniendo en cuenta la
captura en la máquina de Roberto (A) el flujo normal de mensajes SIP
debería ser:
A---INVITE--->B
A<---TRYING---B
A<---RINGING---B
A<---OK---B
A---ACK--->B

Ahora lo que realmente se captura:

A---INVITE--->B
A<---TRYING---B
A<---RINGING---B
A<---RINGING---B
A<---OPTIONS---B
A---OK--->B
A<---OK---B
A---ACK--->D
A<---OK---B
A---ACK--->D
...
A<---BYE---B
A<---BYE---B
A---OK--->B
A---OK--->B


1ER PROBLEMA

B manda tantos OK porque el ACK está siendo enviado a D (MAQ) en vez
de a B. Esto pasa, según veo, porque en el OK que B manda a A con SDP
pone la IP privada en el "Contact" en vez de la pública (pone D en vez
de B) aunque no debería fijarse en

Este problema no priva a las partes implicadas a seguir con la
conexión y mandar RTPs. Mi explicación a esto es que en el momento que
D "descuelga" y manda el OK con SDP ya empieza a mandar RTP e igual a
la inversa: en cuanto A recibe el OK manda el ACK e inmediatamente
comienza a mandar RTP...¿correcto?

Por otro lado, en la captura en MAQ hay paquetes SUBSCRIBE...por qué
se están mandando estos paquetes?

El siguiente problema es que no llega RTP (no en todos los casos): Si
roberto llama a MAQ no llega nada a ninguna de las partes. Si MAQ
llama a Roberto si le llega audio a Roberto pero no a la inversa.
Google no me deja postear links (o eso parece). Lo digo porque he
hecho un gráfico con el flujo que puede ayudar.

A medida que alguien se anima a contestar (si es que alguien se
anima...xD) seguiré avanzando todo lo que pueda. A ver si me podéis
echar una mano!

Muchísimas gracias!!!

Salu2.

Saúl Ibarra Corretgé

unread,
Mar 29, 2012, 4:17:13 PM3/29/12
to aster...@googlegroups.com
Aupa,

Es un poco difícil adivinar qué puede ir mal sin saber cómo está configurado el tema ;-) Qué parámetros de configuración tienes para los dispositivos SIP? (pega lo relevante)

Algo que te puede ayudar a ver el problema es hacer un rtp set debug on, así verás a *dónde* se está mandando el RTP.


Saludos,

--
Saúl Ibarra Corretgé

http://saghul.net | http://about.me/saghul


Message has been deleted

borjav...@gmail.com

unread,
Mar 30, 2012, 6:32:44 AM3/30/12
to aster...@googlegroups.com
Ok! Entiendo que las suosiciones que hago sobre la causa del problema de los ACKs mandados a la privada son ciertas al no haber incidido en ello (no?).

Algunos detalles de la configuración:

externip=212.x.x.x
localnet=192.168.1.0/255.255.255.0
alwaysreyect=yes
rtpkeepalive=0
canreinvite=no
nat=yes

En los uduarios::
nat=yes (indistintamente)

Estoy pensando en la posibilidad de que esta configuración no sea la adecuada ya que el Firewalla redirecciona automáticamente al Asterisk. Por ello entiendo que quizá no sea necesario poner nat=yes en los usuarios, no? ¿Qué influencia tiene poner nat en Asterisk? ¿Sólo el cambio de la información de IP a la que hay que enviar el mensaje? (se cambia la privada por la pública especificada en externip). En el caso de los usuarios hay avrios casos a tener en cuenta:

- Si el usuario está en la misma red que Asterisk, al haber especificado 192.168.1.0/255.255.255.0, este será detectado como detrás de NAT y cambiará la IP por la pública, ¿Correcto? Entonces...¿tiene algún sentido especificar otra vez que el usuario está detrás de NAT? ¿Es redundante o aporta algo?

- Si el usuario está fuera de la red de Asterisk, ¿qué influencia tiene poner nat=yes? Asterisk mira el contact y cambia la dirección por la pública? A ver si entre todos me podéis echar una mano y dejar esto claro,claro...

En cuanto al Firewall, voy a escribirles porque navegando he visto que tienen un par de opciones llamadas "sip-helper" y "sip-nat-trace". Les voy a pedir que me expliquen en qué consisten estas opciones y qué "tocan".




El jueves 29 de marzo de 2012 22:17:13 UTC+2, saghul escribió:
Aupa,  

Saúl Ibarra Corretgé

unread,
Mar 30, 2012, 7:20:02 AM3/30/12
to aster...@googlegroups.com

--
Saúl Ibarra Corretgé
http://saghul.net | http://about.me/saghul


On Friday, March 30, 2012 at 12:15 PM, borjav...@gmail.com wrote:

> Ok! Entiendo que las suosiciones que hago sobre la causa del problema de los ACKs mandados a la privada son ciertas al no haber incidido en ello (no?).
>
> Algunos detalles de la configuración:
>

> externip=212.0.118.86


> localnet=192.168.1.0/255.255.255.0
> alwaysreyect=yes
> rtpkeepalive=0
> canreinvite=no
> nat=yes
>
> En los uduarios::
> nat=yes (indistintamente)
>
> Estoy pensando en la posibilidad de que esta configuración no sea la adecuada ya que el Firewalla redirecciona automáticamente al Asterisk. Por ello entiendo que quizá no sea necesario poner nat=yes en los usuarios, no? ¿Qué influencia tiene poner nat en Asterisk? ¿Sólo el cambio de la información de IP a la que hay que enviar el mensaje? (se cambia la privada por la pública especificada en externip). En el caso de los usuarios hay avrios casos a tener en cuenta:
>
> - Si el usuario está en la misma red que Asterisk, al haber especificado 192.168.1.0/255.255.255.0, este será detectado como detrás de NAT y cambiará la IP por la pública, ¿Correcto? Entonces...¿tiene algún sentido especificar otra vez que el usuario está detrás de NAT? ¿Es redundante o aporta algo?
>
> - Si el usuario está fuera de la red de Asterisk, ¿qué influencia tiene poner nat=yes? Asterisk mira el contact y cambia la dirección por la pública? A ver si entre todos me podéis echar una mano y dejar esto claro,claro...
>
> En cuanto al Firewall, voy a escribirles porque navegando he visto que tienen un par de opciones llamadas "sip-helper" y "sip-nat-trace". Les voy a pedir que me expliquen en qué consisten estas opciones y qué "tocan".
>

Que te desactiven cualquier 'helper' que tenga el firewall. Aparentemente el 97.3% de los fabricantes de routers y firewalls no tiene ni puta idea de SIP pero aún así implementan 'helpers', seguramente en 10 líneas de bash, haciendo un sed a muerte en el paquete. El router de un colega se reiniciaba si le llamaba usando ICE, para llorar.


Fernando Villares

unread,
Mar 30, 2012, 11:01:48 PM3/30/12
to aster...@googlegroups.com
y ojo con esto alwaysreyect=yes no existe ..es reject!!! con J OJO!!!



--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)

~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Para anular la suscripción: asterisk-es...@googlegroups.com

borjav...@gmail.com

unread,
Mar 31, 2012, 4:11:32 AM3/31/12
to aster...@googlegroups.com
OPS...grcias por fijarte!!! Recuerdo que eso fue un copy paste en toda regla...en seguida lo cambio.
Ayer escribí a los de soporte de Fortigate (Firewall) para ver qué me pueden contar. En cuanto tenga noticias os cuento.
- Para anular la suscripción: asterisk-es-unsubscribe@googlegroups.com

Felipe

unread,
May 30, 2014, 2:30:46 PM5/30/14
to aster...@googlegroups.com
Al fin como solucionaste el inconveniente aun se me presenta el mismo problema Gracias.
- Para anular la suscripción: asterisk-es...@googlegroups.com

Jose Rojas

unread,
Jun 11, 2014, 8:41:43 AM6/11/14
to aster...@googlegroups.com
Hola Amigo, abriste los puertos de rtp en el firewall?
Reply all
Reply to author
Forward
0 new messages