RFC 3312 Portugues Pagina 7 :: 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 7





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


Os valores das tags "send", "recv", "local" e "remote" representam o ponto de vista da entidade que gera a descrição SDP. Em uma oferta, "send" é a direção ofertante->aceitante e "local" é o acesso à rede do ofertante. Em um aceite, "send" é a direção aceitante->ofertante e "local" é a rede de acesso do aceitante.

O exemplo seguinte mostra esses novos atributos SDP nas duas linhas de mídia de uma descrição de sessão:

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


5 Uso de pré-condições no modelo oferta-aceite

Negociação de parâmetros no SIP é realizada usando o modelo oferta-aceite descrito em [4]. A idéia por trás desse modelo é fornecer uma visão partilhada dos parâmetros de sessão para ambos os agentes-usuários uma vez o aceite seja recebido pelo ofertante. Esta seção descreve quais valores nossos novos atributos SDP podem ter em um aceite, dependendo de seu valor na oferta.

Para conseguir uma visão compartilhada do status de um fluxo de mídia, nós definimos um modelo que consiste de três tabelas: tanto agentes-usuários implementam uma tabela de status local, e cada troca oferta-aceite tem uma tabela de status de transação associado a ela. O ofertante gera uma tabela de status da transação, idêntica à sua tabela de status local, e a envia ao aceitante na oferta. O aceitante usa as informações dessa tabela status da transação para atualizar sua tabela de status local. O aceitante também atualiza os campos da tabela de status da transação que estavam fora da data e retorna essa tabela ao ofertante no aceite. O ofertante poderá então atualizar sua tabela de status local com as informações recebidas no aceite. Após essa troca oferta-aceite, as tabelas de status local de ambos os agentes-usuários ficarão sincronizadas. Eles agora têm uma visão comum do status do fluxo de mídia. Sessões que envolvem vários fluxos de mídia implementam essas tabelas por fluxo de mídia. Note, no entanto, que esse é um modelo de comportamento de agente-usuário, e não de software. Uma implementação fica livre para seguir qualquer abordagem que replique o comportamento externo que esse modelo define.




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


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.