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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Option tags são definidas nas RFC's em trâmite de padronização. Isso é uma mudança das práticas passadas, e foi instituído para continuar garantindo a interoperabilidade multi-fabricantes (ver discussão na Seção 20.32 e na Seção 20.37). Um registro no IANA de option tags é usada para assegurar consulta fácil.


19.3 Tags

O parâmetro "tag" é usado nos campos-cabeçalhos To e From de mensagens SIP. Ele serve como um mecanismo geral para identificar um diálogo, que é a combinação do Call-ID junto com duas tags, uma de cada participante no diálogo. Quando um UA envia uma requisição fora de um diálogo, ele contém uma tag apenas, fornecendo "metade" do ID do diálogo. O diálogo é completado a partir da(s) resposta(s), cada um dos quais contribui com a segunda metade no campo-cabeçalho To. A bifurcação de requisições SIP significa que múltiplos diálogos podem ser estabelecidos a partir de uma simples requisição. Isso também explica a necessidade de identificador do diálogo pelos dois lados; sem a contribuição dos destinatários, o originador não poderia distinguir os múltiplos diálogos estabelecidos a partir de uma simples requisição.

Quando a tag é gerada por um UA para inserção em uma requisição ou resposta, ela PRECISA ser globalmente única e criptograficamente aleatória com pelo menos 32 bits de aleatoriedade. Uma propriedade dessa exigência de seleção é que um UA vai colocar uma tag diferente no cabeçalho From de um INVITE comparada a tag que seria colocada no cabeçalho To da resposta ao mesmo INVITE. Isso é necessário para que um UA se auto convide a uma sessão, um caso comum para "hairpinning" de chamadas em gateways PSTN. De forma similar, dois INVITE's para diferentes chamadas terão diferentes tags From, e duas respostas para diferentes chamadas terão diferentes tags To.

Além da exigência de exclusividade global, o algoritmo para gerar uma tag é específico de implementação. Tags são úteis em sistemas tolerantes a falhas, onde um diálogo deve ser recuperado em um servidor alternativo após uma falha. Um UAS pode selecionar a tag de tal forma que um backup pode reconhecer uma requisição como parte de um diálogo no servidor que falhou e, portanto, determinar que ele deve tentar recuperar o diálogo e qualquer outro estado associado a ele.


20 Campos-Cabeçalhos

A sintaxe geral para campos-cabeçalhos é coberto em Seção 7.3. Essa seção lista o conjunto completo de campos-cabeçalhos junto com observações sobre a sintaxe, significado e uso. Em toda essa seção, nós usaremos [HX.Y] para nos referir a Seção X.Y da atual RFC 2616 [8] que especifica o HTTP/1.1. Exemplos de cada cabeçalho-campo são dados.



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

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.