RFC 3312 Integração
de Gerenciamento de Recurso e o SIP Outubro 2002
SDP1: A inclui pré-condições local e remoto para QoS
na oferta inicial. Antes de enviar a oferta inicial, A reserva recursos em sua rede
de acesso. Isso é indicado no status atual local do SDP abaixo:
m=audio 20000 RTP/AVP 0 8
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
SDP2: B reserva recursos em sua rede de acesso e, como
todas as pré-condições são atendidas, ele retorna um aceite em uma resposta 180
(Ringing) (3).
m=audio 30000 RTP/AVP 0 8
c=IN IP4 192.0.2.4
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
Vamos supor que após receber essa resposta, A decide
que quer usar somente PCM u-law (payload 0), em oposição a usar ambos PCM's
u-law e A-law (payload 8). Ele enviará um UPDATE a B, possivelmente antes de receber
a resposta 200 (OK) para o INVITE (5). O SDP se pareceria com:
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
B geraria um aceite a essa oferta e o colocaria na
resposta 200 (OK) ao UPDATE.
Note que essa última oferta/aceite para reduzir o número
de codec's suportados pode chegar ao servidor agente-usuário após a resposta 200
(OK) ser gerada. Isso significaria que a sessão é estabelecida antes de A ter
reduzido o número de codec's suportados. Para evitar essa situação, o cliente
agente-usuário poderia esperar o primeiro aceite do agente-usuário antes de definir
seu status atual local como "sendrecv".
Camarillo, et. al. Standards Track [Página 22]
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