Sip.js: Отсутствует заголовок маршрута в ACK после повторного приглашения.

Раздел, который вы ищете, на самом деле раздел 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.

Привет, Денис, я изучил это и поговорил с Джеймсом об этом.

Это ошибка, но, похоже, исходное поведение также было неправильным, поскольку позволяло обновлять набор маршрутов в диалоговом окне.

Поведение UAS при ответе на запрос формирования диалогового окна, описанное в https://tools.ietf.org/html/rfc3261#section -12.1.1, должно заключаться в копировании заголовков маршрута записи, обратном их изменении и сохранении в диалоговом окне. переменная scoped в качестве набора маршрута.

При ответе на запросы в диалоговом окне поведение UAS, как описано в https://tools.ietf.org/html/rfc3261#section -12.2, должно заключаться в повторном использовании существующего набора маршрутов в пределах диалогового окна.

Текущее поведение в зависимости от наличия заголовков маршрута записи в запросах в диалоговом окне для повторного создания набора маршрутов является неправильным.

Мы исправим это в следующем выпуске, но пока вы можете обойти эту проблему, вызвав record_route () для всех запросов, начальных и последовательных, чтобы заголовки маршрута записи находились в последовательных запросах как https: //tools.ietf. org / html / rfc3261 # раздел -12.2 говорит, что это необязательно.

У меня такая же проблема, почему эта проблема закрыта, а проблема на самом деле не устранена?
Мне удалось получить заголовки, найдя диалог и скопировав их оттуда.

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 не было правильных маршрутов после повторного приглашения удержания.