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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


URI do SIPS no Request-URI ou no valor mais alto do campo-cabeçalho Record-Route, se houver alguma, ou o campo-cabeçalho Contact se não houver nenhum campo-cabeçalho Record-Route, o campo-cabeçalho Contact na resposta PRECISA ser um URI do SIPS. O URI DEVE ter escopo global (ou seja, o mesmo URI pode ser usado em mensagens fora desse diálogo). Da mesma forma, o escopo do URI no campo-cabeçalho Contact do INVITE não está limitado a esse diálogo tão somente. Pode portanto ser usado em mensagens para o UAC mesmo fora desse diálogo.

O UAS então constrói o estado do diálogo. Esse estado PRECISA ser mantido durante o diálogo.

Se a requisição chegou sobre o TLS, e o Request-URI contém 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 requisição, tomada na ordem e preservando todos parâmetros de URI. Se nenhum campo-cabeçalho Record-Route estiver presente na requisição, o conjunto de rotas PRECISA ser definido com conjunto vazio. Esse conjunto de rotas, ainda que vazio, sobreescreve qualquer conjunto de rotas pré-existente em futuras requisições nesse diálogo. O destino remoto PRECISA ser definido com a URI do campo-cabeçalho Contact da requisição.

O número de seqüência remoto PRECISA ser definido com o valor do número de seqüência no campo-cabeçalho CSeq da requisição. O número de seqüência local PRECISA ser vazio. 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 definida com a tag do campo To na resposta à requisição (que sempre inclui uma tag), e o componente tag remoto do diálogo ID PRECISA ser definido com a tag do campo From da requisição. Um UAS PRECISA estar preparado para receber uma requisição sem uma tag no campo From, nesse caso a tag é considerada tendo um valor nulo.

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

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


12.1.2 Comportamento do UAC

Quando um UAC envia uma requisição que pode estabelecer um diálogo (como um INVITE), ele PRECISA fornecer um URI do SIP ou do SIPS com escopo global (ou seja, o mesmo URI do SIP pode ser usada em mensagens fora desse diálogo) no campo-cabeçalho Contact da requisição. Se a requisição tiver um Request-URI ou um valor mais alto do campo-cabeçalho Route com um URI do SIPS, o campo-cabeçalho Contact PRECISA conter um URI do SIPS.




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

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.