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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


especificação (isto é, globalmente único). Além desse requisito, o formato preciso do token branch é definido pela implementação.

Os componentes maddr, ttl e sent-by do cabeçalho Via serão definidos quando a requisição é processada pela camada de transporte (Seção 18).

O processamento do Via por proxy's é descrito no Item 8 da Seção 16.6 e no Item 3 da Seção 16.7.


8.1.1.8 Contact

O campo-cabeçalho Contact fornece um URI do SIP ou do SIPS que pode ser usado para contactar essa instância específica do UA em requisições subsequentes. O campo-cabeçalho Contact PRECISA estar presentes e conter exatamente um URI SIP ou SIPS em qualquer requisição que pode resultar no estabelecimento de um diálogo. Para os métodos definidos nessa especificação, que inclui apenas a requisição INVITE. Para essas requisições, o escopo de Contact é global. Ou seja, o valor do campo-cabeçalho Contact contém o URI no qual o UA gostaria de receber requisições, e esse URI PRECISA ser válido mesmo se usado em requisições subseqüentes fora de qualquer diálogo.

Se o Request-URI ou o valor do campo-cabeçalho Route mais alto contiver um URI do SIPS, o campo-cabeçalho Contact PRECISA conter um URI do SIPS também.

Para mais informações sobre o campo-cabeçalho Contact, consulte Seção 20.10.


8.1.1.9 Supported e Require

Se o UAC suportar extensões ao SIP que podem ser aplicadas pelo servidor na resposta, o UAC DEVE incluir um campo-cabeçalho Supported na requisição que lista tags de opção (Seção 19.2) para essas extensões.

As tags de opções listadas PRECISAM apenas se referem as extensões definidas nas RFC's em trilha de padronizações. Isto é para evitar servidores de insistir que clientes implementem recursos não-padrões definidos por fornecedor para receber serviço. Extensões definidas por RFC's experimental e informacionais são explicitamente excluídas de uso com o campo-cabeçalho Supported em uma requisição, porque elas também são muito usadas para documentar extensões definidas por fabricante.

Se o UAC gostaria de insistir que um UAS compreenda uma extensão que o UAC aplicará à requisição para processar a requisição, ele PRECISA inserir um campo-cabeçalho Require à requisição listando a tag de opção para essa extensão. Se o UAC pretende aplicar uma extensão à requisição e insistir que algum proxy's que são 



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

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.