Resumen

  • En RFC 3960, 180 Ringing significaba que el destinatario estaba siendo alertado; no demostraba que un tono o anuncio en banda hubiese llegado al llamante.
  • Un agente semejante a un teléfono tradicional podía generar tono local sin paquetes, abandonarlo al recibir medios y mantener separados negociación, autenticación, reproducción y desenlace.

El llamante podía oír un timbre perfectamente convincente sin que ese sonido hubiera cruzado la red. Su propio terminal lo producía porque sabía que el destino estaba siendo alertado y todavía no veía paquetes. Si después llegaba un anuncio o un tono especial, el terminal cambiaba de fuente. La experiencia parecía continua; la autoridad sobre el sonido no lo era.

RFC 3960 ordenó en 2004 el problema de los medios tempranos: audio o vídeo intercambiado después del INVITE inicial y antes de la respuesta final. Su aporte central fue negar que el progreso de SIP equivaliera a la presencia del flujo.

La política ilustrativa del documento usa tres pasos. Sin 180 Ringing, un cliente de estilo POTS no genera timbre local. Con 180 y sin paquetes entrantes, lo genera. Con 180 y paquetes presentes, reproduce el flujo y no fabrica el timbre. 180 quiere decir que el llamado está siendo alertado, y el servidor debería enviarlo para ese estado con independencia de cómo marche la sesión temprana.

Mirar sólo la señalización era insuficiente. Un servidor sencillo podía emitir audio sin respuestas provisionales fiables. Otro podía contestar una oferta dentro de una respuesta provisional fiable para cumplir precondiciones sin intención de enviar audio aún. RFC 3262 añadió RSeq, RAck y PRACK para fiabilizar respuestas; no certificó paquetes RTP. RFC 3312 permitió condicionar el avance a recursos; no convirtió la respuesta SDP en sonido.

Además, señalización y medios solían tomar rutas distintas. SIP atravesaba proxies de servicio; el flujo buscaba menor retardo. Un paquete podía adelantarse al mensaje que supuestamente lo anunciaba. En el orden opuesto, el 180 podía llegar mientras la conectividad seguía preparándose. Un indicador único de “habrá medios” no resolvía ambas carreras. RFC 3960 prefirió reaccionar a observaciones: ofrecer retroalimentación local y ceder cuando aparecía tráfico real.

Pero tráfico real tampoco significaba conversación útil. Los paquetes podían contener silencio o ruido de confort. RFC 3711 podía aportar autenticación, integridad, defensa contra repetición y cifrado mediante SRTP. Aun así, aceptar criptográficamente el flujo no probaba decodificación, reproducción por el altavoz, comprensión ni participación humana. Había que conservar los escalones.

RFC 3264 definió oferta/respuesta y RFC 3261 el protocolo que la transportaba. El acuerdo de parámetros demostraba compatibilidad negociada, no entrega. El cliente debía poder reproducir tráfico antes de 200 OK; esperar la respuesta final podía cortar las primeras palabras.

La bifurcación convertía una incertidumbre en varias. Un INVITE podía llegar a múltiples destinos y crear varias sesiones tempranas. Mezclar audios confundía, y el ancho de banda podía obligar a escoger una. En el modelo de pasarela, el cliente elegía a menudo una rama y silenciaba las demás. La rama silenciada podía terminar siendo la aceptada por un 2xx; abrirla tarde producía clipping. La rama que sonaba primero no tenía autoridad sobre el resultado final.

El modelo de servidor de aplicaciones separaba mejor el medio temprano del regular. RFC 3959 definió la disposición early-session y su etiqueta de opción. El cliente podía rechazar o silenciar una oferta temprana sin inutilizar la sesión que sobreviviría. Era una mejora de control, no un recibo de entrega: aún había que seleccionar qué flujo presentar.

Alert-Info tampoco dictaba el momento. El campo podía elegir un tono alternativo si el cliente decidía generar timbre local. No decía cuándo debía comenzar esa generación.

La sección de seguridad mostró que el problema no era sólo acústico. Una dirección de transporte en SDP no autenticaba a su propietario. Un atacante podía conocer o adivinar el puerto; una oferta podía dirigir gran volumen hacia una víctima. El documento recomendaba proteger descripciones, autenticar los medios y verificar voluntad de recibir antes de transmitir demasiado. También describió el incentivo de tarificación: si la etapa temprana era gratuita, un extremo deshonesto podía mantener audio bidireccional sin responder 200 OK. Prohibirlo todo dañaría, sin embargo, a los IVR legítimos que recogen un PIN antes de aceptar.

La RFC dejó así una idea histórica precisa: “está sonando” nombraba al menos cuatro cosas—alerta remota, tono local, flujo recibido y experiencia humana—y ninguna debía escribir el recibo de las demás.

El registro editorial y la consulta de erratas completan la fuente principal. El contexto normativo procede de RFC 3261, RFC 3262, RFC 3264, RFC 3959, RFC 3312 y RFC 3711.