Sip.js: reInvite後にACKにRouteヘッダーがありません。

あなたが探しているセクションは実際にはセクション14です：

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

この場合、セクション12は適用されないため、そのセクションに対してコードの機能を確認してください。 一般的に言って、reINVITEのサポートは0.7.xで十分に安定しておらず、サポートされていると見なすことさえできませんでしたが、サポートは0.8.xで仕様に具体化されました。

セクション14を徹底的にチェックしましたが、「ルーティングセット」の使用法/変更については何も書かれていません。

ただし、セクション12（「ルートセット」）に戻るには、最初のINVITE処理中に形成し、ダイアログ内メッセージの処理中に変更せずに再利用する必要があります。
RFCの適切な部分の引用は上に示されています。

今のところ問題は、「ルートセット」がダイアログ内で変更される理由です（sip.jsバージョン0.9.1は最後の応答this.responseから取得します）-これはRFCに準拠していないためです。

ねえデニス、私はこれを調べて、ジェームズと話しました。

これはバグですが、ダイアログ内でルートセットを更新できるという点で、元の動作も正しくなかったようです。

https://tools.ietf.org/html/rfc3261#section -12.1.1で説明されているダイアログ形成要求に応答するときのUASの動作は、レコードルートヘッダーをコピーし、それらを逆にして、ダイアログに保存することです。ルートセットとしてのスコープ変数。

ダイアログ内の要求に応答する場合、 https： //tools.ietf.org/html/rfc3261#section -12.2で説明されているように、UASの動作は、ダイアログ内でスコープされた既存のルートセットを再利用する必要があります。

ルートセットを再作成するためのダイアログ内のリクエストのレコードルートヘッダーの存在に依存する現在の動作は正しくありません。

これは次のリリースで修正される予定ですが、それまでの間、初期および順次のすべてのリクエストに対してrecord_route（）を呼び出すことで回避できるため、record-routeヘッダーはhttps：//tools.ietfのように順次リクエストに含まれ

同じ問題が発生していますが、実際には修正されていないのに、なぜこの問題が解決されるのですか？
ダイアログを見つけてそこからコピーすることで、なんとかヘッダーを取得できました。

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ポイントですが、解決策はこれに似ていると思います。

元のレポーターが問題を解決したようです。 私はそれを再開しました、そして私たちはこのコードを積極的に見ています。

@egreenmachineありがとうございます。 これは、保留/保留解除（再招待）にも影響します。

保留の再招待後にBYEパケットに正しいルートがない場合がありました。