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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Várias linhas de campo-cabeçalho com esses nomes PODEM estar presentes em uma mensagem, mas desde que sua gramática não siga a forma geral listada na Seção 7.3, eles PRECISAM NÃO ser combinados em uma única linha de campo-cabeçalho.

Implementações PRECISAM ser capazes de processar múltiplas linhas de campo-cabeçalho com o mesmo nome em qualquer combinação das formas valor-simples-por-linha ou valor separado por vírgula.

Os grupos seguintes de linhas de campo-cabeçalho são válidos e equivalentes:

      Route: <sip:alice@atlanta.com>
      Subject: Lunch
      Route: <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>

      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>
      Subject: Lunch

      Subject: Lunch
      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,
             <sip:carol@chicago.com>

Cada um dos blocos que se segue é válido, mas não é equivalente entre si:

      Route: <sip:alice@atlanta.com>
      Route: <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>

      Route: <sip:bob@biloxi.com>
      Route: <sip:alice@atlanta.com>
      Route: <sip:carol@chicago.com>

      Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>, 
             <sip:bob@biloxi.com>

O formato de um valor de campo-cabeçalho é definida por nome de cabeçalho. Sempre será ou uma seqüência opaca de octetos TEXT-UTF8, ou uma combinação de espaço-em-branco, tokens, separadores e strings entre aspas. Muitos campos-cabeçalhos existentes vão aderir à forma geral de um valor seguido por uma seqüência separada ponto e vírgula de pares nome-de-parâmetro, o valor-de-parâmetro:

field-name: field-value *(;parameter-name=parameter-value)






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

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.