Resumen

  • RFC 5263 obliga al agente de presencia a esperar la respuesta final o el vencimiento del NOTIFY parcial anterior antes de enviar otro al mismo Request-URI; esa regla serializa transacciones, no confirma un cambio duradero de estado.
  • Una constancia defendible une suscripción, versión y cuerpo recibido con la respuesta SIP, el resultado del análisis y del parche, las huellas anterior y posterior, el almacenamiento y la exposición posterior.

El error apareció después de la respuesta

El observador recibió un NOTIFY, comprobó que pertenecía a una suscripción existente y devolvió una respuesta final de éxito. Después, al procesar el cuerpo parcial, una operación no pudo aplicarse a su copia local. La capa emisora ya había visto cerrarse la transacción.

El observador inició una renovación para pedir estado completo. Incluso podía abandonar el formato parcial en la siguiente suscripción. Desde el punto de vista del agente de presencia, el 200 anterior seguía siendo real; desde el punto de vista de la aplicación, el delta nunca se convirtió en estado utilizable.

RFC 5263 reconoce precisamente esta asimetría: ante un error de procesamiento, renovar o volver al modo completo es razonable, mientras que señalar el fallo al notificador puede no serlo. El silencio hacia arriba no debe confundirse con éxito hacia abajo.

La respuesta final abre la siguiente ranura

El agente de presencia no debe enviar otro NOTIFY parcial al mismo Request-URI hasta recibir una respuesta final al anterior o hasta que venza la transacción. La restricción mantiene una sola transición dependiente en vuelo y ofrece un punto claro para continuar o tratar un fallo.

El marco de eventos SIP indica que una notificación considerada aceptable suele recibir 200. La respuesta no debe demorarse más de lo necesario para el procesamiento automático y nunca debe esperar una decisión del usuario.

Por diseño, el intercambio no es un acuse humano. Tampoco define una confirmación universal de escritura persistente. Es una señal suficiente para que el protocolo abandone una transacción y gestione la siguiente.

La versión sólo existe dentro de la suscripción

El observador permite notificación parcial anunciando application/pidf-diff+xml junto con application/pidf+xml. Puede expresar preferencia, pero la política local del agente influye en la selección final.

La primera notificación en el formato parcial contiene un documento completo y comienza la versión en uno. El contador pertenece a esa suscripción, continúa durante las renovaciones y sólo se reinicia cuando la suscripción termina.

Por eso una respuesta debe conservarse junto con Call-ID, etiquetas, diálogo, Request-URI, cuerpo y versión. El número por sí solo no identifica un estado global. El 200 por sí solo ni siquiera identifica qué huella local debía sustituir a cuál.

Enviado con éxito no significa aplicado con éxito

RFC 5263 pide incrementar la versión frente al documento de presencia parcial enviado con éxito anteriormente a ese observador. La espera de una respuesta final o de un vencimiento forma un historial útil para el emisor.

Ese historial demuestra que el mensaje salió y que el protocolo recibió una terminación de transacción. No observa el resultado del parser, la selección de la copia base, la escritura al almacén, la supervivencia a un reinicio ni la vista consumida por otro proceso.

La diferencia parece académica cuando todos los componentes funcionan. Se vuelve decisiva cuando una autorización, una alerta o una acción de alto valor se apoya en la supuesta actualización.

Tres comparaciones, tres recuperaciones

El observador compara la versión recibida con su contador. Si es igual o menor, considera que existe un fallo del agente y debería descartar el documento. Si aumenta exactamente uno y el cuerpo es un diff, aplica las operaciones y avanza. Si salta más de uno, presume pérdida y debería renovar para recibir estado completo o terminar la suscripción.

Cada rama modifica lo que puede afirmarse. Descartar conserva el estado anterior. Aplicar produce una nueva copia sólo si la operación termina. Renovar reconoce que la cadena local ya no es suficiente. Una respuesta SIP aislada no distingue esas ramas.

El recibo institucional debe registrar la comparación y la decisión, no inferirlas a partir del código de respuesta visto por el emisor.

Cambiar de formato también cambia la historia local

Si el agente cambia el tipo de contenido dentro de una suscripción, el observador elimina la información de presencia recibida antes, salvo el contador local. Lo conserva porque una vuelta posterior al formato parcial continuará la numeración.

Así, una coordenada sobrevive mientras la representación subyacente se reemplaza. Guardar sólo el contador crea una apariencia de continuidad que no explica qué copia fue descartada, qué documento completo ocupó su lugar o qué vio la aplicación entre ambos momentos.

Una renovación que entrega estado completo reancla el presente. No reconstruye el pasado ni demuestra que el delta fallido llegó a una pantalla.

Autenticidad y aplicación no son el mismo control

Las consideraciones de seguridad abarcan confidencialidad, integridad, autenticidad, prevención de repetición y denegación de servicio. RFC 5263 recomienda TLS en su contexto original y contempla S/MIME; RFC 8996 actualiza la dependencia al retirar TLS 1.0 y 1.1.

Una inyección puede provocar una falsa brecha y forzar la solicitud de un estado completo. Impedirla es esencial. Aun así, un NOTIFY auténtico puede encontrar una copia local equivocada, un parche inaplicable, un almacén indisponible o una salida posterior estancada.

La firma del transporte y la respuesta final forman parte de la prueba, pero no reemplazan la constancia del cambio local.

La constancia de estado del observador

Para usos con consecuencias, conserve:

  • presentity, observador, Request-URI, suscripción, diálogo y paquete de eventos;
  • tipos de contenido aceptados, preferencias y selección local del agente;
  • Call-ID, etiquetas, CSeq, tipo, bytes, huella y hora de cada NOTIFY;
  • versión de la suscripción y versión previa esperada;
  • código y hora de la respuesta SIP, vencimiento o reintento;
  • resultado de análisis y error exacto de procesamiento;
  • huella del documento completo previo y resultado de cada parche;
  • huella reconstruida, contador local y confirmación de almacenamiento;
  • renovación, repliegue, cambio de formato y estado completo sustituto;
  • identidad, huella y hora de la exposición aguas abajo; y
  • presentación, intento de contacto, entrega y resultado humano o de servicio.

La constancia no cambia lo que significa 200. Impide que otra capa le atribuya una autoridad que nunca tuvo.

Sources