Resumen

  • RFC 3605 definió a=rtcp a nivel de medio para indicar un puerto y, opcionalmente, una dirección de control cuando la traducción NAT rompe la relación tradicional entre RTP y RTCP.
  • El dato anunciado es una instrucción de transporte, no un recibo. Hay que conservar por separado negociación, socket, observación del mapeo, envío, llegada, validación del paquete, informe RTCP y decisión operativa.

La vieja regla era cómoda: si RTP usaba un puerto par, RTCP ocupaba el siguiente impar. La comodidad se convirtió en error en cuanto un traductor empezó a asignar puertos públicos de forma independiente. Sumar uno al puerto de medios ya no encontraba necesariamente el control. Ni siquiera estaba garantizado que ambos flujos salieran por la misma dirección pública.

Ese es el problema preciso de RFC 3605, publicado en octubre de 2003 en la Standards Track. SDP describía el puerto del medio, pero necesitaba una forma explícita de documentar el puerto RTCP después de la traducción. La solución fue el atributo de valor a=rtcp:<puerto> con dirección opcional. Solo puede usarse a nivel de medio, no como atributo de toda la sesión.

El estándar sustituyó una inferencia por una declaración. No sustituyó la declaración por una medición. Una línea correcta puede apuntar a un socket que todavía no se ha abierto. Puede contener un mapeo observado frente a un servidor y no frente al destino real. Puede llegar íntegra a un programa antiguo que la ignore. Puede indicar una coordenada que expiró mientras la señalización atravesaba colas y reintentos.

La elección del formato explica una asimetría operativa. Los autores descartaron ampliar la línea de medios porque una extensión desconocida podría obligar a aplicaciones antiguas a rechazar toda la descripción. Un atributo desconocido, en cambio, se ignora. El medio RTP puede seguir llegando, mientras el programa no envía RTCP al destino explícito. La compatibilidad conserva servicio parcial a costa de una posible pérdida silenciosa de control.

Por eso el audio no es el recibo del control. Un usuario puede escuchar una conversación y un monitor puede contar paquetes RTP, pero el par puede no estar produciendo informes hacia la coordenada anunciada. Sin esos informes, el sistema pierde evidencia sobre recepción, fuentes y sincronización que RFC 3550 sitúa en RTCP. La ausencia puede pasar desapercibida mientras el camino feliz de medios todavía funciona.

RFC 3605 propone un ejemplo de descubrimiento mediante STUN. El host reserva dos puertos UDP, envía desde cada uno a un servidor y aprende la dirección y el puerto externos que el servidor observó. Pero el texto no convierte esa observación en una promesa. Advierte que el algoritmo supone que el NAT utilizará la misma traducción hacia el servidor STUN y hacia el par SDP, y que no todos los equipos desplegados ofrecen esa característica.

La topología probada es, entonces, más estrecha que la topología deseada. El servidor A observó el tuple X en el instante T. De ahí no se deduce que el par B verá X, que la asociación seguirá viva en T+60 o que el retorno será admitido. Destino, tiempo, protocolo, interfaz y estado del traductor forman parte de la proposición.

Esa precisión cambia el registro que debe conservar una plataforma. No basta con guardar el cuerpo SDP final. Hace falta el hash del original, la versión del generador y del parser, el modo negociado, los sockets locales, el servidor que observó el mapeo, la hora, el tuple público, el par previsto y la primera emisión. Cada cambio de interfaz o de relé debe abrir una nueva época de evidencia.

También debe distinguirse el punto de observación. Un contador en la aplicación indica que intentó enviar. Una captura local muestra que el datagrama cruzó una interfaz. Una captura en el borde remoto demuestra llegada a ese borde. La aceptación por el parser RTCP acredita estructura y asociación con una sesión. Un informe de receptor válido añade mediciones referidas a fuentes e intervalos concretos.

Ninguno de esos recibos puede apropiarse del significado del siguiente. Un paquete recibido no prueba que la analítica lo almacenó. Un informe almacenado no prueba que la automatización lo utilizó. Una decisión de bitrate no prueba que la experiencia humana mejoró. Incluso un informe válido no es certificado de identidad de la persona, de autorización del destino o de calidad bidireccional completa.

El silencio admite demasiadas causas para convertirse directamente en un diagnóstico. El par puede ignorar el atributo, haber negociado multiplexación, usar el puerto adyacente por defecto, perder el mapeo, sufrir un filtro, no haber alcanzado el intervalo de informe o tener rota la exportación de métricas. “Cero informes” describe una base de datos; no describe por sí solo el estado de la red.

Las normas posteriores amplían el árbol de estados. RFC 5761 permite multiplexar RTP y RTCP en un único puerto cuando las partes lo negocian. RFC 8859 trata rtcp como atributo de transporte al analizar la multiplexación. El registro IANA sigue publicándolo como atributo de nivel de medio. Por tanto, la operación debe registrar el resultado negociado, no aplicar retrospectivamente una única regla universal.

RFC 5389 reemplazó el planteamiento más amplio del STUN original y deja claro que se trata de una herramienta, no de una solución completa de travesía NAT. La lección institucional es valiosa: una primitiva mínima puede coordinar una parte del problema sin adquirir autoridad sobre las demás. Descubrir no es reservar. Describir no es entregar. Entregar no es interpretar.

La integridad de la señalización añade autenticidad, no alcance. RFC 3605 observa que quien pudiera reescribir el SDP podría redirigir la fracción RTCP y menciona protección extremo a extremo. Si la firma se verifica, sabemos mejor quién declaró la coordenada y que el texto no cambió. Seguimos sin saber si el socket existe, si el destinatario está autorizado para recibir telemetría o si los paquetes lo alcanzaron.

Un modelo de evidencias útil registra la cadena completa: SDP de origen; resultado del parseo; oferta y respuesta; modo de puertos separados o compartidos; apertura de socket; observación del NAT; coordenada anunciada; integridad; primera salida; primera llegada remota; primer paquete RTCP válido; primera identidad informante; intervalo medido; ingreso en analítica; alarma o ajuste resultante; verificación de calidad.

Ese modelo preserva la posibilidad de corregir. Si se descubre que el par ignoraba el atributo, se puede localizar la época afectada sin inventar datos. Si el mapeo caducó, se puede medir la ventana. Si la analítica perdió informes que sí llegaron, se puede separar un fallo de observabilidad de un fallo de red. La trazabilidad convierte el silencio en una investigación acotada.

RFC 3605 no pretendió gobernar toda la sesión. Dio a dos implementaciones un lenguaje para una coordenada que el NAT había vuelto impredecible. La responsabilidad restante pertenece al código que corre y al operador que lo observa. El destino escrito inicia el trayecto probatorio; nunca lo concluye.