RFC 3261 SIP: Session Initiation Protocol Junho 2002
por retransmitir-las (ver Seção 13.3.1.4), e o UAC só assume a responsabilidade por reconhecê-las com ACK (ver Seção 13.2.2.4). Como esse ACK é retransmitido somente pelo UAC, ele é efetivamente considerado como sua própria transação.
Transações têm um lado cliente e um lado servidor. O lado cliente é conhecido como transação cliente e o lado servidor como transação servidor. A transação cliente envia a requisição, e a transação servidor envia a resposta. As transações cliente e servidor são funções lógicas que são incorporadas em qualquer número de elementos. Especificamente, elas existem dentro de agentes-usuários e servidores proxy com estado. Considere o exemplo na Seção 4. Nesse exemplo, o UAC executa a transação cliente e seu proxy de saída executa a transação servidor. O proxy de saída também executa uma transação cliente, que envia a requisição a uma transação servidor no proxy de entrada. Tal proxy também executa uma transação cliente, que por sua vez envia a requisição a uma transação servidor no UAS. Isso é mostrado na Figura 4.
+---------+ +---------+ +---------+ +---------+
| +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ |
| |C||------->||S| |C||------->||S| |C||------->||S| |
| |l|| ||e| |l|| ||e| |l|| ||e| |
| |i|| ||r| |i|| ||r| |i|| ||r| |
| |e|| ||v| |e|| ||v| |e|| ||v| |
| |n|| ||e| |n|| ||e| |n|| ||e| |
| |t|| ||r| |t|| ||r| |t|| ||r| |
| | || || | | || || | | || || | |
| |T|| ||T| |T|| ||T| |T|| ||T| |
| |r|| ||r| |r|| ||r| |r|| ||r| |
| |a|| ||a| |a|| ||a| |a|| ||a| |
| |n|| ||n| |n|| ||n| |n|| ||n| |
| |s||Response||s| |s||Response||s| |s||Response||s| |
| +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ |
+---------+ +---------+ +---------+ +---------+
UAC Outbound Inbound UAS
Proxy Proxy
Figura 4: Relacionamento de transação
Um proxy sem estado não contém uma transação cliente ou servidor. A transação existe entre o UA ou proxy com estado de um lado, e o proxy com estado ou UA do outro lado. No que se refere a transações SIP, proxy's sem estado são efetivamente transparentes. A finalidade da transação cliente é receber uma requisição do elemento no qual o cliente é inserido (chama esse elemento o "Usuário da Transação" ou TU; ele pode ser um UA ou um proxy com estado), e entregar de forma confiável a requisição a uma transação servidor.
Rosenberg, et. al. Standards Track [Página 123]
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.
Nenhum comentário:
Postar um comentário