Página 2 de 3 PrimeiroPrimeiro 123 ÚltimoÚltimo
+ Responder ao Tópico



  1. As máquinas de cartão usam o mesmo processo de transmissão das máquinas de fax. Com isso estas máquinas necessitam que a voz não esteja "compactada" para que a comunicação ocorra. Os codecs fazem justamente o trabalho de compactação da voz em tempo real que retira os sons inaudíveis aos ouvido humano. Para resolver o problema tente forçar o uso do codec g711 (se sua operadora voip aceitar). Uma coisa importante tmbm é o QoS, já que se a voz "pipocar", mesmo usando o g711, a transmissão irá cessar. O QoS implementado pelos ATAs via TOS/DSCP não funciona corretamente pois todo pacote RTP que retorna (a voz do seu interlocutor) sempre virá com o cabeçalho TOS/DSCP zerado, mesmo que seu provedor envie com alta prioridade. Isso ocorre pq os roteadores alteram o cabeçalho ip destes pacotes ao longo do caminho.

  2. Citação Postado originalmente por aheringer Ver Post
    As máquinas de cartão usam o mesmo processo de transmissão das máquinas de fax. Com isso estas máquinas necessitam que a voz não esteja "compactada" para que a comunicação ocorra. Os codecs fazem justamente o trabalho de compactação da voz em tempo real que retira os sons inaudíveis aos ouvido humano. Para resolver o problema tente forçar o uso do codec g711 (se sua operadora voip aceitar). Uma coisa importante tmbm é o QoS, já que se a voz "pipocar", mesmo usando o g711, a transmissão irá cessar. O QoS implementado pelos ATAs via TOS/DSCP não funciona corretamente pois todo pacote RTP que retorna (a voz do seu interlocutor) sempre virá com o cabeçalho TOS/DSCP zerado, mesmo que seu provedor envie com alta prioridade. Isso ocorre pq os roteadores alteram o cabeçalho ip destes pacotes ao longo do caminho.
    Td bem André? Sumidoooo....

    Seguinte, já tentou implementações MPLS para VoIP?



  3. Eu nunca usei cartão de crédito no voip, mas se for como o amigo acima falou, ou seja, usa o mesmo protocolo que fax habilite o T.38 (nem todas terminações aceitam)

  4. Citação Postado originalmente por sergio Ver Post
    Td bem André? Sumidoooo....

    Seguinte, já tentou implementações MPLS para VoIP?

    Grande Sergio!
    E aí cara, tudo blz ? Feliz ano novo para vc e sua família ! Sim, estou de volta ao fórum depois de um longo tempo sem postar. Gostei muito da sua palestra sobre QoS no MUM e pessoas como vc é que enobrecem o underlinux. Quanto ao MPLs eu não tentei implementar pois acabei desenvolvendo uma solução própria para priorizar o voip e afins. Minha briga com o QoS é antiga e testei de todas as maneiras uma forma de priorizar o tráfego que entra pois são muitas as dificuldades:

    - Priorizar por TOS/DSCP não é uma boa idéia pq o tráfego que retorna sempre vem com DSCP/TOS zerado. Além disso alguns vírus fazem uso deste campo ao gerar seus pacotes.
    - Priorizar por porta tmbm não funciona pq as portas SIP são somente para sinalização sendo que a mídia de voz usa portas aleatórias.
    - Priorizar por destino tmbm não é uma boa idéia pois as maioria das operadoras voip faz o reinvite do tráfego RTP e nunca sabemos para qual servidor será encaminhado.
    - Priorizar por origem funciona porém é necessário manter as regras para cada ATA que esteja em uso . Além disso o uso do softphone fica comprometido.

    Uma solução seria priorizar por L7 mas a última vez que testei ele reconhecia somente o RTP gerado pelo netmeeting, sendo que o filtro para o SIP/CRTP/RTP não está completamente maduro (QoS and Layer7 RTP doesn't work? - LinksysInfo - Community Forums for Linksys Devices). Outro porém é o uso do RTP para aplicações não críticas como jogos, por exemplo. o que acaba inviabilizar o uso do QoS sobre o RTP. Tmbm o fato do pacote RTP ser pequeno, mas de bom fluxo, torna o consumo de processamento um pouco maior.

    A soluçao que adotei foi escrever um programa em C para reconhecer o que é UDP -> RTP->G729 gerador pelo SIPv2 e alterar o buffer das interfaces (fifo) para colocar os pacotes prioritários na frente dos demais pacotes não prioritários. A vantagem disso é que o priorizador reconhece qualquer mídia de voz gerado por qualquer dispositivo (ata, softphones, etc) de forma automática sem fazer reserva de banda. O sistema roda no rtl8186 como bridge e não há necessidade de configurar nada, bastando colocar na porta WAN do equipamento o cabo que vem do roteador e na porta LAN colocar o cabo que sai para a rede local. Com isso, independente do tráfego passante a voz será priorizada sem alterar a estrutura de rede atual.

    Grande abraço,

    André Heringer



  5. Citação Postado originalmente por aheringer Ver Post
    Grande Sergio!
    E aí cara, tudo blz ? Feliz ano novo para vc e sua família ! Sim, estou de volta ao fórum depois de um longo tempo sem postar. Gostei muito da sua palestra sobre QoS no MUM e pessoas como vc é que enobrecem o underlinux. Quanto ao MPLs eu não tentei implementar pois acabei desenvolvendo uma solução própria para priorizar o voip e afins. Minha briga com o QoS é antiga e testei de todas as maneiras uma forma de priorizar o tráfego que entra pois são muitas as dificuldades:

    - Priorizar por TOS/DSCP não é uma boa idéia pq o tráfego que retorna sempre vem com DSCP/TOS zerado. Além disso alguns vírus fazem uso deste campo ao gerar seus pacotes.
    - Priorizar por porta tmbm não funciona pq as portas SIP são somente para sinalização sendo que a mídia de voz usa portas aleatórias.
    - Priorizar por destino tmbm não é uma boa idéia pois as maioria das operadoras voip faz o reinvite do tráfego RTP e nunca sabemos para qual servidor será encaminhado.
    - Priorizar por origem funciona porém é necessário manter as regras para cada ATA que esteja em uso . Além disso o uso do softphone fica comprometido.

    Uma solução seria priorizar por L7 mas a última vez que testei ele reconhecia somente o RTP gerado pelo netmeeting, sendo que o filtro para o SIP/CRTP/RTP não está completamente maduro (QoS and Layer7 RTP doesn't work? - LinksysInfo - Community Forums for Linksys Devices). Outro porém é o uso do RTP para aplicações não críticas como jogos, por exemplo. o que acaba inviabilizar o uso do QoS sobre o RTP. Tmbm o fato do pacote RTP ser pequeno, mas de bom fluxo, torna o consumo de processamento um pouco maior.

    A soluçao que adotei foi escrever um programa em C para reconhecer o que é UDP -> RTP->G729 gerador pelo SIPv2 e alterar o buffer das interfaces (fifo) para colocar os pacotes prioritários na frente dos demais pacotes não prioritários. A vantagem disso é que o priorizador reconhece qualquer mídia de voz gerado por qualquer dispositivo (ata, softphones, etc) de forma automática sem fazer reserva de banda. O sistema roda no rtl8186 como bridge e não há necessidade de configurar nada, bastando colocar na porta WAN do equipamento o cabo que vem do roteador e na porta LAN colocar o cabo que sai para a rede local. Com isso, independente do tráfego passante a voz será priorizada sem alterar a estrutura de rede atual.

    Grande abraço,

    André Heringer
    Um ótimo 2009 para você também!

    Pensei que havia testado alguma coisa no MPLS. Estou tentando aqui, mas não tenho tempo, não tenho equipamentos suficientes, não tenho rede suficiente....hehehehehe. Tá uma fartura danada... farta tudo.


    Sobre seu projeto, você comentou aquele dia, comigo. Muito bom. Você já está comercializando? Se sim, envia para mim no e-mail, pois quando clientes solicitarem eu já tenho o que oferecer!






Tópicos Similares

  1. Como Criar Template para Wordpress?
    Por leoservice no fórum Servidores de Rede
    Respostas: 7
    Último Post: 13-02-2012, 07:06
  2. Como criar rotas para receber outro link
    Por wala no fórum Redes
    Respostas: 3
    Último Post: 19-01-2010, 08:48
  3. Respostas: 1
    Último Post: 19-01-2008, 18:31
  4. Qos para msn e outros
    Por thenet no fórum Redes
    Respostas: 11
    Último Post: 07-12-2007, 09:21
  5. como criar rota para máquinas windows na vpn
    Por rodriguesoline no fórum Servidores de Rede
    Respostas: 6
    Último Post: 05-11-2004, 10:11

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L