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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Os valores do campo-cabeçalho Contact da requisição tipicamente consistem de URI do SIP ou do SIPS que identifica endpoints SIP particulares (por exemplo, "sip: carol@cube2214a.chicago.com"), mas ele PODEM usar qualquer esquema de URI. Um UA do SIP pode escolher registrar os números de telefone (com a URL tel, RFC 2806 [9]) ou endereços de e-mail (com um URL mailto, RFC 2368 [32]) como Contatos para um endereço-de-registro, por exemplo.

Por exemplo, Carol, com endereço-de-registro "sip:carol@chicago.com", iria registrar no registrador SIP do domínio chicago.com. Os pedidos de registro dela então seriam usados por um servidor proxy no domínio chicago.com para rotear requisições ao endereço-de-registro de Carol ao endpoint SIP dela.

Uma vez um cliente tenha estabelecido bindings com um registrador, ele PODE enviar pedidos de registos subsequentes contendo novas bindings ou modificações a bindings existentes quando necessário. A resposta 2xx à requisição REGISTER conterá, em um campo-cabeçalho Contact, uma lista completa de bindings que foram registrados para esse endereço-de-registro nesse registrador.

Se o endereço-de-registro no campo-cabeçalho To de uma requisição REGISTER for um URI do SIPS, então quaisquer valores do campo-cabeçalho Contact da requisição também DEVE ser URI's do SIPS. Os clientes devem somente registrar URI's não-SIPS sob um endereço-de-registro SIPS, quando a segurança dos recursos representados pelo endereço de contato for garantidos por outros meios. Isso pode ser aplicável a URI's que invocam protocolos que não seja o SIP, ou dispositivos SIP garantidos por protocolos que não o TLS.

Pedidos de registro não precisam atualizar todas os bindings. Tipicamente, um UA só atualiza seus próprios endereços de contato.


10.2.1.1 Definindo o Intervalo de Expiração de Endereços de Contato

Quando um cliente envia uma requisição REGISTER, ele PODE sugerir um intervalo de expiração que indica quanto tempo o cliente desejaria que o seu registro ficasse válido. (Conforme descrito na Seção 10.3, o registrador seleciona o intervalo de tempo real baseado em sua política local).

Existem duas maneiras pelas quais um cliente pode sugerir um intervalo de validade para um binding: através de um campo-cabeçalho Expires ou através do parâmetro "expires" do cabeçalho Contact. O último permite que intervalos de validade sejam sugerido em uma base por-binding quando mais de um binding for fornecido em uma única requisição REGISTER, enquanto o primeiro sugere um intervalo de expiração como valor para todo campo-cabeçalho Contact que não contenham o parâmetro "expires".



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

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.