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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


não for a identidade do UAS. No entanto, é RECOMENDADO que um UAS aceite requisições mesmo que ele não reconheça o esquema de URI (por exemplo, tel: URI) no campo-cabeçalho To, ou se o campo-cabeçalho To não enderece um usuário conhecido ou atual desse UAS. Se, por outro lado, o UAS decidir rejeitar a requisição, ele DEVE gerar uma resposta com um código status 403 (Forbidden) e passá-la à transação do servidor para transmissão.

No entanto, o Request-URI identifica o UAS que é para processar a requisição. Se o Request-URI usa um esquema não é suportado pelo UAS, ele DEVE rejeitar a requisição com uma resposta 416 (Unsupported URI Scheme). Se o Request-URI não identifica um endereço pelo qual o UAS está disposto a aceitar requisições, ele DEVE rejeitar a requisição com uma resposta 404 (Not Found). Tipicamente, um UA que usa o método REGISTER para associar seu endereço-de-registro a um endereço de contacto específico verá requisições cujo Request-URI é igual a esse endereço de contato. Outras fontes potenciais de Request-URI's recebidas incluem os campos-cabeçalhos Contact de requisições e respostas enviadas pelo UA que estabelece ou atualiza diálogos.


Requisições Mescladas

Se a requisição não tiver nenhuma tag no campo cabeçalho To, o núcleo UAS PRECISA verificar a requisição contra transações em curso. Se a tag de From, Call-ID, e CSeq bater exatamente com aquelas associadas com uma transação em curso, mas a requisição não coincide com essa transação (baseada nas regras de coicidencias na Seção 17.2.3), o núcleo UAS DEVE gerar uma resposta 482 (Loop Detected) e passá-la à transação do servidor.

A mesma requisição já chegou no UAS mais de uma vez, seguindo caminhos diferentes, provavelmente devido ao forking. O UAS processa a primeira de tal requisição recebida e responde com um 482 (Loop Detected) ao resto delas.


8.2.2.3 Require

Supondo que o UAS decide que ele é o elemento adequado para processar a requisição, ele examina o campo-cabeçalho Require, se estiver presente.

O campo-cabeçalho Require é usado por um UAC para diz a uma UAS sobre extensões SIP que o UAC espera que o UAS suporte a fim de processar a requisição corretamente. Seu formato é descrito na Seção 20.32. Se um UAS não entende uma tag de opção listada em um campo-cabeçalho Require, ele PRECISA responder gerando uma resposta com código status 420 (Bad Extension). O UAS PRECISA adicionar um campo-cabeçalho Unsupported, e listar aquelas opções que ele não entende dentre aquelas listadas no campo-cabeçalho Require da requisição.






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

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.