Funcionamiento de redes basadas en SIP y Kamailio.

En esta entrada  les explicare el funcionamiento de las  redes basadas en SIP y de un servidor SIP de codigo abierto, Kamailio.

Características del protocolo SIP

SIP es un protocolo genérico de establecimiento de sesiones multimedia. El inicio de
la sesión, cambio o término de la misma, son independientes del tipo de medio o aplicación
que establece la llamada; una sesión puede incluir varios tipos de datos, incluyendo audio,
video y muchos otros formatos.

SIP es un protocolo de capa de aplicación, cuyo diseño permite una fácil
implementación y una buena escalabilidad y flexibilidad. Se encuentra disponible en su
versión 2.0 y está documentado a través del RFC 3261; el cual reemplaza a la versión
anterior (RFC2543).

SIP se complementa con otros protocolos tales como SDP (Sesion Description
Protocol) y RTP/RTCP (Real Time Protocol) para completar la comunicación. RTP/RTCP se
emplea para transportar los datos multimedia en tiempo real mientras que SDP se utiliza
para describir las características de los participantes de la sesión multimedia. Es un protocolo
orientado a conexiones End-to-End. Toda la lógica se encuentra almacenada en los
dispositivos finales (salvo el ruteo de mensajes).


Las funciones principales de SIP son:

• Establecer, modificar y finalizar las sesiones entre dos o más participantes.
• Registro y localización de participantes (Movilidad)
• Gestión del conjunto de participantes y de los componentes del sistema.
• Describir las características de las sesiones y negociar las capacidades de los participantes.

Algunas de sus características son:

• Basado en Texto. (Similar a HTTP)
• Uso de Identificador Universal de Recursos (URIs con esquemas sip, sips y tel)
• Métodos básicos: INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS.
• Los mensajes se agrupan en transacciones y llamadas (diálogos).
• Las descripciones de sesiones multimedia (SDP) se encuentran en el cuerpo de los mensajes. 
• Localización basada en DNS.

Protocolo SDP (Session Description Protocol)

Este protocolo fue diseñado para transportar información de la sesión/medios hacia los

destinatarios. Permite asociar más de un flujo de medios a una misma sesión (Audio y Video). Para

ello se establece una descripción y negociación de los parámetros de sesión a través de mensajes

SDP codificados como texto plano (ISO 10646 UTF-8) cuyos nombres de campo y atributos usan US-

ASCII pero los demás emplean 10646. Se eligió este formato para aumentar la “portabilidad” hacia

sistemas Web.

Protocolo RTP / RTCP (Real Time Protocol / Real Time Control Protocol)

El RFC 1889 se refiere a este protocolo como “Transporte y Monitoreo de Flujos en Tiempo

Real”. (Real Time Media Streaming).

Sus funciones principales son:

• Identificación del tipo de carga útil transportada (Codecs de Audio/Video)
• Verificación de la entrega de los paquetes en orden (Marca de tiempo) y si resulta necesario reordenar los bloques fuera de orden.
• Transporte de información de sincronismo para la codificación y decodificación
• Monitoreo de la entrega de la información.

Entidades que componen una red basada en SIP

A continuación se definen las diferentes entidades que componen una red basada en

protocolo SIP. Esto es importante para definir conceptos tenidos en cuenta en este proyecto.

• Agentes de Usuario (User Agent)
• Servidor Registrar
• Servidor Redirect
• Servidor Proxy

Agentes de Usuario (UA)

Se denominan Agentes de Usuario (UA: User Agent) a los terminales que utilizan SIP

para encontrar y negociar con otros terminales las características de la sesión.

Cada Agente de Usuario (UA) se compone lógicamente de dos entidades:

•  Agente de Usuario Cliente (UAC)
• Agente de Usuario Servidor (UAS)

El UAC es la parte del agente de usuario que genera peticiones y recibe respuestas a

esas peticiones. El UAS es la parte del agente de usuario que recibe peticiones y genera

respuestas.

Un agente de usuario se comporta como UAC o UAS dependiendo de la situación.

Por ejemplo un agente de usuario que realiza una llamada se comporta como UAC cuando

envía mensaje de INVITE y recibe las respuestas a ese pedido. Un agente de usuario llamado

se comporta como UAS cuando recibe el mensaje de INVITE y envía las respuestas. Pero esta

situación cambia cuando la parte llamada decide enviar un mensaje BYE para terminar la

sesión. En este caso el agente de usuario llamado se comporta como UAC (enviando un BYE)

y el agente de usuario llamante se comporta como UAS.

Servidor “Registrar”

Este elemento de Red posee la función de autenticar y validar la cuenta de un usuario contra

una base de datos interna o externa y “registrar” la localización actual del mismo. Este tipo de

servicio, la mayoría de las veces se implementa en forma conjunta con el servidor Proxy SIP.

Servidor “Proxy”

Son aplicaciones que reciben los pedidos de los clientes SIP e inician nuevas

peticiones hacia los agentes de usuario de destino o hacia otros servidores Proxy. Es decir,

actúan enrutando los mensajes SIP, en base a reglas predefinidas.

Los Proxy SIP tienen la habilidad de conocer varias rutas alternativas para localizar a

un agente de usuario y pueden intentar el proceso de bifurcación en forma secuencial o en

paralelo dependiendo de cómo este configurado el Proxy.

Servidor “Redirect”

Esta entidad que integra una red SIP escucha peticiones y regresa respuestas que contienen

la localización actual de un usuario en particular. Estas respuestas son mensajes SIP de clase 3XX.

El usuario o Proxy que realizó la petición original extrae la información de las respuestas y

envía otra petición “redirigida” en base al resultado de la búsqueda.

Mensajes, Transacciones y Diálogos SIP

Mensajes SIP

SIP es un protocolo textual que usa una semántica semejante a la del protocolo HTTP.

Como se vio anteriormente, los UAC realizan las peticiones y los UAS retornan respuestas a

las peticiones de los clientes. SIP define la comunicación a través de dos tipos de mensajes.

Las solicitudes (métodos) y las respuestas (códigos de estado) emplean el formato de

mensaje genérico establecido en el RFC 2822 , que consiste en una línea inicial seguida de un

o más campos de cabecera (headers), una línea vacía que indica el final de las cabeceras, y

por último, el cuerpo del mensaje que es opcional.

Peticiones, Solicitudes o Métodos SIP

Las peticiones SIP son caracterizadas por la línea inicial del mensaje, llamada

Request-Line, que contiene el nombre del método, el identificador del destinatario de la

petición (Request-URI) y la versión del protocolo SIP. Existen seis métodos básicos SIP que

describen las peticiones de los clientes:

 -INVITE: Permite invitar un usuario o servicio para participar en una sesión o para

modificar parámetros en una sesión ya existente.

- ACK: Confirma el establecimiento de una sesión.

- OPTION: Solicita información sobre las capacidades de un servidor.

- BYE: Indica la terminación de una sesión.

- CANCEL: Cancela una petición pendiente.

- REGISTER: Registrar al User Agent.

Sin embargo, existen otros métodos adicionales que pueden ser utilizados,

publicados en otros RFCs como los métodos INFO, SUBSCRIBER,etc.

Respuestas (Códigos de estado) SIP

Después de la recepción e interpretación del mensaje de solicitud SIP, el receptor del

mismo responde con un mensaje. Este mensaje, es similar al anterior, difiriendo en la línea

inicial, llamada Status-Line, que contiene la versión de SIP, el código de la respuesta (Status–

Code) y una pequeña descripción (Reason-Phrase). El código de la respuesta está compuesto

por tres dígitos que permiten clasificar los diferentes tipos existentes. El primer dígito define

la clase de la respuesta.

Código - Clases

1xx - Mensajes provisionales.

2xx - Respuestas de éxito.

3xx - Respuestas de redirección.

4xx - Respuestas de fallo de método.

5xx - Respuestas de fallos de servidor.

6xx - Respuestas de fallos globales.

Transacciones y Diálogos SIP

Una Transacción SIP es una secuencia de mensajes entre dos elementos de Red. Corresponde

a una petición y todas sus respuestas. Una transacción puede incluir cero o más respuestas

provisionales y una o más respuestas finales (INVITE puede ser dividido por un Proxy, por lo tanto

tendrá múltiples respuestas finales).

Un Diálogo SIP es una conversación peer-to-peer entre dos UA (Agentes de Usuario). Los

diálogos son identificados usando los campos Call-ID (Id. de llamada), From (De) y To (Para). Los

mensajes con estos campos iguales pertenecerán al mismo diálogo. Un diálogo es una secuencia de

transacciones.

Tipos de Servidores Proxy SIP

Existen dos tipos de servidores Proxy: Stateful y Stateless.

• Stateful Proxy (Dialog & Transaction)

Los servidores Proxy Stateful retienen cierta información (estado) durante la llamada.

Respecto del tipo de información que pueden retener los servidores Proxy Stateful cabría

realizar una nueva clasificación. Es muy común encontrarse con aplicaciones como por

ejemplo aquellas basadas en SER (Sip Express Router) que solamente actúan manteniendo el

estado para una simple transacción SIP (minimal state). En esta caso se dice que estamos en

presencia de un servidor tipo “Transaction Stateful Proxy”. En el caso que se almacene el

estado durante todo el tiempo que dure el establecimiento de una llamada estaremos en

presencia de un “Dialog Stateful Proxy”.

• Stateless Proxy

Los servidores Proxy Stateless, procesan un mensaje SIP y olvidan todo lo referente a

la llamada hasta que vuelven a recibir otro mensaje SIP. La implementación Stateless provee

buena escalabilidad, pues los servidores no requieren mantener información referente al

estado de la llamada una vez que la transacción ha sido procesada. Además, esta solución es

muy robusta dado que el servidor no necesita “recordar” nada en relación con una llamada.

Sin embargo, no todas las funcionalidades pueden ser implementadas en un servidor proxy

stateless, por ejemplo, las funcionalidades relativas al accounting y facturación de las

llamadas puede requerir funcionalidades proxy stateful, de mane

Escenarios de Registro, Inicio y Finalización de Sesión

Escenario de Registro SIP

Para que un usuario pueda ser llamado por otro, este debe registrarse primero ante el

Registrar (o Proxy). El registro consiste en el envío de un mensaje REGISTER seguido de su

correspondiente respuesta 200 OK. Si el usuario no da credenciales válidas recibirá por respuesta un

mensaje 407, con lo cual tendrá que reenviar el mensaje de Registro hasta que tenga éxito.

Escenario de Inicio de Sesión SIP

La invitación a realizar un inicio de sesión SIP comienza con el mensaje INVITE dirigido

comúnmente al Servidor Proxy. Éste responde con un mensaje TRYING (100) para evitar posibles

retransmisiones y reenvía las peticiones hacia el usuario llamado. Todas las respuestas provisionales

generadas por el usuario llamado son regresadas al usuario origen, por ejemplo RINGING (180). Una

respuesta 200 (Ok) es generada en cuanto el usuario llamado contesta.

Escenario de Finalización de Sesión SIP

Una sesión finaliza cuando uno de los usuarios envía el mensaje BYE al otro extremo. El otro

usuario confirma el final de la conversación enviando por respuesta un mensaje 200 (Ok). La

transacción para terminar la sesión se realizará de un extremo a otro sin pasar por el Proxy (sólo si no

existe un registro de ruta).

Registro de Ruta: Hay situaciones en las que el Proxy requiere estar presente en la ruta de todos los

mensajes con fines de control del tráfico, o por ejemplo, cuando existe un router NAT como veremos

más adelante. Esto se logra por medio de la inserción del campo RECORD ROUTE en los encabezados de los mensajes SIP.

Soluciones NAT del lado del cliente

En esta sección se comentan brevemente algunas soluciones para NAT que existen en

el lado del cliente, es decir, o bien en su dispositivo SIP o bien en su router/firewall NAT:

STUN (Simple Traversal of UDP through NAT)

Un dispositivo que usa STUN, antes de registrarse y/o hacer llamadas, se pone en

contacto con un servidor STUN que previamente se indicó en su configuración (ej:

stun.ekiga.net) y a través de él, se entera de si está detrás de NAT y qué tipo de NAT.

A continuación se verá con más detalle lo que ocurre:

Se inicia el dispositivo SIP. Este tiene configurado usar STUN contra un servidor STUN

predeterminado. En su configuración SIP y RTP tienen puertos asignados, supongamos SIP

5060 y RTP 8000. Inicia el test de STUN contra el servidor de STUN. Dicho test realiza una

serie de consultas:

Hola servidor STUN, ¿con qué IP y puerto me ves?

Entonces el dispositivo se entera de si está detrás de NAT. En caso afirmativo continúa el test

con la siguiente consulta:

Te envío un paquete desde mi puerto local 5060 y luego otro desde el 8000, ¿tú qué IP y

puertos mapeados en mi router NAT recibes?

Esto le permite al dispositivo conocer con qué IP y puertos saldría vía IP pública desde su

router NAT (hay que tener en cuenta que un router NAT puede manejar más de una IP

pública).

¿Y si hago la misma consulta pero a tu segunda IP pública? ¿ves la misma IP y puertos?

Esto es crucial y sirve para detectar el NAT simétrico, el único que impide el

funcionamiento de STUN. Si el servidor STUN ve la misma IP y puertos origen entonces el

dispositivo ya sabe qué IP pública y puertos debe indicar en sus mensajes SIP corrigiendo los

que aparecían en negrita.

Supongamos que el puerto SIP 5060 se mapea en el router NAT al 15060 y el RTP

8000 al 1800, entonces el dispositivo SIP indicaría esos valores en su mensaje INVITE en vez

de los indicados en negrita. Con esto sencillamente se consigue que nuestro dispositivo SIP

aparente tener IP pública.

Limitaciones de STUN

STUN no funciona con NAT simétrico (bastante implementado en routers NAT típicos

ofrecidos por las operadoras para ADSL). Esto es debido a que este tipo de NAT no garantiza

que si se contacta con distintas IP's externas éstas lo vean con el mismo puerto público. Es

decir, el test de STUN no serviría puesto que no se sabe con qué puertos lo verá el destino

SIP.

STUN necesita mantener el keepalive de SIP para que el router NAT no cierre la

entrada de nuevos mensajes SIP transcurrido un cierto tiempo (por ejemplo: 20 segundos).

Esto no es problema puesto que el propio cliente podría enviar mensajes SIP periódicos al

destino (como un OPTIONS).

STUN sólo sirve para UDP y no para TCP. Esto es debido a la forma en la que un

router NAT detecta las conexiones establecidas para permitir nuevo tráfico entrante hacia la

LAN. En UDP se considera "misma comunicación" si anteriormente un paquete UDP ha salido

en sentido contrario hacia la IP y puerto público desde el que se reciben ahora nuevos

paquetes UDP. Pero en TCP (protocolo orientado a conexión) el router/firewall NAT sólo

considera una conexión TCP establecida si se ha seguido el protocolo para ello existente en

el propio TCP, es decir: SYN, SYN/ACK y ACK.

TURN (Traversal Using Relay NAT)

TURN se emplea para complementar los casos donde STUN no puede actuar (NAT

simétrico y TCP) pero con el gran costo añadido de requerir de un servidor TURN por donde

se enviará el tráfico. Es decir, un servidor STUN sólo interviene en la consulta inicial de los

clientes SIP, en cambio, un servidor TURN se emplea para enviar a través suyo el tráfico final.

Obviamente en términos de RTP el uso de TURN debe ser la última opción a considerar.

Además, puesto que el servidor TURN debe reunir requisitos de ancho de banda apropiados,

la opción de TURN debe considerarse como una solución del lado del cliente y del servidor.

ICE (Interactive Connectivity Establishment)

ICE no es en realidad un nuevo protocolo, sino una metodología que permite a los

clientes investigar qué solución de lado cliente (por ejemplo STUN ó TURN) es la más

adecuada según el escenario.

ALG (Application Layer Gateway)

AGL es un sistema implementado en el router/firewall que examina los paquetes SIP

que lo atraviesan y modifican las IP's y puertos para adecuarlos a su situación de NAT. Es,

digamos, una solución transparente para el cliente. No obstante, por implementarse en su

red local se considera solución de lado cliente.

Problemas con ALG

Al parecer muchas implementaciones ALG para SIP que vienen en los routers ADSL

son nefastas y reescriben los puertos con valores incorrectos (fuera del rango de 2^16), lo

que impide la transmisión del audio. Debido a este problema, en algunos routers es

necesario desactivar ALG de SIP vía telnet.

Soluciones NAT del lado del Servidor

En esta sección comento algunas soluciones para el NAT que existen en el lado del

servidor, lo que conlleva a la total transparencia desde el punto de vista del cliente. En este

caso será el servidor/proxy SIP el que tome medidas.

Proxy RTP

Un proxy RTP sirve como "pasarela" del tráfico RTP, de tal forma que el llamante y el

llamado envían su tráfico RTP a través de él. Dicho proxy RTP es manejado desde un servidor

SIP y debe disponer de IP pública para que sea accesible a los usuarios.

Supongamos que un usuario tras NAT llama a través de su proxy SIP a un usuario SIP

con IP pública:

Un usuario tras NAT y sin ninguna solución del lado del cliente hace una llamada a

través de su proxy SIP.

El proxy detecta que el INVITE proviene de una IP privada (mirando las cabeceras) así

que modifica las IP's y puertos del contacto SIP reemplazándolos por los valores de la IP y

puertos públicos del router.

Además reescribe la IP y puerto del SDP poniendo la IP del proxy RTP y un puerto que

en una consulta previa dicho proxy RTP le haya ofrecido.

Entonces se rutea el INVITE al destino, el cuál verá como punto de contacto SIP la IP

pública del NAT llamante y como contacto RTP la IP pública del proxy RTP.

Así pues la comunicación SIP pasa por el proxy SIP (como debe ser) mientras que el

tráfico de audio pasa por el proxy RTP que se encarga de puentear los flujos RTP de llamante

y llamado.

Obsérvese también, que si el proxy SIP ha añadido cabeceras "Record-Route" para

permanecer toda la llamada en el path, y como el proxy SIP ha puesto la IP pública NAT del

llamante en la cabecera "Contact" del INVITE que luego ha rutado al llamado, entonces si el

llamado cuelga la llamada enviará algo como:

BYE sip:841101@170.210.68.101:15060 SIP/2.0

Así que el proxy SIP ruteará ese mensaje a la IP pública del llamante. Si esta cabecera

no se hubiese corregido entonces sería:

BYE sip:841101@192.168.128.101:5060 SIP/2.0

Lo que provocaría que el proxy SIP no podría rutearla ya que intentaría rutearla a una

IP privada.

Otras consideraciones

También hay que tener en cuenta el caso en el que el llamado esté tras NAT. En ese

caso el proxy SIP debe detectarlo en la respuesta del llamado ("Trying", "Ringing", "OK"...).

Proxy's RTP disponibles

Las opciones más extendidas (al menos en el mundo del software libre) son RTP

Proxy y Media Proxy, ambos compatibles con OpenSer y con SER, los dos proxy SIP más

populares.

Kamailio

Kamailio es un completo servidor SIP de codigo abierto que implementa las funciones de registrar, proxy, XCAP server, MSRP relay.... y soporta muchas bases de datos como MYSQL, Cassandra ....

Archivo de Configuración: Kamailio.cfg

Kamailio basa su funcionamiento en un núcleo que recibe y procesa mensajes SIP. La
mayor parte de su funcionalidad se brinda a través de módulos extra. Al poseer una
arquitectura modular, Kamailio posee un núcleo muy pequeño, rápido y estable. Las
funcionalidades de los módulos se emplean a través del archivo de configuración de
Kamailio (kamailio.cfg). Este archivo de configuración controla que módulos serán cargados
y define como se comportaran a través de las variables de módulo.


Kamailio.cfg consta de siete secciones lógicas:

1. Sección de Definiciones Globales: Esta parte del archivo .cfg normalmente contiene el
IP y puerto donde el servicio se encuentra escuchando peticiones, el nivel de
depuración empleado (debug level), etc. Las definiciones de esta sección afectan
directamente al servicio (SER daemon).

2. Sección de Módulos: Esta sección contiene una lista de las librerías externas que se
necesesitan para brindar funcionalidad no provista por el núcleo. Estos módulos son
archivos de objetos compartidos “.so” y se cargan con la directiva “loadmodule”;

3. Sección de Configuración de Módulos: Muchas de las librerías especificadas en la
“Sección de Módulos” necesitan del seteo de algunos parámetros para su
funcionamiento. Estos parámetros se setean a través del comando “modparam” bajo
la siguiente forma: modparam (“nombre_modulo”, ”parámetro_modulo”,
valor_modulo).

4. Bloque Principal de Ruteo: Este bloque se asemeja a la función principal (main) de un
programa escrito en C. Este es el punto de entrada del procesamiento de un mensaje
SIP y controla como maneja cada mensaje recibido.(route[1])

5. Bloques Secundarios de Ruteo: Además del bloque principal de ruteo, el archivo .cfg

puede contener otros bloques adicionales de ruteo llamados desde el bloque

principal o desde otro bloque secundario. Un bloque secundario de ruteo es análogo

a una subrutina. (route[x])

6. Bloque de Ruteo de Respuesta: Se pueden utilizar bloques opcionales destinados a

manejar respuestas a mensajes SIP la mayoría de los cuales son mensajes “OK”.

(on_reply_route[x])

7. Bloques de Ruteo de Falla: Se pueden utilizar bloques opcionales cuando se necesita

procesar o manejar diferentes condiciones de falla como por ejemplo un mensaje

“BUSY” o un “timeout”. (failure_route*x+)

SIP: Transacciones, Diálogos y Sesiones

A fines de entender apropiadamente el funcionamiento del archivo de configuración

.cfg, se necesita comprender tres conceptos básicos:

• Transacción SIP: Esta compuesta por un mensaje SIP (y cualquier reenvío) y su respuesta directa (y casi siempre inmediata). Por ejemplo: Un Agente de Usuario (UA) envía un mensaje “REGISTER” a OpenSER y recibe de su parte un mensaje “OK”;
•  Diálogo SIP: Se trata de una relación entre dos o más transacciones que existen por un cierto tiempo. Por ejemplo: Se establece un diálogo entre un mensaje “INVITE” finalizado por un “BYE”);
• Sesión: Se corresponde con el flujo o stream de audio de una conversación entre dos teléfonos SIP.

Procesamiento del archivo de configuración .cfg

Se puede entender al archivo kamailio.cfg como un script que se ejecuta cada vez que

se recibe un mensaje SIP. Por ejemplo, un agente de usuario (UA) envía un mensaje INVITE a

otro UA para establecer una conversación. En este caso al recibir el mensaje INVITE,

OpenSER comienza a procesarlo a través de los comandos encontrados en el bloque de

ruteo principal (main route []).

Luego, el proceso continua hasta que se alcanza un punto en el cual se toma la

decisión acerca de donde enviar el INVITE (usando el comando t_relay()), devolver al origen

una respuesta con error (usando sl_send_reply()), o simplemente descartar el INVITE (ya sea

llegando al final de la ruta principal o por encontrarse con un comando break). Por supuesto,

esto último no se recomienda.

El destinatario responderá al INVITE con un mensaje OK. El mensaje OK es una

respuesta directa al mensaje inicial INVITE por lo tanto es controlado por la sección del

archivo de configuración denominada on_reply_route[x]. Si el destinatario no responde, o

responde con un error (busy, etc), se llama a la rutina failure_route[x].

Finalmente, si en la respuesta no existe error, el origen enviará un mensaje “ACK” para

indicar al destinatario que todo fue recibido y aceptado.

Cuando se emplea t_relay(), el comportamiento se manifiesta de acuerdo a lo

expuesto anteriormente, entonces se dice que OpenSER trabaja como “trasaction stateful

proxy”.

Cabe aclarar que un diálogo como el descripto en el ejemplo anterior incluye otras

respuestas intermedias antes del OK, pero las mismas no fueron contempladas por

simplificación.

Todos los mensajes que encabezan una nueva transacción SIP entran al tope de la

ruta principal (main route[]). En OpenSER existe una total libertad en la manera que se

procesan los mensajes SIP. A continuación se presentan algunos ejemplos de funciones:

• save(“location”): Se emplea para registrar cuando un usuario esta disponible o en línea. 
• lookup(“location”): Esta función retorna la dirección IP del usuario destino de la llamada.
• setflag(x): Permite el almacenamiento de cierta información limitada acerca de los usuaros en forma de banderas o flags.

Entendiendo SIP y RTP

SIP es un protocolo de señalización que permite manejar o controlar una llamada:

invitando a que la misma se realice (INVITE), cancelando durante el timbrado (CANCEL),

cortando una vez establecida (BYE), etc.

Los mensajes SIP pueden ser intercambiados directamente entre agentes de usuario

(UA), aunque a menudo se emplean SIP servers a los fines de ubicar los destinatarios.

Cuando un servidor SIP como OpenSER recibe un mensaje, puede decidir si permanece en el

medio del loop o no. Si no lo hace, OpenSER proveerá al UA la información necesaria para

contactar al otro UA y luego los mensajes SIP se intercambiaran directamente entre los dos

UAs.

Si OpenSER permanece en el loop, por ejemplo para asegurar que un mensaje BYE

sea recibido a los fines de tarifar la comunicación, OpenSER debe insertar un encabezado de

ruta (Route header) en el mensaje SIP usando la función record_route() para indicarle a los

demás que quiere participar. A los fines de que esto funcione, OpenSER y el resto de los

servidores SIP que intervienen deben realizar lo que se denomina “liberar la ruta” (“loose

routing”). Esto significa que los mensajes SIP no deben enviarse directamente al UA sino a

través de aquellos que pusieron un encabezado de ruta (route header) en el mensaje SIP.

Para chequear esto se emplea la función “loose_route()”.

Un mensaje SIP puede contener información adicional, por ejemplo relacionada

sobre como configurar una llamda con audio y video stream. (llamado SDP, Session

Description Protocol).

La información SDP resultará en uno o más sesiones RTP a ser configuradas,

normalmente entre los dos UA. Kamailio no participa de esto. RTP son por naturaleza de

procesamiento de ancho de banda intensivo. Sin embargo, como se describe después,

OpenSER puede asegurar que otra aplicación como un B2BUA (“Back to Back User Agent”) o

RTP Proxy puede convertirse en intermediarios. (“middle man”).

Finalmente, de Real-Time Control Protocol (RTCP) transmite información acerca de

los streams RTP entre UA. RTCP puede emplear el puerto RTP + 1 o un puerto indicado en el

propio mensaje SDP.

Aplicaciones Back-End

Está claro que OpenSER no mantiene información de estado sobre un diálogo SIP,

solo transfiere mensajes SIP (como parte de transacciones) entre dos agentes. La

consecuencia de esto es que OpenSER no puede ser un “peer” en el diálogo.

Si se necesita proveer capacidades de correo de voz o simplemente reproducir un

aviso indicando que el usuario no está disponible se necesitará algo que actúe de

intermediario como UA. Para ello existen módulos extra que proveen dicha funcionalidad

denominadas “back-end user applications”. Estas aplicaciones pueden actúar como “middle

man” para los mensajes SIP, para el audio va RTP, o ambos a la vez. Cada UA entonces

dialogará con este punto intermedio (“middle man”) y nada conocerá del UA remoto. Los

servidores que corren este tipo de aplicaciones reciben el nombre de “B2BUA”.

URI, R-URI, y Ramas (Branches)

Para identificar un usuario de manera unívoca se emplea el identificador URI

(Uniform Resource Identifier). La denominación URI se emplea como una dirección del

contacto destino. La forma típica de un identificador SIP (URI) es la siguiente:

sip:nombreusuario@dominio.com. El identificador URI original ubicado en la primera línea

de un mensaje SIP se llama request-URI (R-URI). Este URI es referenciado dentro del archivo

de configuración .cfg usando la expresión “uri”. Ejemplo: if (uri=~sip:username@.*)

Un URI puede ser manipulado a través del archivo de configuración a través de

diversas funciones desde diferentes módulos. Por ejemplo: lookup(“location”) tomará la

expresión uri modificada a lo largo del proceso, buscará en la base de datos “location” y

reescribirá el URI usando la información de contacto correcta (incluyendo @ipaddress:port).

Al ejectuarse t_relay() el mismo empleará como URI destino la forma final luego de las

transformaciones realizadas.

Algunas funciones, tales como lookup(“location”) pueden agregar ramas al conjunto

de URIs destino. Esto significa que cuando se ejecuta t_relay(), el mensaje INVITE se duplica

hacia todas las (potenciales) formas transformadas. El comando a nivel de núcleo

denominado “revert_uri()” reemplazara el actual URI destino con el valor original dado por

el campo “request-URI”.