Telefones SIP. Computadores com um receptor. Em teoria, muito pode ser feito com eles, mas eles são usados apenas para chamadas :-)
Recentemente, o AsterConf esteve na conferência, e lá os fornecedores conversaram sobre seus telefones, não destacaremos ninguém, eles são todos bons, em algum lugar melhor, em algum lugar mais barato, na verdade, eles fazem a mesma coisa.
Alguns fornecedores melhoram a qualidade do som, alguém prende um tablet com um andróide, alguém tenta adicionar algum tipo de aplicativo. E tudo para instalarmos esses telefones em desktops.
E talvez os telefones sejam bons candidatos para o papel do controle remoto no mundo da IoT: cliquei no botão e obtive o resultado. E, na minha humilde opinião, não há uma maneira simples e suficiente de conectar telefones ao seu "Gerente". Como parte deste artigo, quero mostrar como pode parecer simples em um diagrama e demonstração em vídeo.
E você compartilha nos comentários, por favor, que talvez algo semelhante já tenha sido implementado em algum lugar ou que complemente suas sugestões e pensamentos.
Os telefones têm URL de ação e URIs de ação.
O URL de ação nos permite enviar eventos diferentes para qualquer URL. No URL, podemos especificar variáveis predefinidas que serão preenchidas com dados reais durante uma chamada.
Assim, por exemplo, a configuração do meu telefone é semelhante.
Designer de URL de ação on-line para YealinkO URI de ação nos permite receber comandos no endereço IP do telefone, e o telefone pode fazer chamadas, atender chamadas sob comando, adicionar volume, reiniciar etc. no vídeo abaixo, você pode ver como tudo isso acontece. Devemos indicar o endereço de onde as equipes virão.
Tudo é configurável, qual é o problema, mano?
Essas são interfaces bastante funcionais, mas ... são bastante difíceis de integrar. I.e. precisamos executar 100.500 ações para fazê-lo funcionar. Ou preencha 100 campos nas configurações do dispositivo (você mesmo vê na tela) ou confunda-se com as provisões e prescreva alguns modelos de configuração.
Como resultado, existem muitas ações nas quais é fácil cometer um erro e não conseguir o que você deseja e, em seguida, dedica muito tempo para descobrir os motivos do comportamento inadequado do dispositivo. E bem, se você lida com um e possui cinco a dez, cem e dois fornecedores e até modelos de gerações diferentes. Puff Puff Puff ...
Isso é um problema? Alguém precisa gerenciar o telefone de um assinante? Para o assinante? Do seu desktop, laptop ou smartphone? Suporte técnico? Interno e externo, por exemplo, um provedor virtual de central telefônica? Preciso ter acesso ao telefone de maneira diferente do que o SIP? Integrar o telefone com aplicativos, ignorando o IP-PBX?
Não sei responder inequivocamente, há vantagens e desvantagens. E para perceber as vantagens, eu gostaria de poder conectar rapidamente o URL da ação e o URI da ação ao meu "Gerente". Eu chamo um gerente de servidor, a partir do qual posso ver centralmente uma lista de telefones, seu status e qualquer um deles executar alguma ação disponível.
Vamos ver o diagrama.
Imagine que temos um cliente websockets em nosso telefone.
Então, precisamos especificar no telefone apenas o endereço de rede do "Gerente" e nosso telefone se conectará a ele. Quando conectado, o telefone enviará seu ID, nome, mac. Isso nos permitirá compará-lo com a nossa lista de assinantes de PBX, por exemplo.
Em seguida, assinamos os eventos que ocorrem no telefone. Existem muitos deles, são re-registros, respostas a chamadas, pressionamentos de botão etc. Em seguida, podemos discar o número do nosso gerente enviando um comando. Defina o DND ou remova o DND. Em seguida, envio uma notificação ou lembrete para o telefone, defina um novo logotipo.
E a segurança? Em geral, os telefones SIP podem funcionar para NAT, eles não precisam de um endereço externo. Mas se você definir a porta do servidor da web do telefone como a rede Action URI (onde a área de administração, aliás, funciona) - espere surpresas desagradáveis.
Mas se o telefone se conectar ao "Manager" via websockets, essa é sua iniciativa e seu direito, ele poderá se desconectar e, se você se conectar ao servidor remoto devido ao NAT, parecerá uma conexão do navegador.
Chega de palavras, mais perto do ponto. Eu escrevi um pequeno cliente de telefone (que na minha opinião deveria estar no telefone), que se conecta ao servidor via soquete da web. Além disso, um navegador está conectado a este servidor, que pode receber mensagens do telefone e enviar comandos para lá.
O cliente é apenas um invólucro para o URL da ação e o URI da ação, que funciona com o telefone por meio de suas interfaces familiares e agrupa todos os dados em um soquete da web. Nos soquetes da Web, temos mensagens JSON regulares com as quais qualquer desenvolvedor da Web pode trabalhar.
Assista ao vídeo, tudo é bem simples. Todo o código é mínimo o suficiente apenas para mostrar o conceito.
O que está acontecendo no vídeo?
- iniciamos o servidor que aceita conexões nos websockets,
- iniciamos o cliente (que funciona por URL de ação e URI com o telefone)
- cliente se conecta ao servidor
- iniciamos o servidor da web (com a página em que o código para conexão do navegador via websockets)
- abrir a página no navegador, a página se conecta ao servidor
- estamos enviando uma solicitação de informações da página
- a solicitação vai até o telefone e retorna informações sobre as linhas telefônicas
- também podemos enviar equipes diferentes
- incluindo o comando para fazer uma chamada
- e depois o comando desligar
- todos os dados são visíveis no log da página, bem como no console do servidor ativo e do telefone do cliente
- então você pode ver como ele reage aos comandos na página de telefone
Assim, conectar o telefone ao gerente é apenas um endereço. E as mensagens dos soquetes da web para uma apresentação diferente e vice-versa podem ser qualquer desenvolvedor. No meu caso, uma página está conectada ao gerente. Em geral, pode ser um sistema mais complexo que processa comandos e envia mensagens para o telefone.
Ter um método de conexão simples pode ser conveniente e, portanto, mais fácil de aprender. Por essa interface, em teoria, é possível enviar novas configurações e mensagens adicionais, facilitando a integração do telefone em qualquer infraestrutura.
Em geral, esses são apenas meus pensamentos sobre os resultados da exibição de novos produtos na Asterkonf. Ficarei feliz em ver nos comentários os prós e contras. E talvez um dos fabricantes veja o racional nisso e introduza o chip :-)
Projeto Github