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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


atravessado entenda essa extensão, ele PRECISA inserir um campo-cabeçalho Proxy-Require à requisição listando a tag de opção para essa extensão.

Da mesma forma que o campo-cabeçalho Supported, as tags de opção nos campos-cabeçalhos Require e Proxy-Require PRECISAM se referir só a extensões definidas nas RFC's em trilha de padronizações.


8.1.1.10 Componentes Adicionais de Mensagem

Após uma nova requisição ter sido criada, e os campos-cabeçalhos acima descritos terem sido devidamente construídos, quaisquer campos-cabeçalhos opcionais adicional são adicionados, porque são qualquer campos-cabeçalhos específicos ao método.

Requisições SIP PODEM conter um corpo de mensagem codificado em MIME. Independente do tipo de corpo que uma requisição contém, certos campos-cabeçalhos precisam ser formulados para caracterizar o conteúdo do corpo. Para mais informações sobre esses campos-cabeçalhos, consulte as Seções 20.11 até 20.15.


8.1.2 Enviando a Requisição

O destino da requisição é então computado. A menos que haja especificação em contrário na política local, o destino PRECISA ser determinado aplicando os procedimentos DNS descritos em [4] como segue. Se o primeiro elemento no conjunto de rota indicou um roteador estrito (resultando na formação da requisição, conforme descrito na Seção 12.2.1.1), os procedimentos PRECISAM ser aplicados ao Request-URI da requisição. Caso contrário, os procedimentos são aplicados ao valor do primeiro campo-cabeçalho Route na requisição (se existir algum), ou ao Request-URI da requisição, se não houver nenhum campo-cabeçalho Route presentes. Esses procedimentos geram um conjunto ordenado de endereço, porta e transportes a tentar. Independente de qual URI seja usada como entrada para os procedimentos de [4], se o Request-URI especifica um recurso SIPS, o UAC PRECISA seguir os procedimentos de [4], como se a URI imputada fosse um URI do SIPS.

Política local PODE especificar um conjunto alternativo de destinos a tentar. Se o Request-URI contiver uma URI do SIPS, qualquer destino alternativo PRECISA ser contactado com TLS. Além disso, não existe nenhuma restrição sobre os destinos alternativos se a requisição não contiver nenhum campo-cabeçalho Route. Isso fornece uma alternativa simples para uma rota pré-existente definida como uma maneira de especificar um proxy sainte. No entanto, essa abordagem para configurar um proxy sainte NÃO é RECOMENDADA; uma rota pré-existente definida com um único URI DEVE ser usada. Se a requisição contiver um campo-cabeçalho Route, a requisição DEVE ser enviada aos locais derivados de seu valor mais alto, mas PODE ser enviado a qualquer servidor que o UA está certo honrará as políticas de Route e do Request-URI especificadas nesse documento (em oposição àqueles na RFC 2543). Em particular, um UAC configurado com um proxy sainte DEVE 




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

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.