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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


A resposta 200 (OK) do registrador contém uma lista de campos Contact enumerando todos bindings atuais. O UA compara cada endereço de contato pra ver se ele criou o endereço para contato, usando regras de comparação da Seção 19.1.4. Se assim for, ele atualiza o intervalo de tempo de expiração de acordo com o parâmetro expires ou, se ausente, o valor do campo Expires. O UA então lança uma requisição REGISTER para cada um de seus bindings antes que o intervalo de validade expire. Ele PODE combinar várias atualizações em uma requisição REGISTER.

Um UA DEVE usar o mesmo Call-ID para todos pedidos de registo durante um único ciclo de boot. Atualizações do Pedido de registo DEVEM ser enviadas ao mesmo endereço de rede que do registro original, a menos que sejam redirecionadas.


10.2.5 Definindo o Clock Interno

Se a resposta a uma requisição REGISTER contiver um campo-cabeçalho Date, o cliente PODE usar esse campo-cabeçalho para saber a hora atual para definir quaisquer relógios internos que haja.


10.2.6 Descobrindo um Registrador

UA's podem usar três formas para determinar o endereço ao qual enviar pedidos de registro: por configuração, usando o endereço-de-registro e multicast. Um UA pode ser configurado, de modos além do escopo dessa especificação, com um endereço-de-registro. Se não houver nenhum endereço configurado do registrador, o UA DEVE usar a parte host do endereço-de-registro, como a Request-URI e o endereço da requisição lá, usando os mecanismos normais de localização de servidor SIP [4]. Por exemplo, o UA do usuário "sip:carol@chicago.com" endereça a requisição REGISTER como "sip:chicago.com".

Finalmente, um UA pode ser configurado para usar multicast. Pedidos de registro multicast são destinados ao notório endereço multicast de "todos servidores SIP" "sip.mcast.net" (224.0.1.75 para IPv4). Nenhum endereço multicast conhecido IPv6 foi atribuído ainda; tal alocação será documentada separadamente quando for necessário. UA's SIP PODEM ouvir esse endereço e usá-lo para tomar ciência da localização de outros usuários locais (ver [33]); contudo, eles não respondem à requisição.

Pedido de registro por multicast pode ser inadequado em alguns ambientes, por exemplo, se várias empresas compartilham a mesma rede local.


10.2.7 Transmitindo uma Requisição

Uma vez que o método REGISTER foi construído, e o destino da mensagem identificado, os UAC's seguem os procedimentos descritos na Seção 8.1.2 ao entregar o REGISTER à camada de transação.





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

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.