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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


20.10 Contact

O valor do campo-cabeçalho Contact fornece um URI cujo significado depende do tipo de requisição ou resposta em que ele está.

Um valor do campo-cabeçalho Contact pode conter um nome de exibição, um URI com parâmetros URI, e parâmetros de cabeçalho.

Esse documento define os parâmetros "q" e "expires" de Contact. Esses parâmetros são usados ​​só quando o Contact estiver presente em uma requisição REGISTER ou resposta, ou em respostas 3xx. Parâmetros adicionais podem ser definidos em outras especificações.

Quando o valor do campo-cabeçalho contiver um nome de exibição, o URI incluindo todos os parâmetros URI é delimitado por "<" e ">". Se os delimitadores "<" e ">" não estiverem presentes, todos os parâmetros após o URI são parâmetros de cabeçalho, e não parâmetros URI. O nome de exibição pode ser tokens, ou uma string entre aspas, se um conjunto de caracteres mais amplo for desejado.

Mesmo que o "display-name" esteja vazio, a forma "name-addr" PRECISA ser usada se o "addr-spec" contiver uma vírgula, ponto e vírgula ou uma interrogação. Pode ou não haver LWS entre o display-name e o "<".

Essas regras para analisar um nome de exibição, URI, e parâmetros URI, e parâmetros de cabeçalho também se aplicam aos campos-cabeçalhos To e From.

O campo-cabeçalho Contact tem um papel similar ao do campo-cabeçalho Location em HTTP. No entanto, o campo-cabeçalho do HTTP permite apenas um endereço, sem aspas. Como URI's podem conter vírgulas e ponto e vírgula como caracteres reservados, eles podem ser confundidos com delimitadores de cabeçalho ou de parâmetro, respectivamente.

A forma compacta do campo-cabeçalho Contact é m (para "moved").

Exemplos:

      Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
         ;q=0.7; expires=3600,
         "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
      m: <sips:bob@192.0.2.4>;expires=60










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

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.