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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


A segunda camada é a camada de transporte. Ela define como um cliente envia requisições e recebe respostas e como um servidor recebe requisições e envia respostas na rede. Todos os elementos do SIP contêm uma camada de transporte. A camada de transporte é descrita na Seção 18.

A terceira camada é a camada de transação. Transações são um componente fundamental do SIP. Uma transação é uma requisição enviada por uma transação cliente (usando a camada de transporte) para a transação servidor, junto com todas as respostas a essa requisição enviada de volta da transação servidor ao cliente. A camada de transação trata retransmissões ao nível da camada de aplicação, conferindo respostas às requisições e timeouts ao nível da camada de aplicação. Qualquer tarefa que um cliente agente usuário (user agent client - UAC) realiza ocorre usando uma série de transações. Discussão das transações podem ser encontradas na seção 17. Agentes usuários contêm uma camada de transação, como faz os proxy's stateful (com estado). Proxy's stateless (sem estado) não contêm uma camada de transação. A camada de transação possui um componente cliente (referido como uma transação cliente) e um componente servidor (referido como uma transação servidor), cada um dos quais são representados por uma máquina de estado finito que é construída para processar uma requisição particular.

A camada superior a camada de transação é chamada de usuário da transação (transaction user - TU). Cada uma das entidades SIP, exceto o proxy sem estado, é um usuário da transação. Quando um TU deseja enviar uma requisição, ele cria uma instância da transação cliente e passa-lhe a requisição junto com o endereço IP, porta e transporte de destino para o qual enviar a requisição. O TU que cria uma transação cliente também pode cancelá-la. Quando um cliente cancela uma transação, ele requisita ao servidor deixar de processar, reverter para o estado que estava antes da transação ser iniciada, e gera uma resposta de erro específica a essa transação. Isso é feito com uma requisição CANCEL, que constitui sua própria transação, mas referencia a transação a ser cancelada (Seção 9).

Os elementos do SIP, ou seja, clientes e servidores agentes-usuários, proxy's com e sem estado e registradores, contêm um núcleo que os distinguem entre si. Núcleos, exceto para proxy sem estado, são usuários da transação. Embora o comportamento dos núcleos UAC e UAS dependam do método, existem algumas regras comuns para todos os métodos (Seção 8). Para um UAC, essas regras governam a construção de uma requisição; para um UAS, elas regulam o processamento de uma requisição e geram uma resposta. Como pedidos de registro desempenhar um papel importante no SIP, um UAS que trata um REGISTER é dado ao registrador o nome especial. A Seção 10 descreve o comportamento do núcleo UAC e UAS para o método REGISTER. A Seção 11 descreve o comportamento do núcleo para UAC e UAS para o método OPTIONS, usado para determinar as capacidades de um UA.



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

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.