re-invite o no re-invite, esa es la cuestión

Es muy común que los integradores de Asterisk se enfrenten a una serie de problemáticas con nuestro servicio Sarevoz. Vamos a analizarlo detalladamente para finalmente proponerte una solución. Además, tendrás ocasión de conocer cómo funciona un operador, sus límites y el porqué de las cosas. ¡Vamos allá!

Solicita una propuesta de telefonía IP para tu negocio

• Los user agents envían señalización SIP fuera del ámbito del operador: No estamos interesados en un nuevo endpoint Rocío. Somos el operador, no tenemos pantalla y no podemos garantizar que se muestre en el otro extremo.
• Los mensajes SIP no atendidos por el operador hacen que la llamada se finalice: La mayoría de ellos son relativos al universo de señalización SIP de las PBX: Notify, subscribe, message, info, options, update… 
• Inundar a tu operador puede acabar filtrando tu IP: ¿Es necesario que nos envíes los 10 nuevos destinos de un grupo de salto en paralelo en el mismo milisegundo?

Los user agents envían señalización SIP fuera del ámbito del operador

 
Los operadores sufrimos este caso cuando las PBX nos envían su señalización SIP interna de alguna de las siguientes maneras: como transferencias de llamadas, desvíos de llamadas o comunicación de un nuevo endpoint dentro de un grupo de salto. Estos mensajes se implementan mediante re-invites que se atienden por ser compatibles con el RFC 3261 pero son innecesarios y nos sobrecargan la red y la de los operadores con los que trabajamos.

¿Dónde está el problema? Cada vez que nos llega un re-invite también nos llega un nuevo endpoint audio/RTP, que tienen que pasar por un NAT y probablemente un ALG. Abrimos la posibilidad de una incidencia de audio en 1 solo sentido.

Imagina que tú y otros 100.000 user agents hacen lo mismo. Podríais llegar a saturar al operador y que algún re-invite no pueda ser atendido, abriendo la posibilidad de que se pierda el audio/RTP. También puede ocurrir que el codec del nuevo endpoint no esté soportado por el operador.

No compensa.

Los mensajes SIP no atendidos por el operador hacen que la llamada finalice

 
¿Que es lo que se espera de un operador? Se supone que nuestro cometido es terminar llamadas telefónicas desde y hacia la red pública de telefonía y que debemos hacerlo con fiabilidad, velocidad, escalabilidad, interoperabilidad y lo más importante, barato. 

Hay un montón de RFCs involucrados en la telefonía IP. Los operadores intentamos reducirlo al RFC3261 para garantizar el máximo entendimiento entre nosotros.

Los proveedores de servicio no nos podemos permitir atender la sobrecarga de mensajes que supone el mundo PBX porque repercute notablemente en la velocidad. Si tratásemos de atender todo necesitaríamos una infraestructura enorme y compleja que rompería la escalabilidad y los precios económicos. Como ya sabemos en el mundo de las telecomunicaciones y los sistemas informáticos, cuanto más grande es una infraestructura mayor es la probabilidad de tener puntos de fallo, lo que rompe la fiabilidad.

Tu PBX también intenta suscribirse para ser notificada por determinados servicios, pero nosotros no somos ni tu FreePBX ni tampoco tu servicio de WhatsApp. Es por ello que no deberíamos atender otro tráfico que no sean register, invite y bye, motivo por el que generalmente descartamos mensajes PBX como notify, subscribe, message, info, options, update…

¿Deberíamos atender el método update? Sólo en algunas circunstancias pero no en las que la mayoría de user agents pretenden: barra libre. Cuando descartamos estos mensajes con un “405 Method not Allowed” dependerá del método SIP empleado y de cómo interprete el STD el user agent final (si finaliza o no la llamada).

Lo cierto es que es un problema que observamos cada vez más.

¿Cómo podemos ayudarte?

Inundar a tu operador puede acabar filtrando tu IP

 
Desconocemos la verdadera realidad de las inundaciones de peticiones pero podemos adivinar algunas: quizás las políticas que algunos fabricantes siguen: «subsubsubsub-quierodecir-subcontratación», desarrollo bajo la influencia de psicotrópicos, desarrolladores locos por “Rocío”…

No es correcto enviar re-invites para anunciar que el nuevo destino es Rocío; no es ortodoxo enviarnos un update para comunicarlo, pero lo que no entendemos de ninguna forma es por qué enviarlo 10 veces en 1 segundo. Será que nuestra SkylinePBX también está loca por Rocío…

¿Qué ocurre entonces? Que filtramos tu IP, ya no podrás hacer más llamadas hasta que tu IP salga del filtro, podemos estar hablando de 5′, 10’…

23 segundos después de haberte filtrado nos llega un register que acaba fallando y no se reintenta en 3600 segundos. Es decir, 1 hora sin entrada de llamadas.

Por favor, evitad los re-invite y updates porque no estamos seguros bajo que dudosas circunstancias se ha desarrollado tu centralita.

Asterisk sin re-invites

 
Porque pensamos que antes de morir debemos hacer algo para conseguir un mundo mejor (realmente sólo espero que esto mejore mi karma con Rocío) hemos preparado una pequeña guía de cómo configurar un Asterisk para evitar re-invites hacia el operador. Lo primero, esto ha sido posible gracias a  Gorka Gorrotxategi de la empresa Irontec por su colaboración en el desarrollo de esta guía. Por otro lado, hemos omitido cualquier medida de seguridad, queda fuera del ámbito de este documento.

• Hay una palabra clave en Asterisk: sendrpid. Su propósito es enviar o no enviar el convencional callerid. Puedes encontrarlo en «sip%.conf».
• Hay varios RFCs involucrados en anunciar el callerid en el protocolo SIP. Las cabeceras candidatas son: from, remote-party-ID, p-preferred-ID y p-asserted-ID.
• En Asterisk puedes anunciar tu callerid configurando “sendrpid”[yes|no|pai|rpid]».
• Si ponemos “sendrpid=no” Asterisk evita hacer re-invite al operador al anunciar un nuevo endpoint pero también implica no anunciar la cabecera del callerid en las llamadas ordinarias.

 ¿Qué hacemos a partir de aquí? Gorka me dio la clave: prueba a configurar 2 trunks, uno para las llamadas entrantes y el otro para las llamadas salientes.

• El trunk de entrada con «sendrpid=no» y «directmedia=no».
• El trunk de salida con «sendrpid=pai» y «directmedia=no».
• La otra palabra clave en Asterisk es directmedia que permite configurar el audio RTP direct entre los endpoints en un esquema trapezoidal convencional.
• “directmedia=no” evita el RTP direct entre ambos endpoints.

Let’s rock!

Estamos en un periodo de convergencia: ¡paciencia!

 
Hay un montón de RFCs sobre el universo VoIP pero no hay un director de orquesta que coordine a todos y diga cuándo y cómo utilizarlos. Quiero decir: con sentido común. 

Estamos en un periodo de convergencia, operadores, fabricantes y usuarios, paso a paso.

En el camino perderás algunas llamadas, cambiarás de operador un millón de veces, tendrás que terminar algún que otro destino con tu móvil, cambiarás tu PBX e integrador mil veces, intentarás descifrar la voz de tu interlocutor mientras estás viendo una película en Netflix… y espero que confíes en nosotros para hacer este camino un poco menos duro.

¿Cómo podemos mejorar la telefonía IP de tu negocio?