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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


6. O registrador verifica se a requisição contém ou não o campo-cabeçalho Contact. Se não tiver, ele pula para a última etapa. Se o campo-cabeçalho Contact estiver presente, o registrador verifica se há um valor no campo Contact que contém o valor especial "*" e um campo Expires. Se a requisição tiver campos Contact adicionais ou um tempo de expiração diferente de zero, a requisição é inválida, e o servidor PRECISA retornar uma resposta 400 (Invalid Request) e pular as etapas restantes. Se não, o registrador verifica se o Call-ID confere ou não com o valor armazenado para cada binding. Se não, ele PRECISA remover o binding. Se não conferir, ele PRECISA retirar o binding somente se o campo CSeq na requisição for superior ao valor armazenado para esse binding. Caso contrário, a atualização PRECISA ser abortada e a requisição falhar.

7. O registrador agora processa cada endereço de contato no campo-cabeçalho Contact de cada vez. Para cada endereço, ele determina o intervalo de expiração da seguinte forma:

-  Se o valor do campo tem um parâmetro "expires", esse valor PRECISA ser tomado como a expiração requisitada.

-  Se não houver tal parâmetro, mas a requisição tem um campo-cabeçalho Expires, esse valor PRECISA ser tomado como a expiração requisitada.

-  Se não houver nenhum, um valor padrão configurado localmente PRECISA ser tomado como a expiração requisitada.

O registrador PODE escolher um tempo expiração menor do que o intervalo de expiração requisitada. Se e somente se, o intervalo de expiração requisitado for maior que zero E menor que uma hora E menos que um mínimo configurado no registrador, o registrador PODE rejeitar o pedido de registro com uma resposta 423 (Interval Too Brief). Essa resposta PRECISA conter um campo-cabeçalho Min-Expires que declara o intervalo mínimo de expiração que o registrador está disposto a honrar. Ele então pula as etapas restantes.

Permitindo ao registrador definir o intervalo de registro protege contra freqüentes atualizações de registro excessivas ao mesmo tempo que limita o estado que ele precisa para manter e diminuir a possibilidade de pedidos de registro prestes a ficar obsoletos. O intervalo de expiração de um registro é freqüentemente usado na criação de serviços. Um exemplo é um serviço de siga-me, onde o usuário só poderá estar disponível em um terminal por um período curto. Portanto, registradores devem aceitar registros curtos, uma requisição só deve ser rejeitada se o intervalo for tão curto que as atualizações degradariam o desempenho do registrador.






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

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.