[AsteriskBrasil] G729

[Armando Porto]

Daniel,

sob o aspecto da carga de processamento e preço, a utilização de GSM com
placas da DigiVoice , onde os codecs rodam na placa e não no Asterisk, é uma
excelente relação de custo benefício. Obviamente há casos em que não dá para
escapar do G.729 (a DigiVoice está trabalhando para colocar o CODEC na placa
também). Entretanto num cenário onde haverá grande comunicação entre
ASterisk e rede publia de telefonia comutada (rede tradicional) ou entre
Softphones e SoftPhones o Asterisk faria somente a função de Bridge e não de
transcodificador, com grande vantagem em termos de performance.

Armando


Em 05/07/06, Daniel Varella de Oliveira <dvarella em tecnologiaip.com.br>
escreveu:
>
> PessoALL,
>
> Cheguei a discutir um tempo atrás justamente este assunto da necessidade
> da
> utilização ou NÃO de licenças do codec G.729. Não sob o ponto de vista
> financeiro, mas devido à utilização de banda e "load" do servidor que
> hospeda
> o Asterisk.
>
> Na documentação que lí (e não foi pouca), o Asterisk pode "intermediar" a
> comunicação dos dois pontos devido à diferença de codecs entre os
> equipamentos. Porém lí também sobre o "load" que esta "intermediação"
> causa
> no servidor, fazendo com que o Asterisk trabalhe muito para compactar e
> descompactar os pacotes.
>
> Acho que o melhor cenário para estudar isso seria:
>
> Comunicação entre dois gateways (Gateway A e Gateway B), onde o GWA chama
> o
> GWB utilizando o codec G.729, caso no sip.conf estes estejam utilizando a
> opção canreinvite=yes, deveria não haver necessidade da utilização das
> licenças G.729, pois a comunicação seria ponto-a-ponto. O Asterisk também
> não
> iria "sofrer" para comprimir/descomprimir.
> Caso esta chamada seja redirecionada para um VoiceMail, aí sim ocorre a
> necessidade de se utilizar licenças G.729, pois o Asterisk terá que
> "intermediar" essa comunicação, já que o áudio do voicemail é gravado em
> ulaw.
>
> Bom galera, eu realmente queria saber quando o Asterisk realmente
> precisaria
> das licenças, pois como já disse anteriormente o problema todo não é o
> preço
> da bendita licença, mas sim o load que é gerado no servidor ao ser
> intermediado essa comunicação entre diferentes codecs.
>
> Assim, definindo com mais precisão o load de um servidor com Asterisk,
> podemos provisionar determinados esquemas com muitos ou poucos ramais. Ou
> seja, se o hardware que foi provisionado, vai ou não aguentar o tráfego
> esperado.
>
> Estou com um projeto de 1000 ramais IP para ser implementado, porém
> realmente
> estou com dúvidas nestas questões que estamos discutindo.
>
>
> Desculpem o longo e-mail, mas acho importante explicitar os
> questionamento,
> até mesmo para histórico da lista.
>
>
> --
>
> [ ]'s
>
> Daniel Varella de Oliveira
> Tecnologia IP Ltda
> Tel.: +55 (21)3139-4091 / r. 108
> Rio de Janeiro - Brasil
> www.tecnologiaip.com.br
>
>
>
>
> On Wednesday 05 July 2006 00:16, Caio Pato wrote:
> > On 7/4/06, Fernando Lemes da Silva <ferlemes em gmail.com> wrote:
> > > Alguem poderia dar uma luz sobre esta "falta de decoders"?
> >
> > Faça um teste... faça uma ligação e depois execute esse comando no
> console:
> > *CLI> show g729
> > 0/0 encoders/decoders of 25 licensed channels are currently in use
> > _______________________________________________
> > LIsta de discussões AsteriskBrasil.org
> > AsteriskBrasil em listas.asteriskbrasil.org
> > http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil
> >
> > _______________________________________________
> > Acesse o  wiki AsteriskBrasil.org:
> > http://www.asteriskbrasil.org
>
> _______________________________________________
> LIsta de discussões AsteriskBrasil.org
> AsteriskBrasil em listas.asteriskbrasil.org
> http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil
>
> _______________________________________________
> Acesse o  wiki AsteriskBrasil.org:
> http://www.asteriskbrasil.org
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://listas.asteriskbrasil.org/pipermail/asteriskbrasil/attachments/20060717/e2267f23/attachment.html