SIP - Guía rápida

El Protocolo de inicio de sesión (SIP) es uno de los protocolos más comunes utilizados en la tecnología VoIP. Es un protocolo de capa de aplicación que funciona junto con otros protocolos de capa de aplicación para controlar las sesiones de comunicación multimedia a través de Internet.

Tecnología VoIP

Antes de seguir adelante, comprendamos primero algunos puntos sobre VoIP.

VOIP es una tecnología que le permite entregar contenido de voz y multimedia (videos, imágenes) a través de Internet. Es una de las formas más económicas de comunicarse en cualquier momento y en cualquier lugar con la disponibilidad de Internet.
Algunas ventajas de VOIP incluyen:
- Bajo costo
- Portability
- Sin cables adicionales
- Flexibility
- Videoconferencia
Para una llamada VOIP, todo lo que necesita es una computadora / laptop / móvil con conectividad a Internet. La siguiente figura muestra cómo se realiza una llamada VoIP.

Con todo esto fundamental, volvamos a SIP.

SIP: descripción general

A continuación se presentan algunos puntos a tener en cuenta sobre SIP:

SIP es un protocolo de señalización que se utiliza para crear, modificar y finalizar una sesión multimedia a través del Protocolo de Internet. Una sesión no es más que una simple llamada entre dos puntos finales. Un punto final puede ser un teléfono inteligente, una computadora portátil o cualquier dispositivo que pueda recibir y enviar contenido multimedia a través de Internet.
SIP es un protocolo de capa de aplicación definido por el estándar IETF (Internet Engineering Task Force). Se define enRFC 3261.
SIP incorpora la arquitectura cliente-servidor y el uso de URL y URI desde HTTP y un esquema de codificación de texto y un estilo de encabezado de SMTP.
SIP toma la ayuda de SDP (Protocolo de descripción de sesión) que describe una sesión y RTP (Protocolo de transporte en tiempo real) que se utiliza para transmitir voz y video a través de una red IP.
SIP se puede utilizar para sesiones de dos partes (unidifusión) o de varias partes (multidifusión).
Otras aplicaciones SIP incluyen transferencia de archivos, mensajería instantánea, videoconferencia, juegos en línea y distribución de multimedia al vapor.

¿Dónde encaja SIP?

Básicamente, SIP es un protocolo de capa de aplicación. Es un protocolo de señalización de red simple para crear y finalizar sesiones con uno o más participantes. El protocolo SIP está diseñado para ser independiente del protocolo de transporte subyacente, por lo que las aplicaciones SIP pueden ejecutarse en TCP, UDP u otros protocolos de red de capa inferior.

La siguiente ilustración muestra dónde encaja SIP en el esquema general de las cosas:

Normalmente, el protocolo SIP se utiliza para telefonía por Internet y distribución multimedia entre dos o más puntos finales. Por ejemplo, una persona puede iniciar una llamada telefónica a otra persona usando SIP, o alguien puede crear una llamada de conferencia con muchos participantes.

El protocolo SIP fue diseñado para ser muy simple, con un conjunto limitado de comandos. También está basado en texto, por lo que cualquiera puede leer un mensaje SIP pasado entre los puntos finales en una sesión SIP.

Hay algunas entidades que ayudan a SIP a crear su red. En SIP, cada elemento de red se identifica mediante unSIP URI(Identificador uniforme de recursos) que es como una dirección. Los siguientes son los elementos de la red:

Agente de usuario
Servidor proxy
Servidor de registro
Servidor de redireccionamiento
Servidor de ubicación

Agente de usuario

Es el punto final y uno de los elementos de red más importantes de una red SIP. Un punto final puede iniciar, modificar o terminar una sesión. Los agentes de usuario son el dispositivo o elemento de red más inteligente de una red SIP. Podría ser un softphone, un móvil o una computadora portátil.

Los agentes de usuario se dividen lógicamente en dos partes:

User Agent Client (UAC) - La entidad que envía una solicitud y recibe una respuesta.
User Agent Server (UAS) - La entidad que recibe una solicitud y envía una respuesta.

SIP se basa en una arquitectura cliente-servidor donde el teléfono de la persona que llama actúa como un cliente que inicia una llamada y el teléfono de la persona que llama actúa como un servidor que responde la llamada.

Servidor proxy

Es el elemento de red que toma una solicitud de un agente de usuario y la reenvía a otro usuario.

Básicamente, la función de un servidor proxy es muy similar a la de un enrutador.
Tiene algo de inteligencia para comprender una solicitud SIP y enviarla con la ayuda de URI.
Un servidor proxy se encuentra entre dos agentes de usuario.
Puede haber un máximo de 70 servidores proxy entre un origen y un destino.

Hay dos tipos de servidores proxy:

Stateless Proxy Server- Simplemente reenvía el mensaje recibido. Este tipo de servidor no almacena ninguna información de una llamada o una transacción.
Stateful Proxy Server- Este tipo de servidor proxy realiza un seguimiento de cada solicitud y respuesta recibida y puede usarlo en el futuro si es necesario. Puede retransmitir la solicitud, si no hay respuesta del otro lado a tiempo.

Servidor de registro

El servidor de registro acepta solicitudes de registro de agentes de usuario. Ayuda a los usuarios a autenticarse dentro de la red. Almacena el URI y la ubicación de los usuarios en una base de datos para ayudar a otros servidores SIP dentro del mismo dominio.

Eche un vistazo al siguiente ejemplo que muestra el proceso de un registro SIP.

Aquí la persona que llama quiere registrarse con el dominio TMC. Entonces envía una solicitud de REGISTRO al servidor de registro de TMC y el servidor devuelve una respuesta 200 OK cuando autorizó al cliente.

Servidor de redireccionamiento

El servidor de redireccionamiento recibe solicitudes y busca el destinatario previsto de la solicitud en la base de datos de ubicación creada por el registrador.

El servidor de redireccionamiento utiliza la base de datos para obtener información de ubicación y responde con 3xx (respuesta de redireccionamiento) al usuario. Discutiremos los códigos de respuesta más adelante en este tutorial.

Servidor de ubicación

El servidor de ubicación proporciona información sobre las posibles ubicaciones de la persona que llama a los servidores proxy y de redireccionamiento.

Solo un servidor proxy o un servidor de redireccionamiento puede contactar con un servidor de ubicación.

La siguiente figura muestra las funciones que desempeña cada uno de los elementos de la red al establecer una sesión.

SIP - Arquitectura del sistema

SIP está estructurado como un protocolo en capas, lo que significa que su comportamiento se describe en términos de un conjunto de etapas de procesamiento bastante independientes con solo un acoplamiento flexible entre cada etapa.

La capa más baja de SIP es su syntax and encoding. Su codificación se especifica mediante un aumentoBackus-Naur Form grammar (BNF).
En el segundo nivel está el transport layer. Define cómo un cliente envía solicitudes y recibe respuestas y cómo un servidor recibe solicitudes y envía respuestas a través de la red. Todos los elementos SIP contienen una capa de transporte.
Luego viene el transaction layer. Una transacción es una solicitud enviada por una transacción del Cliente (utilizando la capa de transporte) a una transacción del Servidor, junto con todas las respuestas a esa solicitud enviadas desde la transacción del servidor al cliente. Cualquier tarea que realice un cliente de agente de usuario (UAC) se lleva a cabo mediante una serie de transacciones.Stateless proxies no contienen una capa de transacción.
La capa sobre el transaction layerse llama usuario de la transacción. Cada una de las entidades SIP, excepto laStateless proxies, es un usuario de transacciones.

La siguiente imagen muestra el flujo de llamadas básico de una sesión SIP.

A continuación se muestra una explicación paso a paso del flujo de llamadas anterior:

Una solicitud INVITE que se envía a un servidor proxy es responsable de iniciar una sesión.
El servidor proxy envía 100 Trying responder inmediatamente a la persona que llama (Alice) para detener las retransmisiones de la solicitud INVITE.
El servidor proxy busca la dirección de Bob en el servidor de ubicación. Después de obtener la dirección, reenvía la solicitud INVITE más.
Después de eso, 180 Ringing (Respuestas provisionales) generadas por Bob se devuelven a Alice.
UN 200 OK La respuesta se genera poco después de que Bob contesta el teléfono.
Bob recibe un ACK de Alice, una vez que se 200 OK.
Al mismo tiempo, la sesión se establece y los paquetes RTP (conversaciones) comienzan a fluir desde ambos extremos.
Después de la conversación, cualquier participante (Alice o Bob) puede enviar un BYE solicitud para terminar la sesión.
BYE llega directamente de Alice a Bob sin pasar por el servidor proxy.
Finalmente, Bob envía un 200 OK respuesta para confirmar el BYE y la sesión finaliza.
En el flujo de llamadas básico anterior, tres transactions están (marcados como 1, 2, 3) disponibles.

La llamada completa (de INVITE a 200 OK) se conoce como Dialog.

Trapezoide SIP

¿Cómo ayuda un proxy a conectar un usuario con otro? Averigüemos con la ayuda del siguiente diagrama.

La topología que se muestra en el diagrama se conoce como trapezoide SIP. El proceso se lleva a cabo de la siguiente manera:

Cuando una persona que llama inicia una llamada, se envía un mensaje INVITE al servidor proxy. Al recibir la INVITACIÓN, el servidor proxy intenta resolver la dirección del destinatario con la ayuda del servidor DNS.
Después de obtener la siguiente ruta, el servidor proxy de la persona que llama (Proxy 1, también conocido como servidor proxy saliente) reenvía la solicitud INVITE al servidor proxy del destinatario que actúa como un servidor proxy entrante (Proxy 2) para el destinatario.
El servidor proxy entrante se pone en contacto con el servidor de ubicación para obtener información sobre la dirección de la persona que llama donde se registró el usuario.
Después de obtener información del servidor de ubicación, reenvía la llamada a su destino.
Una vez que los agentes de usuario conocen su dirección, pueden omitir la llamada, es decir, las conversaciones pasan directamente.

Los mensajes SIP son de dos tipos: requests y responses.

La línea de apertura de una solicitud contiene un método que define la solicitud y un Request-URI que define dónde se enviará la solicitud.
De manera similar, la línea de apertura de una respuesta contiene un código de respuesta.

Métodos de solicitud

SIP requestsson los códigos que se utilizan para establecer una comunicación. Para complementarlos, haySIP responses que generalmente indican si una solicitud tuvo éxito o no.

Estas solicitudes SIP que se conocen como MÉTODOS hacen que el mensaje SIP sea viable.

Los MÉTODOS pueden considerarse solicitudes SIP, ya que solicitan que otro agente usuario o servidor realice una acción específica.
Los MÉTODOS se distinguen en dos tipos:
- Métodos básicos
- Métodos de extensión

Métodos básicos

Hay seis métodos básicos que se describen a continuación.

INVITACIÓN

INVITE se utiliza para iniciar una sesión con un agente de usuario. En otras palabras, se utiliza un método INVITE para establecer una sesión de medios entre los agentes de usuario.

INVITE puede contener la información multimedia de la persona que llama en el cuerpo del mensaje.
Una sesión se considera establecida si un INVITADO ha recibido una respuesta exitosa (2xx) o se ha enviado un ACK.

Una solicitud INVITE exitosa establece un dialog entre los dos agentes de usuario que continúa hasta que se envía un BYE para terminar la sesión.
Una INVITACIÓN enviada dentro de un diálogo establecido se conoce como re-INVITE.
Re-INVITE se utiliza para cambiar las características de la sesión o actualizar el estado de un diálogo.

INVITAR Ejemplo

El siguiente código muestra cómo se usa INVITE.

INVITE sips:[email protected] SIP/2.0 
   Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9 
   Max-Forwards: 70 
   From: Alice<sips:[email protected]>;tag = 1234567 
   To: Bob<sips:[email protected]>
   Call-ID: [email protected]  
   CSeq: 1 INVITE 
   Contact: <sips:[email protected]> 
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
   Supported: replaces 
   Content-Type: application/sdp 
   Content-Length: ...  

   v = 0 
   o = Alice 2890844526 2890844526 IN IP4 client.ANC.com 
   s = Session SDP 
   c = IN IP4 client.ANC.com 
   t = 3034423619 0 
   m = audio 49170 RTP/AVP 0 
   a = rtpmap:0 PCMU/8000

ADIÓS

BYE es el método utilizado para terminar una sesión establecida. Esta es una solicitud SIP que puede enviar la persona que llama o el destinatario de la llamada para finalizar una sesión.

No puede ser enviado por un servidor proxy.
La solicitud BYE normalmente se enruta de un extremo a otro, sin pasar por el servidor proxy.
No se puede enviar BYE a un INVITE pendiente o una sesión no establecida.

REGISTRARSE

La solicitud de REGISTRO realiza el registro de un agente de usuario. Esta solicitud la envía un agente de usuario a un servidor de registro.

La solicitud de REGISTRO se puede reenviar o transferir hasta que llegue a un registrador autorizado del dominio especificado.
Lleva el AOR (Dirección de registro) en el To encabezado del usuario que se está registrando.
La solicitud de REGISTRO contiene el período de tiempo (3600 segundos).
Un agente de usuario puede enviar una solicitud de REGISTRO en nombre de otro agente de usuario. Esto se conoce comothird-party registration. Aquí elFrom La etiqueta contiene el URI de la parte que envía el registro en nombre de la parte identificada en el To encabezamiento.

CANCELAR

CANCELAR se utiliza para terminar una sesión que no está establecida. Los agentes de usuario utilizan esta solicitud para cancelar un intento de llamada pendiente iniciado anteriormente.

Puede ser enviado por un agente de usuario o un servidor proxy.
CANCELAR es un hop by hop solicitud, es decir, atraviesa los elementos entre el agente de usuario y recibe la respuesta generada por el siguiente elemento con estado.

ACK

ACK se utiliza para reconocer las respuestas finales a un método INVITE. Un ACK siempre va en la dirección de INVITE.ACK puede contener SDP body (características de los medios), si no está disponible en INVITE.

ACK no se puede utilizar para modificar la descripción de medios que ya se envió en el INVITE inicial.

Un proxy con estado que recibe un ACK debe determinar si el ACK debe reenviarse en sentido descendente a otro proxy o agente de usuario.
Para las respuestas 2xx, ACK es de extremo a extremo, pero para todas las demás respuestas finales, funciona salto a salto cuando se trata de proxies con estado.

OPCIONES

El método OPTIONS se utiliza para consultar a un agente de usuario o un servidor proxy sobre sus capacidades y descubrir su disponibilidad actual. La respuesta a una solicitud enumera las capacidades del agente de usuario o del servidor. Un proxy nunca genera una solicitud de OPCIONES.

Métodos de extensión

Contiene un Expires campo de encabezado que indica la duración de una suscripción.
Una vez transcurrido el período de tiempo, la suscripción finalizará automáticamente.
La suscripción establece un diálogo entre los agentes de usuario.
Puede volver a suscribirse enviando otro SUBSCRIBE dentro del cuadro de diálogo antes de la fecha de vencimiento.
Se recibirá un 200 OK para una suscripción del Usuario.
Los usuarios pueden darse de baja enviando otro método SUBSCRIBE con un valor de Caducidad 0 (cero).

NOTIFICAR

Los agentes de usuario utilizan NOTIFICAR para obtener la ocurrencia de un evento en particular. Por lo general, se activará una NOTIFICACIÓN dentro de un cuadro de diálogo cuando exista una suscripción entre el suscriptor y el notificador.

Cada NOTIFICACIÓN obtendrá una respuesta 200 OK si es recibida por el notificador.
NOTIFICAR contiene un Event campo de encabezado que indica el evento y un subscriptionstate campo de encabezado que indica el estado actual de la suscripción.
Siempre se envía una NOTIFICACIÓN al inicio y finalización de una suscripción.

PUBLICAR

PUBLISH es utilizado por un agente de usuario para enviar información sobre el estado del evento a un servidor.

PUBLICAR es sobre todo útil cuando hay múltiples fuentes de información de eventos.
Una solicitud PUBLICAR es similar a una NOTIFICACIÓN, excepto que no se envía en un diálogo.
Una solicitud PUBLICAR debe contener una Expires campo de encabezado y un Min-Expires campo de encabezado.

REFERIR

REFER es utilizado por un agente de usuario para referir a otro agente de usuario a acceder a un URI para el diálogo.

REFER debe contener un Refer-Toencabezamiento. Este es un encabezado obligatorio para REFER.
REFER puede enviarse dentro o fuera de un diálogo.
UN 202 Accepted activará una solicitud de REFERENCIA que indica que otro agente de usuario ha aceptado la referencia.

INFO

Un agente de usuario utiliza INFO para enviar información de señalización de llamadas a otro agente de usuario con el que ha establecido una sesión de medios.

Esta es una solicitud de un extremo a otro.
Un proxy siempre reenviará una solicitud INFO.

ACTUALIZAR

ACTUALIZAR se utiliza para modificar el estado de una sesión si no se establece una sesión. El usuario puede cambiar el códec con ACTUALIZAR.

SI se establece una sesión, se utiliza una nueva invitación para cambiar / actualizar la sesión.

PRACK

PRACK se utiliza para acusar recibo de una transferencia confiable de respuesta provisional (1XX).

Generalmente PRACK es generado por un cliente cuando recibe una respuesta provisional que contiene un RSeq número de secuencia confiable y un supported:100rel encabezamiento.
PRACK contiene el valor (RSeq + CSeq) en el rack encabezamiento.
El método PRACK se aplica a todas las respuestas provisionales excepto a la respuesta 100 Trying, que nunca se transporta de manera confiable.
Un PRACK puede contener un cuerpo de mensaje; se puede utilizar para el intercambio de ofertas y respuestas.

MENSAJE

Se utiliza para enviar un mensaje instantáneo mediante SIP. Un mensaje instantáneo generalmente consiste en mensajes cortos intercambiados en tiempo real por participantes que participan en una conversación de texto.

El MENSAJE se puede enviar dentro de un diálogo o fuera de un diálogo.
El contenido de un MENSAJE se incluye en el cuerpo del mensaje como MIME adjunto archivo.
UN 200 OK Normalmente se recibe una respuesta para indicar que el mensaje se ha entregado en su destino.

Una respuesta SIP es un mensaje generado por un servidor de agente de usuario (UAS) o un servidor SIP para responder a una solicitud generada por un cliente. Podría ser un reconocimiento formal para evitar la retransmisión de solicitudes por parte de un UAC.

Una respuesta puede contener algunos campos de encabezado adicionales de información necesarios para un UAC.
SIP tiene seis respuestas.
1xx a 5xx se ha tomado prestado de HTTP y 6xx se introduce en SIP.
1xx se considera un provisional respuesta y el resto son final respuestas.

S.No.	Función descriptiva
1	1xx: Respuestas provisionales / informativas Las respuestas informativas se utilizan para indicar call progress. Normalmente, las respuestas son de un extremo a otro (excepto 100 intentos).
2	2xx: Respuestas de éxito Esta clase de respuestas está destinada a indicar que se ha aceptado una solicitud.
3	3xx: Redirigir respuestas Generalmente estas respuestas de clase son enviadas por servidores de redireccionamiento en respuesta a INVITE. También se conocen como respuestas de clase de redireccionamiento.
4	4xx: Respuestas a fallas del cliente Las respuestas de error del cliente indican que la solicitud no se puede cumplir ya que algunos errores se identifican desde el lado de UAC.
5	5xx: Respuesta ante fallos del servidor Esta respuesta de clase se utiliza para indicar que la solicitud no se puede procesar debido a un error con el servidor.
6	6xx: Respuesta de falla global Esta clase de respuesta indica que el servidor sabe que la solicitud fallará siempre que se intente. Como resultado, la solicitud no debe enviarse a otras ubicaciones.

Un encabezado es un componente de un mensaje SIP que transmite información sobre el mensaje. Está estructurado como una secuencia de campos de encabezado.

Los campos de encabezado SIP en la mayoría de los casos siguen las mismas reglas que los campos de encabezado HTTP. Los campos de encabezado se definen comoHeader: field, donde Encabezado se usa para representar el nombre del campo del encabezado y campo es el conjunto de tokens que contiene la información. Cada campo consta de un nombre de campo seguido de dos puntos (":") y el valor del campo (es decir,field-name: field-value).

Encabezados SIP - Forma compacta

Muchos campos de encabezado SIP comunes tienen una forma compacta donde el nombre del campo del encabezado se indica con un solo carácter en minúscula. A continuación se dan algunos ejemplos:

Encabezamiento	Forma compacta
A	T
Vía	V
Identificador de llamadas	yo
Contacto	METRO
Desde	F
Tema	S
Largancia de contenido	yo

Formato de encabezado SIP

La siguiente imagen muestra la estructura de un encabezado SIP típico.

Los encabezados se clasifican de la siguiente manera según su uso en SIP:

Solicitud y respuesta
Solicitar solo
Solo respuesta
Cuerpo del mensaje

SDP significa Protocolo de descripción de sesión. Se utiliza para describir sesiones multimedia en un formato comprendido por los participantes a través de una red. Dependiendo de esta descripción, una parte decide si unirse a una conferencia o cuándo o cómo unirse a una conferencia.

El propietario de una conferencia la anuncia a través de la red enviando mensajes de multidifusión que contienen una descripción de la sesión, por ejemplo, el nombre del propietario, el nombre de la sesión, la codificación, el tiempo, etc. Dependiendo de esta información, los destinatarios del anuncio tomar una decisión sobre la participación en la sesión.
El SDP generalmente está contenido en la parte del cuerpo del Protocolo de inicio de sesión, popularmente llamado SIP.
SDP se define en RFC 2327. Un mensaje SDP se compone de una serie de líneas, denominadas campos, cuyos nombres se abrevian con una sola letra minúscula y están en el orden requerido para simplificar el análisis.

Propósito de SDP

El propósito de SDP es transmitir información sobre flujos de medios en sesiones multimedia para ayudar a los participantes a unirse o recopilar información de una sesión en particular.

SDP es una breve descripción textual estructurada.
Transmite el nombre y el propósito de la sesión, los medios, los protocolos, los formatos de códec, la sincronización y la información de transporte.
Un participante tentativo verifica esta información y decide si unirse a una sesión y cómo y cuándo unirse a una sesión si así lo decide.
El formato tiene entradas en la forma de <type> = <value>, donde <type> define un parámetro de sesión único y <value> proporciona un valor específico para ese parámetro.
La forma general de un mensaje SDP es:

x = parameter1 parameter2 ... parameterN
La línea comienza con una sola letra minúscula, por ejemplo, x. Nunca hay espacios entre la letra y el =, y hay exactamente un espacio entre cada parámetro. Cada campo tiene un número definido de parámetros.

Parámetros de descripción de sesión

Descripción de la sesión (* indica opcional)

v = (versión del protocolo)
o = (propietario / creador e identificador de sesión)
s = (nombre de la sesión)
i = * (información de la sesión)
u = * (URI de descripción)
e = * (dirección de correo electrónico)
p = * (número de teléfono)
c = * (información de conexión; no se requiere si se incluye en todos los medios)
b = * (información de ancho de banda)
z = * (ajustes de zona horaria)
k = * (clave de cifrado)
a = * (cero o más líneas de atributos de sesión)

Versión de protocolo

El campo v = contiene el número de versión de SDP. Debido a que la versión actual de SDP es 0, un mensaje SDP válido siempre comenzará con v = 0.

Origen

El campo o = contiene información sobre el creador de la sesión y los identificadores de sesión. Este campo se utiliza para identificar de forma única la sesión.

El campo contiene:

o = <nombre de usuario> <ID de sesión> <versión> <tipo de red> <tipo de dirección>
los username El parámetro contiene el inicio de sesión o el host del creador.
los session-id El parámetro es una marca de tiempo del Protocolo de tiempo de red (NTP) o un número aleatorio que se utiliza para garantizar la exclusividad.
los version es un campo numérico que se incrementa con cada cambio en la sesión, también se recomienda que sea una marca de tiempo NTP.
los network-typesiempre está IN para Internet. El parámetro de tipo de dirección es IP4 o IP6 para la dirección IPv4 o IPv6, ya sea en forma decimal con puntos o un nombre de host completo.

Nombre e información de la sesión

El campo s = contiene un nombre para la sesión. Puede contener cualquier número de caracteres distinto de cero. El campo opcional i = contiene información sobre la sesión. Puede contener cualquier número de caracteres.

URI

El campo u = opcional contiene un indicador de recursos uniforme (URI) con más información sobre la sesión.

Dirección de correo electrónico y número de teléfono

El campo opcional e = contiene una dirección de correo electrónico del anfitrión de la sesión. El campo opcional p = contiene un número de teléfono.

Datos de conexión

El campo c = contiene información sobre la conexión de medios.

El campo contiene:

c = <tipo de red> <tipo de dirección> <dirección de conexión>
los network-type El parámetro se define como IN para Internet.
los address-type se define como IP4 para direcciones IPv4 e IP6 para direcciones IPv6.
los connection-address es la dirección IP o el host que enviará los paquetes de medios, que pueden ser multicast o unicast.
Si es multidifusión, el campo de dirección de conexión contiene:

dirección-conexión = dirección-base-multicast / ttl / numero-de-direcciones

dónde ttl es el valor del tiempo de vida y el número de direcciones indica cuántas direcciones de multidifusión contiguas se incluyen comenzando con la dirección de multidifusión base.

Banda ancha

El campo b = opcional contiene información sobre el ancho de banda requerido. Es de la forma -

b = modificador: ancho de banda - valor

Hora, tiempos de repetición y zonas horarias

El campo t = contiene la hora de inicio y la hora de finalización de la sesión.

t = hora de inicio hora de parada

El campo opcional r = contiene información sobre los tiempos de repetición que se pueden especificar en NTP o en días ( d ), horas ( h ) o minutos ( m ).

El campo opcional z = contiene información sobre los desplazamientos de zona horaria. Este campo se utiliza si la sesión que tiene lugar abarca un cambio del horario de verano al horario estándar o viceversa.

Anuncios de medios

El campo opcional m = contiene información sobre el tipo de sesión de medios. El campo contiene:

m = lista de formatos de transporte de puerto de medios

El parámetro de medios es audio, video, texto, aplicación, mensaje, imagen o control. El parámetro de puerto contiene el número de puerto.
El parámetro de transporte contiene el protocolo de transporte o el perfil RTP utilizado.
La lista de formatos contiene más información sobre los medios. Por lo general, contiene tipos de carga útil de medios definidos en perfiles de audio y video RTP.

Example:
m = audio 49430 RTP/AVP 0 6 8 99

Uno de estos tres códecs se puede utilizar para la sesión de medios de audio. Si la intención es establecer tres canales de audio, se utilizarían tres campos de medios separados.

Atributos

El campo opcional a = contiene atributos de la sesión de medios anterior. Este campo se puede utilizar paraextend SDP to provide more information about the media. Si un usuario de SDP no lo comprende completamente, el campo de atributo puede ignorarse. Puede haber uno o más campos de atributos para cada tipo de carga útil de medios enumerados en el campo de medios.

Los atributos en SDP pueden ser

nivel de sesión, o
nivel de medios.

El nivel de sesión significa que el atributo aparece antes de la primera línea de medios en el SDP. Si este es el caso, el atributo se aplica a todas las líneas de medios debajo de él.

Nivel de medios significa que aparece después de una línea de medios. En este caso, el atributo solo se aplica a este flujo de medios en particular.

SDP puede incluir atributos de nivel de sesión y de nivel de medios. Si el mismo atributo aparece en ambos, el atributo de nivel de medios anula el atributo de nivel de sesión para ese flujo de medios en particular. Tenga en cuenta que el campo de datos de conexión también puede ser de nivel de sesión o de medio.

Un ejemplo de SDP

A continuación se muestra una descripción de sesión de ejemplo, tomada de RFC 2327 -

v = 0
o = mhandley2890844526 2890842807 IN IP4 126.16.64.4
s = SDP Seminar
i = A Seminar on the session description protocol
u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e = [email protected](Mark Handley)
c = IN IP4 224.2.17.12/127
t = 2873397496 2873404696
a = recvonly
m = audio 49170 RTP/AVP 0
m = video 51372 RTP/AVP 31
m = application 32416udp wb
a = orient:portrait

El uso de SDP con SIP se indica en la respuesta de oferta de SDP RFC 3264. El tipo de cuerpo del mensaje predeterminado en SIP es application/sdp.

La parte que llama enumera las capacidades de los medios que están dispuestos a recibir en SDP, generalmente en un INVITE o en un ACK.
La parte llamada enumera sus capacidades de medios en la respuesta 200 OK al INVITE.

Un uso típico de SIP de SDP incluye los siguientes campos: versión, origen, asunto, hora, conexión y uno o más medios y atributos.

SIP no utiliza los campos de asunto y hora, pero se incluyen por motivos de compatibilidad.
En el estándar SDP, el campo de asunto es un campo obligatorio y debe contener al menos un carácter, sugerido como s = - si no hay asunto.
El campo de tiempo generalmente se establece en t = 00. SIP usa los campos de conexión, medios y atributos para configurar sesiones entre UA.
El campo de origen tiene un uso limitado con SIP.
El ID de sesión generalmente se mantiene constante durante una sesión SIP.
La versión se incrementa cada vez que se cambia el SDP. Si el SDP que se envía no cambia del enviado anteriormente, la versión se mantiene igual.
Como el tipo de sesión de medios y el códec que se utilizará son parte de la negociación de la conexión, SIP puede usar SDP para especificar múltiples tipos de medios alternativos y para aceptar o rechazar selectivamente esos tipos de medios.

La especificación de oferta / respuesta, RFC 3264, recomienda que se utilice un atributo que contenga a = rtpmap: para cada campo de medios. Un flujo de medios se rechaza estableciendo el número de puerto en cero para el campo de medios correspondiente en la respuesta SDP.

Ejemplo

En el siguiente ejemplo, la persona que llama Tesla quiere configurar una llamada de audio y video con dos posibles códecs de audio y un códec de video en el SDP llevado en el INVITE inicial -

v = 0 
o = John 0844526 2890844526 IN IP4 172.22.1.102  
s = - 
c = IN IP4 172.22.1.102 
t = 0 0 
m = audio 6000 RTP/AVP 97 98 
a = rtpmap:97 AMR/16000/1 
a = rtpmap:98 AMR-WB/8000/1 
m = video 49172 RTP/AVP 32 
a = rtpmap:32 MPV/90000

Los códecs están referenciados por los números de perfil 97, 98 de RTP / AVP.

La parte llamada Marry responde a la llamada, elige el segundo códec para el primer campo de medios y rechaza el segundo campo de medios, solo desea una sesión de AMR.

v = 0 
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s = - 
c = IN IP4 200.201.202.203 
t = 0 0 
m = audio 60000 RTP/AVP 8 
a = rtpmap:97 AMR/16000 
m = video 0 RTP/AVP 32

Si esta llamada de solo audio no es aceptable, Tom enviaría un ACK y luego un BYE para cancelar la llamada. De lo contrario, se establecería la sesión de audio y se intercambiarían paquetes RTP.

Como ilustra este ejemplo, a menos que se mantenga el número y el orden de los campos de medios, la parte que llama no sabría con certeza qué sesiones de medios estaban siendo aceptadas y rechazadas por la parte llamada.

Las reglas de oferta / respuesta se resumen en las siguientes secciones.

Reglas para generar una oferta

Una oferta de SDP debe incluir todos los campos de SDP obligatorios (esto incluye v =, o =, s =, c = y t =). Estos son campos obligatorios en SDP.

Por lo general, incluye un campo de medios ( m = ), pero no es necesario. Las líneas de medios contienen todos los códecs enumerados en orden de preferencia. La única excepción a esto es que si el punto final admite una gran cantidad de códecs, se debe enumerar el que tiene más probabilidades de ser aceptado o el más preferido. Los diferentes tipos de medios incluyen audio, video, texto, MSRP, BFCP, etc.

Reglas para generar una respuesta

Una respuesta de SDP a una oferta debe construirse de acuerdo con las siguientes reglas:

La respuesta debe tener el mismo número de m = líneas en el mismo orden que la respuesta.
Las transmisiones de medios individuales se pueden rechazar configurando el número de puerto en 0.
Las transmisiones se aceptan enviando un número de puerto distinto de cero.
Las cargas útiles enumeradas para cada tipo de medio deben ser un subconjunto de las cargas útiles enumeradas en la oferta.
Para cargas útiles dinámicas, no es necesario utilizar el mismo número de carga útil dinámica en cada dirección. Por lo general, solo se selecciona una única carga útil.

Reglas para modificar una sesión

Cualquiera de las partes puede iniciar otro intercambio de oferta / respuesta para modificar una sesión. Cuando se modifica una sesión, se deben seguir las siguientes reglas:

El número de versión de la línea de origen ( o = ) debe ser el mismo que el último enviado, lo que indica que este SDP es idéntico al intercambio anterior, o puede incrementarse en uno, lo que indica un nuevo SDP que debe analizarse.
La oferta debe incluir todas las líneas de medios existentes y deben enviarse en el mismo orden.
Se pueden agregar transmisiones de medios adicionales al final de la lista de líneas m = .
Se puede eliminar un flujo de medios existente estableciendo el número de puerto en 0. Esta línea de medios debe permanecer en el SDP y en todos los intercambios de ofertas / respuestas futuras para esta sesión.

Llamada en espera

Un participante en una llamada puede poner temporalmente al otro en espera. Esto se hace enviando un INVITE con un SDP idéntico al del INVITE original pero cona = sendonly atributo presente.

La llamada se activa de nuevo enviando otro INVITE con el a = sendrecvatributo presente. La siguiente ilustración muestra el flujo de llamadas de una llamada en espera.

Personal mobilityes la capacidad de tener un identificador constante en varios dispositivos. SIP admite la movilidad personal básica mediante el método REGISTRO, que permite que un dispositivo móvil cambie su dirección IP y el punto de conexión a Internet y aún pueda recibir llamadas entrantes.

SIP también puede admitir service mobility - la capacidad de un usuario de mantener los mismos servicios cuando es móvil

Movilidad SIP durante el traspaso (pre-llamada)

Un dispositivo vincula su URI de contacto con la dirección de registro mediante un simple registro sip. Según la dirección IP del dispositivo, el registro autoriza que esta información se actualice automáticamente en la red sip.

Durante el traspaso, el agente de usuario se enruta entre diferentes operadores, donde tiene que registrarse nuevamente con un contacto como un AOR con otro proveedor de servicios.

Por ejemplo, tomemos el ejemplo del siguiente flujo de llamadas. UA que ha recibido temporalmente un nuevo SIP URI con un nuevo proveedor de servicios. A continuación, la UA realiza un doble registro:

El primer registro es con el nuevo operador de servicios, que vincula el URI de contacto del dispositivo con el AOR URI del nuevo proveedor de servicios.
La segunda solicitud de REGISTRO se reenvía al proveedor de servicios original y proporciona el AOR del nuevo proveedor de servicios como el URI de contacto.

Como se muestra más adelante en el flujo de llamadas, cuando llega una solicitud a la red del proveedor de servicios original, la INVITACIÓN se redirige al nuevo proveedor de servicios que luego enruta la llamada al usuario.

Para el primer registro, el mensaje que contiene el URI del dispositivo sería:

REGISTER sip:visited.registrar1.com SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 72d65a24 
Call-ID: [email protected] 
CSeq: 1 REGISTER 
Contact: <sip:[email protected]:5060> 
Expires: 600000 
Content-Length: 0

El segundo mensaje de registro con el URI de itinerancia sería:

REGISTER sip:home.registrar2.in SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 45375 
Call-ID:[email protected] 
CSeq: 6421 REGISTER 
Contact: <sip:[email protected]> 
Content-Length: 0

El primer INVITE que se representa en la figura anterior se enviaría a sip: registrar2.in; el segundo INVITE se enviaría a sip: sip: [email protected], que se enviaría asip:[email protected]. Llega a Tom y permite que se establezca la sesión. Periódicamente, ambos registros deberían actualizarse.

Movilidad durante una llamada (volver a invitar)

El agente de usuario puede cambiar su dirección IP durante la sesión al cambiar de una red a otra. El SIP básico admite este escenario, ya que un re-INVITE en un cuadro de diálogo se puede utilizar para actualizar el URI de contacto y cambiar la información de medios en el SDP.

Eche un vistazo al flujo de llamadas mencionado en la figura siguiente.

Aquí, Tom detecta una nueva red,
Utiliza DHCP para adquirir una nueva dirección IP y
Realiza un re-INVITE para permitir que la señalización y el flujo de medios a la nueva dirección IP.

Si la UA puede recibir medios de ambas redes, la interrupción es insignificante. Si este no es el caso, es posible que se pierdan algunos paquetes de medios, lo que provocará una ligera interrupción de la llamada.

El re-INVITE aparecería de la siguiente manera:

INVITE sip:[email protected] SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:[email protected]> 

From: sip:[email protected];tag = 70133df4 
Call-ID: 76d4861c19c 
CSeq: 1 INVITE 
Accept: application/sdp 
Accept-Language: en 

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE 
Contact: <sip:172.22.1.102:5060>; 
Content-Type: application/sdp 
Content-Length: 168 

v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1 
s = - 
c = IN IP4 192.168.2.1 
b = AS:49 
t = 0 0 
b = RR:0 
b = RS:0 
a = rtpmap:97 AMR/8000/1 
m = audio 6000 RTP/AVP 96 
a = fmtp:102 0-15 
a = ptime:20 
a = maxptime:240

El re-INVITE contiene la nueva dirección IP de Bowditch en los campos de encabezado Vía y Contacto e información de medios SDP.

Movilidad en Midcall (con reemplazo de encabezado)

En la movilidad de midcall, el conjunto de rutas real (conjunto de proxies SIP que deben atravesar los mensajes SIP) debe cambiar. No podemos usar un re-INVITE en movilidad a mitad de llamada

Por ejemplo, si se necesita un proxy para el cruce de NAT, entonces se debe cambiar el URI de contacto; se debe crear un nuevo cuadro de diálogo. Por lo tanto, tiene que enviar un nuevo INVITE con un encabezado Reemplaza, que identifica la sesión existente.

Note - Supongamos que A y B están en una llamada y si A obtiene otro INVITE (digamos de C) con un encabezado de reemplazo (debe coincidir con el diálogo existente), entonces A debe aceptar el INVITE y terminar la sesión con B y transferir todos los recursos a diálogo recién formado.

El flujo de llamadas se muestra en la siguiente figura. Es similar al flujo de llamadas anterior que usa re-INVITE, excepto que se genera automáticamente un BYE para terminar el diálogo existente cuando se acepta INVITE with the Replaces.

A continuación se presentan los puntos a tener en cuenta en este escenario:

El diálogo existente entre Tom y Jerry incluye el antiguo servidor proxy visitado.
El nuevo cuadro de diálogo que utiliza la nueva red inalámbrica requiere la inclusión del nuevo servidor proxy visitado.
Como resultado, Tom envía un INVITE with Replaces, que crea un nuevo cuadro de diálogo que incluye el nuevo servidor proxy visitado, pero no el antiguo servidor proxy visitado.
Cuando Jerry acepta la INVITACIÓN, se envía automáticamente un BYE para terminar el diálogo antiguo que se enruta a través del antiguo servidor proxy visitado que ahora ya no está involucrado en la sesión.
La sesión de medios resultante se establece utilizando la nueva dirección IP de Tom del SDP en INVITE.

Movilidad de servicio

Los servicios en SIP se pueden proporcionar en proxies o en UA. Proporcionar movilidad de servicios junto con movilidad personal puede ser un desafío a menos que los dispositivos del usuario estén configurados de manera idéntica con los mismos servicios.

SIP puede admitir fácilmente la movilidad del servicio a través de Internet. Cuando está conectado a Internet, un UA configurado para usar un conjunto de proxies en India aún puede usar esos proxies cuando está en roaming en Europa. No tiene ningún impacto en la calidad de la sesión de medios, ya que los medios siempre fluyen directamente entre los dos UA y no atraviesan los servidores proxy SIP.

Los servicios residentes en el punto final están disponibles solo cuando el punto final está conectado a Internet. Un servicio de terminación, como un servicio de reenvío de llamadas implementado en un punto final, fallará si el punto final ha perdido temporalmente su conexión a Internet. Por lo tanto, algunos servicios se implementan en la red utilizando servidores proxy SIP.

En ocasiones, un servidor proxy reenvía una única llamada SIP a varios puntos finales SIP. Este proceso se conoce como bifurcación. Aquí, una sola llamada puede hacer sonar varios puntos finales al mismo tiempo.

Con la bifurcación SIP, puede hacer que su teléfono de escritorio suene al mismo tiempo que su softphone o un teléfono SIP en su móvil, lo que le permite tomar la llamada desde cualquier dispositivo fácilmente.

Por lo general, en una oficina, suponga que el jefe no puede atender la llamada o no, la bifurcación SIP permite que la secretaria responda las llamadas de su extensión.

La bifurcación será posible si hay un proxy con estado disponible, ya que necesita funcionar y responder de los muchos que recibe.

Tenemos dos tipos de bifurcaciones:

Bifurcación paralela
Bifurcación secuencial

Bifurcación paralela

En este escenario, el servidor proxy bifurcará el INVITE a, digamos, dos dispositivos (UA2, UA3) a la vez. Ambos dispositivos generarán 180 Ringing y quien reciba la llamada generará 200 OK. La respuesta (suponga UA2) que llega primero al Originador establecerá una sesión con UA2. Para la otra respuesta, se activará una CANCELACIÓN.

Si el originador recibe ambas respuestas simultáneamente, entonces, basándose en el valor q, enviará la respuesta.

Bifurcación secuencial

En este escenario, el servidor proxy bifurcará INVITE a un dispositivo (UA2). Si UA2 no está disponible u ocupado en ese momento, entonces el proxy lo bifurcará a otro dispositivo (UA3).

Sucursal: ID y etiqueta

Los ID de sucursal ayudan a los servidores proxy a hacer coincidir las respuestas con las solicitudes bifurcadas. Sin ID de sucursal, un servidor proxy no podría comprender la respuesta bifurcada. Branch-id estará disponible en el encabezado Via.

El UAC utiliza etiquetas para distinguir múltiples respuestas finales de diferentes UAS. Un UAS no puede resolver si la solicitud se ha bifurcado o no. Por lo tanto, debe agregar una etiqueta.

Los proxies también pueden agregar etiquetas si genera una respuesta final, nunca insertan etiquetas en las solicitudes o respuestas que envían.

Es posible que varios servidores proxy también puedan bifurcar una sola solicitud. Por lo tanto, el proxy que se bifurcará agregará sus propios ID únicos a las ramas que creó.

Tramo de llamada e ID de llamada

Un tramo de llamada se refiere a una relación de señalización uno a uno entre dos agentes de usuario. El ID de llamada es un identificador único que se incluye en un mensaje SIP que se refiere a la llamada. Una llamada es una colección de tramos de llamada.

Un UAC comienza enviando una INVITACIÓN. Debido a la bifurcación, puede recibir varios 200 OK de diferentes UA. Cada uno corresponde a un tramo de llamada diferente dentro de la misma llamada.

Por tanto, una llamada es un grupo de tramos de llamada. Un tramo de llamada se refiere a la conexión de extremo a extremo entre UA.

Los espacios CSeq en las dos direcciones de un tramo de llamada son independientes. Dentro de una sola dirección, el número de secuencia se incrementa para cada transacción.

Mensaje de voz

El correo de voz es muy común hoy en día para los usuarios empresariales. Es una aplicación telefónica. Se trata de una imagen cuando el interlocutor llamado no está disponible o no puede recibir la llamada, el PBX le anunciará al interlocutor que deje un mensaje de voz.

El agente de usuario obtendrá una respuesta 3xx o lo redireccionará al servidor de correo de voz si el número de la persona a la que llama no está disponible. Sin embargo, se necesita algún tipo de extensión SIP para indicarle al sistema de correo de voz qué buzón utilizar, es decir, qué saludo reproducir y dónde almacenar el mensaje grabado. Hay dos formas de lograrlo:

Mediante el uso de una extensión de campo de encabezado SIP
Mediante el uso de Request-URI para señalar esta información

Supongamos para el usuario sip:[email protected] tiene un sistema de correo de voz en sip: voicemail.tutorialspoint.com que proporciona correo de voz, el Request-URI de INVITE cuando se reenvía al servidor de correo de voz podría verse así:

sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486

La siguiente ilustración muestra cómo Request-URI lleva el identificador del buzón y el motivo (aquí 486).

Como sabemos, un servidor proxy puede ser sin estado o con estado. Aquí, en este capítulo, discutiremos más sobre servidores proxy y enrutamiento SIP.

Servidor proxy sin estado

Un servidor proxy sin estado simplemente reenvía el mensaje que recibe. Este tipo de servidor no almacena ninguna información de la llamada o transacción.

Los proxies sin estado se olvidan de la solicitud SIP una vez que se ha reenviado.
La transacción será rápida a través de proxies sin estado.

Servidor proxy con estado

Un servidor proxy con estado realiza un seguimiento de cada solicitud y respuesta que recibe. Puede utilizar la información almacenada en el futuro, si es necesario. Puede retransmitir la solicitud si no recibe una respuesta del otro lado.

Los proxies con estado recuerdan la solicitud después de que se haya reenviado, por lo que pueden usarla para el enrutamiento avanzado. Los proxies con estado mantienen el estado de la transacción . La transacción implica el estado de la transacción,notestado de llamada .
La transacción no es tan rápida con proxies con estado como sin estado.
Los proxies con estado pueden bifurcar y retransmitir si es necesario (por ejemplo: desvío de llamadas ocupado, por ejemplo).

Vía y ruta de registro

Ruta de registro

El encabezado Record-Route se inserta en las solicitudes mediante proxies que querían estar en la ruta de solicitudes posteriores para el mismo identificador de llamada. Luego, el agente de usuario lo utiliza para enrutar solicitudes posteriores.

Vía

Los servidores insertan los encabezados de vía en las solicitudes para detectar bucles y ayudar a las respuestas a encontrar el camino de regreso al cliente. Esto es útil para que solo las respuestas lleguen a su destino.

El propio UA genera y agrega su propia dirección en un campo de encabezado Via mientras envía la solicitud.
Un proxy que reenvía la solicitud agrega un campo de encabezado Vía que contiene su propia dirección al principio de la lista de campos de encabezado Vía.
Un proxy o UA que genera una respuesta a una solicitud copia todos los campos del encabezado Via de la solicitud en orden en la respuesta, luego envía la respuesta a la dirección especificada en el campo superior del encabezado Via.
Un proxy que recibe una respuesta comprueba el campo de encabezado Via superior y coincide con su propia dirección. Si no coincide, la respuesta se ha descartado.
A continuación, se elimina el campo de encabezado Via superior y la respuesta se reenvía a la dirección especificada en el siguiente campo de encabezado Via.

Los campos de encabezado Vía contienen el nombre del protocolo, el número de versión y el transporte (SIP / 2.0 / UDP, SIP / 2.0 / TCP, etc.) y contienen números de puerto y parámetros como recibido, rport, rama.

Una etiqueta recibida se agrega a un campo de encabezado Via si un UA o un proxy recibe la solicitud de una dirección diferente a la especificada en el campo de encabezado Via superior.
Los UA y los proxies agregan un parámetro de rama a los campos de encabezado Via, que se calcula como una función hash del Request-URI, y el To, From, Call-ID y el número CSeq.

SIP (Softphone) y PSTN (teléfono antiguo) son redes diferentes y hablan idiomas diferentes. Así que necesitamos un traductor (aquí Gateway) para comunicarnos entre estas dos redes.

Tomemos un ejemplo para mostrar cómo un teléfono SIP realiza una llamada telefónica a una PSTN a través de una puerta de enlace PSTN.

En este ejemplo, Tom (sip:[email protected]) es un teléfono sip y Jerry usa un número de teléfono global +91401234567.

SIP a PSTN a través de puertas de enlace

La siguiente ilustración muestra un flujo de llamadas desde SIP a PSTN a través de puertas de enlace.

A continuación se incluye una explicación paso a paso de todo el proceso que se lleva a cabo al realizar una llamada desde un teléfono SIP a PSTN.

En primer lugar, el teléfono SIP (Tom) marca el número global +91401234567 para comunicarse con Jerry. El agente de usuario SIP lo entiende como un número global y lo convierte en request-uri usando DNS y activa la solicitud.
El teléfono SIP envía la INVITACIÓN directamente a la puerta de enlace.
La puerta de enlace inicia la llamada a la PSTN seleccionando una troncal SS7 ISUP al siguiente conmutador telefónico de la PSTN.
Los dígitos marcados desde INVITE se asignan al IAM de ISUP. La PSTN devuelve el mensaje de dirección completa de la PU-RDSI (ACM) para indicar que se ha creado la troncal.
El teléfono genera un tono de llamada y pasa al cambio de teléfono. La puerta de enlace asigna el ACM a la respuesta de progreso de sesión 183 que contiene un SDP que indica el puerto RTP que la puerta de enlace utilizará para conectar el audio desde la PSTN.
Tras la recepción del 183, el UAC de la persona que llama comienza a recibir los paquetes RTP enviados desde la puerta de enlace y presenta el audio a la persona que llama para que sepa que la persona que llama progresa en la PSTN.
La llamada se completa cuando la parte llamada contesta el teléfono, lo que hace que el conmutador telefónico envíe un mensaje de respuesta (ANM) a la puerta de enlace.
Luego, la puerta de enlace corta la conexión de audio PSTN en ambas direcciones y envía una respuesta 200 OK a la persona que llama. Como la ruta de medios RTP ya está establecida, la puerta de enlace responde al SDP en el 183 pero no provoca cambios en la conexión RTP.
El UAC envía un ACK para completar el intercambio de señalización SIP. Como no hay un mensaje equivalente en la PU-RDSI, la puerta de enlace absorbe el ACK.
La persona que llama envía BYE a la puerta de enlace para terminar. La puerta de enlace asigna el BYE al mensaje de liberación de la PU-RDSI (REL).
La puerta de enlace envía el 200OK al BYE y recibe un RLC de la PSTN.

Un códec, abreviatura de codificador-decodificador, realiza dos operaciones básicas:

Primero, convierte una señal de voz analógica a su forma digital equivalente para que pueda transmitirse fácilmente.
A partir de entonces, convierte la señal digital comprimida de nuevo a su forma analógica original para que pueda reproducirse.

Hay muchos códecs disponibles en el mercado, algunos son gratuitos mientras que otros requieren licencia. Los códecs varían en la calidad del sonido y varían en ancho de banda en consecuencia.

Los dispositivos de hardware, como teléfonos y puertas de enlace, admiten varios códecs diferentes. Mientras hablan, negocian qué códec utilizarán.

Aquí, en este capítulo, discutiremos algunos códecs de audio SIP populares que se utilizan ampliamente.

G.711

G.711 es un códec introducido por la UIT en 1972 para su uso en telefonía digital. El códec tiene dos variantes:A-Law se utiliza en Europa y en enlaces telefónicos internacionales, uLaw se utiliza en EE. UU. y Japón.

G.711 utiliza una compresión logarítmica. Exprime cada muestra de 16 bits a 8 bits, por lo que logra una relación de compresión de 1: 2.
La tasa de bits es de 64 kbit / s para una dirección, por lo que una llamada consume 128 kbit / s.
G.711 es el mismo códec utilizado por la red PSTN, por lo que proporciona la mejor calidad de voz. Sin embargo, consume más ancho de banda que otros códecs.
Funciona mejor en redes de área local donde tenemos mucho ancho de banda disponible.

G.729

G.729 es un códec con pocos requisitos de ancho de banda; proporciona una buena calidad de audio.

El códec codifica audio en cuadros de 10 ms de longitud. Dada una frecuencia de muestreo de 8 kHz, una trama de 10 ms contiene 80 muestras de audio.
El algoritmo del códec codifica cada trama en 10 bytes, por lo que la tasa de bits resultante es de 8 kbit / s en una dirección.
G.729 es un códec con licencia. Los usuarios finales que deseen utilizar este códec deben comprar un hardware que lo implemente (ya sea un teléfono VoIP o una puerta de enlace).
Una variante de G.729 de uso frecuente es G.729a. Es compatible con cables con el códec original, pero tiene menos requisitos de CPU.

G.723.1

G.723.1 es el resultado de un concurso que anunció la UIT con el objetivo de diseñar un códec que permitiera realizar llamadas por enlaces de módem de 28,8 y 33 kbit / s.

Tenemos dos variantes de G.723.1. Ambos operan en cuadros de audio de 30 ms (es decir, 240 muestras), pero los algoritmos difieren.
La tasa de bits de la primera variante es de 6,4 kbit / s, mientras que para la segunda variante es de 5,3 kbit / s.
Las tramas codificadas para las dos variantes tienen una longitud de 24 y 20 bytes, respectivamente.

GSM 06.10

GSM 06.10 es un códec diseñado para redes móviles GSM. También se conoce como GSM Full Rate.

Esta variante del códec GSM se puede utilizar libremente, por lo que a menudo la encontrará en aplicaciones VoIP de código abierto.
El códec opera en tramas de audio de 20 ms de longitud (es decir, 160 muestras) y comprime cada trama a 33 bytes, por lo que la tasa de bits resultante es de 13 kbit /.

Un agente de usuario back-to-back (B2BUA) es un elemento de red lógico en aplicaciones SIP. Es un tipo de SIP UA que recibe una solicitud SIP, luego reformula la solicitud y la envía como una nueva solicitud.

A diferencia de un servidor proxy, mantiene el estado de diálogo y debe participar en todas las solicitudes enviadas en los diálogos que ha establecido. Un B2BUA rompe la naturaleza de extremo a extremo de SIP.

B2BUA - ¿Cómo funciona?

Un agente de B2BUA opera entre dos puntos finales de una llamada telefónica y divide el canal de comunicación en dos call legs. B2BUA es una concatenación de UAC y UAS. Participa en toda la señalización SIP entre ambos extremos de la llamada, ha establecido. Como B2BUA disponible en un diálogo, el proveedor de servicios puede implementar algunas características de valor agregado.

En el tramo de la llamada de origen, el B2BUA actúa como un servidor de agente de usuario (UAS) y procesa la solicitud como un cliente de agente de usuario (UAC) hasta el extremo de destino, manejando la señalización entre los puntos finales uno tras otro.

Un B2BUA mantiene el estado completo de las llamadas que maneja. Cada lado de un B2BUA opera como un elemento de red SIP estándar como se especifica en RFC 3261.

Funciones de B2BUA

Un B2BUA proporciona las siguientes funciones:

Gestión de llamadas (facturación, desconexión automática de llamadas, transferencia de llamadas, etc.)
Interfuncionamiento de redes (quizás con adaptación de protocolo)
Ocultación de los componentes internos de la red (direcciones privadas, topología de red, etc.)

A menudo, los B2BUA también se implementan en pasarelas de medios para conectar los flujos de medios para un control total sobre la sesión.

Ejemplo de B2BUA

Muchos sistemas de telefonía empresarial de centralita privada (PBX) incorporan lógica B2BUA.

Algunos cortafuegos incorporan la funcionalidad ALG (puerta de enlace de capa de aplicación), que permite que un cortafuegos autorice el tráfico de medios y SIP mientras mantiene un alto nivel de seguridad.

Otro tipo común de B2BUA se conoce como controlador de borde de sesión (SBC).