q
A funcionalidade de reescrita de número E.164 permite a implantação do plano de discagem. A partir de um determinado número chamado, uma ação de reescrita desse número é realizada com o objetivo de encaminhar a chamada corretamente, o que é feito na seção [RasSrv::RewriteE164].
Para cada regra de reescrita deve-se usar a sintaxe: [!]número-original=número-destino A implementação de um plano de numeração completo pode exigir dezenas de regras, que devem ser vistas sob dois aspectos: chamadas para dentro da zona ou chamadas para fora. A seguir exemplos com DGK hierárquico.
Chamada do terminal A para o B (ambos na área 11) 1 Direto pelo ramal: 2000
1 Com código da área: 11 2000 1 Regra (GK A): 11....=.... Chamada do terminal A para o C
1 Deve incluir código de área e escape: 0 33 1000 1 Regra (GK C): 033....=....
2 GK A encaminha ligações com prefixo 0 para o DGK. 2 DGK encaminha ligações com prefixo 033 para GK C.
A funcionalidade de reescrita de número E.164 permite a implantação do plano de dis- cagem no GnuGK. A partir de um determinado número chamado, uma ação de reescrita desse número é realizada pelo gatekeeper com o objetivo de encaminhar a chamada para o terminal (ou gatekeeper) correto. Fazendo uma comparação com o sistema telefônico, por exemplo, se alguém localizado no Rio Grande do Sul faz uma ligação para o Rio de Janeiro discando “0-xx-21-1234-1234”, este número deve ser encaminhado para o terminal de número “1234-1234”, sendo que os primeiros dígitos (“0-xx-21”) são apenas para permitir que a ligação seja encaminhada corretamente.
No GnuGK, a reescrita dos números é feita na seção [RasSrv::RewriteE164], que pode possuir diversas regras com a seguinte sintaxe:
[!]número-original=número-destino
Se a regra começa com número-original, indica que este número deve ser substituído por número-destino. Se a regra começa com o prefixo “!”, inverte-se o sentido da regra, fazendo com que os números que não têm número-original como prefixo, tenham número-destino adicionado como prefixo.
Também estão disponíveis os caracteres curinga ‘.’ e ‘%’. O caractere ‘.’ indica que deve haver um dígito qualquer na posição em que ele está, enquanto ‘%’ indica que o número daquela posição será eliminado.
Se tivermos, por exemplo, as seguintes regras de reescrita: [RasSrv::RewriteE164]
08=188 (substituição simples)
Ad m in is tr aç ão d e V id eo co nf er ênci a %%%%.=. (elimina 4 dígitos)
0044....=144.... (iniciado com 0044 com pelo menos 4 dígitos mais) Neste caso:
1 Se discado 082222, o resultado da reescrita será 1882222; 1 Se discado 092222, o resultado será 188092222;
1 Se discado 11112000, o resultado será 2000; 1 Se discado 00441234, o resultado será 1441234.
A implantação de um plano de numeração completo pode exigir dezenas de regras, e deve sempre ser vista sob dois aspectos: chamadas para dentro da zona ou chamadas para fora. Chamadas para dentro da zona são aquelas encaminhadas por outros gatekeepers com destino aos terminais da rede local de videoconferência. Chamadas para fora da zona são aquelas com destino a outras redes de videoconferência (outros gatekeepers).
Os exemplos abaixo são novamente relacionados com ligações telefônicas e mostram como podem ser necessárias diversas regras caso existam diversos países, áreas e terminais. Os exemplos são de regras em um gatekeeper no Brasil, na área 21. Ele procura reescrever todos os números para o formato <código-país><código-área><código-terminal>, exceto as chamadas para terminais locais, que são reescritas para o número do terminal local. Exemplos usando o DGK:
1 Chamada do terminal A para o B (ambos na área 11): 2 Chamada direto pelo ramal: 2000
2 Chamada com código de área: 11 2000 Regra (GK A) remove código de área: 11....=.... 1 Chamada do terminal A para o terminal C (área 33):
2 Deve sempre ser adicionado ao ramal o código de área do destino e o dígito de escape: 0 33 1000
Regra (GK C): 033....=....
GK A encaminha ligações com prefixo 0 para o DGK. O DGK encaminha ligações com prefixo 033 para o GK C.
GK A GK B GK C
DGK
Área 11 Área 22 Área 33
Cliente A 1000 Cliente B2000 Cliente C1000 Figura 3.6 Chamada entre cliente de mesma área.
Capí tu lo 3 - P lan o d e nu m er aç ão e g at ek ee pe r GK A GK B GK C DGK
Área 11 Área 22 Área 33
Cliente A
1000 Cliente B2000 Cliente C1000
Autenticação
q
A autenticação e o registro de terminais são feitos através de mensagens RRQ e suas res- postas (RCF, RRJ). No GnuGK, a autenticação é configurada na seção [Gatekeeper::Auth]. Diversos mecanismos de autenticação disponíveis:
1 Autenticação simples por alias e IP. 1 Utilização de bancos de dados SQL.
1 Autenticação em servidores RADIUS, entre outros.
A autenticação dos terminais é feita através das mensagens RRQ (Registration Request) enviadas dos terminais para o gatekeeper, e das respostas que o gatekeeper dá a essas mensagens, seja RRJ (Registration Reject) ou RCF (Registration Confirm). Para mais detalhes das mensagens H.225, reveja o Capítulo 2.
No GnuGK, a configuração da autenticação de terminais é feita inicialmente na seção [Gatekeeper::Auth] e se estende para outras seções conforme os mecanismos de autenti- cação selecionados. Esta seção tem, basicamente, a seguinte estrutura:
[Gatekeeper::Auth] <mecanismo1>=<regra>;RRQ <mecanismo2>=<regra>;RRQ ...
O exemplo acima mostra a utilização de dois mecanismos de validação, ambos aplicados sobre as mensagens RRQ. A sintaxe das linhas que especificam os mecanismos de validação é a seguinte:
<mecanismo>=<regra>;RRQ Onde:
1 <mecanismo>: indica como será feita a autenticação: senha simples, utilizando banco de dados SQL, autenticação por IP, entre outras;
1 <regra>: define se este mecanismo é obrigatório, opcional, ou outras opções; Figura 3.7
Chamada entre cliente de área diferente.
Ad m in is tr aç ão d e V id eo co nf er ênci a
1 RRQ: identifica que o mecanismo irá atuar sobre as mensagens RRQ. Pode ser substituído por outros valores, como ARQ e GRQ. No restante dos exemplos será utilizado apenas RRQ para facilitar o entendimento.
Mecanismos
Existem diversos mecanismos de validação disponíveis. Entre os mais importantes estão: 1 SimplePasswordAuth: validação por usuário e senha.
1 AliasAuth: valida uma tupla (alias, IP), onde alias pode ser o apelido ou ramal de um terminal.
1 SQLPasswordAuth: o mesmo que SimplePasswordAuth, mas utiliza um banco de dados SQL para armazenar as informações (usuários e senhas).
1 SQLAliasAuth: o mesmo que AliasAuth, mas utilizando um banco de dados com os aliases. 1 RadAliasAuth: similar a AliasAuth, mas utilizando servidores RADIUS (Remote
Authentication Dial In User Service), que é um protocolo de redes que permite o uso de serviços de autenticação, autorização e contabilização centralizados em um servidor.
Um servidor RADIUS pode fazer a ponte entre o GnuGK e uma base LDAP.
1 RadAuth: validação de usuário e senha com base no H.235 e utilizando servidores RADIUS. No restante deste capítulo serão vistos, principalmente, os mecanismos SimplePasswor- dAuth e AliasAuth.
O addpasswd é um utilitário instalado com o GnuGK que permite a criação de senhas crip- tografadas para serem armazenadas no arquivo de configuração. Duas seções do arquivo de configurações onde senhas costumam ser utilizadas são as seções GkStatus::Auth, para autenticação na conexão com a porta de status, e SimplePasswordAuth, para autenticação de terminais.
A sintaxe do aplicativo é simples, basta escolher o arquivo de configuração e a seção deste arquivo, onde a senha será gravada e entrar com o nome de usuário e sua senha. A sintaxe e um exemplo seguem abaixo:
$ addpasswd [arquivo_de_config] [seção] [usuário] [senha] $ addpasswd /etc/gatekeeper.ini GkStatus::Auth admin senha123
Em relação às regras, são elas que especificam como (e quanto) o mecanismo deve ser utili- zado. Antes de mostrar as regras disponíveis, é interessante observar que a execução de um mecanismo pode ter como resultado um dos 3 valores a seguir:
1 ok: a requisição foi autenticada por este mecanismo;
1 fail: a autenticação com este mecanismo falhou e deve ser rejeitada (uma senha incor- reta, por exemplo);
1 next: o mecanismo não pode realizar a autenticação (validação de um nome de usuário não existente na base de dados, por exemplo). Vá para o próximo mecanismo.
Regras
Sabendo dos possíveis resultados, podemos verificar as regras disponíveis:
Capí tu lo 3 - P lan o d e nu m er aç ão e g at ek ee pe r
1 required: a requisição deve ser autenticada utilizando o mecanismo especificado, caso contrário será rejeitada. Ainda assim, o próximo mecanismo configurado será checado para validar o registro;
1 sufficient: o mesmo processo da regra required, com a diferença de que nenhum mecanismo depois desse terá validade. Ou seja, a resposta dada a este mecanismo é a resposta final à autenticação;
1 alternative: o mesmo que sufficient, porém, se o mecanismo não puder decidir se aceita ou nega o registro (se a resposta for next), ele passa a requisição para o próximo mecanismo. Vejamos alguns exemplos do uso de mecanismos e regras de autenticação:
1 Exemplo 1:
[Gatekeeper::Auth] AliasAuth=optional;RRQ
SimplePasswordAuth=sufficient;RRQ default=allow
Neste exemplo, primeiro é feita uma tentativa de autenticação por alias, que é opcional. Por- tanto, se a resposta à autenticação for ok ou next, o processo segue para o próximo meca- nismo. Mas se a resposta for fail, a requisição de registro é negada. O próximo mecanismo especificado é o SimplePasswordAuth, onde é feita a autenticação por usuário e senha. Este mecanismo é sufficient e, portanto, decisivo: sua resposta será a resposta final à requisição. Vale observar que os detalhes de cada um desses mecanismos são configurados em seções específicas para cada mecanismo, por isso não são apresentados no exemplo.
Além dos mecanismos, o exemplo mostra a linha default=allow, que define como devem ser tratadas as requisições para as quais não foi especificado nenhum mecanismo. Por padrão estamos aceitando (allow) todas as requisições diferentes de RRQ, que são tratadas pelos mecanismos especificados. 1 Exemplo 2: [Gatekeeper::Auth] SimplePasswordAuth=alternative;RRQ RadAuth=sufficient;RRQ default=allow
q
Autenticação por alias (ID H.323 ou ramal):
1 AliasAuth utiliza a seção [RasSrv::RRQAuth], que possui a sintaxe: <identificador>=sigip:<endereço IP>:<porta>
Exemplo:
[RasSrv::RRQAuth]
55551234=sigip:200.188.10.1:1720
55556789=sigip:156.130.25.9:1720
Autenticação por usuário e senha:1 Os mecanismos SimplePasswordAuth, SQLPasswordAuth e RadAuth validam o registro dos terminais analisando usuário e senha de acesso.
Ad m in is tr aç ão d e V id eo co nf er ênci a
q
1 O uso de senha requer que o terminal tenha suporte à especificação H.235. Autenticação por usuário e senha:
1 Assim como na validação por alias, cada mecanismo tem sua seção no arquivo de configurações:
2 SimplePasswordAuth: utiliza a seção [SimplePasswordAuth] onde estão os dados de validação.
SQLPaswordAuth: utiliza a seção [SQLPasswordAuth] para configurar um banco de dados SQL onde estão contidas as informações de usuário e senha.
RadAuth: utiliza a seção [RadAuth] e busca os dados de um servidor RADIUS.
Neste segundo exemplo, a primeira autenticação é feita por usuário e senha. Como está configurada como alternative, se o resultado for ok ou fail, esta será a resposta final para a requisição. Mas, caso o resultado seja next, será utilizado o segundo mecanismo, RadAuth, que dará a resposta final. A seguir serão discutidos dois mecanismos de autenticação: a autenticação por alias (especialmente o AliasAuth) e a autenticação por usuário e senha (especialmente o SimplePasswordAuth).
Na autenticação por alias, ou seja, por apelido (identificador H.323) ou ramal, podem ser utilizados os mecanismos AliasAuth, SQLAliasAuth e RadAliasAuth. Eles validam as requi- sições analisando a associação de alias e endereço IP. Todos eles funcionam de maneira semelhante, mas são configurados em seções diferentes do arquivo de configurações e armazenam os dados de autenticação em locais diferentes:
1 AliasAuth: utiliza a seção [RasSrv::RRQAuth], que é onde estão armazenados os dados de autenticação;
1 SQLAliasAuth: utiliza a seção [SQLAliasAuth] e busca os dados para autenticação em um banco de dados SQL;
1 RadAliasAuth: utiliza a seção [RadAliasAuth] e busca os dados de um servidor RADIUS. Como citado, o mecanismo AliasAuth utiliza a seção [RasSrv::RRQAuth]. Esta seção possui comandos com a seguinte sintaxe:
<identificador>=sigip:<endereço IP>:<porta> Onde:
1 <identificador>: alias que será mapeado para o IP especificado.
1 <sigip>: uma das duas opções disponíveis. A outra opção é sigaddr, que informa que o IP e porta estão especificados no formato de uma expressão regular; sigip é uma especiali- zação do sigaddr, para utilização do IP e porta no formato padrão “A.B.C.D:porta”. 1 <endereço IP>: endereço IP para o qual o alias será mapeado.
1 <porta>: porta para comunicação com o terminal de IP <endereço IP>. Exemplo:
[RasSrv::RRQAuth]
55551234=sigip:200.188.10.1:1720 55556789=sigip:156.130.25.9:1720
Capí tu lo 3 - P lan o d e nu m er aç ão e g at ek ee pe r
No exemplo, o terminal com ramal 55551234 é mapeado para o IP 200.188.10.1.1 (porta 1720), enquanto o terminal com ramal 55556789 corresponde ao IP 156.130.25.9 (porta 1720 também). SimplePasswordAuth:
q
1 Utiliza a seção [SimplePasswordAuth] que possui a sintaxe: <usuário>=<senha>
1 Senhas de acesso são criadas pelo utilitário addpasswd.
Na autenticação por usuário e senha, é possível utilizar os mecanismos SimplePasswordAuth, SQLPasswordAuth e RadAuth. Assim como na validação por alias, cada mecanismo tem sua seção no arquivo de configurações:
1 SimplePasswordAuth: utiliza a seção [SimplePasswordAuth], que já contém os dados de validação;
1 SQLPaswordAuth: utiliza a seção [SQLPasswordAuth] para configurar um banco de dados SQL onde estão contidas as informações de usuário e senha;
1 RadAuth: utiliza a seção [RadAuth] e busca os dados de um servidor RADIUS.
Como citado, o mecanismo SimplePasswordAuth utiliza a seção [SimplePasswordAuth]. Esta seção possui os nomes de usuários e suas respectivas senhas, como no exemplo a seguir:
[SimplePasswordAuth] fulano=J4rfje7jdk= sicrano=ee533dgf4g= beltrano=YY64GGrfje7jdk=
A sintaxe de cada linha é <usuário>=<senha>, sendo que estas senhas estão criptografadas, criadas pelo utilitário addpasswd. O uso desta ferramenta já foi explicado e segue um exemplo: Sintaxe:
addpasswd <arquivo_config> <seção> <usuário> <senha> Exemplo:
addpasswd /etc/gnugk.ini SimplePasswordAuth fulano senha
Todas as opções de autenticação disponíveis, assim como detalhes das configurações do servidor RADIUS e do banco de dados SQL, podem ser obtidos no manual do GnuGK.
Contabilização
q
Geração de registros das chamadas, imprescindível para avaliar a utilização do sistema. O GnuGK gera um registro com informações detalhadas sobre cada uma das chamadas efetuadas através dele: tempo de chamada, origem, destino etc. Esse registro é denomi- nado Call Detail Record (CDR).
Mecanismos de armazenar o CDR: 1 File Acct
1 Rad Acct 1 SQL Acct
Ad m in is tr aç ão d e V id eo co nf er ênci a
A contabilização no gatekeeper, ou seja, a geração de registros das chamadas, é imprescin- dível para avaliar a utilização do sistema. O GnuGK gera um registro, denominado
Call Detail Record (CDR), que armazena informações detalhadas sobre cada uma das cha-
madas efetuadas através do gatekeeper: tempo de chamada, origem, destino etc. Existem diversas maneiras de coletar e armazenar esses registros, como bancos de dados, arquivos texto, servidores externos, entre outros. A configuração da contabilização no GnuGK é feita através da seção [Gatekeeper::Acct]. As configurações dessa seção seguem a seguinte sintaxe:
<mecanimo>=<regra>;evento1,evento2,...,eventoN
Os mecanismos e regras da seção de contabilização funcionam nos mesmos moldes do processo de autenticação. Nessa seção podem ser definidos vários mecanismos e também os eventos que serão contabilizados por cada mecanismo. Entre os mecanismos disponíveis, os mais importantes são:
1 FileAcct: armazena os CDRs em arquivo texto;
1 RadAcct: envia os CDRs para um servidor RADIUS, que pode fazer o armazenamento dos dados como desejar;
1 SQLAcct: grava os registros diretamente em banco de dados SQL.
Assim como na seção de autenticação, os mecanismos podem dar uma das três respostas: ok,
fail ou next. As regras também são as mesmas, mas funcionam de maneira um pouco diferente:
1 required: se o mecanismo falhou ao registrar o evento, define o resultado final do processo de contabilização como fail. Após este mecanismo o evento é passado para o próximo mecanismo configurado;
1 optional: independente de sucesso ou falha, o próximo mecanismo configurado sempre será considerado. Seu resultado não altera o resultado final do processo de contabilização; 1 sufficient: similar ao required, mas em caso de sucesso o processo de contabilização
é finalizado;
1 alternative: similar ao sufficient, pois para a execução em caso de sucesso. Mas, em caso de falha, não define o resultado final (ao contrário do que é feito em sufficient e em required). Como comentado, cada mecanismo pode registrar um ou mais eventos. Os eventos passíveis de registro são:
1 start: registro gerado no início de uma chamada (mensagem Setup); 1 stop: registro gerado no fim de uma chamada;
1 connect: uma chamada foi conectada;
1 update: a chamada está ativa e é feita uma atualização periódica para refletir a nova duração da chamada;
1 on: registro gerado no momento em que o gatekeeper é ligado; 1 off: registro gerado no momento em que o gatekeeper é desligado. Seguem exemplos de configurações de contabilização:
Exemplo 1:
[Gatekeeper::Acct]
RadAcct=optional;start,stop
Capí tu lo 3 - P lan o d e nu m er aç ão e g at ek ee pe r
Neste exemplo, primeiro é feita uma tentativa de registro dos eventos start e stop utilizando um servidor RADIUS. Seja qual for o resultado deste mecanismo, o mecanismo FileAcct será executado, onde serão armazenados os eventos start, stop, on e off. O resultado deste segundo mecanismo será o resultado final do processo de contabilização.
Exemplo 2:
[Gatekeeper::Acct]
RadAcct=alternative;start,stop SQLAcct=sufficient;stop
Neste segundo exemplo, é feita uma tentativa de registro em um servidor RADIUS e, em caso de falha, é feito o registro em um banco de dados. Novamente, para mais detalhes sobre a contabilização no GnuGK é aconselhável consultar o seu manual.