Sip.js: Fehlender Routen-Header bei ACK nach reInvite.

Der gesuchte Abschnitt ist eigentlich Abschnitt 14:

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

Bitte überprüfen Sie die Funktionalität Ihres Codes anhand dieses Abschnitts, da Abschnitt 12 in diesem Fall nicht gilt. Im Allgemeinen war die reINVITE-Unterstützung in 0.7.x nicht stabil genug, um überhaupt als unterstützt angesehen zu werden, aber die Unterstützung wurde in 0.8.x auf die Spezifikation ausgearbeitet.

Ich habe den Abschnitt 14 gründlich überprüft und er sagt nichts über die Verwendung / Änderung des "Routing-Sets" aus.

Aber zurück zu Abschnitt 12 - "Routensatz" - muss während der anfänglichen INVITE-Verarbeitung gebildet und ohne Modifikation während der Verarbeitung von In-Dialog-Nachrichten wiederverwendet werden.
Das Zitieren geeigneter Teile von RFC ist oben angegeben.

Im Moment stellt sich die Frage, warum "route set" im Dialog geändert wird (sip.js-Version 0.9.1 nimmt sie aus der letzten Antwort this.response) - da dies nicht RFC-konform ist.

Hey Denis, ich habe mir das angeschaut und mit James darüber gesprochen.

Dies ist ein Fehler, aber es scheint, dass das ursprüngliche Verhalten auch insofern nicht korrekt war, als es erlaubte, den Routensatz in einem Dialogfeld zu aktualisieren.

Das UAS-Verhalten beim Antworten auf eine Dialogformungsanforderung, beschrieben in https://tools.ietf.org/html/rfc3261#section -12.1.1 , sollte darin bestehen, die Header der Datensatzrouten zu kopieren, umzukehren und in einem Dialog zu speichern Bereichsvariable als Routensatz.

Bei der Beantwortung von Anfragen innerhalb eines Dialogs sollte das UAS-Verhalten, wie in https://tools.ietf.org/html/rfc3261#section -12.2 beschrieben, darin bestehen, den vorhandenen Routensatz innerhalb des Dialogs wiederzuverwenden.

Das aktuelle Verhalten in Abhängigkeit vom Vorhandensein von Datensatz-Routen-Headern bei Anforderungen innerhalb eines Dialogs, den Routensatz neu zu erstellen, ist nicht korrekt.

Wir werden dies in der nächsten Version beheben, aber in der Zwischenzeit können Sie dies umgehen, indem Sie record_route() für alle Anfragen, initial und sequentiell, aufrufen, sodass record-route-Header in sequentiellen Anfragen als https://tools.ietf vorliegen. org/html/rfc3261#section -12.2 sagt, dass es optional ist.

Ich habe das gleiche Problem, warum wird dieses Problem geschlossen, obwohl das Problem nicht behoben ist?
Ich habe es geschafft, die Header zu erhalten, indem ich den Dialog gefunden und von dort kopiert habe.

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 Punkte für den Stil denke ich, aber ich denke, die Lösung wird ähnlich sein.

Es sieht so aus, als hätte der ursprüngliche Reporter das Problem geschlossen. Ich habe es wieder geöffnet und wir schauen uns diesen Code aktiv an.

Danke @egreenmachine. Dies betrifft auch Hold/Unhold (Wiedereinladungen).

Der Fall, den wir hatten, war, dass das BYE-Paket nach einer erneuten Einladung nicht die richtigen Routen hatte.