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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


8.1 Comportamento do UAC

Essa seção cobre o comprtamento de UAC fora de um diálogo.


8.1.1 Gerando a Requisição

Uma requisição SIP válida formulada por um UAC PRECISA, no mínimo, conter os seguintes campos-cabeçalhos: To, From, CSeq, Call-ID, Max-Forwards e Via; todos esses campos-cabeçalhos são obrigatórios em todas requisições SIP. Esses seis campos-cabeçalhos são blocos fundamentais para montagem de uma mensagem SIP, porque eles conjuntamente fornecem a maioria dos serviços de roteamento críticos de mensagem incluindo o endereçamento de mensagens, o roteamento de respostas, limite de propagação de mensagens, ordenação de mensagens, e a identificação única de transações. Esses campos-cabeçalhos entrarão além da linha de requisição obrigatória, que contém o método, o Request-URI e a versão do SIP.

Exemplos de requisições enviadas fora de um diálogo incluem um INVITE para estabelecer uma sessão (Seção 13) e um OPTIONS para consultar capacidades (Seção 11).


8.1.1.1 Request-URI

O Request-URI inicial da mensagem DEVE ser definido com o valor do URI no campo To. Uma exceção notável é o método REGISTER; o comportamento de fixar a Request-URI do REGISTER é dado na Seção 10. Também pode ser indesejável por razões de privacidade ou conveniência definir esses campos com o mesmo valor (especialmente se o UA originador espera que o Request-URI será alterada durante o trânsito).

Em algumas circunstâncias especiais, a presença de um conjunto de rotas pré-existentes podem afetar a Request-URI da mensagem. Um conjunto de rotas pré-existente é um conjunto ordenado de URI's que identificam uma sequência de servidores, para quais um UAC enviará requisições saintes que estão fora de um diálogo. Comumente, são configurados no UA por um usuário ou provedor de serviço manualmente, ou através de algum outro mecanismo não-SIP. Quando um provedor deseja configurar um UA com um proxy saite, é RECOMENDADO que isso seja feito fornecendo-lhe com um conjunto de rota pré-existente com uma única URI, aquela do proxy sainte.

Quando um conjunto de rotas pré-existente estiver presente, os procedimentos para preencher o Request-URI e campo-cabeçalho Route detalhado na Seção 12.2.1.1 PRECISA ser seguido (mesmo que não exista nenhum diálogo), usando o Request-URI desejada como o URI do destino remoto.






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

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.