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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


INVITE, a única requisição para atualizar alvo definida é o re-INVITE (ver Seção 14). Outras extensões podem definir diferentes requisições para atualizar destino em diálogos estabelecidos de outras formas.

Note que um ACK NÃO é uma requisição para atualizar alvo.

Requisições para atualizar alvo só atualiza o URI do alvo remoto do diálogo, e não o conjunto de rotas formado a partir do campo Record-Route. Atualizar o último introduziria problemas severos de retro-compatibilidade com sistemas que estão em conformidade com a RFC 2543.


12.2.1 Comportamento do UAC

12.2.1.1 Gerando a Requisição

Uma requisição dentro de um diálogo é construída usando muitos dos componentes de estado armazenados como parte do diálogo.

O URI no campo To da requisição PRECISA ser definida com o URI remota do estado do diálogo. A tag no campo-cabeçalho To da requisição PRECISA ser definida com a tag remoto do diálogo ID. O URI do campo From da requisição PRECISA ser definida com o URI local do estado do diálogo. A tag no campo-cabeçalho From da requisição PRECISA ser definida com a tag local do diálogo ID. Se o valor das tags remota ou local for nulo, o parâmetro tag PRECISA ser omitido dos campos-cabeçalhos To ou From, respectivamente.

Uso do URI dos campos To e From da requisição original dentro das requisições subseqüentes é feito para manter a retro-compatibilidade com a RFC 2543, que usava o URI para identificação do diálogo. Nessa especificação, só as tags são usadas para identificação de diálogo. É esperado que reflexão obrigatória do URI original dos campos To e From em requisições em meio-ao-diálogo seja desaprovado em uma revisão subseqüente dessa especificação.

O Call-ID da requisição PRECISA ser definido com o Call-ID do diálogo. Requisições dentro de um diálogo PRECISAM conter números de seqüência CSeq estrita e monotonicamente crescentes e contíguos (incrementando-por-um) em cada direção (excetuando-se ACK e CANCEL claro, cujos números iguala aos das requisições sendo estabelecidas ou canceladas). Portanto, se o número de sequência local não for vazio, o valor do número de seqüência local PRECISA ser incrementado por um, e esse valor PRECISA ser colocado no campo-cabeçalho CSeq. Se o número de seqüência local for vazio, um valor inicial PRECISA ser escolhido usando as orientações da Seção 8.1.1.5. O campo método no valor do campo-cabeçalho CSeq PRECISA casar com o método da requisição.






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

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.