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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Com um comprimento de 32 bits, um cliente pode gerar, dentro de uma única chamada, uma requisição a cada segundo por quase 136 anos antes de precisar recomeçar a contagem. O valor inicial do número de seqüência é escolhido de forma que requisições subsequentes dentro da mesma chamada não vai reiniciar a contagem. Um valor inicial diferente de zero permite aos clientes usar um número de seqüência inicial com base no tempo. Um cliente pode, por exemplo, escolher os 31 bits mais significativos de um relógio com segundos de 32-bit como um número de seqüência inicial.

O UAC usa o alvo remoto e conjunto de rota para construir os campos-cabeçalhos Request-URI e Route da requisição.

Se o conjunto de rotas estiver vazio, o UAC local PRECISA colocar o URI do alvo remoto no Request-URI. O UAC NÃO PODE adicionar um campo-cabeçalho Route à requisição.

Se o conjunto de rotas não estiver vazio, e o primeiro URI no conjunto de rotas tiver o parâmetro lr (ver Seção 19.1.1), o UAC local PRECISA colocar a URI do alvo remoto no Request-URI e PRECISA incluir um campo-cabeçalho Route contendo os valores do conjunto de rotas em ordem, incluindo todos os parâmetros.

Se o conjunto de rotas não estiver vazio, e sua primeira URI não tiver o parâmetro lr, o UAC local PRECISA colocar o primeiro URI do conjunto de rotas no Request-URI, retirando quaisquer parâmetros que não sejam permitidos em um Request-URI. O UAC PRECISA adicionar um campo-cabeçalho Route contendo o restante dos valores no conjunto de rotas em ordem, incluindo todos os parâmetros. O UAC PRECISA então colocar o URI do destino remoto no campo-cabeçalho Route como o último valor.

Por exemplo, se o alvo remoto for sip:user@remoteua e o conjunto de rotas contém:

<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>

A requisição será formada com os seguintes campos-cabeçalhos Request-URI e Route:

   METHOD sip:proxy1
   Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>

Se o primeiro URI do conjunto de rotas não tiver o parâmetro lr, o proxy indicado não entende os mecanismos de roteamento descritos nesse documento e agirá conforme especificado na RFC 2543, substituindo o Request-URI pelo primeiro valor do campo-cabeçalho Route que ele recebe enquanto encaminha a mensagem. Colocar o Request-URI no final do campo-cabeçalho Route preserva as 



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

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.