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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


A transação cliente também é responsável por receber respostas e entrega-las ao TU, filtrar qualquer retransmissão de resposta ou respostas anuladas (como uma resposta ao ACK). Além disso, no caso de uma requisição INVITE, a transação cliente é responsável por gerar a requisição ACK para qualquer resposta final aceitando uma resposta 2xx.

De forma similar, o propósito da transação servidor é receber requisições da camada de transporte e entregá-las ao TU. A transação servidor filtra quaisquer retransmissões de requisições da rede. A transação servidor aceita respostas do TU e as entrega à camada de transporte para transmissão na rede. No caso de uma transação INVITE, ele absorve a requisição ACK para qualquer resposta final excetuando uma resposta 2xx.

A resposta 2xx e seu ACK recebem tratamento especial. Essa resposta é retransmitida só por um UAS, e seu ACK gerado só pelo UAC. Esse tratamento fim-a-fim é necessário de modo que um chamador saiba o conjunto completo de usuários que aceitou o chamado. Por causa desse tratamento especial, retransmissões de respostas 2xx são tratadas pelo núcleo UA, e não pela camada de transação. De forma similar, a geração de ACK à 2xx é tratado pelo núcleo UA. Cada proxy ao longo do caminho meramente encaminha cada resposta 2xx ao INVITE e seu ACK correspondente.


17.1 Transação Cliente

A transação cliente fornece sua funcionalidade através da manutenção de uma máquina de estado.

O TU se comunica com a transação cliente através de uma interface simples. Quando o TU deseja iniciar uma nova transação, ele cria uma transação cliente e passa pra ela a requisição SIP a enviar e um endereço IP, porta e transporte a qual enviá-lo. A transação cliente inicia a executar sua máquina de estado. Respostas válidas são passadas ​​até o TU da transação cliente.

Existem dois tipos de máquinas de estado para transação cliente, dependendo do método da requisição aprovada pelo TU. Um lida com transações clientes para requisições INVITE. Esse tipo de máquina é referido como uma transação INVITE cliente. Outro tipo lida com transações clientes para todas as requisições, exceto INVITE e ACK. Esse é referido como uma transação cliente não-INVITE. Não há nenhuma transação cliente para ACK. Se o TU desejar enviar um ACK, ele passa um diretamente a uma camada de transporte para transmissão.







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

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.