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

RFC 3261                     SIP: Session Initiation Protocol                     Junho 2002





Requisições que não mudam em nada o estado de um diálogo podem ser recebidas dentro de 

um diálogo (por exemplo, uma requisição OPTIONS). Elas são processadas como se elas 

tivessem sido recebidas fora do diálogo.



Se o número de seqüência remoto estiver vazio, ele PRECISA ser definido com o valor do 

número de seqüência presente no valor no campo-cabeçalho CSeq da requisição. Se o número de 

seqüência remoto não estiver vazio, mas o número de sequência da requisição for inferior 

ao número de seqüência remoto, a requisição está fora de ordem e PRECISA ser rejeitada 

com uma Resposta 500 (Server Internal Error). Se o número de seqüência remoto não estiver 

vazio, e o número de sequência da requisição for maior que o número de seqüência remoto, 

a requisição está em ordem. É possível que o número de seqüência CSeq ser superior ao 

número de seqüência remoto por mais de um. Isso não é uma condição de erro, e um UAS DEVE 

estar preparado para receber e processar requisições com valores CSeq maior do que um 

superior àquele da requisição recebida anteriormente. O UAS PRECISA então definir o 

número de seqüência remoto com o valor do número de seqüência do valor no campo-cabeçalho 

CSeq da requisição.



Se um proxy desafia uma requisição gerada pelo UAC, o UAC tem que re-submeter a 

requisição com as credenciais. A requisição re-submetida terá um novo número CSeq. 

O UAS nunca verá a primeira requisição, e, assim, ele notará uma lacuna no espaço do 

número CSeq. Essa lacuna não representa nenhuma condição de erro.



Quando um UAS recebe uma requisição para atualizar alvo, ele PRECISA substituir o URI do 

alvo remoto do diálogo pelo URI do campo-cabeçalho Contact nessa requisição, se estiver 

presente.





12.3 Terminando um Diálogo

Independente do método, se uma requisição fora de um diálogo gera uma resposta final 

não-2xx, todos os diálogos early's criados através de respostas provisórias a essa 

requisição são encerrados. O mecanismo para terminar diálogos confirmados é específico de 

método. Nessa especificação, o método BYE termina uma sessão e o diálogo associado a ele.

Consulte a Seção 15 para obter mais detalhes.





13 Iniciando uma Sessão

13.1 Visão Geral



Quando um cliente agente-usuário deseja iniciar uma sessão (por exemplo, áudio, vídeo ou 

um jogo), ele formula uma requisição INVITE. A requisição INVITE pede a um servidor para 

estabelecer uma sessão. Essa requisição pode ser encaminhada pelos proxy's, eventualmente 

chegando a um ou mais UAS que potencialmente pode aceitar o convite. Estes UAS's 

freqüentemente precisará consultar o usuário sobre a possibilidade de aceitar o convite. 

Esses UAS's precisará freqüentemente consultar o usuário sobre a possibilidade de aceitar 

o 







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

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.