Resumen

  • RFC 5124 combina AVPF y SAVP en SAVPF, pero conserva las funciones y límites de cada capa.
  • La negociación se realiza por línea de medios; una línea puede fallar y las demás seguir adelante.
  • AVP, AVPF, SAVP y SAVPF son alternativas excluyentes dentro de una descripción de medios.
  • Un receptor que no soporta SAVPF debe rechazar esa línea, no degradarla en silencio.
  • Si quiere SAVPF y no se ofreció, debe rechazar y puede formular una contraoferta posterior.
  • SRTCP añade campos a los paquetes RTCP y esa ampliación reduce la frecuencia posible de feedback bajo el mismo presupuesto.
  • RFC 5124 exige ajustar avg_rtcp_size al tamaño protegido; el valor histórico por defecto añade unos 14 bytes.
  • El umbral de feedback depende de ancho de banda, participantes, tamaño de paquete, eventos, códec y plazo útil.
  • La selección SAVPF no demuestra que la señalización estuviera protegida frente a una degradación.
  • Tampoco demuestra claves activas, aceptación SRTCP, llegada a tiempo, respuesta del emisor o recuperación visual.
  • SRTCP exige integridad, pero puede usar cifrado NULL; en grupos, una etiqueta válida no siempre individualiza al autor.
  • El control responsable conserva un expediente por medio y por época de perfil, no una sola luz verde para toda la sesión.

Una llamada que nunca fue una sola cosa

Un extremo ofrece audio y vídeo. Para el audio, ambos interlocutores aceptan RTP/SAVPF, acuerdan el material criptográfico y empiezan a intercambiar control protegido. Para el vídeo, el segundo extremo no reconoce el perfil combinado y rechaza la línea. La conversación puede conservar audio. El vídeo no existe como sesión aceptada.

Un panel que muestre «llamada segura» borra la decisión importante. Un panel que muestre «fallo total» también la borra. RFC 5124 permite que una negociación de medios fracase mientras otras prosperan. La unidad mínima de verdad es la descripción de medios, vinculada a su sesión RTP, su transporte y su época de claves.

La regla evita dos ficciones. La primera sería aceptar SAVPF como si el otro extremo lo hubiera ofrecido o entendido. La segunda sería responder con SAVPF a una oferta distinta y llamar al resultado acuerdo. Cuando el receptor desea el perfil seguro con feedback pero no lo encuentra en la oferta, tiene que rechazar la línea y, si corresponde, iniciar una nueva oferta. El rechazo no es una anomalía burocrática; es el recibo que impide inventar consentimiento técnico.

Dos capas que no pierden sus cuentas

AVPF define formatos de feedback y modifica el calendario RTCP para permitir informes anticipados. SAVP aplica SRTP y SRTCP. RFC 5124 coloca una función sobre la otra: el programador AVPF decide que hay un paquete por enviar y la capa segura lo encapsula. Todos los paquetes RTCP bajo SAVPF deben convertirse en SRTCP.

El resultado protegido es mayor. El documento estima campos adicionales de 10 a 20 bytes en los casos considerados y cita 14 bytes como valor por defecto. La cifra puede variar con etiquetas, identificadores de clave o transformaciones futuras. Por eso la obligación no consiste en sumar siempre catorce, sino en hacer que avg_rtcp_size represente el paquete SRTCP real.

RTCP dispone de una cuota. El tamaño medio, el ancho de banda, el número de participantes y la tasa de eventos determinan cuántos mensajes caben. La aproximación de RFC 4585, N <= B*T/R, muestra el mecanismo: si R crece y B y T permanecen, el sistema puede informar menos eventos N.

El efecto no invalida la seguridad. Expone su coste material. Un cálculo que ignore los bytes protegidos puede prometer feedback inmediato mientras la red sólo sostiene feedback temprano o regular. El protocolo permanece activo; la utilidad temporal cambia.

Tres modos y una fecha de caducidad

En Immediate Feedback, cada receptor dispone aproximadamente de presupuesto suficiente para comunicar cada evento relevante. En Early RTCP ya no puede informar todo, aunque algunos mensajes todavía llegan a tiempo para que el emisor adapte el flujo. En Regular RTCP, el tamaño del grupo o el intervalo vuelve inútil el feedback por evento.

No existe un número universal de participantes que separe esos modos. Influyen la tasa de paquetes, el tipo de feedback, la pérdida, el códec y la frecuencia de eventos. La protección añade otra variable mediante el tamaño. Una actualización criptográfica puede no romper ninguna autenticación y, aun así, reducir el margen temporal.

RFC 4585 llama T_max_fb_delay al máximo retraso durante el cual un aviso sigue siendo útil para la aplicación. Puede ser distinto para audio, vídeo o señalización de tonos. RFC 5124 no garantiza que cualquier SRTCP llegue antes. Una etiqueta válida responde a integridad y contexto; el reloj responde a otra pregunta.

El expediente operativo necesita evento detectado, instante programado, instante transmitido, llegada, aceptación autenticada y actuación del emisor. Sólo después procede observar retransmisión, punto de refresco, estado del decodificador y resultado presentado. Saltar directamente desde «perfil aceptado» hasta «vídeo reparado» elimina seis comprobaciones.

El acuerdo también necesita defensa

La oferta puede enumerar perfiles seguros e inseguros. RFC 5124 advierte que esa mezcla permite ataques de bidding down. Si se mantiene por interoperabilidad, la señalización tiene que protegerse apropiadamente. No basta con que el orden local prefiera SAVPF. Debe ser posible demostrar que nadie quitó, reordenó o modificó alternativas y atributos durante el intercambio.

La protección de SRTCP empieza después de la selección y de las claves. No puede autenticar retrospectivamente una oferta que nunca estuvo cubierta. Este orden causal convierte el transcript de señalización en un activo operativo. Sin él, un resultado AVPF puede deberse a incapacidad legítima, a política local o a manipulación; el estado final no decide entre esas explicaciones.

El caso de anuncios no interactivos es aún más claro. Una descripción enviada por SAP, correo o web no obtiene respuesta negociada. El iniciador debe ofrecer acceso adecuado y proteger la distribución. Si emplea los parámetros inline de RFC 4568 por un canal sin confidencialidad, un tercero puede conocer la clave. El posterior candado conceptual de SAVPF no deshace la exposición.

Seguridad con nombre y apellido

RFC 3711 permite confidencialidad, integridad o autenticación de mensajes y defensa frente a repetición. La integridad de SRTCP es obligatoria, porque alterar el control puede perjudicar el flujo, pero el cifrado es configurable y existe una transformación NULL. Por eso «SAVPF» no equivale automáticamente a «contenido confidencial».

En una comunicación de grupo, varios miembros pueden compartir material. Una etiqueta correcta puede acreditar pertenencia al conjunto de poseedores, no la identidad singular de quien envió el paquete. La propia RFC 3711 limita el sentido de autenticación en ese caso. Informar «origen autenticado» sin describir el modelo de claves es ampliar la evidencia.

El recibo de seguridad del paquete incluye algoritmo, clave, índice SRTCP, ventana de repetición, época y resultado de verificación. El token SDP no transporta ese resultado. Un paquete puede llegar al puerto correcto, tener la forma correcta y ser descartado por un contexto viejo o por repetición.

Una frontera de compatibilidad concreta

SAVP y SAVPF pueden coexistir dentro de una sesión RTP segura; AVP y AVPF pueden hacerlo dentro de una sesión no segura. Lo que no se permite es mezclar las familias segura e insegura en la misma sesión, porque RTP y SRTP no son formatos intercambiables allí. Diferentes sesiones RTP sí pueden usar perfiles distintos.

La distinción explica por qué «el cliente es compatible» resulta insuficiente. Puede recibir medios seguros con SAVP y no emitir feedback temprano. Puede soportar SAVPF para audio pero no para cierto flujo de vídeo. Puede anunciar capacidad y carecer de una configuración de claves aceptable. La matriz debe conservar sesión, medio, perfil y función.

En el procedimiento RTSP que describe RFC 5124, el cliente selecciona exactamente un perfil por flujo mediante SETUP y el servidor lo confirma o lo rechaza. Cambiarlo exige desmontar y restablecer el flujo. Cada nueva construcción necesita transporte, claves y continuidad verificados. Una interfaz que presenta el cambio como un interruptor oculta ese trabajo.

Lo histórico no es una estadística de uso

RFC 5124 figura como Proposed Standard de febrero de 2008, sin actualización u obsolescencia declarada en los metadatos del RFC Editor. RFC 8866 reemplazó la antigua especificación SDP y RFC 7826 reemplazó la versión RTSP citada. RFC 5763 y RFC 5764 dieron forma posterior a DTLS-SRTP. Son hechos de evolución documental, no prueba de que un producto actual use SAVPF.

El registro IANA acredita asignaciones. Los ejemplos con MIKEY, descripciones de seguridad o DTLS-SRTP ilustran intercambios posibles. Ninguna fuente congelada ofrece un censo de despliegue, un incidente, una prueba de interoperabilidad de fabricante o una mejora medida de experiencia. La afirmación válida es arquitectónica: la composición crea obligaciones y límites observables.

Fuentes