Resumo

  • O PRACK acusa o recebimento de uma resposta provisória confiável específica. O 2xx que responde ao PRACK não é a resposta final da INVITE.
  • RSeq e RAck preservam identidade e ordem dentro do diálogo, inclusive quando há oferta/resposta antes do atendimento; nenhum desses sinais comprova que a mídia chegou ao usuário.

O problema não era fazer a chamada terminar mais cedo

No RFC 3261, uma INVITE pode receber nenhuma, uma ou várias respostas provisórias antes do resultado final. Uma resposta 101–199 pode indicar progresso e criar um diálogo antecipado. A aceitação vem em 2xx; redirecionamento, recusa ou falha chegam em outras classes finais. A especificação básica, porém, não entrega essas respostas provisórias de modo confiável.

Em uma integração com a rede telefônica, perder uma indicação provisória podia significar perder mais do que um ícone de “chamando”. Uma resposta podia carregar estado de diálogo ou uma descrição de sessão necessária para mídia antecipada. O resultado final continuava independente, mas o caminho até ele já tinha adquirido informação que precisava ser confirmada.

O RFC 3262 não promoveu toda resposta intermediária a resultado. Ele definiu a opção 100rel e o pedido PRACK. Com Supported: 100rel, o servidor pode enviar de forma confiável uma resposta provisória não 100 à INVITE. Com Require: 100rel, deve fazê-lo ou rejeitar a exigência de extensão. A resposta 100 Trying fica fora porque é salto a salto, enquanto o mecanismo de respostas provisórias confiáveis é fim a fim.

O endereço exato da confirmação

Uma 1xx confiável traz Require: 100rel e um número RSeq. A primeira escolha ocorre dentro do intervalo prescrito, e a numeração pertence à transação. Isso impede tratar um RSeq como identidade global de chamada.

A resposta é retransmitida com recuo exponencial a partir de T1. Para interromper a retransmissão, não basta chegar qualquer PRACK: o pedido precisa estar no mesmo diálogo e trazer em RAck o RSeq, o número CSeq e o método da resposta reconhecida. São três coordenadas que ligam a confirmação ao estado correto.

Se houver correspondência com uma resposta ainda pendente, o servidor devolve 2xx ao PRACK e remove aquela 1xx da lista de não confirmadas. Se não houver correspondência, devolve 481. A diferença de transação é a chave: o 2xx confirma que o PRACK foi processado; a INVITE ainda espera sua própria resposta final.

Por isso o texto do RFC diz que o PRACK desempenha papel parecido com ACK, mas também realça a diferença. PRACK é um pedido SIP comum dentro do diálogo, como BYE, protegido salto a salto por sua própria transação e respondido separadamente. Ele não toma emprestada a autoridade do ACK final.

Uma fila curta e ordenada

As confirmações não são cumulativas. Para controlar congestionamento, o RFC recomenda uma única resposta provisória confiável pendente e proíbe enviar a segunda antes de confirmar a primeira. Nas seguintes, RSeq cresce exatamente de um em um e não dá a volta.

O destinatário reconhece uma retransmissão por diálogo, CSeq e RSeq e descarta a cópia. Se uma resposta posterior chegar fora de ordem, não pode ser processada nem receber PRACK naquele momento; pode ser guardada à espera da lacuna. Assim, “confiável” inclui ordem e correspondência, não apenas eventual aparição em uma captura de pacotes.

Se durante 64*T1 não chegar o PRACK correspondente, o UAS deve, segundo a recomendação normativa, rejeitar o pedido original com 5xx. A extensão resolve uma perda silenciosa criando um estado observável, mas esse estado tem custo: temporizadores, memória de sequência, rota do diálogo e autenticação podem falhar.

Uma sessão pode ganhar parâmetros antes de ganhar um sim

O PRACK aceita corpo. Quando a INVITE contém uma oferta, uma resposta provisória confiável pode trazer a resposta. Quando a INVITE não contém oferta, a primeira mensagem confiável pode apresentar uma na 1xx e o PRACK deve respondê-la. Um PRACK também pode levar nova oferta; nesse caso, o 2xx do PRACK contém a resposta.

Concluir oferta/resposta não conclui a INVITE. O RFC 3262 orienta o agente a estabelecer a sessão segundo os parâmetros negociados mesmo que o pedido inicial ainda não tenha resposta final. E, se uma 1xx confiável com descrição de sessão continua sem PRACK, o UAS não pode enviar o 2xx final de aceitação até que ela seja confirmada. A dependência protege a negociação; não transforma a confirmação em atendimento.

O RFC 6337 documenta as sutilezas posteriores. Suporte dos dois lados a 100rel não torna automaticamente confiáveis todas as respostas provisórias. Quando a INVITE já contém oferta, o primeiro SDP em uma resposta confiável sem falha é a resposta efetiva; um SDP anterior em 1xx não confiável funciona apenas como prévia.

O método UPDATE do RFC 3311 permite alterar parâmetros em diálogos antecipados ou confirmados. Isso oferece outros caminhos de negociação, mas não apaga as fronteiras. UPDATE, PRACK e INVITE conservam pedidos, respostas e estados próprios.

A mídia não assina o recibo da sinalização

O RFC 3960 descreve música, anúncios, tons e outras formas de mídia antecipada antes da resposta final. O fluxo RTP e a sinalização SIP não percorrem necessariamente o mesmo caminho nem chegam na mesma ordem. Uma ponta pode observar áudio antes do sinal que o contextualiza.

Logo, PRACK não comprova entrega de RTP, audição humana ou qualidade. Ouvir uma gravação também não prova que um RAck correspondente chegou ao UAS. Um painel pode apresentar as duas linhas de tempo juntas; não deve substituir uma pela outra.

O registro da IANA confirma que PRACK, RAck, RSeq e 100rel são atribuições formais referenciadas ao RFC 3262. Ele não informa implantação, participação de tráfego ou conformidade de um equipamento.

Há ainda uma fronteira de segurança. Um invasor capaz de injetar PRACK poderia fazer cessar a retransmissão de informação provisória importante. Por isso o RFC pede que PRACK seja autenticado como os demais pedidos. Uma sequência correta demonstra encaixe de estado, não identidade confiável.

Fontes