RFC 3312 Integração
de Gerenciamento de Recurso e o SIP Outubro 2002
9 Tipo de Pré-condição Não Conhecido
Esse documento define a tag "qos" para pré-condições
de qualidade de serviço. Novos tipos de pré-condições definidos no futuro terão
novas tag's associadas. Um UA que recebe um tipo de pré-condição desconhecido, com
um strength-tag "mandatory" em uma oferta, PRECISA recusar a oferta a
menos que as pré-condições obrigatórias desconhecidas só tenham a tag "local".
Nesse caso, o UA não precisa estar envolvido a fim de aceitar as pré-condições.
O UA pedirá confirmação das pré-condições e, quando a confirmação chegar, ele retomará
o estabelecimento de sessão.
Um UA que recusa uma oferta segue as regras descritas
na seção 8, mas em vez da tag "failure", ele usa a tag
"unknown", como mostrado no exemplo abaixo:
m=audio 20000 RTP/AVP 0
a=des:foo unknown e2e send
10 Múltiplas Pré-condições por Stream de Mídia
Um stream de mídia PODE conter múltiplas pré-condições.
Diferentes pré-condições PODEM ter o mesmo tipo de pré-condição e diferentes tipos
de status (p.ex., pré-condições de qualidade de serviço fim-a-fim e segmentado)
ou diferentes tipos de pré-condição. (Esse documento só define o tipo de pré-condição
"qos", mas extensões podem definir mais tipos de pré-condição no
futuro).
Todas as pré-condições para um stream de mídia PRECISAM
ser atendidas a fim de retomar o estabelecimento de sessão. O exemplo seguinte mostra
uma descrição de sessão que usa ambos os tipos de status fim-a-fim e segmentado
para um fluxo de mídia.
m=audio 20000 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=curr:qos e2e none
a=des:qos optional e2e
sendrecv
Camarillo, et. al. Standards Track [Página 15]
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