Não sei com o que comparar o provisioning. Talvez com um gato? Parece que dá para viver sem ele, mas com ele é um pouco melhor. Especialmente se ele estiver trabalhando ))
Definição do problema:
- Quero configurar telefones SIP de forma rápida, simples e segura. Ao instalar o telefone, e ainda mais ao reconfigurá-lo.
- Muitos fornecedores têm seus próprios formatos de configuração, suas próprias ferramentas para gerar configurações, suas formas de proteger configurações. E não quero ter que lidar com cada um.
- Muitas soluções de provisioning, a) são orientadas para um fornecedor ou um sistema telefônico específico, b) são bastante complexas de implementar, com muitos scripts, parâmetros, blá-blá...
Sobre o ponto 3, gostaria de comentar que existem excelentes sistemas de provisioning , , , onde templates para telefones de diferentes fornecedores estão disponíveis publicamente. Há soluções comerciais que também permitem configurar no módulo de provisioning o funcionamento de telefones de diversos fabricantes, por exemplo, o PABX Yeastar.
No Habr também há muitos tutoriais sobre como configurar dispositivos de vários fornecedores: , . Mas como dizem, todos os sistemas têm um grave defeito. Então, vamos fazer nossa própria solução.
nosso formato
Como diz o xkcd, se você não quer lidar com 14 formatos — . Por isso, usamos configurações gerais para qualquer telefone e criaremos nosso formato de configuração json.
Mais ou menos assim:
{
"key": "sdgjdeu9443908",
"token": "590sfdsf8u984",
"model": "gxp1620",
"vendor": "grandstream",
"mac": "001565113af8",
"timezone_offset": "GMT+03",
"ntp_server": "pool.ntp.org",
"status": true,
"accounts": [
{
"name": "Mobilon",
"line": 1,
"sip_register": "sip.mobilonsip.ru",
"sip_name": "sip102",
"sip_user": "sip102",
"sip_password": "4321",
"sip_auth": "sip102"
}
]
}Assim, em qualquer telefone, é necessário configurar o horário local e as linhas SIP. Aqui é tudo simples. Exemplos adicionais podem ser vistos .
no seu servidor de provisioning
Nos manuais do fabricante, geralmente há um item que diz: pegue o csv, registre login-senha-endereço MAC, use nosso script para gerar os arquivos, coloque-os sob um servidor web Apache e tudo ficará bem.
No próximo item do manual, geralmente é mencionado que o arquivo de configuração gerado também pode ser criptografado.
Mas tudo isso é clássico. A abordagem moderna, inspirada por smoothies e Twitter, sugere que devemos criar um servidor web que não seja tão poderoso quanto o Apache, mas que realize uma única tarefa pequena: gerar e fornecer configurações por meio de um link.
Vamos parar aqui e recordar que praticamente todos os telefones SIP agora podem obter configurações via http/https, por isso não consideramos outras implementações (ftp, tftp, ftps). Além disso, cada telefone conhece seu endereço MAC. Portanto, faremos duas referências: uma pessoal — pelo identificador do dispositivo, e a segunda geral, que funciona com um token geral e o endereço MAC.
Também não vou me aprofundar na zero-config, ou seja, na configuração do telefone "do zero", ou seja, você o conecta à rede e ele, voilà, funciona. Não, no meu cenário, você conecta à rede, faz uma configuração prévia (configura para receber a configuração do servidor de provisionamento), e então você toma um piña colada e reconfigura o telefone como deve ser através do provisionamento. Disponibilizar a Opção 66 é tarefa do servidor DHCP.
Aliás, estou cansado de dizer "provisioning", portanto a palavra foi abreviada para "provision", por favor, não me critiquem.
E mais: nosso servidor de provisionamento não tem UI, ou seja, interface do usuário. Talvez, por enquanto, mas não tenho certeza, porque não é necessário para mim. No entanto, existe uma API para salvar/excluir configurações, obter uma lista de fornecedores suportados, modelos, tudo descrito segundo os padrões da especificação swagger.
Por que API e não UI? Porque eu já tenho meu próprio sistema telefônico, então tenho uma fonte de credenciais, onde posso simplesmente pegar esses dados, compor o json necessário e publicar no servidor de provisionamento. E então, o servidor de provisionamento, segundo as regras especificadas no arquivo json, fornecerá ao dispositivo solicitado sua configuração ou não fornecerá, se o dispositivo não for o correto, ou não corresponder aos critérios também especificados nesse json.
E assim, esse microserviço de provisionamento foi criado. Chama-se , o código-fonte está disponível no GitHub, também há , exemplo de uso do docker .
Características principais:
em qualquer caso, acesso limitado à configuração por tempo, por padrão 10 minutos. Se você quiser tornar a configuração acessível novamente — republicar a configuração.
um formato para todos os fornecedores, toda a configuração foi retirada para o sonata, você envia um json padronizado, configura qualquer equipamento disponível.
todas as configurações fornecidas aos dispositivos são registradas, todos os pontos problemáticos podem ser vistos no log e os erros podem ser visualizados.
é possível usar um único link com um token, cada telefone recebe sua própria configuração, especificando o endereço MAC. Ou um link pessoal pelo key.
API para gerenciamento e emissão de configurações para os telefones estão separados por portas.
Testes. Para mim, era muito importante registrar o formato da configuração emitida e cobrir todas as situações normais de emissão de configuração com testes. Para que tudo funcionasse de forma clara.
Pontos negativos:
Até agora, a criptografia não está sendo utilizada no âmbito do sonata. Ou seja, você pode começar a usar HTTPS, colocando, por exemplo, o nginx, na frente do sonata. Mas os métodos próprios ainda não foram implementados. Por quê? O projeto ainda é novo, acabou de provisionar, dificilmente, sua primeira centena de dispositivos. E claro, estou coletando ideias e feedbacks. Além disso, para garantir que tudo seja seguro, para que as configurações não possam ser interceptadas na rede, provavelmente vale a pena se dedicar a chaves de criptografia, TLS e similares, mas isso será para mais tarde.
Falta de UI. Isso pode ser uma desvantagem significativa para o usuário final, mas para o administrador de sistema uma utilidade de console é mais importante do que um aplicativo completo. Fazer uma utilidade de console estava nos planos, mas não tenho certeza se é necessária?
Qual é o resultado?
Um pequeno e simples servidor web para provisionar vários modelos de telefones com API para gerenciamento.
Mais uma vez, como isso deve funcionar?
- Instalamos o sonata.
- Formamos a configuração json e a publicamos no sonata.
- Depois, recebemos do sonata um link para o provisionamento.
- Então, colocamos esse link no aparelho telefônico.
- O aparelho baixa a configuração.
Na exploração posterior, apenas dois passos:
- Formamos a configuração json e a publicamos no sonata.
- O aparelho baixa a configuração.
Quais telefones estão sendo provisionados?
Fornecedores Grandstream, Fanvil, Yealink. As configurações dentro do fornecedor são mais ou menos as mesmas, mas podem variar dependendo do firmware — pode ser necessário realizar testes adicionais.
Quais regras podem ser definidas?
Por tempo. Você pode especificar um horário até o qual a configuração estará disponível.
Por endereço MAC. Ao emitir a configuração por um link pessoal, o endereço MAC também será verificado.
Por IP. Pelo endereço IP de onde a solicitação foi feita.
Como interagir com o sonata?
Através da API, fazendo requisições HTTP. A API estará disponível na sua instalação. Como a API suporta a especificação swagger, você pode usar para testes de requisições à API.
Ok, ótimo. É uma coisa legal, como experimentar?
É mais fácil implantar uma imagem Docker com base no repositório . O repositório contém instruções para instalação.
А если знаю node.js?
Se você tem experiência com JavaScript, logo entenderá como tudo funciona aqui.
Haverá desenvolvimento do sonata?
Parcialmente, alcancei meus objetivos. O desenvolvimento futuro é uma questão das minhas tarefas relacionadas à automação da configuração dos telefones. Há também a possibilidade de expandir as configurações para personalizar os botões do telefone, adicionar endereços de provisionamento, e talvez mais alguma coisa, escreva nos comentários.
Resumo e agradecimentos
Ficarei feliz com sugestões, objeções, comentários e perguntas construtivas, pois pode haver algo que não tenha sido bem explicado.
Também agradeço a todos os colegas que ajudaram, consultaram, testaram, forneceram ou doaram telefones para os testes. Realmente, muitas pessoas que com quem conversei por trabalho, em chats e emails, estão envolvidas de diferentes maneiras no projeto. Obrigado pelas ideias e pensamentos.
Fonte: habr.com
