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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


No exemplo abaixo, não existem aspas-duplas em torno do parâmetro Digest:

      Authorization: Digest username="Alice", realm="atlanta.com",
       nonce="84a4cc6f3082121f32b42a2187831a9e",
       response="7587245234b3434cc3412213e5f113a5432"


20.8 Call-ID

O campo-cabeçalho Call-ID exclusivamente identifica uma chamada particular ou todos os pedidos de registro de um cliente particular. Uma simples conferência multimídia pode dar origem a várias chamadas com diferentes Call-ID's, por exemplo, se um usuário convida um único indivíduo várias vezes à mesma (long-running) conferência. Call-ID's são case-sensitive e são simplesmente comparados byte-a-byte.

A forma compacta do campo-cabeçalho Call-ID é i.

Exemplos:

      Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
      i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4


20.9 Call-Info

O campo-cabeçalho Call-Info fornece informações adicionais à cerca do chamador ou do chamado, dependendo se ele for encontrado em uma requisição ou uma resposta. O propósito do URI é descrito pelo parâmetro "purpose". O parâmetro "icon" designa uma imagem adequada como uma representação icônica do chamador ou do chamado. O parâmetro "info" descreve o chamador ou chamado em geral, por exemplo, através de uma página web. O parâmetro "card" fornece um cartão de visita, por exemplo, em formatos vCard [36] ou LDIF [37]. Tokens adicionais podem ser registrados no IANA e os procedimentos na Seção 27.

Uso do campo-cabeçalho Call-Info pode representar um risco a segurança. Se um chamado busca os URI's fornecidos por um chamador malicioso, o chamado pode estar em risco ao exibir conteúdo impróprio ou ofensivo, conteúdo perigoso ou ilegal, e assim por diante. Portanto, é RECOMENDADO que um UA apenas preste as informações no campo-cabeçalho Call-Info se ele pode verificar a autenticidade do elemento que originou o campo-cabeçalho e confia nesse elemento. Isso não precisa ser o peer UA; um proxy pode inserir esse campo-cabeçalho em requisições.

Exemplo:

   Call-Info: <http: alice="" photo.jpg="" wwww.example.com=""> ;purpose=icon,
     <http: alice="" www.example.com=""> ;purpose=info



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

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.