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

RFC 3261                      SIP: Session Initiation Protocol                     Junho 2002





Request-URI: A Request-URI é uma URI SIP ou SIPS conforme descrito na Seção 19.1 ou 

uma URI geral (RFC 2396 [5]). Ela indica o usuário ou o serviço para o qual essa 

requisição está sendo endereçada. A Request-URI NÃO PODE conter caracteres espaços ou 

controle unescaped e NÃO PODE estar delimitado por "<>".



Elementos do SIP PODEM suportar Request-URI's com esquemas diferentes de "sip" e 

"sips", por exemplo, o esquema de URI "tel" da RFC 2806 [9]. Elementos SIP PODEM 

traduzir URI's não-SIP usando qualquer mecanismo à sua disposição, que resulte em 

URI do SIP, URI do SIPS, ou algum outro esquema.



SIP-Version: Ambos as mensagens requisição e resposta incluem a versão do SIP em uso, e 

segue o [H3.1] (com o HTTP substituído por SIP, e o HTTP/1.1 substituído por SIP/2.0) 

quanto a versão de encomenda, requisitos de conformidade e atualização de números de 

versão. Para estar em conformidade com essa especificação, aplicações enviando 

mensagens SIP PRECISAM incluir um SIP-Version como "SIP/2.0". A string SIP-Version não 

é sensível a maiúsculo-minúsculo, mas implementações PRECISAM enviar string maiúscula.



Diferente do HTTP/1.1, o SIP trata o número de versão como uma string literal. Na 

prática, isso não deve fazer nenhuma diferença.





7.2 Respostas



Respostas SIP são distinguidas dos requisições por ter um Status-Line como sua linha-início. 

Uma Status-Line consiste da versão do protocolo seguido por um Status-Code numérico e sua 

frase textual associada, com cada elemento separado por um caractere SP simples.



Nenhum CR ou LF é permitido exceto na seqüência final CRLF.



Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF



O código de status (Status-Code) é um código resultado inteiro de 3 dígitos que indica o 

resultado da tentativa de entender e satisfazer uma requisição. A frase razão 

(Reason-Phrase) destina-se a dar uma descrição textual breve do Status-Code. O código de 

status (Status-Code) é destinado ao uso por autômatos, enquanto a frase razão 

(Reason-Phrase) é destinada ao usuário humano. Um cliente não é obrigado a analisar ou 

exibir a frase razão (Reason-Phrase).



Embora essa especificação sugira expressão específica para a frase razão, implementações 

PODEM escolher outro texto, por exemplo, na língua indicada no campo-cabeçalho 

Accept-Language da requisição.









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

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.