Ao usar um PBX hosted é necessário que se estabeleça um comparativo entre as opções que este tipo de serviço prove a quem o procura.
As limitações estão normalmente na quantidade de chamadas que podem ser executadas simultaneamente, na quantidade de minutos que será usado mensalmente e nos serviços que estarão a disposição do usuário.
Todas as limitações variam de acordo com a opção de serviço escolhida pelo interessado, mas nesse artigo de hoje o quero mostrar é a quantidade de megabytes que um minuto de chamada VoIP consome, dessa forma o usuário poderá estabelecer seus critérios tanto para a compra de um serviço PBX hosted quanto para a compra de um pacote de transmissão de dados através do uso de um celular 3G por exemplo.
Com os dados será possível realizar o calculo de custo da chamada, que será composto pelo custo do pacote minutos e mais o custo do minuto VoIP, tendo os dados do pacote você fará a seguinte conta, pega-se quanto de trafego ele permite e divide-se pelo consumo de um minuto de ligação e depois pega-se a quantia de minutos possíveis e o preço fazendo a divisão de um pelo outro teremos o custo do minuto falado e a esse valor adiciona-se o valor do minuto VoIP ai teremos quanto custa uma ligação VoIP usando-se um 3G.
O serviço de ramais mais popular entre os brasileiros é o PBXES este serviço de PBX hosted com ramais VoIP tem a seguinte característica quando se trata de consumo, um minuto de voz transmitida é igual a 2mb.
É muito importante o usuário estar ciente de determinadas questões e o consumo é uma dessas questões. O que tenho visto é que os usuários e técnicos de VoIP tem uma grande falta de interesse em se ater as questões pertinentes a funcionamento e muito aprofundamento na questão do preço do minuto VoIP e no tipo de pacote que o provedor VoIP esta oferecendo, muitas vezes esses pacotes contém uma proposta que na realidade é inviável e o usuário por falta de conhecimento acaba se iludindo. Caso prático desses pacotes é o VoIP Ilimitado, onde a palavra ilimitada ganha vários números, o mais comum são 3000 minutos, mas na realidade ao se comprar uma conta ilimitada muitas vezes não se pensa que para uma residência 3000 é uma quantia de minutos que nunca se usa e também que um serviço VoIP onde se tem um canal nunca atingirá essa marca.
A partir dessas observações me pego pensando que as pessoas têm muito tempo livre, ou que o tempo não tem custo, acredito que o bom uso e o conhecimento dos recursos levam fatalmente a uma maior economia a médio longo prazo do que a simples batalha pelo serviço com preços ridiculamente baixo, que nunca é tão baixo assim.
Eu vou descrever aqui como funciona o consumo de uma chamada Voip para que todos possam avaliar.
O codec G711 usa em média 90kbps e o G729 usa em média 30kbps, a formula usada para o calculo de consumo é:
MB per hour used =kbps *3600 (seconds in an hour) = kilobits per hour kilobits per hour /1024 (convert into megabits)=megabits per hour megabits per hour /8 (8 bits in a byte) = Megabytes (MB) per hour.
Complicado? Então vai mastigado
G711 = (90x3600) /1024 /8 = em torno de 40MB por hora.
G729 = (30x3600) /1024 /8 = em torno de 13MB por hora.
Lembrando que esse consumo é um consumo com base a um lado da chamada, e que para uma ligação ha dois lados o consumo deve ser dobrado.
Para minorar a situação existe a supressão do silencio que é um assunto que vamos deixar para uma próxima vez. (VAD)
Consumo de Banda:
Bandwidth
* GIPS Family - 13.3 Kbps and up
* GSM - 13 Kbps (full rate), 20ms frame size
* iLBC - 15Kbps,20ms frame size: 13.3 Kbps, 30ms frame size
* ITU G.711 - 64 Kbps, sample-based Also known as alaw/ulaw
* ITU G.722 - 48/56/64 Kbps ADPCM 7Khz audio bandwidth
* ITU G.722.1 - 24/32 Kbps 7Khz audio bandwidth (based on Polycom's SIREN codec)
* ITU G.722.1C - 32 Kbps, a Polycom extension, 14Khz audio bandwidth
* ITU G.722.2 - 6.6Kbps to 23.85Kbps. Also known as AMR-WB. CELP 7Khz audio bandwidth
* ITU G.723.1 - 5.3/6.3 Kbps, 30ms frame size
* ITU G.726 - 16/24/32/40 Kbps
* ITU G.728 - 16 Kbps
* ITU G.729 - 8 Kbps, 10ms frame size
* Speex - 2.15 to 44.2 Kbps
* LPC10 - 2.5 Kbps
* DoD CELP - 4.8 Kbps
Abaixo temos uma parte do artigo em inglês, porque não ha motivo para a tradução, uma vez que o que mais importa é a relação do consumo por tipos de rede e isso pode ser identificado no texto com facilidade.
With circuit-switched voice networks, all voice calls use 64 Kbps fixed-bandwidth links regardless of how much of the conversation is speech and how much is silence. With VoIP networks, all conversation and silence is packetized. Using Voice Activity Detection (VAD), packets of silence can be suppressed.
A G.711 call on a Frame Relay connection without IP/RTP header compression or VAD should take about 82.4 kbps. The formula I'm using for this is:
{(64,000 / 50) + 320 + 48} * 50
The 320 is for the IP, UDP, and RTP headers (in bits) and the 48 is for Frame Relay headers (also in bits).
I came up with the 50 by assuming a rate of one packet every 20ms, which is the default. 64,000 is obviously the bandwidth used by G.711. For G.729, the formula is the same just use 8,000 instead.
For Ethernet, instead use 112 bits (14 bytes) for the Layer 2 overhead and you'll come up with:
{(64,000 / 50) + 320 + 112} * 50 = 85.6 kbps
For an IPSec VPN, overhead is roughly 4X as much (estimate 480 bits). So you get:
{(64,000 / 50) + 320 + 480} * 50 = 100.4 kbps
If you've enabled IP/RTP header compression the overhead goes from 320 bits to 16-32 bits. This doesn't make a huge difference with G.711, but with G.729 the bandwidth savings are quite significant (as much as over 50%)
G.729 on Frame Relay without IP/RTP header compression:
{(8,000 / 50) + 320 + 48} * 50 = 26.4 kbps
Same but with IP/RTP header compression:
{(8,000 / 50) + 32 + 48} * 50 = 12.0 kbps
sábado, 4 de julho de 2009
domingo, 28 de junho de 2009
VoIP qualidade e confiabilidade
Dois dos maiores desafios da tecnologia de transmissão de voz através de uma rede IP são a confiabilidade e a qualidade da transmissão.
A confiabilidade esta ligada ao fato de que a chamada tem que chegar ate o destino e a qualidade tem relação com a forma como esta chamada irá chegar. Para atingir minimamente estes desafios será necessário que tenhamos certeza que ao realizar uma chamada o outro lado irá receber e recebendo tenha condições de entender o que esta sendo dito na chamada.
Estes desafios são frutos de questões simples, mas a primeira delas é que a chamada VoIP ira sair de uma rede local onde pode haver controle de tráfego e qualidade e irá trafegar por um período de tempo em uma rede onde não há a menor chance de ter-se um controle ainda que mínimo, pois a chamada ao entrar na rede Internet não nos permite prever os acontecimentos que irão ocorrer no momento da transmissão.
Todos esperamos que as empresas ligadas ao serviço de Internet estejam fazendo sua lição de casa e que com isso nossa chamada possa chegar ao seu destino, e ai teremos a primeira etapa, após esta teremos que ter certeza que os envolvidos estejam comprometidos com a qualidade das transmissões e dessa forma nossa chamada chegará audível e na ordem correta.
Temos na cadeia de fatores que estão diretamente ligados a confiabilidade e qualidade de uma transmissão de voz através da rede os seguintes interventores: NAT Transversal, ICE e STUN e vou colocar um pouco de cada um neste artigo e para os que quiserem se aprofundar é só usar o Google escrevendo : VoIP realibility and quality ou então associando o termo VoIP com cada um dos termos citados.
NAT acrônimo do inglês Network Address Translation, ou seja, o responsável pela tradução dos endereços IP. Em muitos casos essa tradução não é necessária, mas em outras ocasiões sim, por exemplo, quando usa-se uma rede particular com endereço privado e as estações desta rede irão acessar acessem a Internet. Dessa forma, se a estação 10.1.1.2 necessita acessar um servidor na internet, então será necessário traduzir o endereço 10.1.1.2 para um endereço conhecido. O principal protocolo usado para tramissão na Internet é o TCP e no caso do VoIP o UDP, estes protocolos se utilizamd do conceito de multiplexação através de portas de origem e destino, nos permitinod utilizar somente um endereço IP público para traduzir vários endereços privados (NAT masquerade ou NAT Hide), com a utilização de portas diferentes e armazenando todas estas informações em uma tabela de conexões.
O NAT Traversal verifica se os equipamentos envolvidos no estabelecimento da conexão possuem suporte para NAT Traversal, a seguir os equipamentos devem detectar se existe ou não a tradução de endereços. Por fim, deve-se negociar os parâmetros do protocolo (portas utilizadas para encapsulamento, utilização de cookies, etc) e em seguida iniciar a transmissão de dados utilizando pacotes encapsulados.
Este recurso pode ser utilizado com conexões VPN do tipo gateway-to-gateway ou client-to-gateway e deve ser verificado na documentação do equipamento se o mesmo suporta NAT Traversal ou UDP Encapsulation (expressão também utilizada por alguns fabricantes).
STUN acrônimo de Simple Traversal of UDP através de NATs (Network Address Translation) é um protocolo para auxiliar os dispositivos que se encontrem atrás de um NAT firewall ou mesmo de um roteador. A RFC 5389 esta redefinindo o termo STUN como 'Session Traversal Utilities for NAT'. Um servidor STUN ((Simple Traversal of User Datagram Protocol [UDP], por meio da Network Address Translators [NATs]), é um servidor que permite que clientes NAT (ex.: computadores protegidos por firewall) realizem chamadas telefônicas a um provedor VoIP que se encontre fora da rede local.
O servidor STUN permite que os clientes descubram seu endereço público, o tipo de NAT utilizado, e o lado da porta da Internet associada à NAT com uma porta local específica. Essas informações são usadas para permitir a comunicação UDP entre o cliente e o provedor VoIP, e então, estabelecer a chamada. O protocolo STUN é definido pela RFC 3489 e a porta comumente usada por um servidor STUN é a porta UDP 3478.
ICE ancronismo de Interactive Connectivity Establishment, ICE não é um novo protocolo, mas uma metodologia que faz uso de protocolos existentes, tais como o STUN Simple Traversal of UDP Through NAT (STUN), o Traversal Using Relay NAT (TURN) inclusive usa o Real Specific IP (RSIP).
O ICE funciona através de uma cooperação mútua de ambos os parâmetros finais de um diálogo SIP.
Com o trabalho em conjunto de endpoints NAT Traversal, uma série de propriedades importantes são obtidas. O ICE sempre funciona, independente do tipo ou número de NATs, e sempre representa a solução mais barata para transporte de um “Carrier”. Este método cria uma latência mínima em voz sobre IP, e pode ser usado sem aumentar o delay de uma chamada. O ICE é bem mais robusto que o STUN, sendo que o ICE também facilita a transição da Internet do IPv4 para o IPv6, dando suporte para as chamadas entre dual-stack e clientes IPV6 atrás de um NAT. Em algumas condições o STUN pode ser usado em conjunto com o ICE, para garantir que o telefone nunca toque a menos que os utilizadores possam tanto ouvir e ver uns aos outros.
Existem muitas teorias que estão em estudo e muitos trabalhos que estão sendo realizados e em fase de implantação para garantir a qualidade e a confiabilidade do trafego na Internet e estas ações irão em um futuro muito próximo aumentar a qualidade e a confiabilidade das transmissões de voz através da rede IP e consequentemente melhorar sobremaneira o VoIP.
A confiabilidade esta ligada ao fato de que a chamada tem que chegar ate o destino e a qualidade tem relação com a forma como esta chamada irá chegar. Para atingir minimamente estes desafios será necessário que tenhamos certeza que ao realizar uma chamada o outro lado irá receber e recebendo tenha condições de entender o que esta sendo dito na chamada.
Estes desafios são frutos de questões simples, mas a primeira delas é que a chamada VoIP ira sair de uma rede local onde pode haver controle de tráfego e qualidade e irá trafegar por um período de tempo em uma rede onde não há a menor chance de ter-se um controle ainda que mínimo, pois a chamada ao entrar na rede Internet não nos permite prever os acontecimentos que irão ocorrer no momento da transmissão.
Todos esperamos que as empresas ligadas ao serviço de Internet estejam fazendo sua lição de casa e que com isso nossa chamada possa chegar ao seu destino, e ai teremos a primeira etapa, após esta teremos que ter certeza que os envolvidos estejam comprometidos com a qualidade das transmissões e dessa forma nossa chamada chegará audível e na ordem correta.
Temos na cadeia de fatores que estão diretamente ligados a confiabilidade e qualidade de uma transmissão de voz através da rede os seguintes interventores: NAT Transversal, ICE e STUN e vou colocar um pouco de cada um neste artigo e para os que quiserem se aprofundar é só usar o Google escrevendo : VoIP realibility and quality ou então associando o termo VoIP com cada um dos termos citados.
NAT acrônimo do inglês Network Address Translation, ou seja, o responsável pela tradução dos endereços IP. Em muitos casos essa tradução não é necessária, mas em outras ocasiões sim, por exemplo, quando usa-se uma rede particular com endereço privado e as estações desta rede irão acessar acessem a Internet. Dessa forma, se a estação 10.1.1.2 necessita acessar um servidor na internet, então será necessário traduzir o endereço 10.1.1.2 para um endereço conhecido. O principal protocolo usado para tramissão na Internet é o TCP e no caso do VoIP o UDP, estes protocolos se utilizamd do conceito de multiplexação através de portas de origem e destino, nos permitinod utilizar somente um endereço IP público para traduzir vários endereços privados (NAT masquerade ou NAT Hide), com a utilização de portas diferentes e armazenando todas estas informações em uma tabela de conexões.
O NAT Traversal verifica se os equipamentos envolvidos no estabelecimento da conexão possuem suporte para NAT Traversal, a seguir os equipamentos devem detectar se existe ou não a tradução de endereços. Por fim, deve-se negociar os parâmetros do protocolo (portas utilizadas para encapsulamento, utilização de cookies, etc) e em seguida iniciar a transmissão de dados utilizando pacotes encapsulados.
Este recurso pode ser utilizado com conexões VPN do tipo gateway-to-gateway ou client-to-gateway e deve ser verificado na documentação do equipamento se o mesmo suporta NAT Traversal ou UDP Encapsulation (expressão também utilizada por alguns fabricantes).
STUN acrônimo de Simple Traversal of UDP através de NATs (Network Address Translation) é um protocolo para auxiliar os dispositivos que se encontrem atrás de um NAT firewall ou mesmo de um roteador. A RFC 5389 esta redefinindo o termo STUN como 'Session Traversal Utilities for NAT'. Um servidor STUN ((Simple Traversal of User Datagram Protocol [UDP], por meio da Network Address Translators [NATs]), é um servidor que permite que clientes NAT (ex.: computadores protegidos por firewall) realizem chamadas telefônicas a um provedor VoIP que se encontre fora da rede local.
O servidor STUN permite que os clientes descubram seu endereço público, o tipo de NAT utilizado, e o lado da porta da Internet associada à NAT com uma porta local específica. Essas informações são usadas para permitir a comunicação UDP entre o cliente e o provedor VoIP, e então, estabelecer a chamada. O protocolo STUN é definido pela RFC 3489 e a porta comumente usada por um servidor STUN é a porta UDP 3478.
ICE ancronismo de Interactive Connectivity Establishment, ICE não é um novo protocolo, mas uma metodologia que faz uso de protocolos existentes, tais como o STUN Simple Traversal of UDP Through NAT (STUN), o Traversal Using Relay NAT (TURN) inclusive usa o Real Specific IP (RSIP).
O ICE funciona através de uma cooperação mútua de ambos os parâmetros finais de um diálogo SIP.
Com o trabalho em conjunto de endpoints NAT Traversal, uma série de propriedades importantes são obtidas. O ICE sempre funciona, independente do tipo ou número de NATs, e sempre representa a solução mais barata para transporte de um “Carrier”. Este método cria uma latência mínima em voz sobre IP, e pode ser usado sem aumentar o delay de uma chamada. O ICE é bem mais robusto que o STUN, sendo que o ICE também facilita a transição da Internet do IPv4 para o IPv6, dando suporte para as chamadas entre dual-stack e clientes IPV6 atrás de um NAT. Em algumas condições o STUN pode ser usado em conjunto com o ICE, para garantir que o telefone nunca toque a menos que os utilizadores possam tanto ouvir e ver uns aos outros.
Existem muitas teorias que estão em estudo e muitos trabalhos que estão sendo realizados e em fase de implantação para garantir a qualidade e a confiabilidade do trafego na Internet e estas ações irão em um futuro muito próximo aumentar a qualidade e a confiabilidade das transmissões de voz através da rede IP e consequentemente melhorar sobremaneira o VoIP.
sábado, 27 de junho de 2009
Voip e consumo de banda de Internet
Usei este espaço até hoje para colocar minhas idéias e o fruto de meus estudos e trabalho, aqui não há esquemas ou formulas para se ganhar nada que não seja fruto de trabalho, quem estiver procurando por este tipo de informação este não é o local.
Não sei como fazer para fazer chamadas burlando empresas, não busco por isso, aqui tem informações na maioria das vêzes de conteúdo técnico e talvez por isso até mesmo difíceis de serem entendidas, pela sua própria complexidade ou pela incapacidade do autor de se fazer entender ou de transmiti-las, e por isso peço desculpas – “mea culpa”.
Já escrevi alguns artigos sobre VoIP e Internet, e como a dependência do VoIP é total ou seja só funciona se houver conexão de Internet suficiente para tal, entendo que escrever mais sobre o assunto ainda que parte do manuscrito seja repetitivo é e será relevante para que acabe sendo compreendido na totalidade.
Codecs, sua importância é determinada pelo fato de termos que VoIP funciona recebendo e enviando pacotes de voz através de uma rede IP podendo esta ser uma rede VPN local ou mesmo a rede mundial, a capacidade e de absorção do tráfego e a disponibilidade de banda para este é determinante na qualidade da transmissão. Eu aprendi que VoIP não tem garantia de entrega quando esta sendo usada a rede mundial, uma vez que QoS, ToS e outros dispositivos que contribuem para uma boa transmissão ficam totalmente sem controle ao estar sendo usada a rede publica, nesta tem preferência o que tiver uma maior taxa de Throughput (ou taxa de transferência), que é a quantidade de dados transferidos de um lugar a outro, ou a quantidade de dados processados em um determinado espaço de tempo.
A taxa de Throughput é a taxa de transferência efetiva de um determinado sistema, por exemplo uma rede de computadores, e poderá ser menor que a taxa de entrada devido às perdas e atrasos no sistema, os chamados Jitter e Lags que são produzidos por ajustes que são obrigatórios para que se tente garantir a entrega dos pacotes que estão na rede.
Já escrevi uma vez que o Troughput não é largura de banda nominal, podemos ter um link de 4 Mbps mas se no caminho onde o conteúdo for roteado encontramos por exemplo um link de 1Mbps o throughput será automaticamente nivelado pelo menor link. Por isso é que tem que se estar o tempo todo analisando não só a rede e os links mas também a rota que esta sendo usada para a transmissão, e sobre essa não há, quando se trata da W3C, o menor controle.
Há muitas discussões e divergencias sobre Codecs, qual o mais apropriado para VoIP, qual o que deixa a tramissão mais clara, qual o que é mais estavel, estas e mais uma centena de questionamentos não possuem em minha modesta opinião uma resposta que possa ser considerada verdade absoluta pois tudo depende de tudo. O que entendo é que possa ser feito testes para analise da condição que se encontra a chamada, e que para cada local e tipo de conexão iremos ter uma resposta, são atipicos os exemplos que podem servir para todos os casos e situações.
Acredito ser um bom começo o estudo sistematico das tecnologias quando estas são chamadas emergentes, nestes casos não temos teorias e sim hipóteses que servirão um dia para termos os conceitos e as teorias imutaveis como é o caso da Matematica e da Fisica, por isso mesmo hoje vou colocar aqui links que servem para leitura e consulta sobre Codecs e consumo de banda em chamadas telefonicas e deixo os de uma empresa que tem o respeito de todos, a Cisco.
Links:
Páginas da Cisco
http://www.cisco.com/en/US/products/ps10024/products_qanda_item09186a0080a35d91.shtml#qa1
http://www.cisco.com/application/pdf/paws/108768/pqa_108768.pdf
Página da Cisco onde esta Cisco Technical Tips Conventions
http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml
Páginas da Cisco onde se pode estudar os Codecs e sua composicação e seu consumo.
http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00800b6710.shtml
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml
Codecs sua complexidade MOS e negociação
http://www.cisco.com/application/pdf/paws/14069/codec_complexity.pdf
Consumo de banda segundo a Cisco, documento 7934
http://www.cisco.com/application/pdf/paws/7934/bwidth_consume.pdf
Acredito que o material acima seja um bom começo para aqueles que gostem de realizar um bom trabalho profissional e também para os que costumam questionar as afriamções e declarações de outrem, lendo-os todos passarão a poder contribuir para que se chegue a um consenso, afinal não se tira conhecimento de pedra.
Não sei como fazer para fazer chamadas burlando empresas, não busco por isso, aqui tem informações na maioria das vêzes de conteúdo técnico e talvez por isso até mesmo difíceis de serem entendidas, pela sua própria complexidade ou pela incapacidade do autor de se fazer entender ou de transmiti-las, e por isso peço desculpas – “mea culpa”.
Já escrevi alguns artigos sobre VoIP e Internet, e como a dependência do VoIP é total ou seja só funciona se houver conexão de Internet suficiente para tal, entendo que escrever mais sobre o assunto ainda que parte do manuscrito seja repetitivo é e será relevante para que acabe sendo compreendido na totalidade.
Codecs, sua importância é determinada pelo fato de termos que VoIP funciona recebendo e enviando pacotes de voz através de uma rede IP podendo esta ser uma rede VPN local ou mesmo a rede mundial, a capacidade e de absorção do tráfego e a disponibilidade de banda para este é determinante na qualidade da transmissão. Eu aprendi que VoIP não tem garantia de entrega quando esta sendo usada a rede mundial, uma vez que QoS, ToS e outros dispositivos que contribuem para uma boa transmissão ficam totalmente sem controle ao estar sendo usada a rede publica, nesta tem preferência o que tiver uma maior taxa de Throughput (ou taxa de transferência), que é a quantidade de dados transferidos de um lugar a outro, ou a quantidade de dados processados em um determinado espaço de tempo.
A taxa de Throughput é a taxa de transferência efetiva de um determinado sistema, por exemplo uma rede de computadores, e poderá ser menor que a taxa de entrada devido às perdas e atrasos no sistema, os chamados Jitter e Lags que são produzidos por ajustes que são obrigatórios para que se tente garantir a entrega dos pacotes que estão na rede.
Já escrevi uma vez que o Troughput não é largura de banda nominal, podemos ter um link de 4 Mbps mas se no caminho onde o conteúdo for roteado encontramos por exemplo um link de 1Mbps o throughput será automaticamente nivelado pelo menor link. Por isso é que tem que se estar o tempo todo analisando não só a rede e os links mas também a rota que esta sendo usada para a transmissão, e sobre essa não há, quando se trata da W3C, o menor controle.
Há muitas discussões e divergencias sobre Codecs, qual o mais apropriado para VoIP, qual o que deixa a tramissão mais clara, qual o que é mais estavel, estas e mais uma centena de questionamentos não possuem em minha modesta opinião uma resposta que possa ser considerada verdade absoluta pois tudo depende de tudo. O que entendo é que possa ser feito testes para analise da condição que se encontra a chamada, e que para cada local e tipo de conexão iremos ter uma resposta, são atipicos os exemplos que podem servir para todos os casos e situações.
Acredito ser um bom começo o estudo sistematico das tecnologias quando estas são chamadas emergentes, nestes casos não temos teorias e sim hipóteses que servirão um dia para termos os conceitos e as teorias imutaveis como é o caso da Matematica e da Fisica, por isso mesmo hoje vou colocar aqui links que servem para leitura e consulta sobre Codecs e consumo de banda em chamadas telefonicas e deixo os de uma empresa que tem o respeito de todos, a Cisco.
Links:
Páginas da Cisco
http://www.cisco.com/en/US/products/ps10024/products_qanda_item09186a0080a35d91.shtml#qa1
http://www.cisco.com/application/pdf/paws/108768/pqa_108768.pdf
Página da Cisco onde esta Cisco Technical Tips Conventions
http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml
Páginas da Cisco onde se pode estudar os Codecs e sua composicação e seu consumo.
http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00800b6710.shtml
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml
Codecs sua complexidade MOS e negociação
http://www.cisco.com/application/pdf/paws/14069/codec_complexity.pdf
Consumo de banda segundo a Cisco, documento 7934
http://www.cisco.com/application/pdf/paws/7934/bwidth_consume.pdf
Acredito que o material acima seja um bom começo para aqueles que gostem de realizar um bom trabalho profissional e também para os que costumam questionar as afriamções e declarações de outrem, lendo-os todos passarão a poder contribuir para que se chegue a um consenso, afinal não se tira conhecimento de pedra.
Assinar:
Postagens (Atom)