Sip.js: Header Route tidak ada di ACK setelah reInvite.

Bagian yang Anda cari sebenarnya adalah bagian 14:

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

Harap periksa fungsionalitas kode Anda terhadap bagian itu, karena bagian 12 tidak berlaku dalam kasus ini. Secara umum, dukungan reINVITE tidak cukup stabil di 0.7.x bahkan untuk dianggap didukung, tetapi dukungan itu disempurnakan ke spesifikasi di 0.8.x.

Saya benar-benar memeriksa bagian 14, dan tidak mengatakan apa-apa tentang penggunaan/memodifikasi "set perutean"

Tetapi kembali ke bagian 12 - "set rute" - harus dibentuk saat pemrosesan INVITE awal, dan digunakan kembali tanpa modifikasi saat pemrosesan pesan dalam dialog.
Mengutip bagian RFC yang sesuai diberikan di atas.

Untuk saat ini pertanyaannya adalah mengapa "set rute" dimodifikasi dalam dialog (sip.js versi 0.9.1 dibutuhkan dari respons terakhir this.response) - karena ini bukan kesesuaian RFC.

Hei Denis, saya melihat ini dan berbicara dengan James tentang hal itu.

Ini adalah bug, tetapi tampaknya perilaku aslinya juga tidak benar karena mengizinkan set rute untuk diperbarui dalam dialog.

Perilaku UAS saat menanggapi permintaan pembentukan dialog, dijelaskan dalam https://tools.ietf.org/html/rfc3261#section -12.1.1 , harus menyalin header rute rekaman, membalikkannya dan menyimpannya dalam dialog variabel lingkup sebagai set rute.

Saat menanggapi permintaan dalam dialog, perilaku UAS, seperti yang dijelaskan di https://tools.ietf.org/html/rfc3261#section -12.2, harus menggunakan kembali kumpulan rute yang ada yang dicakup dalam dialog.

Perilaku saat ini bergantung pada keberadaan header rute rekaman pada permintaan dalam dialog untuk membuat ulang kumpulan rute tidak benar.

Kami akan memperbaikinya di rilis berikutnya, tetapi sementara itu Anda dapat mengatasinya dengan memanggil record_route() untuk semua permintaan, awal dan berurutan, sehingga header record-route akan berada dalam permintaan berurutan sebagai https://tools.ietf. org/html/rfc3261#section -12.2 mengatakan opsional.

Saya mengalami masalah yang sama, mengapa masalah ini ditutup sementara masalah sebenarnya tidak diperbaiki?
Saya berhasil mendapatkan tajuk dengan menemukan dialog dan menyalinnya dari sana.

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 poin untuk gaya saya pikir, tapi saya pikir solusinya akan mirip dengan ini.

Sepertinya reporter asli menutup masalah ini. Saya telah membukanya kembali dan kami secara aktif melihat kode ini.

Terima kasih @egreenmachine. Ini juga mempengaruhi penahanan/pembatalan (re-invites).

Kasus yang kami alami adalah paket BYE tidak memiliki rute yang benar setelah undangan ulang ditahan.