Resumo

  • Na RFC 5370, o transcodificador T é um B2BUA, e não um proxy. O INVITE recebido de A e o INVITE criado para B pertencem a transações diferentes.
  • T gera uma nova resposta final para A e deve, em geral, usar o mesmo código recebido de B. Se o 183 Session Progress se perder, o 603 visto por A não identifica sozinho se T ou B recusou.
  • History-Info recompõe a atribuição. A mesma disciplina vale para o From reconstruído, a lista de um único destino e a exceção de opt-in: correlação útil não deve ser promovida a continuidade ou consentimento sem prova.

Um número podia ser copiado sem copiar sua causa

A envia um INVITE para T. T envia outro INVITE para B. Quando B responde, T não encaminha o pacote original como faria um elemento transparente. Ele gera uma resposta nova na transação mantida com A.

A RFC 5370 diz que essa nova resposta deve usar o mesmo código de estado recebido na perna de saída. A escolha conserva a categoria operacional do resultado: se B recusou, A também vê uma recusa.

Mas o código é somente uma parte do evento. Ele não carrega a identidade da transação, a política que o produziu nem a autoridade que tomou a decisão.

Uma plataforma que une eventos apenas por status = 603 obtém simetria visual. Perde a diferença entre “o serviço não admitiu a solicitação” e “o destinatário não aceitou o convite do serviço”.

T era um B2BUA, não um fio

O documento repete uma distinção decisiva: T atua como Back-to-Back User Agent, não como proxy. O INVITE enviado a B pertence a uma transação diferente do INVITE recebido de A.

T também produz a descrição de sessão de acordo com a transformação que oferece. Um serviço para incompatibilidade de codecs de áudio anuncia os codecs que ele próprio suporta na perna T–B.

Isso permite negociação independente em cada lado. Também significa que Call-ID, branch, diálogo, autenticação e SDP não atravessam T como uma única identidade.

O operador pode criar uma chave de correlação comum. Essa chave é útil, mas registra uma relação estabelecida por T; não apaga os dois atos protocolários.

O 183 perdido apagava a pista

No fluxo malsucedido da RFC, T envia 183 Session Progress para A, cria o INVITE para B, recebe 603 Decline e gera outro 603 para A.

Se o 183 chega, A possui ao menos uma pista de que T avançou para o processamento da sessão. Se ele se perde, o 603 final fica ambíguo.

A não sabe se T rejeitou o INVITE inicial ou se B rejeitou o INVITE de T. Os mesmos três dígitos podem descrever duas autoridades.

Esse caso mostra por que eventos provisórios não são apenas ruído de diagnóstico. Em certas arquiteturas, eles contêm a única observação que separa admissão do serviço de resultado no destino.

History-Info preservava autoria operacional

A RFC 5370 aponta History-Info entre T e A como forma de resolver a ambiguidade. A história não altera o 603; acrescenta o caminho necessário para interpretá-lo.

Um armazenamento que guarda somente estados terminais pode ser compacto e ainda assim incapaz de responder quem recusou. A ausência de história deve aparecer como incerteza, não como autorização para escolher a explicação mais comum.

O texto original citava a RFC 4244. A RFC 7044 atualizou posteriormente o contexto de History-Info. Essa evolução não comprova que uma sessão concreta tenha carregado ou preservado o campo.

É preciso verificar suporte, política de privacidade, cabeçalhos reais e lacunas de captura. Proveniência documental não substitui evidência da execução.

A alternativa separava os resultados com mais mensagens

O documento examinou outra arquitetura. T poderia responder 200 OK a A, criar o INVITE para B separadamente e permitir que A acompanhasse o resultado pela assinatura do estado da conferência.

Essa opção tornava duas decisões explícitas: T aceitou A; depois B aceitou ou recusou T. Não seria necessário fazer um único código parecer o resultado de ponta a ponta.

Ela foi rejeitada por ser mais complexa, exigir mais mensagens e aumentar o tempo de estabelecimento. O fluxo escolhido comprou simplicidade e rapidez, mas passou a depender de History-Info para explicar certas falhas.

Reduzir a quantidade de mensagens não autorizou reduzir toda a evidência. O custo de observabilidade foi deslocado.

O From mantinha representação, não origem de pacote

T deve formar o From do INVITE de saída com o valor recebido no INVITE de entrada, respeitando os requisitos de privacidade. A regra não inclui o parâmetro tag.

B pode, portanto, ver uma identidade que representa A em uma solicitação efetivamente originada por T. A aparência do chamador continua; a identidade da transação muda.

Também são diferentes: o usuário autenticado por T, a autorização para usar o serviço, a identidade exibida a B e uma eventual afirmação verificável sobre o originador original.

A RFC citava a RFC 4474 para identidade SIP; a RFC 8224 a substituiu depois. A referência histórica não prova qual mecanismo um sistema atual usa nem se B validou a afirmação.

SDP e destinatário viajavam juntos, mas mandavam em coisas diferentes

A envia a T um INVITE multipart com SDP e um corpo recipient-list. O SDP descreve a proposta de mídia na perna A–T. A lista diz a T para quem ele pode gerar uma nova solicitação.

A lista contém somente o URI de B. Se houver mais de um URI, T deve responder 488 e indicar que o máximo é um.

Proteger a integridade do SDP e não da lista preservaria codecs enquanto deixaria mutável o destino da ação. O recibo precisa ligar os bytes exatos da lista à transação de entrada e ao URI usado na saída.

A limitação de um destino pertence a esse modelo de transcodificação entre duas partes; não revoga o uso multiparte da RFC 5366.

A exceção de opt-in era um resultado condicionado

Serviços de lista podem ampliar uma solicitação e produzir comunicações não desejadas. Mesmo assim, a RFC 5370 conclui que o transcodificador desse modelo não precisa usar listas de opt-in.

O raciocínio tem três premissas: T gera apenas um INVITE; A conhece e escreve o URI de B; a identidade de A aparece na solicitação criada por T.

Se o produto passar a expandir grupos, resolver um identificador para destinos que A não conhecia ou ocultar completamente o chamador, já não é o mesmo caso.

Guardar apenas a conclusão “opt-in não exigido” congela a permissão e apaga seus limites. A política deveria verificar as três premissas a cada chamada.

Autenticação não avaliava a transformação

T deve autenticar e autorizar usuários. A RFC também destaca integridade da lista e cita S/MIME ou TLS como mecanismos disponíveis no contexto da época.

Esses controles provam aspectos de acesso e instrução. Não demonstram que T escolheu o SDP correto, converteu com fidelidade, reteve apenas o necessário ou eliminou os dados depois.

As pernas A–T e T–B têm contextos próprios. Proteção na primeira não se transforma automaticamente em proteção na segunda.

Referências como RFC 5246 são evidência histórica do texto de 2008, não uma recomendação de configuração contemporânea. O mecanismo realmente negociado deve ser registrado.

O 302 ainda exigia uma escolha de A

Na invocação iniciada pelo destinatário, B pode responder 302 Moved Temporarily quando não aceita o SDP. O Contact aponta para T e carrega, em ?body=, uma lista com o URI de B.

O 302 não chama T por conta própria. A encerra a primeira tentativa, interpreta o corpo escapado e decide se cria outro INVITE.

A RFC observa que codificar um corpo em um URI é complexo e que o modelo 3pcc é mais simples para esse cenário.

Uma auditoria precisa separar a proposta de B, a validação do Contact, a decisão de A, a transação A–T e a transação T–B. “Redirecionado” não significa “transcodificado”.

O resultado acessível não cabia no código SIP

A especificação busca permitir serviços que apoiem pessoas surdas, com deficiência auditiva ou de fala. Conversão de voz em texto é um exemplo.

Dois 200 OK, duas pernas de mídia e pacotes transformados não provam que a pessoa entendeu. Idioma, direção, precisão, atraso e apresentação podem falhar independentemente.

O código SIP descreve controle de sessão. A métrica humana precisa de observação no nível do usuário e deve permanecer desconhecida quando ela não existe.

Transformar sucesso de infraestrutura em sucesso de acessibilidade seria repetir o mesmo erro do 603: copiar uma classificação para um evento diferente.

Códigos iguais ajudam a correlacionar, não a fundir

É legítimo usar o mesmo código para correlacionar as duas pernas. A deve receber uma síntese útil do resultado observado por T.

O problema começa quando correlação é tratada como identidade. Nesse ponto, logs escondem T como tomador de decisões, políticas de privacidade ficam invisíveis e o destino recebe autoria que talvez pertença ao serviço.

A Minimum Initial Specification de Lu Heng serve como lente declarada: o registro mínimo deve conter invocador, autorização, lista protegida, privacidade, duas transações, respostas por perna, história causal e identidade do serviço.

Reality Layers mantém código, transação, identidade, mídia e compreensão em camadas diferentes. A igualdade em uma camada não preenche as demais.

A ponte concentrou poder e prova

Depois que o modelo de conferência é escolhido, T autentica A, aplica autorização, interpreta o destinatário, aplica privacidade, reconstrói o From, gera SDP, origina o segundo INVITE, recebe B, cria a resposta para A e transforma mídia.

Cada ato pode falhar separadamente. Um evento único chamado “sessão de transcodificação” não explica qual política ou agente produziu o resultado.

Essa é a fronteira com a cobertura da RFC 5369. O framework discute quando a conversão é necessária e compara topologias. A RFC 5370 mostra o que é quebrado e reconstruído dentro do modelo de ponte.

O ensinamento não é desconfiar de 603. É exigir que o código viaje com a transação, a autoridade e a história que permitem lê-lo corretamente.