O documento analisa as opções de sistemas de comunicação IP disponíveis, incluindo PBXs IP tradicionais e implementações com múltiplos serviços de voz, vídeo e conferência. Dois sistemas favoritos são destacados: o Avaya IP Office, que pode ser implementado em hardware ou software, e o 3CX, um sistema de software puro que evoluiu para suportar Linux. A escolha ideal depende da análise do cenário específico de cada organização.

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. 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. 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. 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. 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. 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. 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. 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. 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/