Trunking SIP
Este documento cubre la configuración de pares SIP, el monitoreo de keepalive de OPTIONS, la negociación de códecs SDP, el manejo de re-INVITE en diálogo, los servicios en llamada (mantener/reanudar, transferencia REFER, actualización de refresco), temporizadores de sesión, retransmisión de DTMF y estados de llamada de trunk SIP en OmniMSC.
Para el enrutamiento relacionado con SIP, consulte Configuración de Enrutamiento. Para SIP con ISUP encapsulado, consulte Trunking SIP-I. Para la resolución de problemas de trunk SIP, consulte Guía de Resolución de Problemas. Para secuencias de flujo de llamadas que muestran la señalización SIP en contexto, consulte Diagramas de Flujo de Llamadas. Para la negociación de códecs de puerta de enlace de medios, consulte Control de Medios. Para los parámetros de configuración de pares SIP, consulte Referencia de Configuración.
Configuración de Pares SIP
Cada par SIP representa un punto final remoto como una puerta de enlace VoIP, SBC, nodo IMS o proveedor de trunking SIP. Los pares se definen en el bloque de configuración :sip y se hacen referencia por nombre en la tabla de rutas.
| Parámetro | Tipo | Predeterminado | Descripción |
|---|---|---|---|
name | string | -- (requerido) | Nombre lógico del par. Referenciado en las entradas de la tabla de rutas. |
address | string | -- (requerido) | Dirección IP o nombre de host del par. |
port | integer | 5060 | Puerto SIP del par. |
transport | atom | :udp | Protocolo de transporte: :udp, :tcp o :tls. |
codecs | list(atom) | [:pcmu, :pcma] | Códecs de audio soportados para la negociación SDP. |
max_channels | integer | 100 | Máximo de llamadas concurrentes a este par. |
options_interval | integer o nil | nil | Intervalo en segundos para las sondas de keepalive SIP OPTIONS. |
OmniMSC se identifica con el encabezado User-Agent OmniMSC/0.1 en todas las solicitudes y respuestas SIP salientes.
Keepalive de SIP OPTIONS
Cuando se configura options_interval para un par, el Administrador de Pares SIP envía solicitudes periódicas SIP OPTIONS para monitorear la salud del par. El estado del par determina si es elegible para el enrutamiento de llamadas.
Estados de Salud del Par
Cada par rastrea un estado de :up, :down o :unknown. Al iniciar, todos los pares comienzan en el estado :unknown.
| Evento | Transición | Efecto |
|---|---|---|
| OPTIONS 200 OK recibido | Cualquiera -> up | Par elegible para enrutamiento |
| Tiempos de espera de OPTIONS consecutivos | up/unknown -> down | Par excluido del enrutamiento, alarma activada |
| OPTIONS 200 OK después de down | down -> up | Par re-elegible, alarma despejada |
max_channels alcanzado | up -> up (límite suave) | Nuevas llamadas rechazadas para este par, llamadas existentes no afectadas |
Para el monitoreo de pares SIP en el panel de control, consulte Guía del Panel de Control.
Flujo SIP de Llamada MO
Cuando OmniMSC enruta una llamada de origen móvil a un par SIP, se produce el siguiente intercambio de señalización SIP entre OmniMSC y el par remoto.
El INVITE lleva una oferta SDP con códecs basados en la configuración del par y las capacidades del BSC. El 200 OK contiene la respuesta SDP con el códec seleccionado y la dirección RTP remota. Después de ACK, la ruta de medios RTP se establece a través de la puerta de enlace de medios.
Manejo de Re-INVITE en Diálogo
Un par SIP puede enviar un re-INVITE dentro de un diálogo establecido para varios propósitos: mantener la llamada, reanudar, cambiar el códec o refrescar la sesión. OmniMSC acepta cualquier re-INVITE en diálogo con un 200 OK utilizando el SDP de la sesión actual. Si el re-INVITE lleva un cuerpo SDP, el SDP remoto se actualiza a partir de él.
El re-INVITE se responde de la misma manera independientemente del propósito (200 OK con el SDP de la sesión actual). OmniMSC no envía 488 No Aceptable Aquí en respuesta a un re-INVITE y no renegocia el códec en un re-INVITE. El di��logo existente y la sesión de medios permanecen en su lugar. Además, OmniMSC inspecciona el SDP ofrecido en busca de una transición de mantener/reanudar y lo señala al FSM de Control de Llamadas (CC) (ver Servicios en Llamada a continuación).
Servicios en Llamada
OmniMSC maneja tres procedimientos en diálogo en la llamada en una pierna de trunk SIP establecida: mantener/reanudar la llamada, transferencia de llamada REFER y refresco de sesión UPDATE. Los tres solo se aplican en el estado de llamada active; las solicitudes recibidas fuera de active son ignoradas o rechazadas según corresponda.
Mantener y Reanudar Llamadas
Un par remoto coloca la llamada en espera enviando un re-INVITE (o UPDATE) cuyo SDP marca el flujo de medios como inactivo. OmniMSC reconoce tanto las codificaciones de espera modernas como las heredadas (RFC 3264 sección 5.1, TS 29.163 Anexo B):
| Codificación de Espera | Marcador SDP | Notas |
|---|---|---|
| Atributo de dirección | a=sendonly o a=inactive | Preferido (RFC 3264). El atributo a nivel de medios anula el a nivel de sesión |
| Conexión en cero | c=0.0.0.0 | Oferta de espera heredada RFC 2543 |
| Reanudar | a=sendrecv (o ningún atributo de dirección) y un c= no cero | Devuelve el flujo a activo |
En una transición a espera, OmniMSC responde con 200 OK y señala hold_ind al FSM de CC; el FSM marca la llamada como en espera y propaga la condición hacia la estación móvil (un NOTIFY con un indicador de espera remota) y la capa MNCC. En una transición de regreso a activo, se señala retrieve_ind y se borra el estado de espera. Ofertas repetidas con una dirección inalterada (por ejemplo, un refresco de sesión que mantiene la llamada en espera) son idempotentes y no vuelven a señalar una transición.
Transferencia de Llamada REFER (RFC 3515)
Un par puede transferir la llamada enviando un REFER en diálogo cuyo encabezado Refer-To nombra el objetivo de la transferencia. OmniMSC acepta el REFER con un 202 Aceptado (estableciendo la suscripción implícita del evento de referencia), informa la transferencia al FSM de CC como una indicación de ECT (Transferencia de Llamada Explícita, TS 24.091) que lleva la URI Refer-To, y reporta el progreso de vuelta al transferidor a través de mensajes NOTIFY sipfrag (RFC 3515 sección 2.4.5). Un REFER sin un Refer-To utilizable es rechazado con 400 Solicitud Incorrecta.
Los NOTIFY de progreso llevan un cuerpo message/sipfrag con la línea de estado de la transacción de la pierna lejana y un encabezado Subscription-State:
| NOTIFY | cuerpo sipfrag | Subscription-State |
|---|---|---|
| Progreso | SIP/2.0 100 Intentando | activo |
| Finalización | SIP/2.0 200 OK | terminado;razón=noresource |
Temporizador de Sesión (RFC 4028)
OmniMSC soporta temporizadores de sesión SIP según RFC 4028 para detectar y limpiar sesiones SIP huérfanas. Los temporizadores de sesión aseguran que ambos puntos finales refresquen periódicamente la sesión, previniendo un estado de llamada obsoleto después de fallos en la red.
| Parámetro | Valor | Descripción |
|---|---|---|
| Session-Expires | 1800s (predeterminado) | Tiempo máximo entre refrescos de sesión |
| Min-SE | 90s | Valor mínimo aceptable de Session-Expires |
| Refresher | UAC o UAS | Determinado durante la negociación |
| session_refresh_method | :invite (predeterminado) o :update | Método utilizado para enviar el refresco periódico |
Negociación del Temporizador de Sesión
OmniMSC incluye los encabezados Session-Expires y Min-SE en las solicitudes INVITE salientes. Cuando OmniMSC recibe un 422 Intervalo de Sesión Demasiado Pequeño en respuesta a un INVITE saliente, reconoce el 422, extrae el Min-SE del par y vuelve a intentar el INVITE con un Session-Expires actualizado que sea al menos el mínimo del par.
El refresco se envía a la mitad del intervalo de Session-Expires negociado. Si no llega ningún refresco antes de que expire la sesión, OmniMSC envía BYE para desmantelar la llamada y libera todos los recursos asociados.
Método de Refresco: re-INVITE o UPDATE (RFC 3311)
Por defecto, el refresco se envía como un re-INVITE. Cuando un trunk está configurado con session_refresh_method: :update, OmniMSC refresca la sesión con un UPDATE (RFC 3311) en su lugar. UPDATE es más liviano: es una transacción independiente que no perturba la oferta/respuesta y no requiere ACK. Un UPDATE 200 OK nunca se reconoce, mientras que un re-INVITE 200 OK se ACKea como de costumbre.
OmniMSC también responde a un UPDATE iniciado por el par. Cuando el UPDATE lleva una oferta SDP, OmniMSC refleja su SDP actual como la respuesta; el 200 OK publicita el Session-Expires negociado. Un UPDATE que lleva una oferta de espera impulsa la misma señalización de mantener/reanudar al FSM de CC que un re-INVITE.
Retransmisión de DTMF
OmniMSC retransmite tonos DTMF utilizando mensajes SIP INFO según el tipo de contenido application/dtmf-relay. Este método se utiliza cuando el par no soporta la carga útil RTP de evento telefónico RFC 2833 o cuando se prefiere DTMF fuera de banda.
| Campo | Descripción | Ejemplo |
|---|---|---|
| Content-Type | Tipo MIME para la retransmisión de DTMF | application/dtmf-relay |
| Signal | Dígito DTMF (0-9, *, #, A-D) | Signal=5 |
| Duration | Duración del tono en milisegundos | Duration=160 |
Cuando se detectan eventos DTMF desde el lado de la radio (a través de la puerta de enlace de medios), OmniMSC genera un mensaje SIP INFO hacia el par SIP con la señal y duración correspondientes. En la dirección inversa, los eventos DTMF SIP INFO entrantes se reenvían a la puerta de enlace de medios para su reproducción hacia la estación móvil.
Negociación de Códecs SDP
OmniMSC genera ofertas SDP basadas en la intersección de la lista de códecs configurados del par y las capacidades de códec de voz reportadas por el BSC. Los códecs se ofrecen en orden de preferencia.
Códecs Soportados
| Códec | Tipo de Carga RTP | Tasa de Reloj | Parámetros fmtp |
|---|---|---|---|
| PCMU | 0 | 8000 | -- |
| PCMA | 8 | 8000 | -- |
| AMR (banda estrecha) | dinámico (96) | 8000 | octet-align=1 |
| AMR-WB (banda ancha) | dinámico (97) | 16000 | octet-align=1 |
La lista de códecs predeterminada es [:pcmu, :pcma] (carga útil PCMU 0 y carga útil PCMA 8). AMR se ofrece con octet-align=1 (RFC 4867) para interoperabilidad con redes de acceso 3GPP. La versión de voz de GSM de tasa completa se mapea a PCMA (carga útil 8) en el lado SIP. AMR y AMR-WB se ofrecen cuando el BSC indica soporte para estos códecs en la lista de versiones de voz durante la asignación.
Selección de Códec
La selección de códec sigue el modelo de Oferta/Respuesta SDP (RFC 3264):
- OmniMSC construye la oferta SDP a partir de la lista de códecs del par, filtrada por las capacidades de voz del BSC.
- El par remoto responde con una respuesta SDP que contiene uno o más códecs aceptados.
- OmniMSC selecciona el primer códec común del orden de la oferta original.
- La puerta de enlace de medios es instruida (a través de MDCX) con el códec seleccionado y los parámetros RTP.
Si no existe un códec común, OmniMSC responde con o recibe 488 No Aceptable Aquí.
Estados de Llamada de Trunk SIP
Estados de Llamada Saliente
Estados de Llamada Entrante
Referencias
| Referencia | Título | Relevancia |
|---|---|---|
| RFC 3261 | SIP: Protocolo de Inicio de Sesión | Señalización SIP central |
| RFC 4028 | Temporizadores de Sesión en SIP | Session-Expires, Min-SE, mecanismo de refresco |
| RFC 3311 | El Método SIP UPDATE | Refresco de sesión basado en UPDATE |
| RFC 3515 | El Método SIP Refer | Transferencia de llamada REFER, progreso NOTIFY sipfrag |
| RFC 2833 | Carga Útil RTP para Dígitos DTMF | Tipo de carga útil RTP de evento telefónico |
| RFC 3264 | Modelo de Oferta/Respuesta con SDP | Negociación de códecs SDP, marcadores de mantener/reanudar |
| RFC 4867 | Formato de Carga RTP para AMR y AMR-WB | Parámetro de alineación de octetos AMR |
| RFC 3326 | Campo de Encabezado de Razón | Código de causa en BYE/CANCEL |
| TS 29.163 | Interoperabilidad entre redes IMS y CS | Anexo B: interoperabilidad de mantener/reanudar |