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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


8.1.1.2 To

Primeiro e antes de tudo, o campo-cabeçalho To especifica o destino "lógico" desejado da requisição, ou o endereço de registro do usuário ou do recurso que é o objetivo dessa requisição. Isso pode ou não ser o destino final da requisição. O campo-cabeçalho To PODE conter um URI do SIP ou do SIPS, mas pode também fazer uso de outros esquemas de URI (URL tel (RFC 2806 [9]), por exemplo) quando for apropriado. Todas implementações SIP PRECISAM suportar o esquema de URI do SIP. Qualquer implementação que suporta TLS PRECISA suportar o esquema de URI do SIPS. O campo-cabeçalho To permite um nome de exibição.

Um UAC pode aprender como preencher o campo-cabeçalho To para uma requisição particular de inúmeras maneiras. Normalmente, o usuário irá sugerir o campo-cabeçalho To através de uma interface humana, talvez introduzindo a URI manualmente ou a selecionando de algum tipo de lista de endereços. Freqüentemente, o usuário não irá inserir uma URI completa, mas em vez disso uma string de dígitos ou letras (por exemplo, "Bob"). É do critério do UA escolher como interpretar essa entrada. Usando string para formar a parte usuário de uma URI do SIP implica que o UA deseja que o nome seja resolvido no domínio pelo lado direito (right-hand side - RHS) do sinal arroba na URI SIP (por exemplo, sip: bob@example.com). Usando string para formar a parte usuário de uma URI do SIPS implica que o UA pretende se comunicar de forma segura, e que o nome deve ser resolvido no domínio pelo RHS do sinal arroba. O RHS será frequentemente o domínio local do requisitante, o que permite o domínio local processar a requisição sainte. Isso é útil para funcionalidades como "discagem rápida", que exigem interpretação da parte usuário no domínio local. A URL tel pode ser usada quando o UA não deseja especificar o domínio que deve interpretar um número telefônico que foi inserido pelo usuário. Em vez disso, cada domínio através do qual passa a requisição seria dado essa oportunidade. Como exemplo, um usuário em um aeroporto pode se logar e enviar suas requisições através de um proxy sainte no aeroporto. Se ele digitar "411" (esse é o número telefônico para auxílio à lista local nos Estados Unidos), que precisa ser interpretado e processado pelo proxy sainte no aeroporto, e não o domínio do usuário. Nesse caso, tel:411 seria a escolha certa.

Uma requisição fora de um diálogo NÃO PODE conter uma tag To, o token tag no campo To de uma requisição identifica o peer do diálogo. Como nenhum diálogo foi estabelecido, nenhum token tag está presente.

Para mais informações sobre o campo-cabeçalho To, veja a Seção 20.39. A seguir é um exemplo de um campo-cabeçalho To válido:

To: Carol <sip:carol@chicago.com>







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

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.