Foi eu que mandei. O authenticate vai resolver o problema, mas vai autenticar sempre, se você colocá-lo antes das rotas de saída. O que eu propus permite que você controle por ramal. Até daria pra misturar os dois (eu usei DISA, poderia ter usado o authenticate diferenciando o ramal por contexto).
E tem outra difereça muito importante: usando o authenticate, você apenas decide se passa ou não passa a ligação, baseado numa senha. Se passar, as credenciais serão as do ramal que está discando. Com o DISA, você troca totalmente o ramal e contexto para os selecionados no arquivo de senhas, de forma que as credenciais usadas na ligação passam a ser de quem usou a senha. Meu cliente queria exatamente isso: ter 100 ramais, e 2000 senhas, onde cada um que tinha uma senha poderia pegar um ramal livre e discar, usando a própria senha, o sistema bilhetaria no nome dele (e no ramal virtual dele, que não tem ninguém logado normalmente mas tem um número válido para efeito de bilhetagem). Pense no que é melhor pra você. Segue abaixo o texto, novamente: ==========================8<-------------------------------------------- Eu implementei um sistema de cadeado pra um cliente há algumas semanas. Não ficou "uma brastemp" mas foi o que veio à cabeça na hora. Certamente ainda vou tentar desenvolver um melhor para colocar no lugar depois. Nesse caso específico, nós estávamos usando uma instalação baseada em AMP/AAH, e o que fiz foi o seguinte: 1) Criei um contexto novo, chamado cadeado, e coloquei nele uma extensão que chama o DISA. A extensão pode chamar por exemplo *00. 2) Dupliquei o contexto "from-internal" com o nome "from-internal-semcadeado". 3) Retirei o contexto all-outbound e incluí o contexto "cadeado" no contexto "from-internal". Opcionalmente você pode também incluir o contexto "cadeado" no "from-internal-semcadeado". Agora você tem um contexto default que não disca pra fora, mas pode discar *00 pra cair no disa. E os ramais que você quer livrar do cadeado, basta trocar o contexto default deles para o -semcadeado que eles voltam ao normal. Fiz assim porque a quantidade de ramais que não teriam cadeado era pequena. Se for o contrário, inverta os nomes, vai dar menos trabalho. O DISA vai ler uma base de dados de senha, onde cada usuário vai ter que digitar sua senha para poder ganhar um tom de linha e daí fazer a ligação. O contexto onde o DISA disca é o all-outbound-routes. Agora, se alguém que está num ramal cujo contexto não tem o all-outbound-routes, se ele tentar ligar pra fora, vai falhar. Ele vai precisar discar *00, daí virá um novo tom de linha pra discar a senha... Depois de discar a senha (se ela for válida), virá um novo tom de linha onde ele disca pra fora. Se for discar pra ramais internos, basta discar direto, pois está no contexto default dele. Não creio que o DISA seja um problema de segurança nesse caso, pois você vai estar rodando o disa no contexto all-outbound-routes, que ele já teria acesso de qualquer forma, você só colocou uma senha no caminho. (É normal ver o DISA como furo de segurança quando não for bem usado). Desculpe não poder dar mais detalhes, creio que meu empregador não permitiria que eu colasse aqui o que foi feito lá exatamente. Mas você entendeu a idéia :-) Observações: 1) O DISA não pergunta usuário, apenas a senha. É como se o número-senha fosse um login e senha ao mesmo tempo. Isso pode ser ruim, pois na hora de mudar a senha de alguém você precisa verificar se não repetiu outra senha. 2) É possível que alguém disque senhas sequenciais até achar alguma válida, já que não tem login. Use senhas de muitos dígitos e bem espaçadas entre si, e veja nos logs se pega alguém tentando fazer isso. 3) A maneira com que o DISA opera faz com que ele mude o caller ID de saída da ligação para aquele associado ao ramal de quem está discando, mesmo que essa pessoa tenha ido usar o ramal de outro usuário. Isso faz com que nos CDRs apareça quem ligou e nunca de onde ele ligou (não dá pra ter idéia se foi do telefone dele mesmo ou não). Isso não é tão ruim, mas é importante saber. 4) Não use essa solução como definitiva, tente bolar alguma coisa melhor. Como eu disse, foi só um quebra-galho até implementar alguma coisa melhor. E, quando você bolar alguma melhor, manda ela pra mim, heheheh :-) Abraços, andre On 9/29/06, Leonardo Kamache (Gmail) <lkamache em gmail.com> wrote: > Dê uma olhada na aplicação authenticate. Deve ser isso que está querendo. > > > Abraços; > > LK > > > > > On 9/28/06, bruno em connectech.com.br <bruno em connectech.com.br> wrote: > > Senhores, > > > > A algum tempo atras foi enviado uma mensagem para a lista com a funcao > cadeado no extensions.conf e > > outra funcao que nao me lembro. Se alguem ou o autor enviar novamente > aquela mensagem seria muito > > interessante. Estive olhando o historico e nao consegui encontrar. > > > > Grato, > > > > Bruno > > > > Bruno Mayworm - Consultor de T.I. > > Connectech Networks > > (24)92268387 > > ---------------------------------------- > > Estação VoIP 2006 > > 5 e 6 Dezembro > > Curitiba PR > > http://www.estacaovoip.com.br > > > > _______________________________________________ > > LIsta de discussões AsteriskBrasil.org > > AsteriskBrasil em listas.asteriskbrasil.org > > > http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil > > > > _______________________________________________ > > Acesse o wiki AsteriskBrasil.org: > > http://www.asteriskbrasil.org > > > > > ---------------------------------------- > Estação VoIP 2006 > 5 e 6 Dezembro > Curitiba PR > http://www.estacaovoip.com.br > > _______________________________________________ > LIsta de discussões AsteriskBrasil.org > AsteriskBrasil em listas.asteriskbrasil.org > http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil > > _______________________________________________ > Acesse o wiki AsteriskBrasil.org: > http://www.asteriskbrasil.org > > -- Andre Ruiz <andre.ruiz em gmail.com> Curitiba, PR, Brasil
