RFC 3312 Integração
de Gerenciamento de Recurso e o SIP Outubro 2002
Direction
Current Desired Strength
______________________________________
local send
no none
local recv no
none
remote send
no optional
remote recv
no none
Tabela 2: Tabela para o tipo de
status segmentado
No instante do envio da oferta, a tabela local de
status do ofertante e a tabela de status da transação contêm os mesmos valores.
Com a tabela de status da transação, o
agente-usuário PRECISA gerar as linhas de status-atual e de status-desejado,
seguindo a sintaxe da Seção 4 e as regras descritas abaixo na Seção 5.1.1.
5.1.1 Codificando o SDP
Para o tipo de status fim-a-fim, o agente-usuário
PRECISA gerar uma linha current-status com a tag "e2e" para o fluxo
de mídia. Se os strength-tags para ambas as direções forem iguais (isto é,
ambos "mandatory") na tabela de status da transação, o agente-usuário
PRECISA adicionar uma linha desired-status com a tag "sendrecv". Se
ambas as tags forem diferentes, o agente-usuário PRECISA incluir duas linhas de
status desejado, uma com a tag "send" e a outra com a tag "recv".
A semântica de duas linhas com
o mesmo strength-tag, uma linha com uma tag "send" e a outra com uma
tag "recv", é o mesmo que uma única linha "sendrecv".
Contudo, a fim de conseguir uma codificação mais compacta, nós escolhemos fazer
o último formato obrigatório.
Para o tipo status segmentado, o agente-usuário
PRECISA gerar duas linhas de current-status: uma com a tag "local" e a
outra com a tag "remote". O agente-usuário PRECISA adicionar uma ou
duas linhas desired-status por segmento (isto é, local e remote). Se, para um
segmento particular (local ou remoto), as tags em ambas as direções na tabela
de status da transação forem iguais (isto é, ambos "mandatory"), o
agente-usuário PRECISA adicionar uma linha de status desejado com a tag "sendrecv".
Se ambas as tags forem diferentes, o agente-usuário PRECISA incluir duas linhas
desired-status, uma com a tag "send" e a outra com a tag
"recv".
Note que as regras acima se aplicam ao strength-tag desejado
"none" também. Dessa forma, um agente-usuário que suporta qualidade
de serviço, porém não pensado para usá-lo, adiciona linhas de status desejado
com o strength-tag "none". Como essa tag pode ser atualizada no
aceite, como descrito na Seção 5.2, o aceitante pode requisitar reserva de
qualidade de serviço sem precisar de outra troca oferta/aceite.
Camarillo, et. al. Standards Track [Página 9]
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