RFC 3261 Português Página 64

RFC 3261 SIP: Session Initiation Protocol Junho 2002

Ao receber uma requisição REGISTER, um registrador segue essas etapas:

1. O registrador inspeciona o Request-URI para determinar se ele tem acesso ou não aos bindings do domínio identificado na Request-URI. Se não tiver acesso, e se o servidor também age como um servidor proxy, o servidor DEVE encaminhar a requisição ao domínio endereçado, seguindo o comportamento geral para proxy-iar mensagens descritas na Seção 16.

2. Para garantir ao registrador suportar quaisquer extensões necessárias, o registrador PRECISA processar valores do campo-cabeçalho Require como descritos para UAS's na Seção 8.2.2.

3. Um registrador DEVE autenticar o UAC. Mecanismos para autenticação de agentes-usuários SIP são descritos na Seção 22. Comportamento no processo de registro, de modo algum sobreescreve o infraestrutura genérica de autenticação do SIP. Se nenhum mecanismo de autenticação estiver disponível, o registrador PODE tomar o endereço de From como a identidade declarada do originador da requisição.

4. O registrador DEVE determinar se o usuário autenticado está autorizado a modificar pedidos de registro para esse endereço-de-registro. Por exemplo, um registrador pode consultar um banco de dados de autorização que mapeia nomes de usuário para uma lista de endereços-de-registro para quais esse usuário tem autorização para modificar bindings. Se o usuário autenticado não for autorizado a modificar bindings, o registrador PRECISA retornar uma resposta 403 (Forbidden) e pular os passos restantes.

Em arquiteturas que suportam a operação de registro por terceira parte, uma entidade pode ser responsável por atualizar os pedidos de registro associados com os múltiplos endereços-de-registro.

5. O registrador extrai o endereço-de-registro do campo-cabeçalho To da requisição. Se o endereço-de-registro não for válido para o domínio no Request-URI, o registrador PRECISA enviar uma resposta 404 (Not Found) e pular as etapas restantes. O URI PRECISA então ser convertido em uma forma canônica. Para fazer isso, todos os parâmetros URI PRECISAM ser removidos (incluindo user-param), e quaisquer caracteres escapados PRECISAM ser convertidos em suas formas não escapados. O resultado serve como um índice para a lista bindings.

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

Página Anterior

Tabela de Conteúdo

Página Seguinte



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.