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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


ou um núcleo UAC. Um núcleo UAC irá tratar a geração do ACK a essa resposta, enquanto um núcleo proxy sempre encaminhará upstream 200 (OK). O tratamento diferente de 200 (OK) entre o proxy e o UAC é a razão porque esse tratamento não ocorra na camada transação.

A transação cliente PRECISA ser destruída no instante em que ela entra no estado "Terminated". Isso é realmente necessário para garantir a operação correta. A razão é que respostas 2xx a um INVITE são tratadas de forma diferente; cada uma é encaminhada por proxy's, e o tratamento de ACK em um UAC é diferente. Assim, cada uma 2xx precisa ser passada ​​a um núcleo proxy (de modo que ela possa ser encaminhada) e um núcleo UAC (de sorte que ela possa ser reconhecida). Nenhum processamento na camada transação ocorre. Sempre que uma resposta for recebida pelo transporte, se a camada transporte não encontrar nenhuma transação cliente que confira (usando as regras da Seção 17.1.3), a resposta é passada diretamente ao núcleo. Como a transação cliente que confere é destruída na primeira 2xx, a 2xx subseqüente não encontrará correspondência e, portanto, será passada ao núcleo.


17.1.1.3 Construção da Requisição ACK

Esta seção especifica a construção de requisições ACK enviadas dentro da transação cliente. Um núcleo UAC que gera um ACK a 2xx PRECISA, ao invés disso, seguir as regras descritas na Seção 13.

A requisição ACK construída pela transação cliente PRECISA conter valores para os Call-ID, From e Request-URI, que sejam iguais aos valores desses campos-cabeçalhos na requisição passado ao transporte pela transação cliente (chamam isso de "requisição original"). O campo-cabeçalho To no ACK PRECISA ser igual ao campo-cabeçalho To na resposta sendo reconhecida e, portanto, geralmente diferem do campo-cabeçalho To na requisição original pela adição do parâmetro tag. O ACK PRECISA conter um único campo-cabeçalho Via, e esse PRECISA ser igual ao campo-cabeçalho Via no topo da requisição original. O campo-cabeçalho CSeq no ACK PRECISA conter o mesmo valor para o número de seqüência que estava presente na requisição original, mas o parâmetro method PRECISA ser igual a "ACK".











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

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.