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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Se nenhum desses mecanismos que expressa um tempo de expiração sugerido estiver presente em uma requisição REGISTER, o cliente está indicando seu desejo para o servidor escolher.


10.2.1.2 Preferências entre Endereços de Contato

Se mais de um Contact for enviado em uma requisição REGISTER, o UA se registrando pretende associar todos os valores URI's desses campos-cabeçalhos Contact com o endereço-de-registro presente no campo To. Essa lista pode ser priorizada com o parâmetro "q" no campo-cabeçalho Contact. O parâmetro "q" indica uma preferência relativa do valor particular do campo-cabeçalho Contact em comparado com outros bindings para esse endereço-de-registro. A Seção 16.6 descreve como um servidor proxy usa essa indicação de preferência.


10.2.2 Removendo Bindings

Pedidos de registro são estados flexíveis e expiram a menos que sejam atualizados, mas também podem ser removidos explicitamente. Um cliente pode tentar influenciar o intervalo de expiração selecionados pelo registrador como descrito na Seção 10.2.1. Um UA requisita a remoção imediata de um binding, especificando um intervalo de expiração "0" para esse endereço de contato em uma requisição REGISTER. UA's DEVEM suportar esse mecanismo de modo que bindings possam ser removidos antes que o intervalo de expiração tenha expirado.

O valor "*" do campo-cabeçalho Contact específicos de REGISTER se aplica a todos pedidos de registros, mas NÃO PODE ser usado quando o campo-cabeçalho Expires estiver presente com um valor "0".

O uso do valor "*" no campo-cabeçalho Contact permite a um UA ao registrar remover todos bindings associados com um endereço-de-registro, sem saber seus valores precisos.


10.2.3 Trazendo Bindings

Uma resposta de sucesso para uma requisição REGISTER contém a lista completa de bindings existentes, independentemente se a requisição continha ou não um campo-cabeçalho Contact. Se nenhum campo-cabeçalho Contact estiver presente em uma requisição REGISTER, a lista bindings é deixada inalterada.


10.2.4 Atualizado Bindings

Cada UA é responsável por atualizar os bindings que ele estabeleceu antes. Um UA NÃO DEVE atualizar bindings estabelecido por outros UA's.





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

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.