Sip.js: Cabeçalho de rota ausente no ACK após reInvite.

A seção que você está procurando é, na verdade, a seção 14:

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

Verifique a funcionalidade do seu código em relação a essa seção, pois a seção 12 não se aplica neste caso. De um modo geral, o suporte reINVITE não era estável o suficiente no 0.7.x para ser considerado suportado, mas o suporte foi desenvolvido de acordo com as especificações no 0.8.x.

Eu verifiquei completamente a seção 14, e ela não diz nada sobre o uso / modificação do "conjunto de roteamento"

Mas voltando à seção 12 - "conjunto de rotas" - deve ser formado durante o processamento inicial de INVITE e reutilizado sem modificação durante o processamento de mensagens no diálogo.
A citação de partes apropriadas do RFC é fornecida acima.

Por enquanto, a questão é por que "conjunto de rotas" é modificado no diálogo (sip.js versão 0.9.1 leva da última resposta this.response) - já que isso não está em conformidade com RFC.

Ei, Denis, eu investiguei isso e falei com James sobre isso.

Este é um bug, mas parece que o comportamento original também não estava correto, pois permitia que o conjunto de rotas fosse atualizado em uma caixa de diálogo.

O comportamento do UAS ao responder a uma solicitação de formação de diálogo, descrito em https://tools.ietf.org/html/rfc3261#section -12.1.1, deve ser copiar os cabeçalhos de rota de registro, revertê-los e salvá-los em um diálogo variável com escopo definido como a rota definida.

Ao responder às solicitações em uma caixa de diálogo, o comportamento do UAS, conforme descrito em https://tools.ietf.org/html/rfc3261#section -12.2, deve ser reutilizar o conjunto de rotas existente com escopo na caixa de diálogo.

O comportamento atual de depender da presença de cabeçalhos de rota de registro em solicitações dentro de uma caixa de diálogo para recriar o conjunto de rotas não está correto.

Vamos corrigir isso na próxima versão, mas enquanto isso você pode contornar chamando record_route () para todas as solicitações, iniciais e sequenciais, de modo que os cabeçalhos de rota de registro estejam em solicitações sequenciais como https: //tools.ietf. org / html / rfc3261 # section -12.2 diz que é opcional.

Estou tendo o mesmo problema, por que esse problema foi fechado enquanto o problema não foi realmente corrigido?
Consegui obter os cabeçalhos encontrando a caixa de diálogo e copiando-os 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 pontos para o estilo, eu acho, mas acho que a solução será semelhante a esta.

Parece que o repórter original encerrou o problema. Eu o reabri e estamos analisando ativamente este código.

Obrigado @egreenmachine. Isso também afeta a retenção / liberação (novos convites).

O caso que tivemos foi o pacote BYE não ter as rotas corretas após um novo convite em espera.