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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Quando um UAC recebe uma resposta que estabelece um diálogo, ele constrói o estado do diálogo. Esse estado PRECISA ser mantido durante o diálogo.

Se a requisição foi enviada através do TLS, e o Request-URI continha um URI do SIPS, o flag "secure" é definido como TRUE.

O conjunto de rotas PRECISA ser definido com a lista de URI's no campo-cabeçalho Record-Route da resposta, tomadas na ordem inversa e preservando todos parâmetros do URI. Se nenhum campo-cabeçalho Record-Route estiver presente na resposta, o conjunto de rotas PRECISA ser definido com conjunto vazio. Esse conjunto de rotas, ainda que vazio, sobreescreve qualquer conjunto de rota pré-existente em futuras requisições nesse diálogo. O alvo remoto PRECISA ser definido com o URI do campo-cabeçalho Contact da resposta.

O número de seqüência local PRECISA ser definido com o valor do número de sequência no campo-cabeçalho CSeq da requisição. O número de seqüência remoto PRECISA ser vazio (ele é estabelecido quando o UA remoto envia uma requisição dentro do diálogo). O componente identificador de chamada do diálogo ID PRECISA ser definido com o valor do Call-ID da requisição. O componente tag local do diálogo ID PRECISA ser definido com a tag no campo From da requisição, e o componente tag remoto do diálogo ID PRECISA ser definida com a tag no campo To da resposta. Um UAC PRECISA estar preparado para receber uma resposta sem uma tag no campo To, nesse caso a tag é considerada tendo um valor nulo.

Isso é para manter retro-compatibilidade com a RFC 2543, que não obrigava o uso de tags no campo To.

O URI remota PRECISA ser definida com o URI do campo To, e o URI local PRECISA ser definida com o URI do campo From.


12.2 Requisições dentro de um Diálogo

Uma vez que o diálogo tenha sido estabelecido entre dois UA's, qualquer um deles PODE iniciar novas transações quando necessário dentro do diálogo. O UA enviando a requisição assumirá o papel de UAC da transação. O UA que recebe a requisição assumirá o papel de UAS. Note que eles podem assumir diferentes papéis daqueles que os UA's mantiveram durante a transação que estabeleceu o diálogo.

Requisições dentro de um diálogo PODEM conter campos-cabeçalhos Record-Route e Contact. No entanto, essas requisições não causam ao conjunto de rotas do diálogo sofrer modificações, apesar delas puderem modificar o URI do alvo remoto. Especificamente, requisições que não são requisições para atualizar alvo não modificam a URI do alvo remoto do diálogo, e requisições que são requisições para atualizar destino modificam. Para diálogos que foram estabelecidos com um 




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

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.