SIP, el Session Initiation Protocol, es cómo se establecen las llamadas telefónicas en internet. Cuando un dispositivo quiere llamar a otro, SIP lleva la negociación: quién llama, dónde se puede localizar al otro lado, qué códecs de audio admiten ambos y cuándo alguien cuelga. La voz en sí nunca viaja sobre SIP. Una vez que los dos lados se ponen de acuerdo, el audio fluye como un flujo separado, casi siempre RTP.
Esa separación es lo único que hay que llevarse de esta guía: SIP es la conversación sobre la llamada, no la llamada. Todo lo demás, los métodos, los códigos de respuesta, los puertos, se sigue de ahí. La guía cubre cómo funciona una llamada SIP mensaje a mensaje, qué significa el vocabulario y los lugares donde aparece SIP cuando quien contesta tus llamadas es un agente de voz con IA.
Qué es SIP y qué no es
SIP es un protocolo de señalización de la capa de aplicación definido por el IETF. Apareció primero como RFC 2543 en 1999 y se revisó como RFC 3261 en 2002, que sigue siendo el estándar que implementa cada teléfono SIP, PBX y operador. Sus diseñadores tomaron prestados el modelo de solicitud-respuesta y la sintaxis de texto de HTTP, así que un mensaje SIP es algo que puedes leer en una captura de paquetes sin herramientas especiales.
Tres cosas que SIP no es:
- No es el audio. SIP negocia la sesión y luego se hace a un lado. La voz y el video viajan como paquetes RTP, descritos más abajo.
- No es un servicio. Nadie te vende “SIP”. Lo que venden los operadores es el troncal SIP: un servicio que usa el protocolo SIP para conectar tu sistema telefónico con la red telefónica pública.
- No es la única forma de señalizar una llamada. H.323 es anterior, WebRTC gestiona las llamadas dentro de los navegadores y los protocolos propietarios corren dentro de aplicaciones cerradas. SIP ganó el mundo de la telefonía empresarial porque es abierto, basado en texto y lo bastante simple como para que cada fabricante pudiera implementarlo.
Cómo funciona una llamada SIP
Una llamada SIP es un breve intercambio de solicitudes de texto y respuestas numeradas. Esta es una llamada entrante típica, desde que suena hasta que se cuelga:
- INVITE. El lado de quien llama envía un INVITE a la dirección del destinatario. Su cuerpo lleva un bloque SDP (Session Description Protocol) con la IP de quien llama, el puerto donde quiere el audio y los códecs que admite.
- 100 Trying. Los proxies del camino confirman la recepción, para que quien llama deje de retransmitir.
- 180 Ringing. El dispositivo llamado está avisando a su usuario. Es cuando quien llama oye el tono de llamada.
- 200 OK. La parte llamada contesta. La respuesta lleva su propio bloque SDP, lo que completa la negociación de códecs.
- ACK. Quien llama confirma la respuesta final. La sesión queda establecida y el audio RTP empieza a fluir en ambas direcciones.
- BYE. Quien cuelga envía un BYE. El otro lado responde 200 OK y la sesión termina.
A mitad de llamada, cualquiera de los dos lados puede enviar un nuevo INVITE, llamado re-INVITE, para cambiar la sesión: ponerla en espera, añadir video o cambiar de códec. Una solicitud REFER pide al otro lado que llame a otro destino, que es cómo funcionan las transferencias.
Así es un INVITE de verdad en el cable, ligeramente recortado:
INVITE sip:+14155550132@sip.example.com SIP/2.0
Via: SIP/2.0/TLS client.example.com:5061;branch=z9hG4bK74bf9
Max-Forwards: 70
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
To: <sip:+14155550132@sip.example.com>
Call-ID: 3848276298220188511@client.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.example.com;transport=tls>
Content-Type: application/sdp
Content-Length: 213
v=0
o=alice 2890844526 2890844526 IN IP4 client.example.com
s=-
c=IN IP4 client.example.com
t=0 0
m=audio 40000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000Las tres últimas líneas de la oferta SDP son los códecs sobre la mesa: el payload 0 es G.711 μ-law, el payload 8 es G.711 A-law y el payload 101 es telephone-event, la vía fuera de banda de enviar pulsaciones de teclas DTMF dentro del flujo de audio. Una llamada por la red pública casi siempre acaba en una de las dos variantes de G.711, y por eso el audio telefónico suena como suena.
Métodos SIP que conviene conocer
Las solicitudes SIP se llaman métodos. Estos son los que te encontrarás en una captura:
| Método | Qué hace |
|---|---|
| INVITE | Inicia una sesión, o la cambia a mitad de llamada (re-INVITE) |
| ACK | Confirma la respuesta final a un INVITE |
| BYE | Termina la sesión |
| CANCEL | Abandona un INVITE que aún no ha sido contestado |
| REGISTER | Dice a un registrar “estoy disponible en esta dirección” |
| OPTIONS | Pregunta a un dispositivo qué puede hacer, sin llamarlo |
| REFER | Pide al otro lado que llame a un tercero: la base de las transferencias |
| INFO | Lleva información a mitad de llamada, una de las formas en que pueden viajar los dígitos DTMF |
Cada solicitud recibe respuestas con códigos de tres dígitos, agrupados por el primer dígito:
| Clase | Significado | Ejemplos |
|---|---|---|
| 1xx | Provisional | 100 Trying, 180 Ringing, 183 Session Progress |
| 2xx | Éxito | 200 OK, 202 Accepted |
| 3xx | Redirección | 301 Moved Permanently, 302 Moved Temporarily |
| 4xx | Error del cliente | 401 Unauthorized, 403 Forbidden, 404 Not Found, 486 Busy Here |
| 5xx | Error del servidor | 500 Server Internal Error, 503 Service Unavailable |
| 6xx | Fallo global | 603 Decline, 604 Does Not Exist Anywhere |
Dos de estos se ganan su sitio durante el establecimiento. Un 401 o un 407 no es un fallo; es un desafío de autenticación, y se espera que el remitente reintente con credenciales digest. Un 488 Not Acceptable Here significa que los dos lados no comparten ningún códec, la forma educada en que una llamada dice que las dos partes nunca acordaron cómo codificar el audio.
Direcciones, registro y las cajas de en medio
Las direcciones SIP se parecen a las direcciones de correo: sip:alice@example.com, opcionalmente con un puerto o un transporte, como en sip:alice@example.com:5061;transport=tls. Un número de teléfono se convierte en una URI SIP añadiendo el dominio del operador, y por eso sip:+14155550132@sip.example.com es una dirección completa a la que se puede llamar.
Como los dispositivos se mueven y están detrás de NAT, un teléfono SIP dice a la red dónde está: envía un REGISTER a su registrar, que anota “alice@example.com está ahora mismo en esta IP”. Cuando llega un INVITE para Alice, un servidor proxy busca ese registro y reenvía la solicitud a donde Alice esté realmente. Delante de casi todos los despliegues reales hay un session border controller (SBC), un portero para el tráfico SIP que termina la señalización, oculta la red interna, aplica la política de seguridad y normaliza las cosas raras que hacen los stacks SIP de distintos fabricantes.
SIP vs RTP vs SDP
Tres protocolos se reparten el trabajo de cada llamada SIP:
| Protocolo | Función |
|---|---|
| SIP | Señalización: localiza al destinatario, negocia la sesión, la termina |
| SDP | Descripción: el payload dentro de los mensajes SIP que enumera códecs, IP y puertos |
| RTP | Medios: lleva el audio o el video reales, marcados con números de secuencia y marcas de tiempo |
Por eso una llamada puede sonar perfectamente y entregar solo silencio. La mitad SIP funcionó, así que ambos teléfonos coinciden en que existe una llamada, pero la mitad RTP está rota, normalmente por un firewall o un NAT que deja pasar la señalización y descarta los medios. Cuando depures una llamada sin audio, mira el camino de los medios, no la señalización. La misma separación es lo que convierte el jitter en un problema de RTP: los campos de secuencia y marca de tiempo de cada paquete RTP, definidos por el RFC 3550, son exactamente lo que un receptor mide para calcularlo.
SIP vs VoIP vs troncal SIP
Los tres términos se usan como si fueran sinónimos, y no lo son:
| Término | Qué es |
|---|---|
| VoIP | La idea general: voz transmitida sobre redes IP |
| SIP | Un protocolo de señalización usado para establecer llamadas VoIP |
| Troncal SIP | Un servicio de operador que usa SIP para conectar tu sistema telefónico con la PSTN |
Si VoIP es la idea de llamar por internet, SIP es la gramática que hablan los dos extremos, y un troncal SIP es la suscripción que mete tu llamada en la red telefónica pública. La guía de troncales SIP cubre el lado del servicio: proveedores, canales y configuración.
Transportes, puertos y cifrado
La señalización SIP funciona sobre UDP o TCP en el puerto 5060, o sobre TLS en el puerto 5061. UDP es el valor por defecto tradicional y evita el bloqueo de cabeza de línea, pero los mensajes grandes se fragmentan, así que TCP es habitual para cualquier cosa de cierto tamaño. TLS cifra la señalización y autentica al otro extremo, y es lo que los operadores esperan para cualquier cosa en producción.
SIP en claro no cifra nada: cualquiera en el camino puede leer la señalización, y los medios viajan en RTP sin cifrar. La solución estándar es TLS para la señalización más SRTP, definido por el RFC 3711, para los medios. Ambos extremos tienen que ponerse de acuerdo, porque activar el cifrado en un solo lado es una forma fiable de producir llamadas que conectan y no llevan audio.
Una advertencia que ha sobrevivido a todas las décadas de SIP: no expongas un endpoint SIP abierto. Los escáneres barren internet en busca del puerto 5060 a los pocos minutos de aparecer, buscando troncales que hagan llamadas gratis. Autentica a los remitentes con credenciales digest, añade a la lista de permitidos las IP de señalización de tu operador, o ambas cosas.
Dónde se encuentra SIP con un agente de voz
Si pones un agente de voz con IA en la red telefónica, SIP es el protocolo que hace el trabajo en los dos bordes de la llamada: el operador entrega las llamadas entrantes a la plataforma de agentes como INVITE SIP, y la plataforma devuelve las llamadas salientes y las transferencias por el mismo camino. Algunos detalles del protocolo dejan de ser curiosidades en el momento en que ese stack es tuyo:
- Las transferencias son REFER. Cuando el agente pasa a quien llama con una persona, la plataforma envía un SIP REFER pidiendo al operador que haga sonar un nuevo destino. Un REFER a secas es una transferencia en frío; que sea en caliente, donde la persona oye primero el contexto, es trabajo del agente antes de que salga el REFER.
- Las pulsaciones de teclas tienen tres transportes. Los dígitos DTMF pueden viajar en banda como audio, fuera de banda como eventos telephone-event del RFC 4733 (el payload 101 del INVITE de arriba) o dentro de mensajes SIP INFO. Un desajuste entre lo que el teléfono envía y lo que el agente escucha es la razón de que los menús de “marque 1” se traguen dígitos en silencio.
- El audio es a 8 kHz. Las llamadas telefónicas negocian G.711, así que el reconocimiento de voz del agente ve audio de banda estrecha le guste o no. Prueba con audio telefónico real antes de ajustar cualquier otra cosa; la guía de G.711 cubre lo que corta el códec.
- Las llamadas de navegador son otro mundo. WebRTC tiene su propio modelo, agnóstico de la señalización, con cifrado obligatorio y buffers de jitter adaptativos. La guía de WebRTC frente a WebSocket traza las diferencias para agentes de voz que viven en un navegador en lugar de en la red telefónica.
En Cartesia, los Managed Agents aceptan llamadas desde tu propio troncal SIP sobre TCP o TLS, con el cifrado de medios SRTP ajustado a disabled, allowed o required, y autentican las llamadas entrantes con credenciales digest o una lista de IP permitidas. Las transferencias salen como REFER SIP a números de teléfono o URI SIP. La integración de troncales SIP (Inglés) explica cómo apuntar un operador al endpoint SIP de Cartesia, y la guía de troncales SIP cubre la configuración completa, incluidos los campos de la API y la tabla de fallos.
Guías relacionadas
- ¿Qué es un troncal SIP? Cómo funciona con IA de voz
- Códec G.711: μ-law, A-law y audio telefónico a 8 kHz
- Qué es DTMF: tonos, frecuencias y agentes de voz
- ¿Qué es el jitter en VoIP? Cómo medirlo y corregirlo
- WebRTC vs WebSocket para IA de voz en tiempo real
- Transferencia en caliente vs en frío: qué es