RFC 3261 Português Página 82

RFC 3261 SIP: Session Initiation Protocol Junho 2002

Após ter recebido a resposta final não-2xx o núcleo do UAC considera a transação INVITE completada. A transação cliente do INVITE trata a geração de ACK's para a resposta (ver Seção 17).

13.2.2.4 Respostas 2xx

Múltiplas respostas 2xx podem chegar ao UAC para uma única requisição INVITE devido a um proxy forking. Cada resposta é distinguida pelo parâmetro tag no campo-cabeçalho To, e cada uma representa um diálogo distinto, com um distinto identificador do diálogo.

Se o identificador do diálogo na resposta 2xx bate com o identificador de diálogo de um diálogo existente, o diálogo PRECISA ser transitado para o estado "confirmed", e o conjunto de rotas para o diálogo PRECISA ser recomputado baseado na resposta 2xx usando os procedimentos da Seção 12.2.1.2. Do contrário, um novo diálogo estado "confirmed" PRECISA ser construído usando os procedimentos da Seção 12.1.2.

Note que a única parte de estado que é recomputado é o conjunto de rotas. Outras partes de estado como os números de sequência mais altos (remoto e local) enviados dentro do diálogo não são recomputados. O conjunto de rotas é só recomputado para manter compatibilidade. A RFC 2543 não obrigava fazer espelhamento do campo-cabeçalho Record-Route em uma 1xx, só em 2xx. Contudo, nós não podemos atualizar o estado inteiro do diálogo, since requisições em meio-ao-diálogo podem ter sido enviadas dentro do diálogo early, modificando os números de sequência, por exemplo.

O núcleo do UAC PRECISA gerar uma requisição ACK para cada 2xx recebida da camada de transação. Os campos-cabeçalhos do ACK são construidos da mesma forma que para qualquer requisição enviada dentro de um diálogo (ver Seção 12) com a exceção do CSeq e os campos-cabeçalhos relacionado a autenticação. O número de sequência do campo-cabeçalho CSeq PRECISA ser o mesmo que do INVITE sendo confirmado, mas o método de CSeq PRECISA ser ACK. O ACK PRECISA conter as mesmas credenciais que do INVITE. Se a 2xx contiver um oferta (baseado nas regras acima), o ACK PRECISA carregar um aceite em seu corpo. Se o oferta na resposta 2xx não for aceitável, o núcleo do UAC PRECISA gerar um aceite válido no ACK e então enviar um BYE imediatamente.

Uma vez o ACK tenha sido construído, os procedimentos de [4] são usados para determinar o endereço e porta destino, e transporte. Contudo, a requisição é passada à camada de transporte diretamente para transmissão, em vez de uma transação cliente. Isso é porque o núcleo do UAC trata re-transmissões do ACK, e não a camada de transação. O ACK PRECISA ser passado ao transporte cliente sempre que chegar uma re-transmissão da resposta final 2xx que disparou o ACK.

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

Página Anterior

Tabela de Conteúdo

Página Seguinte



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.