Resumen

  • PRACK confirma una respuesta provisional fiable determinada. El 2xx que responde a PRACK no es la respuesta final a la INVITE original.
  • RSeq y RAck atan el acuse al diálogo, CSeq, método y orden correctos; aunque oferta/respuesta avance, no demuestran que el medio haya llegado ni que alguien haya contestado.

Un estado que podía perderse

RFC 3261 permite que una INVITE reciba cero, una o varias respuestas provisionales antes del resultado final. Las 101–199 comunican progreso y pueden crear un diálogo temprano. La aceptación corresponde a un 2xx final; otras clases finales redirigen o rechazan. La especificación básica, sin embargo, no entrega de forma fiable esas respuestas provisionales.

La distinción importa cuando una 1xx lleva estado necesario para interoperar con telefonía tradicional, crear el diálogo o transportar una descripción de sesión. Perderla no decide por sí mismo el destino de la llamada, pero puede romper el camino que debía conducir a esa decisión.

RFC 3262 añadió 100rel y el método PRACK. Si la INVITE anuncia Supported: 100rel, el UAS puede enviar de manera fiable una respuesta provisional distinta de 100. Si exige Require: 100rel, debe hacerlo o rechazar la exigencia. 100 Trying queda fuera porque actúa salto a salto y la nueva confirmación funciona extremo a extremo.

Qué identifica realmente RAck

La respuesta fiable lleva Require: 100rel y un número RSeq. El primer valor se elige en el rango definido y su espacio pertenece a una sola transacción. Un número igual en otra INVITE no representa el mismo mensaje.

El UAS retransmite la 1xx con retroceso exponencial desde T1. Solo un PRACK correspondiente detiene la serie. Debe pertenecer al mismo diálogo y su RAck reproduce el RSeq, el número CSeq y el método del mensaje acusado. Son tres coordenadas que evitan confirmar un progreso vago o una rama distinta.

Si encuentra una respuesta pendiente, el UAS contesta 2xx al PRACK y deja de retransmitirla. Si no existe coincidencia, responde 481. Ese 2xx cierra la transacción PRACK; no acepta la INVITE. La decisión de llamada conserva su propia respuesta final.

PRACK se parece a ACK por la función, pero no es ACK para una 1xx. Es una petición no-INVITE normal dentro del diálogo, con fiabilidad de transacción salto a salto y respuesta propia. Su independencia hace posible confirmar el estado intermedio sin apropiarse del significado final.

El orden también forma parte de la fiabilidad

Los acuses no son acumulativos. RFC 3262 recomienda mantener una sola respuesta provisional fiable pendiente y prohíbe enviar la segunda antes de confirmar la primera. Después, RSeq crece exactamente de uno en uno y no da la vuelta.

El receptor reconoce una retransmisión mediante diálogo, CSeq y RSeq, y descarta la copia. Si llega un RSeq posterior antes del esperado, no lo procesa ni lo confirma; puede guardarlo mientras espera el hueco. La propiedad buscada es «esta respuesta, en esta posición», no solo «algún paquete apareció».

Tras 64*T1 sin PRACK, el UAS debería rechazar la petición original con 5xx. La extensión elimina una incertidumbre y crea otra superficie operativa: temporizadores, listas pendientes, ruta del diálogo, secuencias y autenticación deben conservarse. El estándar no dice cuántas redes actuales lo hacen bien.

La llegada de una respuesta final tampoco borra automáticamente todo lo anterior. En los casos permitidos, el UAS debe estar preparado para procesar un PRACK pendiente aun después del resultado final, aunque ya no puede originar nuevas respuestas provisionales fiables. Esta regla evita deducir que «final» significa que cualquier transacción asociada desapareció en el mismo instante; cada intercambio conserva su cierre propio.

Una negociación adelantada no es una aceptación

PRACK puede llevar cuerpo. Si la INVITE contiene una oferta, una 1xx fiable puede transportar la respuesta. Si no contiene oferta, la 1xx puede presentarla y PRACK debe responder. PRACK también puede llevar una oferta nueva, cuya respuesta aparece en su 2xx.

Así, los parámetros de sesión pueden quedar establecidos antes de la respuesta final. Aun así, la INVITE sigue abierta. Cuando una 1xx fiable no confirmada contiene descripción de sesión, el UAS debe retrasar el 2xx final de aceptación hasta recibir PRACK. Se protege oferta/respuesta, no se delega la aceptación en el acuse.

RFC 6337 aclara que dos extremos compatibles con 100rel no convierten todas las provisionales en fiables. Con una oferta en la INVITE, el primer SDP de una respuesta fiable sin fallo es la respuesta verdadera; un SDP previo en 1xx no fiable solo actúa como adelanto.

RFC 3311 permite con UPDATE cambiar parámetros en diálogos tempranos o confirmados. Ofrece más rutas para oferta/respuesta, pero INVITE, PRACK y UPDATE siguen siendo transacciones distintas.

La cronología del audio no autentica la señal

RFC 3960 aborda tonos, anuncios y otros medios tempranos. Señalización SIP y RTP están acoplados de forma laxa y pueden seguir caminos y tiempos diferentes.

Por ello, PRACK no prueba que el audio llegara o fuera oído. Oír un anuncio tampoco prueba que el RSeq correcto recibiera su RAck. Las dos observaciones pueden correlacionarse, pero ninguna autoriza a inventar la otra.

El registro IANA enumera PRACK, RAck, RSeq y 100rel con referencia a RFC 3262. Acredita asignación formal, no despliegue ni conformidad. Además, un atacante podría inyectar PRACK y detener retransmisiones importantes; por eso la petición debe autenticarse como cualquier otra. Coincidencia de estado e identidad fiable son controles diferentes.

Fuentes