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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


de clareza, os dois estão separados nessa ilustração. Observe também que UA's podem enviar suas requisições através de um servidor proxy, a fim de chegar a um registrador se os dois forem elementos separados.

O SIP não obriga um mecanismo específico para implementar o serviço de localização. A única exigência é que um registrador em um domínio PRECISA ser capaz de ler e de gravar dados no serviço de localização, e um servidor proxy ou um redirect nesse domínio PRECISA ser capaz de ler essa mesma informação. Um registrador PODE estar co-localizado em um determinado servidor proxy SIP no mesmo domínio.


10.2 Construindo a Requisição REGISTER

Requisições REGISTER adicionam, removem e consultam ligações. Uma requisição REGISTER pode adicionar uma nova ligação entre um endereço-de-registro e um ou mais endereços de contato. Fazer registro em nome de um endereço-de-registro particular pode ser realizado por uma terceira parte devidamente autorizada. Um cliente também pode remover vinculações anteriores ou consultar para determinar quais vínculos estão atualmente em vigor para um endereço-de-registro.

Exceto quando mencionado, a construção da requisição REGISTER e o comportamento dos clientes que enviam uma requisição REGISTER é idêntico ao comportamento geral do UAC descrito na Seção 8.1 e Seção 17.1.

Uma requisição REGISTER não estabelece um diálogo. Um UAC PODE incluir um campo cabeçalho Route em uma requisição REGISTER baseado em um conjunto de rota pré-existente como descrito na Seção 8.1. O campo-cabeçalho Record-Route não tem nenhum significado em requisições REGISTER ou respostas, e PRECISA ser ignorado se estiver presente. Em particular, o UAC NÃO PODE criar um novo conjunto de rota baseado na presença ou ausência de um campo-cabeçalho Record-Route em qualquer resposta a uma requisição REGISTER.

Os campos-cabeçalhos a seguir, exceto Contact, PRECISAM ser incluídos em uma requisição REGISTER. Um campo-cabeçalho Contact PODE ser incluído:

Request-URI: Request-URI nomeiam o domínio do serviço de localização para qual o pedido de registo se destina (por exemplo, "sip:chicago.com"). Os componentes "userinfo" e "@" do URI do SIP NÃO PODE estar presente.

To: O campo cabeçalho To contém o endereço-de-registro cujo registo deve ser criado, consultado ou modificado. O campo-cabeçalho To e o campo Request-URI normalmente diferem, porque o anterior contém um nome de usuário. Este endereço-de-registro PRECISA ser um URI do SIP ou um URI do SIPS.





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

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.