Sip.js: En-tête de route manquant sur ACK après reInvite.

La section que vous recherchez est en fait la section 14 :

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

Veuillez vérifier la fonctionnalité de votre code par rapport à cette section, car la section 12 ne s'applique pas dans ce cas. De manière générale, la prise en charge de reINVITE n'était pas suffisamment stable dans la 0.7.x pour même être considérée comme prise en charge, mais la prise en charge a été étoffée selon les spécifications de la 0.8.x.

J'ai soigneusement vérifié la section 14, et elle ne dit rien sur l'utilisation/la modification du "jeu de routage"

Mais pour en revenir à la section 12 - "ensemble de routes" - doit être formé pendant le traitement initial d'INVITE, et réutilisé sans modification pendant le traitement des messages en boîte de dialogue.
La citation des parties appropriées de la RFC est donnée ci-dessus.

Pour l'instant, la question est de savoir pourquoi "route set" est modifié dans la boîte de dialogue (sip.js version 0.9.1 il prend à partir de la dernière réponse this.response) - car cela n'est pas conforme aux RFC.

Salut Denis, j'ai regardé ça et j'en ai parlé avec James.

Il s'agit d'un bogue, mais il semble que le comportement d'origine n'était pas non plus correct en ce sens qu'il permettait la mise à jour de l'ensemble de routes dans une boîte de dialogue.

Le comportement UAS lors de la réponse à une demande de formation de dialogue, décrit dans https://tools.ietf.org/html/rfc3261#section -12.1.1 , devrait être de copier les en-têtes de route d'enregistrement, de les inverser et de les enregistrer dans une boîte de dialogue variable d'étendue en tant qu'ensemble d'itinéraires.

Lorsque vous répondez aux demandes dans une boîte de dialogue, le comportement de l'UAS, comme décrit dans https://tools.ietf.org/html/rfc3261#section -12.2, doit être de réutiliser l'ensemble de routes existant défini dans la boîte de dialogue.

Le comportement actuel consistant à dépendre de la présence d'en-têtes de route d'enregistrement sur les demandes dans une boîte de dialogue pour recréer l'ensemble de routes n'est pas correct.

Nous corrigerons ce problème dans la prochaine version, mais en attendant, vous pouvez contourner le problème en appelant record_route() pour toutes les requêtes, initiales et séquentielles, afin que les en-têtes record-route soient dans des requêtes séquentielles comme https://tools.ietf. org/html/rfc3261#section -12.2 dit que c'est facultatif.

J'ai le même problème, pourquoi ce problème est-il fermé alors que le problème n'est pas réellement résolu ?
J'ai réussi à obtenir les en-têtes en trouvant la boîte de dialogue et en les copiant à partir de là.

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 point pour le style je pense, mais je pense que la solution sera similaire à celle-ci.

Il semble que le journaliste d'origine ait clos le problème. Je l'ai rouvert et nous examinons activement ce code.

Merci @egreenmachine. Cela affecte également la mise en attente/remise en attente (ré-invitations).

Le cas que nous avons eu était que le paquet BYE n'avait pas les bons itinéraires après une réinvitation en attente.