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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


mensagem (essas regras se aplicam tanto a requisições como a respostas). Como seria de esperar para um UAS, o valor do Call-ID do diálogo ID é definido com o Call-ID da mensagem, a tag remota é definido com a tag no campo From da mensagem, e a tag local é definida com a tag no campo To da mensagem.

Um diálogo contém determinadas partes necessárias de estado para transmissões de mais mensagens dentro do diálogo. Esse estado consiste do diálogo ID, um número de seqüência local (usado para ordenar requisições do UA ao seu par), um número de seqüência remoto (usado para ordenar requisições de seu par ao UA), um URI local, um URI remota, o destino remoto, um flag booleano chamado "secure", e um conjunto de rota, que é uma lista ordenada de URI's. O conjunto de rota é a lista de servidores que precisam ser atravessados ao enviar uma requisição ao par. Um diálogo também pode estar no estado "early", o qual ocorre quando ele é criado com uma resposta provisória, e então transita para o estado "confirmed" quando chegar uma resposta final 2xx. Para outras respostas, ou se não chegar nenhuma resposta nesse diálogo, o diálogo early termina.


12.1 Creação de um Diálogo

Diálogos são criados através da geração de respostas de não-falha a requisições com métodos específicos. Dentro dessa especificação, somente respostas 2xx e 101-199 com a tag To, onde a requisição foi o INVITE, irá estabelecer um diálogo. Um diálogo estabelecido por uma resposta não-final a uma requisição fica no estado "early" e é chamado um diálogo early. Extensões PODEM definir outros meios para criação de diálogos. A Seção 13 fornece mais detalhes que são específicos ao método INVITE. Aqui, nós descreveremos o processo de criação de estado de diálogo que é independente do método.

UA's PRECISAM atribuir valores aos componentes do diálogo ID como descrito abaixo.


12.1.1 Comportamento do UAS

Quando um UAS responde a uma requisição com uma resposta que estabelece um diálogo (tal como uma resposta 2xx ao INVITE), o UAS PRECISA copiar todos valores do campo-cabeçalho Record-Route da requisição para a resposta (incluindo URI's, parâmetros de URI, e quaisquer parâmetros do campo-cabeçalho Record-Route, se eles são ou não conhecidos do UAS) e PRECISA manter a ordem desses valores. O UAS PRECISA adicionar um campo-cabeçalho Contact à resposta. O campo-cabeçalho Contact contém um endereço onde o UAS gostaria fosse contactado nas requisições subsequentes do diálogo (o que inclui o ACK para uma resposta 2xx no caso de um INVITE). Geralmente, a parte host dessa URI é o endereço IP ou FQDN do host. O URI fornecida no campo-cabeçalho Contact PRECISA ser um URI do SIP ou do SIPS. Se a requisição que iniciou o diálogo continha um 




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

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.