¿Qué es SIP?

Los sistemas telefónicos de distintos fabricantes necesitan una forma compartida de acordar una llamada.

SIP no transporta medio, y ese límite explica por qué una llamada conectada puede no tener audio.

¿Qué hace realmente SIP?

Consigue que dos partes acuerden que debe ocurrir una sesión, y en qué condiciones.

RFC 3261, la especificación de junio de 2002 que lo define, describe SIP como "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants". Las cinco tareas son localizar el extremo remoto, decidir si aceptará la llamada, acordar el medio, hacer sonar el timbre, y más tarde colgar o transferir. La especificación las enumera como:

User location: determination of the end system to be used for
     communication;

User availability: determination of the willingness of the called
     party to engage in communications;

User capabilities: determination of the media and media parameters
     to be used;

Session setup: "ringing", establishment of session parameters at
     both called and calling party;

Session management: including transfer and termination of
     sessions, modifying session parameters, and invoking
     services.

Ninguna de las cinco consiste en transportar el audio. Ese es todo el alcance.

¿Por qué mi llamada conecta sin audio?

Porque el audio nunca fue responsabilidad de SIP, y los dos caminos pueden fallar de forma independiente.

La especificación es explícita sobre su propio alcance:

SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture.

El medio viaja sobre RTP, negociado durante el establecimiento y luego fluyendo por su cuenta, frecuentemente entre extremos que la señalización nunca tocó. La señalización puede completarse y ambos lados pueden acordar que una sesión está activa. El audio puede no llegar porque un cortafuegos, un traductor de direcciones de red o una regla de enrutamiento entre los extremos de medio lo descartó mientras dejaba la señalización intacta.

Por eso el audio en un solo sentido y la ausencia de audio son su propia categoría de diagnóstico en lugar de una variante de fallo de llamada. El registro de llamadas mostrará una llamada conectada porque eso es exactamente lo que logró la señalización. Solución de problemas de voz recorre los síntomas. La herramienta de llamada de prueba de Bird imprime un resumen de pico de audio para cada dirección, donde un cero en un lado es el síntoma de audio en un solo sentido expresado como número.

Esa misma separación es lo que permite que otros elementos encajen sin problema. RFC 3261 lo expresa como "SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services." El buzón de voz, los grupos de salto, la grabación de llamadas y un agente de IA están todos construidos sobre las primitivas en lugar de definidos por el protocolo.

¿Tengo que registrar un cliente antes de que pueda llamar?

No. Los trunks Bird autentican llamadas sin registro de cliente.

SIP sí define una función de registro, que es la forma en que un agente de usuario le indica a la red dónde se le puede localizar en ese momento. Es lo que hace que un teléfono de escritorio sea localizable cuando alguien marca una extensión. Pero registrarse y hacer una llamada son actos separados, y un sistema que solo origina llamadas nunca necesita ser localizable.

Un SIP INVITE es el método que solicita una llamada. Bird autentica cada uno contra la lista de IPs permitidas del trunk o mediante un desafío de contraseña. Los clientes no se registran con el trunk. Configura Bird como trunk en lugar de como cuenta registrada: sin sección type=registration en Asterisk, register=false en un gateway de FreeSWITCH, registro en none en FreePBX o 3CX. Cuando un softphone no ofrece forma de desactivar el registro, el intento fallido de registro es cosmético y marcar sigue funcionando, porque la plataforma actúa sobre la invitación y no sobre el registro. Configuración de cliente SIP tiene las configuraciones detalladas.

El corolario es dónde van las credenciales. Tu cliente envía dos identidades distintas. El identificador de llamada va en la cabecera From y debe ser un número que hayas verificado. El nombre de usuario digest es bird en cada trunk. Poner el identificador de llamada en el campo de autenticación provoca un error de autenticación en lugar de un error que mencione el identificador de llamada.

¿Por qué las respuestas se parecen a HTTP?

Porque el protocolo fue diseñado así, hasta los rangos numéricos.

SIP es un protocolo de solicitud y respuesta basado en texto con métodos y cabeceras. Sus respuestas llegan en las mismas seis clases con los mismos números conocidos, un 404 para un destino que no existe y un 486 para un sistema final ocupado. La estructura compartida te permite leer una traza SIP de forma muy similar a como leerías una de HTTP.

Hay dos excepciones. Una sexta clase, 6xx, no tiene equivalente en HTTP y significa que ningún servidor puede satisfacer la solicitud, no solo este. Un código común también tiene un significado en Bird que el estándar no describe. Qué significan los códigos de respuesta SIP cubre ambos casos, incluyendo por qué un 503 de Bird suele ser un rechazo que prefiere no explicar en la red en lugar de una sobrecarga.

¿Dónde encuentro SIP en Bird?

En el trunk, que es la dirección a la que tu equipo envía.

Cada trunk tiene un dominio SIP fijo y acepta UDP o TCP en 5060, o TLS en 5061 si quieres la señalización cifrada en tránsito. Qué puede enviar hacia él lo decides tú, y un trunk nuevo no acepta nada hasta que lo indiques. Qué es un trunk SIP cubre esa decisión y los tres mecanismos detrás de ella. Qué es un API de voz cubre cómo la mitad SIP y la mitad HTTP se reparten el trabajo.