Sip.js: Falta el encabezado de ruta en ACK después de volver a invitar.

La sección que está buscando es en realidad la sección 14:

https://tools.ietf.org/html/rfc3261#section -14

Verifique la funcionalidad de su código con esa sección, ya que la sección 12 no se aplica en este caso. En términos generales, el soporte de reINVITE no fue lo suficientemente estable en 0.7.x para siquiera considerarse compatible, pero el soporte se completó según las especificaciones en 0.8.x.

Revisé minuciosamente la sección 14 y no dice nada sobre el uso / modificación del "conjunto de enrutamiento"

Pero volviendo a la sección 12 - "conjunto de rutas" - tiene que formarse durante el procesamiento inicial de INVITE y reutilizarse sin modificaciones mientras se procesan los mensajes en el diálogo.
Más arriba se citan las partes apropiadas de RFC.

Por ahora, la pregunta es por qué el "conjunto de rutas" se modifica en el diálogo (sip.js versión 0.9.1 toma de la última respuesta this.response), ya que no cumple con RFC.

Hola Denis, miré esto y hablé con James al respecto.

Esto es un error, pero parece que el comportamiento original tampoco fue correcto, ya que permitió que el conjunto de rutas se actualizara dentro de un cuadro de diálogo.

El comportamiento de UAS al responder a una solicitud de formación de diálogo, que se describe en https://tools.ietf.org/html/rfc3261#section -12.1.1, debería ser copiar los encabezados de ruta de registro, invertirlos y guardarlos en un diálogo variable de ámbito como la ruta establecida.

Al responder a solicitudes dentro de un diálogo, el comportamiento de UAS, como se describe en https://tools.ietf.org/html/rfc3261#section -12.2, debe ser reutilizar el conjunto de rutas existente dentro del ámbito del diálogo.

El comportamiento actual de depender de la presencia de encabezados de ruta de registro en las solicitudes dentro de un cuadro de diálogo para volver a crear el conjunto de rutas no es correcto.

Arreglaremos esto en la próxima versión, pero mientras tanto, puede solucionarlo llamando a record_route () para todas las solicitudes, iniciales y secuenciales, de modo que los encabezados de ruta de registro estén en solicitudes secuenciales como https: //tools.ietf. org / html / rfc3261 # la sección -12.2 dice que es opcional.

Estoy teniendo el mismo problema, ¿por qué este problema está cerrado mientras el problema no está realmente solucionado?
Me las arreglé para obtener los encabezados buscando el cuadro de diálogo y copiándolos desde allí.

diff --git a/src/SIPMessage.ts b/src/SIPMessage.ts
index a95e8ee..3226160 100644
--- a/src/SIPMessage.ts
+++ b/src/SIPMessage.ts
@@ -755,6 +755,9 @@ export class IncomingResponse extends IncomingMessage implements IncomingRespons
     if (!contact || !contact.uri) {
       throw new Error("Failed to parse contact header.");
     }
+
+    const dialog = this.ua.dialogs[this.callId + this.fromTag + this.toTag];
+
     const ruri = contact.uri;
     const request = new OutgoingRequest(
       C.ACK,
@@ -767,7 +770,7 @@ export class IncomingResponse extends IncomingMessage implements IncomingRespons
         fromTag: this.fromTag,
         toUri: this.to.uri,
         toTag: this.toTag,
-        routeSet: this.getHeaders("record-route").reverse()
+        routeSet: (dialog ? dialog.routeSet : this.getHeaders("record-route").reverse())
       },
       options ? options.extraHeaders : undefined,
       options ? options.body : undefined

0 puntos para el estilo, creo, pero creo que la solución será similar a esta.

Parece que el reportero original cerró el problema. Lo he vuelto a abrir y estamos examinando activamente este código.

Gracias @egreenmachine. Esto también afecta a mantener / retirar (volver a invitar).

El caso que tuvimos fue que el paquete BYE no tenía las rutas correctas después de una nueva invitación en espera.