RFC 3312 Integração
de Gerenciamento de Recurso e o SIP Outubro 2002
Um servidor agente-usuário pode receber uma
requisição INVITE sem oferta na mesma. Nesse
caso, seguindo os procedimentos normais definidos em [1] e [5], o servidor
agente-usuário fornecerá uma oferta em uma resposta 1xx confiável. O cliente
agente-usuário enviará o aceite em outra requisição SIP (ou seja, o PRACK à
1xx). Se a oferta e o aceite contêm pré-condições, o servidor agente-usuário
NÃO DEVE alertar o usuário até que todos os pré-requisitos obrigatórios no
aceite sejam atendidas.
Note que nesse caso, um servidor
agente-usuário que fornece uma oferta inicial com pré-condições, uma resposta 180
(Ringing) com pré-condições nunca será enviada, porquanto o servidor
agente-usuário não pode alertar o usuário até que todas as pré-condições sejam atendidas.
Um UAS que não é capaz de reunir unilateralmente
todas as pré-condições obrigatórias PRECISA incluir um atributo confirm-status
no SDP (oferta ou aceite) que ele envia (ver Seção 7). Além disso, o SDP
(oferta ou aceite) que contém esse atributo confirm-status PRECISA ser enviado
tão logo seja permitida pelas regras do modelo oferta-aceite do SIP.
Enquanto o estabelecimento de sessão estiver suspenso,
agentes-usuários NÃO DEVEM enviar nenhum dado em qualquer fluxo de mídia. No
caso do RTP [6], nem pacotes RTP e nem RTCP são enviados.
Um servidor agente-usuário sabe que todas as
precondições são reunidas em uma linha de media quando sua tabela status local
tem um valor "yes" em todas as linhas cujo strength-tag seja "mandatory".
Quando as pré-condições de todas as linhas de media da sessão sejam atendidas,
o estabelecimento da sessão DEVE retomar.
Para um INVITE inicial, suspender e retomar o estabelecimento
de sessão é muito intuitivo. A parte chamada não será alertada até que todas as
pré-condições obrigatórias sejam conhecidas. Contudo, ofertas que contêm pré-condições
enviadas em meio a uma sessão em curso precisam de explanação adicional. Ambos
os agentes-usuários DEVEM continuar usando os parâmetros antigos de sessão até
que todas as pré-condições obrigatórias sejam reunidas. Nesse momento, os agentes-usuários
podem começar usando os novos parâmetros de sessão. A seção 13 contém um exemplo dessa situação.
7 Status de Confirmação
O atributo confirm-status PODE ser usado tanto em ofertas
quanto em aceites. Esse atributo representa um limiar
na reserva de recurso. Quando esse limiar é atingido ou ultrapassado, o agente-usuário
PRECISA enviar uma oferta ao peer agente-usuário, que reflete o novo status atual
da linha de mídia tão logo seja permitida pelas regras oferta-aceite do SIP. Se
esse limiar for trocado de novo (por exemplo, a rede pára de fornecer recursos pelo
fluxo de mídia), o agente-usuário PRECISA enviar uma nova oferta também, tão
logo seja permitida pelas regras oferta/aceite do SIP.
Camarillo, et. al. Standards Track [Página 12]
Página Original:
Observação:
Modelo 'offer/answer' do documento original em inglês foi traduzido para o
português como: modelo oferta-aceite.
Nenhum comentário:
Postar um comentário