RFC 3312 Portugues Pagina 10 :: Admirável Mundo Novo




Muito Bem Vindo

Prezado Leitor, a proposta desse Blog é compartilhar conhecimento com as pessoas que trabalham com Linux, Asterisk, OpenSER, e com tecnologia de voz sobre a rede IP em geral, através de tutoriais, dicas, howto, notícias entre outros assuntos.

Atente para termo de uso do conteúdo do blog no rodapé da página.

domingo, 3 de julho de 2011

RFC 3312 Portugues Pagina 10





RFC 3312       Integração de Gerenciamento de Recurso e o SIP   Outubro 2002


O exemplo a seguir mostra o SDP correspondente às tabelas 1 e 2.

m=audio 20000 RTP/AVP 0
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
m=audio 20002 RTP/AVP 0
a=curr:qos local none
a=curr:qos remote none
a=des:qos optional remote send
a=des:qos none remote recv
a=des:qos none local sendrecv


5.2 Gerando um Aceite

Quando o aceitante recebe a oferta, ele recria a tabela status de transação usando os atributos SDP contidos na oferta. O aceitante atualiza ambas as suas tabelas de status local e status de transação seguindo as regras abaixo:


Desired Strength: Nós definimos uma ordenação absoluta para o strength-tags: "none", "optional" e "mandatory". O "mandatory" é a tag com o grau mais alto e "none" a tag com o grau mais baixo. Um aceitante PODE atualizar o strength desejado em qualquer entrada da tabela status de transação, mas ele NÃO PODE rebaixá-lo. Portanto, é OK promover a grau maior de "none" para "optional", de "none" a "mandatory" ou de "optional" a "mandatory", mas nunca ao contrário.

Current Status: Para cada linha, o valor do campo "Current" na tabela status de transação e na tabela de status local do aceitante, precisa ser comparada. A tabela 3 mostra as quatro possíveis combinações. Se ambos os campos têm o mesmo valor (as duas primeiras linhas da tabela 3), nada precisa ser atualizado. Se o campo "Current" da tabela status da transação for "Yes", e o campo da tabela status local for "No" (terceira linha da tabela 3), a última PRECISA ser definida como "Yes". Se o campo "Current" da tabela status da transação for "No", e o campo da tabela status local for "Yes" (quarta linha da tabela 3), o aceitante precisa verificar se ele tem informação local (ou seja, se uma confirmação de reserva de recurso foi recebida) a cerca desse status current particular. Se ele tiver, o campo "Current" da tabela status da transação é definido como "Yes". Se o aceitante não tiver informação local a cerca desse status current, o campo "Current" da tabela status local PRECISA ser definido como "No".





Camarillo, et. al.                 Standards Track                    [Página 10]


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:




Creative Commons License
Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP
by Cléviton Mendes de Araújo is licensed under a Creative Commons Atribuição 2.5 Brasil License.