O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Uma Análise dos Sistemas de Comunicação IP

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Próximos SlideShares
Congresso iii unifacsv3
Congresso iii unifacsv3
Carregando em…3
×

Confira estes a seguir

1 de 9 Anúncio

Uma Análise dos Sistemas de Comunicação IP

Baixar para ler offline

Análise das opções disponíveis para Comunicação IP, em Nuvem, virtualizadas, ou em appliance, compreendendo os protocolos SIP e os mecanismos SBC e Stun, cenários de aplicação.

Análise das opções disponíveis para Comunicação IP, em Nuvem, virtualizadas, ou em appliance, compreendendo os protocolos SIP e os mecanismos SBC e Stun, cenários de aplicação.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Semelhante a Uma Análise dos Sistemas de Comunicação IP (20)

Anúncio

Mais recentes (20)

Uma Análise dos Sistemas de Comunicação IP

  1. 1. Uma Análise dos Sistemas de Comunicação IP, Unificadas e PBX’s IP Resumo Este artigo versa sobre as ofertas de sistemas de Comunicação IP atualmente disponíveis comercialmente, desde o PBX IP tradicional até implementações com integração de múltiplos serviços de voz, vídeo e conferência, no qual procura-se elencar e analisar as variadas arquiteturas, funcionalidades, capacidades, vantagens e desvantagens, assim como sua aplicabilidade quanto ao tipo de Cenário em relação à sua disposição integralmente por Software, seja na Nuvem ou em máquina virtual local ou ainda como um appliance de Hardware. Introdução No atual contexto das redes de Comunicação por IP estamos vivenciando uma rápida transição do modelo baseado em Hardware anteriormente existente onde conviviam sistemas integrados de Hardware ou híbrido de Hardware/Software para um implementado integralmente por software, notadamente como máquinas virtuais em sistemas VMware ou Hyper-V. Já em 2011 Marc Andreessen vaticinava ao Wall Street Journal [1] que o “software estava engolindo o mundo”. Esta declaração, vinda do coautor visionário do Mosaic, o primeiro browser do mercado, vem se revelando bastante evidende nos dias atuais. Uma outra interpretação para o novo contexto que se apresenta é a de que tudo o que você de fato vê é o software, sendo esta entidade representada por uma poderosa interface Web- GUI, independentemente da plataforma, no qual o Hardware e a plataforma perde sua relevância. A partir desta visão, o importante é o software que você de fato vê e suas funcionalidades, não importando a plataforma subjacente. Neste contexto, torna-se irrelevante se a plataforma é implementada em appliance, se reside na Nuvem, em Virtualização Local ou ainda Híbrida (ambos). Neste breve estudo apresentamos uma análise sobre as opções disponíveis. Faz-se mister advertir que preferências e interesses comerciais influenciam e se refletem nas análises e por isto não podemos pretender apresentar uma análise plenamente isenta, desta forma este artigo poderá refletir opiniões particulares do autor. Um outro cuidado a ser tomado é que a dinâmica das mudanças tecnológicas contribui para uma difusão nas análises em um mundo em que nem mesmo a longevidade representa uma garantia absoluta. Contudo, parque instalado e fração de participação no mercado ainda conferem um peso importante às soluções. A seguir, iremos analisar o cenário atual, as diversas arquiteturas disponíveis e nos deteremos sobre dois sistemas elencados entre os nossos favoritos, IP Office da Avaya e o 3CX. A partir de uma análise de arquiteturas gerais nos deteremos nestes dois modelos de sistemas de comunicação IP e os utilizaremos para fazer uma análise comparativa entre eles e os demais sistemas e plataformas existentes no mercado .
  2. 2. Avaya IP Office O Avaya IP Office é mais conhecido pela sua implementação em appliance por hardware, o IPO500, e uma descrição mais detalhada deste sistema pode ser encontrada em [2]. Em termos gerais um appliance de hardware significa um dispositivo/equipamento implementado em hardware desenvolvido especificamente para abrigar um determinado sistema. Uma característica importante do IP Office é sua característica híbrida. A hibridização no contexto do IP Office significa que ele é capaz de se conectar por hardware e software com interfaces próprias ao mundo TDM [3], que poderemos sumarizar como sendo o mundo tradicional da telefonia legada, ou seja, aquele constituído por links E1/R2, ISDN e também troncos analógicos. Por outro lado, o IP Office é um equipamento capaz de falar com o mundo IP SIP e H.323. O IPO500 é provavelmente o único sistema do mercado capaz de se comunicar com todos os mundos da Telefonia, desde a legada estabelecida ao mundo SIP contemporâneo. É caracterizado pelo baixo consumo de energia – apenas 80 Watts, e alta confiabilidade, apresentando um MTBF [4] de até 15 anos ! O sistema encontra-se instalado em mais de 500 mil instalações ao redor do globo e vem sendo continuamente suportado e com lançamentos semestrais de novas versões. Atualmente conta com uma versão para máquinas virtuais, inteiramente em software, que pode utilizar um IPO500 como extensão ou ser disponibilizado inteiramente em Nuvem. Desta forma, podemos dizer que o IPO500/IP Office conseguiu superar a barreira do confinamento em um appliance em hardware e realizar a transição para o mundo inteiramente em software, exatamente aquele previsto por Marc Andreessen. Por estes motivos, o IP Office, que tem evoluído desde 2008 obteve sucesso em atravessar a barreira do tempo com louvor e mantém-se atualizado, justificando-se como uma possível escolha. Existem outras implementações em appliance de fabricantes distintos, em que a Grandstream merece citação, porém o IPO500 é sem dúvida a mais completa e flexível, eleito como referência de appliance em hardware que empregaremos no restante deste artigo. 3CX O 3CX é um sistema de telefonia IP completo, puramente implementado por software que desde os seus primórdios visou a facilidade de uso. Ao contrário de seus concorrentes baseados cruamente em Asterisk, o 3CX adotou inicialmente um “motor” Microsoft. Esta visão de favorecimento da funcionalidade combinada com a facilidade e uma interface de configuração intuitiva e amigável ao usuário favoreceu a projeção da 3CX no mercado. Contudo, as versões anteriores apresentavam uma fragilidade importante, que era a dependência da plataforma Windows. Embora para as empresas “puramente Windows” esta arquitetura representasse uma vantagem, esta mesma característica representava também algumas desvantagens, notadamente a necessidade de arcar com licenças Windows e o fato de requerer gateways externos para realizar a compatibilização com a telefonia TDM. A necessidade de uma plataforma Windows representava anteriormente, de certa forma, uma desvantagem em relação a sistemas como o IP Office, por exemplo, que em
  3. 3. ambientes híbridos e que requeriam maior envergadura se mostrava claramente mais flexível a adaptável. A 3CX mais recentemente adotou a plataforma Debian Linux, um grande salto, que possibilitou o uso do sistema em plataformas baseadas em máquina virtual Linux, ou pequenos appliances genéricos e se ajustou de forma bastante flexível a plataformas baseadas em Nuvem. Simultaneamente a 3CX investiu na automatização dos procedimentos de instalação e troubleshooting, detecção de anomalias e incompatibilidades, ao mesmo tempo em que enriquecia as funcionalidades e propiciava uma interface de gerenciamento bastante versátil, plenamente Web e gráfica. Por estes motivos, o 3CX, que conhecemos de longa data, a partir principalmente dos últimos tempos, tornou-se extremamente atraente, principalmente onde o tronco SIP é a alternativa ao TDM. No restante deste artigo será a referência para PBXs baseados na Nuvem e exclusivamente em Software. Sistemas Livres e Sistemas Proprietários Desde os primórdios da telefonia um sistema de telefonia IP específico tem se destacado como o preponderante no mundo do Open Source, também denominado de Software Livre. O Open Source é um mundo bastante amplo e que de fato representa uma alternativa que espelha o mundo de softwares ditos proprietários, concorrendo par-a-par com este. O Asterisk é o representante maior do mundo Open Source com relação à Telefonia IP, da mesma forma que sistemas operacionais como o Debian, CentOS e Ubuntu e bancos de dados NoSQL como o MongoDB, juntamente com o arcabouço composto por variadas linguagens e versões de banco de dados “freeware”. Inúmeros sistemas de telefonia IP são baseados em Asterisk, sendo este o motor explícito ou implícito de variados sistemas de telefonia IP. Contudo, o Asterisk por si só não propicia ou favorece facilidades e recursos de gerenciamento e interconectividade de forma tão bem estruturada como aquela oferecida por sistemas ditos “proprietários”. Em verdade, muitos sistemas ditos proprietários se valem de motores baseados em Open Source para formatar os seus produtos, implementando uma camada de apresentação mais bem elaborada. Variantes do Asterisk existem sob diversas denominações, como o Issabel e o Elastix, entre outros. A grande questão que se coloca então não é propriamente se o sistema é Open Source, mas como se apresenta o sistema de telefonia IP para o administrador de redes e os usuários, que agora denominaremos de Comunicações Unificadas para significar uma maior e mais ampla abrangência de aplicações, privilegiando a usabilidade e funcionalidades embutidas. O que agora importa para o administrador do sistema é a potência do sistema. E devemos entender potência como a facilidade de uso, que se reflete em quão rápido, funcional e eficaz é o Dashboard do sistema. Este Dashboard deve permitir realizar as devidas configurações, reconfigurações, movimentações, adições, mudanças, backups, reparos e recuperações, monitoramento, troubleshooting e gerência através de uma única e poderosa interface Web-GUI de forma intuitiva e quase instantânea.
  4. 4. Agora que todo o sistema de comunicação interno e externo passa a depender de um sistema específico não é mais viável adquirir um sistema Open Source “cru” que demandará um tempo extremamente longo de customização. Este tempo agora representa um custo muitas vezes inaceitável e que será cobrado em horas técnicas, sejam elas internas ou externas. De um jeito ou de outro “alguém” estará pagando por isto. Quando então comparamos um sistema como o 3CX ou IP Office com o Asterisk deveremos levar em conta os fatores de custo escondido, que são justamente o tempo de aprendizado, o “time to learn” e o tempo de customização. Visando suprir estas carências muitas empresas se especializaram em fornecer sistemas complementares, com uma interface auxiliar de configuração, que em geral são fornecidas por um determinado custo ou contrato. De certa forma, recaem no fornecimento de um outro produto, com uma denominação acima do Asterisk, embora este esteja quase sempre subjacente. Tendo estes fatores em mente, o mais importante a ser pesado ao realizar a escolha de um sistema de telefonia é a potência do sistema medida em termos de funcionalidades que são enxergadas como características de software. Soluções de Hardware e Soluções de Software De forma geral, ao contrário do que poderia parecer no contexto atual, as soluções em hardware local ainda podem ser mais efetivas e tornar os sistemas mais facilmente gerenciáveis em determinadas situações, sobretudo em instalações menores. Geralmente vamos encontrar pequenos appliances em ambientes sub-50 e até sub-100. Neste casos, podemos mesmo dizer que o “appliance não está completamente morto”, muito pleo contrário, pois tudo depende de fato do ... Cenário ! De toda, forma, no caso de sistemas novos, cuja implementação parta de fato do zero ou represente uma transição de um cenário TDM para um inteiramente novo, sem reaproveitamento de qualquer estrutura legada, a solução totalmente baseada em Software, seja em máquina virtual ou em Nuvem deve sempre ser considerada e avaliada. Outro fator especialmente importante e que também deve ser considerado é o tipo de tronco a ser utilizado. O E1R2 ainda é predominante no Brasil, embora um movimento mais forte por parte das Operadoras esteja ampliando significativamente a oferta de troncos do tipo “SIP puro”, ou seja, aquele que chega por fibra ótica diretamente na localidade do cliente. Nestes casos o appliance pode ser deixado de lado em favor da máquina virtual VMware ou Hyper-V. Nuvem ou Local Já sabemos então que podemos disponibilizar um PBX IP, ou Sistema de Comunicação IP através de Hardware, Hardware/Software, Máquina Virtual ou Nuvem e que devemos escolher entre as opções de deployment de PBX IP. Para podermos melhor compreender os critérios para realizar tais escolhas listamos estes deployments: • Pequeno e médio appliance de hardware com link(s) E1R2(s) • Pequeno e médio appliance de hardware com link(s) SIP • Máquina virtual Local VMware com tronco SIP • Nuvem, ou seja, máquina virtual remota em Provedor
  5. 5. A grande questão que se apresenta atualmente é a seguinte. Devemos colocar tudo em Nuvem e somente em Nuvem ou existem cenários distintos que requerem um análise mais detalhada da aplicabilidade de cada solução ? A resposta para este tipo de questionamento reside no entendimento do seu cenário. O cenário é composto por variados parâmetros tais como: • Forma de uso da telefonia, sua intensidade e tipo de uso • Concentração de usuários na Localidade Principal • Dispersão geográfica dos usuários e mobilidade • Tipos de troncos disponíveis, E1R2 versus SIP • Tipos de aparelhos existentes, parque legado, novos e usados • Utilização de Softfones e Celulares Entendemos que somente a correta análise do cenário, a forma de uso, perfil de tráfego, perfil dos usuários, distribuição geográfica dos usuários e aplicações poderá determinar qual é a melhor arquitetura a ser utilizada, devendo ser evitada a escolha “a priori”. É importante também compreender o contexto de forma objetiva, deixando de lado alguns mitos criados acerca da computação em Nuvem e que a seguir elencamos como não necessariamente verdadeiras, ou seja, mito criados e cuja crença determina decisões equivocadas: • A Computação em Nuvem simplifica a administração e gerenciamento • A Computação em Nuvem sempre melhora o desempenho • A Computação em Nuvem é mais segura • A Computação em Nuvem sempre reduz os custos Muitas vezes baseamos nossas decisões a partir de preceitos de marketing criados para favorecer mitos que influenciam na tomada de decisões. O que se conhece como verdade no mundo da computação é que toda decisão acerca da adoção de uma tecnologia ou formato de negócio deve ser precedida de um estudo detalhado e conhecimento criterioso do cenário, o que também conhecemos como assessment. A adoção de uma solução baseando-se somente no apelo de marketing ou material promocional dos Provedores de Serviço pode bloquear a visão do cenário e levar a decisões equivocadas. Para facilitar a escolha, embora não seja de caráter absoluto e dependa do contexto, exemplificamos abaixo alguns contextos possíveis e que irão determinar o cenário de instalação quanto ao ambiente computacional: • Servidor com VMware ou Hyper-V • Servidores de pequeno porte, não possui VMware ou Hyper-V • Pequeno Porte com tronco E1R2 • Médio Porte com troncos E1R2 • Pequeno Porte com tronco SIP • Médio Porte com tronco SIP A Computação em Nuvem possui atratividades bastante evidentes. As principais são com relação à gestão de equipamentos de hardware e software que demandam espaço, energia
  6. 6. e gestão para serem mantidos localmente. A simples colocação destes recursos na Nuvem libera espaço físico importante, reduz o consumo de energia e permite adotar um modelo de negócio baseado em “pay-per-use”. Do ponto de vista financeiro pode ser extremamente atraente, dependendo do contexto. Também é mais fácil acomodar questões de mobilidade, usuários remotos e acessos externos, sendo mais fácil de gerenciar para este cenário de utilização. Por outro lado, a gestão dos softwares, aplicações, sistemas e serviços na Nuvem não se torna automaticamente trivial, muito menos ainda a segurança, confiabilidade e tempo de resposta. Se é verdade que a Computação em Nuvem libera a empresa de certas obrigações e preocupações, também é verdade que acrescenta outras complexidades, notadamente quanto à segurança e a latência. E, uma vez que os recursos computacionais passam a residir longe dos usuários e clientes, esta distância será então medida em tempo de propagação dos dados enviados e recebidos, ou seja, latência, um impacto que precisa ser medido. Quando se considera os endpoints, nem sempre é possível trocar todos os aparelhos telefônicos IP já existentes, “trocando-tudo-por-outros”. Tais processos de mudanças nem sempre são vantajosos e podem ser bastante custosos. Deve-se ainda avaliar se os protocolos envolvidos nas comunicações já existentes são plenamente compatíveis com os protocolos reconhecidos nos sistemas em Nuvem. Desta forma, a relação custo/benefício ainda vigorará nas tomadas de decisão. Por exemplo, aparelhos de telefonia IP baseados no protocolo H.323 provavelmente não poderão ser compatibilizados com Sistemas de Comunicação IP compatíveis com o protocolo SIP. Característica da Empresa Tipo de Tronco Nuvem Appliance de HW Local Virtualização VMware ou Hyper-V Local Pequena Empresa SIP +++ +++ + Pequena Empresa E1R2 + +++ + Média Empresa, alta mobilidade e dispersão geográfica SIP +++ + ++ Média Empresa, concentração local de usuários SIP, E1R2 ++ +++ +++ Grande Empresa, com alta mobilidade e diversas localidades SIP, E1R2 +++ + +++ Legendas: +++ (mais recomendado),++(recomendação neutra),+(menos recomendado)
  7. 7. Uma vez tendo sido tomados todos os devidos cuidados e realizada a análise criteriosa dos sistemas baseados em Nuvem, poderemos então melhor perceber os benefícios da Comunicação IP na Nuvem, sobretudo quando esta é claramente favorável aos usuários. O quadro anterior apresenta uma análise quanto aos cenários. Fatores e Considerar, o STUN e o SBC Ao colocar o seu sistema de Comunicação IP na Nuvem um importante fator deve ser considerado, a Segurança. Desta forma, será preciso empregar algum tipo de tunelamento entre o seu PBX e os usuários locais. Este aumento da complexidade pode ser resolvido utilizando um firewall específico para Voz, o Session Border Controller[6]. No caso do 3CX é preciso ativar uma máquina virtual por software para implementar o Session Border Controller. A questão que se coloca aqui é se não estaremos de certa forma “trocando um appliance por outro appliance”. Uma alternativa ao SBC é o uso do STUN[7], que possibilita contornar questões de mapeamento de portas e endereçamento IP relacionada ao protocolo SIP. O STUN permite reescrever o protocolo SIP para que o roteamento ocorra de forma correta através do NAT. Menos segura, esta técnica requer configurações adicionais no firewall. De toda forma, estas técnicas permitem implementar a mobilidade e oferecer extensões remotas aos usuários geograficamente dispersos. Contudo, deve-se sempre levar em conta que necessariamente estaremos habilitando usuários externos a penetrar em nossa rede de comunicação IP, o que pode representar alguns desafios de segurança adicionais. A correta separação da rede de voz e dados em VLANs separadas é uma diretriz natural e óbvia mas que, às vezes por desconhecimento, é frequentemente ignorada. Faz-se preciso, portanto, conhecer quais portas estarão envolvidas nos processos de comunicação internos e externos, além da própria porta SIP 5060 e as portas empregadas pelo tráfego RTP. O Custo Gerencial e de Aprendizado Quando se analisa custos tende-se primeiramente a considerar somente o custo de aquisição ou o custo da mensalidade. Costuma-se ainda realizar alguns jogos semânticos empregando a palavra investimento em lugar de custo. No entanto, a boa prática manda considerar o Custo/Benefício. E além do custo direto, seja de aquisição seja com o encargo mensal envolvido com um provedor e/ou locação de ativos e software é preciso também considerar os custos escondidos. Dentre os custos escondidos é interessante considerar também: • Custo Gerencial • Custo de Aprendizado O custo Gerencial e o de Aprendizado estão associados e referem-se justamente ao tempo dispendido na apropriação do conhecimento a fim de dominar a ferramenta gerencial efetiva e no exercício de seu pleno potencial. A fase que precede estes custos consiste
  8. 8. justamente em avaliar o tempo de aprendizado e os benefícios apresentados pela ferramenta em termos de flexibilidade e efetividade no manejo do sistema. Em geral, a dificuldade de uso pesará contra o sistema e representará um custo embutido. Este custo pode consistir em tempo adicional para pesquisar soluções, lentidão no tempo de resposta ou recorrência de suporte que poderá acrescentar custos de serviços adicionais à solução. A questão seguinte é o modelo de precificação adotado pelos sistemas de telefonia IP em geral. No caso dos aparelhos de telefonia IP estes continuam sendo comercializados no esquema tradicional, ou seja, aquisição no modelo de compra ou locação. De toda forma, trata-se de uma questão eminentemente financeira. Já com relação à precificação dos sistemas baseados em Nuvem ou Software, no modelo SAAS (Software As A Service), há dois modelos preponderantes: • Custo mensal por ramal • Custo mensal ou anual por sistema baseado em ligações simultâneas O modelo baseado em custo mensal por ramal é bastante comum e adotado por diversos Provedores de Serviços. Não envolve a aquisição definitiva do licenciamento e pode envolver um grau de comprometimento, em geral não superior a um ano. Já o modelo baseado em ligações simultâneas, como no caso do 3CX, considera a quantidade de chamadas simultâneas que um sistema pode realizar. Desta forma não há limitações quanto ao número de ramais e o sistema de cobrança acaba ficando mais acessível em cenários de uso menos intensos de telefonia, como é o caso da telefonia administrativa. Nos casos em que o uso da Comunicação IP não é tipificada como Centro de Atendimento, SAC, Atendimento Direto ao Consumidor e Call Centers em geral, a relação entre ligações simultâneas e número de usuários varia entre 3 a 4 por tronco em ligação. Eventualmente o fator 5 pode ser utilizado quando a utilização é menos intensa. A título de exemplo, podemos considerar o caso de 16 ligações simultâneas, adequado para um sistema de 80 usuários em baixo impacto de uso. Nestes casos, o valor por ramal mensal convergiria para algo como 1 dólar por usuário/mês em seu patamar mínimo. Este custo poderá variar em função do perfil de utilização podendo dobrar, ou seja, alcançando 2 dólares por usuário/mês para um uso mais intenso. No caso de Call Center este custo tenderá a 3 ou 4 dólares por usuário/mês. Em todo o caso, sistemas de Call Center requerem estudos específicos devido à carga de impacto, perfil de uso, regras e políticas, administração e gerenciamento dos sistemas de filas e gravação que não costumam ser questões importantes em sistemas de telefonia regulares, ou seja, “não-call centers”. Por outro lado, sistemas cujo modelo de cobrança é baseado em ramais SIP diretamente posicionam seu custo na faixa de 5 a 8 dólares por licença de ramal ao mês, independentemente do perfil de utilização. Existe ainda uma miríade de sistemas baseados em Nuvem de variadas funcionalidades e tipos, cuja hospedagem fica inteiramente a cargo do Provedor dos Serviços. Nestes casos o controle de todos os fatores de rede assim como a qualidade dos serviços é delegada ou inteiramente vinculada ao Provedor dos Serviços de Telefonia/Comunicação IP.
  9. 9. Conclusão Diversas arquiteturas e modelos estão hoje disponibilizados a fim de implementar a Comunicação IP total. Todas estas arquiteturas têm em comum o fato de serem eminentemente implementações de Software. Porém não é possível afirmar que exista um modelo único ou afirmar que a melhor escolha é baseado apenas em Nuvem ou Virtualização, cabendo ainda a implementação por appliance. O passo mais importante em qualquer definição deve partir sempre da avalição do cenário de uso para que se possa fazer uma avaliação dos modelos disponíveis e, somente então, definir a arquitetura de implementação, se Nuvem, Virtualizado Local ou appliance de hardware. Não é portanto possível afirmar que existe um modelo perfeito que se encaixa em todos os casos. Conheça a sua Organização primeiro e antes de qualquer outro estudo. Sobre o Autor Sergio Sampaio Spinola, Engenheiro Eletricista pela PUC-RJ e Mestre em Sistemas de Computação [5] é um pioneiro da era das primeiras redes locais, sendo cofundador da SAGA Sistemas e Computadores em 1986 e atualmente conduz a empresa IP10 tecnologia [2], voltada para o mercado de Comunicações IP. Possui as credenciais de 3CX Advanced Engineer. Referências [1] WSJ. The Software is Eating the World, disponível em https://www.wsj.com/articles/SB10001424053111903480904576512250915629460 [2] IP10 Tecnologia: https://www.ip10.com.br [3]TDM, Tutorial Teleco: https://www.teleco.com.br/tutoriais/tutorialtdm/pagina_1.asp [4] MTBF: https://whatis.techtarget.com/definition/MTBF-mean-time-between-failures [5] Gestão de Contexto Aplicada ao Encaminhamento Adptativo em Soluções Convergentes: Disponível em https://pt.slideshare.net/ip10lab/gestao-contexto-qosqoe [6] Session Border Controller: Disponível em https://www.3cx.com.br/3cxacademy/intermediario/ramais-remotos-sbc/ [7]STUN: https://www.3cx.com.br/3cxacademy/intermediario/configurando-ramais- remotos/

×