Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


8.1.1.6 Max-Forwards

O campo-cabeçalho Max-Forwards serve para limitar o número de saltos que uma requisição pode trânsitar na direção ao seu destino. Ele consiste de um inteiro que é diminuído por um a cada salto. Se o valor de Max-Forwards chegar a 0 antes da requisição alcançar ao seu destino, ela será rejeitada com uma resposta de erro 483 (Too Many Hops).

Um UAC PRECISA inserir um campo-cabeçalho Max-Forwards em cada requisição que ele origina com um valor que DEVE ser 70. Esse número foi escolhido para ser suficientemente grande para garantir que a requisição não seria descartada em alguma rede SIP quando não houvessem loops, mas não tão grande quanto a consumir recursos de proxy quando ocorrer um loop. Os valores baixos devem ser usados com cautela e apenas em redes onde a topologia é conhecida pelo UA.


8.1.1.7 Via

O campo-cabeçalho Via indica que o transporte usado pela transação e identifica o local onde a resposta deve ser enviada. Um valor do campo-cabeçalho Via é adicionado somente após o transporte que será usado atingir o próximo salto tenha sido selecionado (o que pode envolver o uso dos procedimentos em [4]).

Quando o UAC cria uma requisição, ele PRECISA inserir um campo Via nessa requisição. O nome e a versão do protocolo no campo-cabeçalho PRECISA ser SIP e 2.0, respectivamente. O valor do campo-cabeçalho Via PRECISA conter um parâmetro branch. Esse parâmetro é usado para identificar a transação criada por essa requisição. Esse parâmetro é usado tanto pelo cliente quanto pelo servidor.

O valor do parâmetro branch PRECISA ser único no espaço e no tempo para todas requisições enviadas pelo UA. As exceções a essa regra são CANCEL e ACK para respostas não-2xx. Como discutido abaixo, uma requisição CANCEL terá o mesmo valor do parâmetro branch que da a branch que ela cancela. Como discutido na Seção 17.1.1.3, um ACK para uma resposta não-2xx também terá o mesmo branch ID que do INVITE cuja resposta ele reconhece.

A propriedade singular do parâmetro branch ID, para facilitar o seu uso como um ID da transação, não fazia parte da RFC 2543.

O branch ID inserido por um elemento em conformidade com essa especificação PRECISA sempre começar com os caracteres "z9hG4bK". Esses 7 caracteres são usados como um cookie mágico (7 é considerado suficiente para garantir que implementação baseada na antiga RFC 2543 não pegaria esse valor), de modo que os servidores que recebem a requisição pode determinar que o branch ID foi construído na forma descrita por essa 





Rosenberg, et. al.          Standards Track                    [Página 39]

Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:

User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.

Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de 
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:

MUST:
PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO, 
NECESSITAR, É MANDATÓRIO.

MUST NOT:
NÃO PODE, É PROIBIDO, É VEDADO.

SHOULD:
DEVE, É RECOMENDADO.

SHOULD NOT:
NÃO DEVE, NÃO É RECOMENDADO.

MAY:
PODE, É OPCIONAL.