O que é um Cartão Ethernet com TOE?

Fonte original: http://www.wave.no/products.html?id=189



Ethernet 1 Gbps com TOE

O que é um Cartão com TOE?

Com uma NIC (cartão de interface de rede) padrão, todo processamento TCP/IP é feito sobre a CPU, com a exceção do checksum e da remontagem de pacote. Uma NIC padrão é a solução frequentemente barata em termos de preço, mas muito cara em termos de utilização de ciclos de CPU. A pilha TCP/IP coloca uma carga excessiva sobre as CPUs dos hosts. Em velocidades 10/100, muitas CPUs conseguem dar conta da carga de processamento do TCP. Uma regra básica geral é que uma CPU com 1 Hz é requerida para processar a sobrecarga TCP associada com a transferência de dados de 1 bit/seg. Com o advento do padrão Ethernet Gigabit, as CPUs dos servidores podem ficar no talo, como se diz na gíria, enquanto processa a carga da pilha TCP/IP associado com a transferência de dados. Isso é especialmente verdadeiro para inicializadores iSCSI, ou seja, computadores que acessam seus storages via o protoloco iSCSI.

Uma solução para inicializadores iSCSI é usar adaptadores iSCSI storage em vez de uma NIC padrão. Esses cartões contém um mecanismo para retirada completa de carga da CPU do protocolo iSCSI em hardware e que são análogos aos adaptadores de barramento de host SCSI usado por um SCSI anexado diretamente; contudo, tais cartões podem normalmente ser usados somente como adaptadores iSCSI storage e não como adaptadores de rede para propósito geral.

Uma outra solução é usar um mecanismo que possa retirar a carga da pilha TCP/IP da CPU host - TCP/IP Offload Engine (TOE). Esse é o hardware que uma NIC usa para retirar o processamento TCP/IP da CPU host, liberando ciclos valiosos de CPU para o processamento das aplicações. Com uma placa com TOE, os requerimentos de processamento para as quatro camadas, incluindo TCP, são movidos da CPU do host para o hardware do cartão de rede. O resultado são servidores mais rápidos, uma rede acelerada, e desempenho superior das aplicações.

NIC aceleradas com TOE pode ser usada por aplicações LAN de propósito geral bem como pelo iSCSI (mesmo que seja simultaneamente). Se for usado por aplicações iSCSI, um software de driver iSCSI é necessário.

Leia aquiLeitura complementar obrigatória dessa dica.

Ajuda para Configuração de VLAN no Arquivo interfaces

Além de script de inicialização e do comando vconfig, no Debian a configuração de VLAN pode ser feita a partir do arquivo /etc/network/interfaces que possui uma formatação própria para isso.

Abaixo está uma versão em português da página manual para a configuração de VLAN a partir do arquivo citado, conforme aparece quando se executa o comando seguinte:

#man vlan-interfaces

VLAN-INTERFACES (5)Formatos de ArquivoVLAN-INTERFACES (5)

NOME

/etc/network/interfaces (vlan) - extensões do formato do arquivo interfaces (5) para VLAN.

DESCRIÇÃO

/etc/network/interfaces contém a informação de configuração da interface de rede para os comandos ifup (8) e ifdown (8). Essa página manual descreve as extensões VLAN para o formato padrão do arquivo interfaces (5).

Extensões primárias existem para criar e destruir interfaces VLAN, extensões secundárias existem para manipulação de interface ipv4 que sejam geralmente necessárias quando usando (muitas) VLANs.

CRIAÇÃO DE VLAN

Definições de interface VLAN existem para nome de interface VLAN, e uma opção para ter nomes de interface de 4 números preenchidos com zero, ou apenas os dígitos planos sem ser antecedidos por zeros. O exemplo seguinte mostra quatro formas de criar uma VLAN com ID 1 na interface eth0. Todas elas resultam em nomes diferentes.

iface eth0.1 inet static

address 192.168.1.1

netmask 255.255.255.0

iface vlan1 inet static

vlan-raw-device eth0

address 192.168.1.1

netmask 255.255.255.0

iface eth0.0001 inet static

address 192.168.1.1

netmask 255.255.255.0

iface vlan0001 inet static

vlan-raw-device eth0

address 192.168.1.1

netmask 255.255.255.0

# Não temos um suporte brilhante p/ bridge

iface br0.2 inet static

vlan-raw-device br0

address 192.168.1.1

netmask 255.255.255.0

# Aliases são ignoradas

iface br0.2:1 inet static

address 192.168.1.1

netmask 255.255.255.255

OPÇÕES IFACE EXTRAS

Normalmente quem usa VLANs também deseja fazer algumas outras manipulações com a pilha IP ou a interface.

vlan-raw-device devicename

Indica o dispositivo sobre o qual criar a VLAN. Isso é ignorado quando o devicename faz parte da definição do nome da interface VLAN.

ip-proxy-arp 0|1

Ativa ou desativa o proxy-arp para essa interface especifica. Isso também funciona em Ethernet normal como dispositivos.

ip-rp-filter 0|1|2

Define o filtro do caminho de retorno para essa interface especifica. Isso também funciona em Ethernet normal como dispositivos.

hw-mac-address mac-address

Esse parâmetro define o endereço mac da interface antes de ativá-la. Isso funciona sobre qualquer dispositivo que permite definir o endereço de hardware com o comando IP.

AUTOR

Essa página manual foi adaptada do arquivo interfaces (5) por Ard van Breemen

VEJA TAMBÉM

vconfig (8), interfaces (5)

vlan 10 de Agosto 2000

VLAN-INTERFACES (5)

Usando Disco RAM com Linux

Da mesma forma que as duas opções tmpfs e ramfs já publicada aqui, o disco RAM ou RAM disk, é o mecanismo do Linux que permite criar discos virtuais na memória física de modo que um sistema em produção pode ganhar peformance pelo simples fato de não precisar fazer muito I/O com o disco rígido.

Isso é muito útil no Asterisk quando você usa ele como URA e até mesmo quando voce usa-o como PABX que toca bastante guia ou prompt de voz.

O método a escolher depende do gosto do cliente. Sinta-se a vontade para escolher o seu ...

O conteúdo de ajuda a seguir está conforme aparece nos fontes do Linux.

Usando o dispositivo de bloco RAM disk com Linux

/Documentation/ramdisk.txt

----------------------------------------

Conteúdo:

1) Visão Geral

2) Parâmetros da Linha de Comando do Kernel

3) Usando o comando “rdev -r"

4) Um Exemplo de Criação de um RAM Disk Comprimida

1) Visão Geral

--------------------

O driver do RAM disk é uma forma de usar a memória principal do sistema como um dispositivo de bloco. É exigido pelo initrd, um sistema de arquivo de início usado se você precisa carregar os módulos a fim de acessar o sistema de arquivo root (veja Documentation/initrd.txt). Pode também ser usado como um sistema de arquivo temporário para funcionamento do crypto, desde que os conteúdos sejam apagados no reboot.

O RAM disk cresce dinamicamente quando mais espaço é requerido. Ele faz isso usando a RAM a partir do cache buffer. O driver marca os buffers que ele está usando como demarcados de sorte que o subsistema VM não tentará reclamá-los depois.

Também, o driver RAMdisk suporta até 16 RAMdisks brilhantemente, e pode ser reconfigurados para suportar até 255 RAMdisks – alterando-se a linha "#define NUM_RAMDISKS" no arquivo fonte drivers/block/rd.c. Para usar o suporte à RAM disk com o seu sistema, execute './MAKEDEV ram' a partir do diretório /dev. Todos os RAM disks tem número major 1, e starta com o número minor 0 para o /dev/ram0, etc. Se for usado, os kernels modernos usam o /dev/ram0 para um initrd.

O parâmetro antigo "ramdisk=" foi alterado para "ramdisk_size=" para tornar mais claro. O "ramdisk=" original foi mantido para contornar as questões de compatibilidade, mas ele pode ser retirado no futuro.

O novo diver RAMdisk também tem a capacidade de carregar imagens comprimidas da RAMdisk, permitindo espremer mais programas numa instalação mediana ou em um disco flexível de restauração.

2) Parâmetros de Linha de Comando do Kernel

---------------------------------------------------------------------------------

ramdisk_size=N

==============

Esse parâmetro diz ao driver do RAM disk para definir o tamanho de N KBytes das RAMdisks. O padrão é 4096 (4 MB) (8192 (8 MB) no S390).

ramdisk_blocksize=N

===================

Esse parâmetro diz ao driver do RAM disk quantos bytes usar por bloco. O padrão é 512.

3) Usando o Comando "rdev -r"

------------------------------------------------------

O uso da palavra (de dois bytes) que "rdev -r" define na imagem do kernel está a seguir. Os 11 bits inferiores (0 -> 10) especificam um offset (em blocos de 1 kB) de até 2 MB (2^11) de onde achar a RAM disk (isso usado para ser o tamanho). O bit 14 indica que uma RAM disk é para ser carregada, e o bit 15 indica se uma seqüência prompt/wait é pra ser dado antes de tentar ler a RAM disk. Já que a RAM disk cresce dinamicamente enquanto os dados estão sendo escritos nela, um campo tamanho não é preciso. Os bits de 11 a 13 não são usados atualmente e podem ser zero também. Esses números não são de magia secreta, como visto abaixo:

./arch/i386/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK 0x07FF

./arch/i386/kernel/setup.c:#define RAMDISK_PROMPT_FLAG 0x8000

./arch/i386/kernel/setup.c:#define RAMDISK_LOAD_FLAG 0x4000

Considere uma instalação de dois disquetes típicos, onde você terá o kernel em um disco, e já tem que colocar uma imagem da RAMdisk no disco #2.

Portanto, você deseja definir os bits de 0 a 13 como 0, significa que sua RAM disk inicia com um offset igual 0 KB do começo do disquete.

A linha de comando equivalente é: "ramdisk_start=0"

Você deseja que o bit 14 igual a um, indicando que uma RAM disk é pra ser carregado. A linha de comando equivalente é: "load_ramdisk=1"

Você deseja que o bit 15 igual a um, para indicar que você deseja uma seqüência de prompt/keypress de modo que você tenha uma chance para trocar os disquetes.

A linha de comando equivalente é: "prompt_ramdisk=1"

Colocando isso junto permite 2^15 + 2^14 + 0 = 49152 para um palavra de rdev. Então para criar um do conjunto, você faria:

/usr/src/linux# cat arch/i386/boot/zImage > /dev/fd0

/usr/src/linux# rdev /dev/fd0 /dev/fd0

/usr/src/linux# rdev -r /dev/fd0 49152

Se você criar um disco de boot que tenha o LILO, então para ponto acima, você usaria:

append = "ramdisk_start=0 load_ramdisk=1 prompt_ramdisk=1"

Já o start padrão = 0 e o prompt padrão = 1, você poderia usar:

append = "load_ramdisk=1"

> Usando uma RamDisk Comprimida ...

Criação de uma RAM Disk Comprimida

4) Um Exemplo de Criação de uma RAM Disk Comprimida

---------------------------------------------------------------------------------------------------

Para criar uma imagem RAM disk, você precisará de um dispositivo de bloco reserva sobre o qual construir. Esse pode ser o dispositivo RAM disk em si, ou uma partição de disco não usada (como, por exemplo, uma partição swap não montada). Para esse exemplo, usaremos o dispositivo RAM disk, "/dev/ram0".

Note que essa técnica não deve ser usada em uma máquina com menos de 8 MBytes de RAM. Se estiver usando uma partição de disco reserva em vez do /dev/ram0, então essa restrição não se aplica.

a) Decida sobre o tamanho da RAMdisk que você deseja. Digamos 2 MB para esse exemplo.

A Crie para que possa escrever no dispositivo RAM disk. (Esse passo não é exigido atualmente, mas pode ser no futuro). É inteligente zerar saída da área (especialmente para discos) de forma que a compressão máxima seja alcançada para os blocos não usados da imagem em torno dos quais você está para criar.

dd if=/dev/zero of=/dev/ram0 bs=1k count=2048

b) Crie um sistema de arquivo nela. Digamos o ext2fs para esse exemplo.

mke2fs -vm0 /dev/ram0 2048

c) Monte-a, copie os arquivos que você deseja para ela (por exemplo, /etc/* /dev/* ...) e desmonte-a de novo.

d) Compacte o conteúdo da RAM disk. O nível de compressão será de aproximadamente 50% do espaço usado pelos arquivos. O espaço não usado na RAM disk será comprimido em quase nada.

dd if=/dev/ram0 bs=1k count=2048 | gzip -v9 > /tmp/ram_image.gz

e) Coloque o kernel no disquete.

dd if=zImage of=/dev/fd0 bs=1k

f) Coloque a imagem da RAMdisk no disquete, depois do kernel. Use um offset que seja ligeiramente maior que o kernel, de sorte que você possa colocar um outro (possivelmente maior) kernel no mesmo disquete posteriormente sem sobrescrever a imagem da RAM disk. Um offset de 400 KB para kernels com tamanho em torno de 350 KB seria razoável. Garanta que offset+tamanho de ram_image.gz não seja maior do que o espaço total do seu disquete (normalmente 1440 KB).

dd if=/tmp/ram_image.gz of=/dev/fd0 bs=1k seek=400

g) Use "rdev" para definir o dispositivo de boot, o offset da RAM disk, o flag de prompt, etc.

Para prompt_ramdisk=1, load_ramdisk=1, ramdisk_start=400, um teria 2^15 + 2^14 + 400 = 49552.

rdev /dev/fd0 /dev/fd0

rdev -r /dev/fd0 49552

Pronto! Você agora tem seu disquete de boot/root com a RAMdisk comprimida. Alguns usuários podem desejar combinar os passos (d) e (f) usando um pipe.

--------------------------------------------------------------------------

Paul Gortmaker 12/95

Changelog:

----------

10-22-04: Updated to reflect changes in command line options, remove obsolete references, general cleanup.

James Nelson (james4765@gmail.com)

12-95: Documento Original

Opções de Montagem do RAMFS

A segue uma versão do conteúdo do arquivo texto ramfs que documenta o sistema de arquivo ramfs acompanha os fontes do Kernel Linux. Pra quem pretende implementar sistemas grandes com Asterisk e OpenSER e em geral outros sistemas que demandam recurso de máquina precisa considerar esse tipo de recurso do Linux. Notadamente, se o sistema executa muito I/O com o disco.



Documentation/filesystems/ramfs.txt




ramfs - Permite redimensionamento automático de memória baseado em filesystem.



Ramfs é um sistema de arquivo que mantém todos os arquivos na RAM. Ele permite acesso de
leitura e escrita. Em contraste com os RAMdisks, que mantém alocada uma quantidade fixa de RAM, o ramfs expande e encolhe de modo a acomodar os arquivos que ele contém.



Você pode montar o ramfs com:
Linux#: mount -t ramfs nome /mnt/qualquerlugar



Então apenas crie e use os arquivos. Quando o sistema de arquivo é desmontado, todo o seu conteúdo será perdido.



NOTA!
Este sistema de arquivo é provavelmente muito útil não como um sistema de arquivo real, mas como um exemplo de sistemas de arquivos virtuais que pode ser escrito.



Limites do Recurso:


Por padrão um sistema de arquivo ramfs será limitado ao uso da metade da metade da memória (física) para armazenamento dos conteúdos dos arquivos, um pouco mais quando os meta dados for incluídos. Os limites de uso dos recursos do ramfs podem ser controlados com as seguintes opções do comando mount:



maxsize=NNN
Define o uso máximo de memória permitido do sistema de arquivo para NNN kilobytes. Isso será arredondado pra baixo a um múltiplo do tamanho da página. O padrão é a metade da memória física.



NB. Diferente de muitos outros limites, definindo esse a zero *não* significa sem limite, mas limitará normalmente o tamanho dos dados do sistema de arquivo a zero página. Pode existir um uso para isso em alguma situação pervertida.



maxfilesize=NNN
Define o tamanho máximo de um arquivo simples no sistema de arquivo a NNN kilobytes. Isso será arredondado pra baixo a um múltiplo do tamanho da página. Se NNN=0, não existe limite. O padrão é sem limite.



maxdentries=NNN
Define o número máximo de entradas de diretório no sistema de arquivo (hard links) para NNN. Se NNN=0, não existe limite. Por padrão é definido como maxsize/4.



maxinodes=NNN
Define o número máximo de nós-i (ou seja, arquivos distintos) no sistema de arquivo para NNN. Se NNN=0, não existe limite. O padrão é sem limite (mas nunca pode haver mais nós-i que entradas de diretórios).

Um Exemplo de Alta Disponibilidade do Asterisk com o Heartbeat

A seguir um howto que mostra um exemplo simples de implementação de alta disponibilidade do Asterisk usando conjuntamente o gateway foneBridge da Redfone. Para conhecer mais sobre essa solução tem publicado aqui no Blog um artigo sobre a integração desse produto fonebridge com Asterisk em um esquema HA (High Availability).

Da mesma forma também existe aqui um tutorial com a explicação sobre HA com o Heartbeat. Existem várias outras variações para otimizar o uso dos servidores.

Um HOWTO de Alta Disponibilidade do Asterisk com o Heartbeat e fonebridge da Redfone

Fonte original: http://www.voip-info.org/wiki/view/Asterisk+High+Availability+Solutions, acessado em 01/12/2006.

Visão Geral

Esse é um HOWTO para uma instalação simples do Asterisk para Alta Disponibilidade usando Ferramentas Open Source combinadas com capacidade de recuperação de falhas e hardware inteligente (o fonebridge).

O utilitário heartbeat é usado em um cenário 'Passivo-Ativo', mas pode facilmente ser modificado para fazer o cenário 'Ativo-Ativo'.

Informação Básica

Os grandes clientes da indústria de Call Center e Bancos detestam aceitar a idéia de uma implementação sem nenhum mecanismo de recuperação de falha e sem mecanismo de alta disponibilidade, por isso é que estamos usando a combinação de hardware e software para atender a essas demandas.

Informação Básica

O cenário seguinte foi usado na operação de um Call center de tamanho médio que possui por volta de 60 ramais analógicos e com uma única porta E1 PRI.

Hardware

· 2 x Servidores Supermicro 1U (P4, 512Mb, Dual Gig Eth, Dual SATA com RAID 0);

· 1 x Redfone fonebridge 4E1 para terminação da conectividade PRI, banco de canais poderoso e fornece capacidade de recuperação de falhas entre os dois Supermicros;

· 1 x T1 PRI;

· 3 x banco de canais FXS Adtran 750 para abrir telefones analógicos;

· 2 x Protectors UPS/Surge.

Software

· Fedora Core 4;

· Asterisk, zaptel, libpri baixada do head CVS;

· Conjunto de software Linux HA da Ultramonkey. Eles tem RPMs para Red Heart 3 que instala bem sobre o Fedora Core 4;

· Cada servidor é uma imagem especular um do outro em termos de configurações do Asterisk e de software.

Instalação do Software

Depois de uma instalação padrão do FC4, Asterisk, zaptel, libpri, foi instalado todos os pacotes da Ultramonkey seguindo de certa forma seu guia: http://www.ultramonkey.org/3/installation-rh.el.3.html.

Você pode ter algumas questões de dependências, notadamente as libs do perl, mas nós conseguimos satisfazer todas elas usando o Yum. Se você estiver rodando o Debian, você deve ser capaz de realizar as mesmas coisas com o Apt.

Configurando o Hearbeat

Após a instalação do heartbeat existem somente três arquivos que precisam ser modificados para seu ambiente. São eles: ha.cf, haresources e o authkeys. Todos eles devem ser colocados no diretório /etc/ha.d/. Os arquivos devem ser absolutamente idênticos em todas as máquinas que fazem parte do seu Cluster Asterisk para Alta Disponibilidade. Temos somente dois servidores rodando, mas você pode facilmente escalar para mais usando precisamente as mesmas configurações. Estes são os nossos arquivos de configurações. Todas as linhas comentadas foram removidas, mas conforme se pode ver, elas são curtas e simples.

ha.cf:

debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 200ms
deadtime 2
warntime 1
initdead 120
udpport 694
bcast eth0
node asterisk1
node asterisk2

haresources:

asterisk1 10.10.10.110 fonulator asterisk

authkeys:

auth 1

1 sha1 SuPerS&cretP@$$werd

Operação

Cada servidor Asterisk tem um único endereço IP que é parte do segmento de rede LAN. Esta pode ser uma rede NATeada ou uma face da Internet com endereço IP público. O Heartbeat gerencia a monitoração do estado do hardware de cada máquina sobre a rede Ethernet ou sobre a porta serial ou uma combinação de ambas (recomendado) e atribui o endereço IP Virtual ao servidor Asterisk que está atualmente em um estado ativo. Exemplo:

Asterisk1= 10.10.10.100

Asterisk2= 10.10.10.120

Virtual IP= 10.10.10.110 (veja o haresources)

Com o heartbeat é importante que seus nomes de nó’s sejam idênticos aos nomes de host refletidos no comando host# uname -n. Você também pode precisar adicionar manualmente instruções do endereço IP e nome de hosts ao seu arquivo /etc/hosts, de sorte que cada máquina saiba como alcançar um ao outro via IP.

Seguindo as regras no arquivo haresources, o Heartbeat vai atribuir o nome asterisk1 a máquina como o servidor principal quando ambos os sistemas fazem o StartUp. Ele então startará os scripts seguintes: fonulator (este é o pequeno script que configura o fonebridge) e o asterisk que starta o servidor Asterisk1. Estes são ambos os scripts padrões do StartUp colocados no diretório /etc/init.d/.

Se o servidor principal sofrer uma pane de hardware ou simplesmente parar de responder as mensagens heartbeat trocadas entre os dois nó’s, o asterisk2 vai executar /etc/init.d/fonulator start para reconfigurar o fonebridge em operação para que esse, então, comece a redirecionar o tráfego de mídia para asterisk2 seguido pelo script /etc/init.d/asterisk start para startar o serviço Asterisk no servidor2 .

Resultados

Com o heartbeat, a transferência de controle do endereço IP virtual ocorre em menos de segundo. O utilitário fonulator re-configura o gateway fonebridge quase ao mesmo tempo e depois dependendo de sua plataforma de hardware e da complexidade das aplicações rodando no Asterisk, isso pode ficar entre 5-15 segundos para o Asterisk começar rodar no seu servidor secundário, carregar todos os arquivos de configuração, limpar alarmes e ficar pronto para processar chamadas. O tempo total de recuperação de falha fica em torno de 15-20 segundos.

Recursos

Ultramonkey http://www.ultramonkey.org (pacotes de software para Alta Disponibilidade)
Linux HA http://www.linux-ha.org (O Projeto Linux para Alta Disponibilidade)
Redfone http://www.red-fone.com (Fabricante da fonebridge 4T1/E1)

Ultra Monkey

A solução atual implementada usa o UltraMonkey (http://www.ultramonkey.org) para balanceamento de carga e recuperação de falha e funciona igual a um campeão. Há obviamente um monte de detalhes aqui, e eu ficaria feliz em detalhá-los se as pessoas estiverem interessadas. Existe também um site que tem dois clusters com alcançabilidade uniforme para todos os telefones e os canais PRI´s. Nada disso requer muitos ajustes no plano de discagem em uma base diária.

SLA no Asterisk 1.4

Vale aqui alguns comentários iniciais para quem vai ler esse tutorial ...

Aqui está o conteúdo completo sobre monitoração de linhas compartilhadas, ou simplesmente SLA - é a contração que vem do inglês de "Shared Line Appearances", no Asterisk, conforme consta no arquivo /doc/sla.pdf no diretório dos fontes do Asterisk, escrito pelo Russell da Digium. É com esse recurso do Asterisk que torna possível a implementação de funcionalidade do tipo chefe-secretária, entre outras.

É sempre bom lembrar aos iniciantes, para que essa funcionalidade possa funcionar perfeitamente é necessário que os aparelhos telefônicos IP com o SIP possam dar suporte completo a mesma, o que depende da implementação no firmware de tais aparelhos das RFC´s adicionais do SIP. Portanto, a implementação completa dessa funcionalidade no Asterisk depende diretamente do aparelho IP.

Para tanto, é bom fazer uma pesquisa de mercado para ver os fabricantes e modelos que dão suporte a tal funcionalidade. Tenho conhecimento que modelos dos fabricantes Polycom, Aastra, Snom, Thomson, Linksys e GrandStream dão suporte a mesma com o Asterisk. Naturalmente são modelos de medianos para os top's de linhas desses fornecedores. Certamente, devem existir outros fabricantes. É consultar o mercado.

Se pretende tão somente ter uma idéia sobre esse recurso leia "Linha compartilhadas no Asterisk" aqui mesmo nesse blog, uma versão resumida desse tutorial.

1 Introdução

A funcionalidade “SLA” no Asterisk foi pensada para permitir a uma instalação que emula um sistema de teclas simples. Ele usa as várias camadas de abstração já embutidas no Asterisk para emular funcionalidade de sistema de tecla ao longo de vários dispositivos, incluindo canais IP´s.

2 Configuração

2.1 Sumário

Um sistema SLA é constituído de troncos e aparelhos virtuais mapeados para dispositivos Asterisk reais. A configuração para tudo isso é feito em três diferentes arquivos: extensions.conf, sla.conf e o arquivo de configuração especifico do canal como sip.conf ou zapata.conf.

2.2 Dialplan

A implementação SLA pode gerar automaticamente o dialplan necessário para operação básica se a opção “autocontext” estiver definida como troncos e aparelhos no arquivo sla.conf. Contudo, como referência, aqui está um dialplan gerado automaticamente para ajudar na montagem customizada do dialplan para incluir outras funcionalidades, como voicemail (3.2).

Contudo, observe que existe um pouco de configuração adicional necessária se o tronco for um canal IP. Isso será discutido na seção que fala sobre troncos (2.3).

Existem extensões para chamadas entrantes para um tronco específico, o qual executa a aplicação SLATrunk, bem como para as chamadas entrantes vindas de um aparelho, o qual executa a aplicação SLAStation. Observe que existem múltiplas extensões para chamadas entrantes vindas de um aparelho. Isso é porque o sistema SLA precisa saber se o telefone apenas saiu do gancho, ou se o usuário pressionou um botão linha específico.

Também observe que existe uma prioridade hint para cada linha de cada aparelho. Isso permite que o sistema SLA controle cada led individual de cada telefone para garantir que ele mostra o estado correto da linha. Os telefones precisam fazer um subscribe ao estado de cada uma das suas linhas monitoradas.

Favor consulte a seção de exemplos para ver uma amostra completa de dialplan para SLA.

> Prossegue ...

2.3 Troncos

2.3 Troncos

Um tronco SLA é um mapeamento entre um tronco virtual e um dispositivo Asterisk real. Esse dispositivo pode ser uma linha analógica FXO ou qualquer coisa como um tronco SIP. Um tronco precisa ser configurado em dois lugares. Primeiro, configura-se o dispositivo em si no arquivo de configuração do canal especifico como zapata.conf ou sip.conf. Uma vez o tronco esteja configurado, então o mapeia para um tronco SLA no arquivo sla.conf.

[line1]

type=trunk

device=Zap/1

Cuidar de configurar o contexto do tronco para que seja o mesmo que aquele que está definido para a opção “autocontext” no arquivo sla.conf, se a configuração automática do dialplan for usada. Isso seria feito na linha de entrada regular nos arquivos zapata.conf, sip.conf, etc. observe que a geração automática do dialplan cria a extensão automática SLATrunk() na extensão ‘s’. Isso é perfeito para canais Zap que são troncos FXO, por exemplo. Contudo, isso pode não uma boa idéia para um tronco IP, uma vez que a ligação que chega sobre o tronco pode especificar um número real.

Se o dialplan for montado manualmente, assegurar que as ligações entrantes em um tronco execute a aplicação SLATrunk() com um argumento do nome do tronco, como mostrado no dialplan do exemplo anterior.

Troncos IP´s podem ser usados, mas eles existem alguma configuração adicional para funcionar.

Para esse exemplo, digamos que nós temos um tronco SIP chamado “mytrunk” que é usado como a line4. Alem do mais, quando ligações chegam por esse tronco, eles são levados para dizer que eles estão chamando o número ”12564286000”. Também, digamos que os números que são validos para ligações saintes por esse tronco são números NANP, da forma 1NXXNXXXXXX.

No arquivo sip.conf, existiria uma linha de entrada para [mytrunk]. Para [mytrunk], definido no parâmetro context=line4.

[line4]

type=trunk

device=Local/disa@line4_outbound

[line4]

exten => 12564286000,1,SLATrunk(line4)

[line4_outbound]

exten => disa,1,Disa(no-password|line4_outbound)

exten => _1NXXNXXXXXX,1,Dial(SIP/\${EXTEN}@mytrunk)

Assim, quando um aparelho ergue seu fone e conecta com a linha 4, eles são conectados ao dialplan local. A aplicação Disa gera tom de discagem ao fone e coleta dígitos até que eles casem com uma extensão. Neste caso, uma vez que o telefone disca o número como 12565551212, a ligação vai sair pelo tronco SIP.

> Prossegue ...

2.4 Aparelhos (Stations)

2.4 Aparelhos (Stations)

Um aparelho SLA é um mapeamento entre um aparelho virtual e um dispositivo Asterisk real. Atualmente, o único driver de canal que tem todas as funcionalidades necessárias para suportar um ambiente SLA é o canal sip. Assim, para configurar um telefone SIP para ser usada como um aparelho, você precisa configurar os arquivos sla.conf e o sip.conf.

[station1]

type=station

device=SIP/station1

trunk=line1

trunk=line2

Aqui está algumas dicas de como configurar um telefone SIP para uso com o SLA:

1. Adicione o canal SIP como um [station] no arquivo sla.conf.

2. Configure o telefone no arquivo sip.conf. Se a configuração de dialplan automático foi usada pela ativação da opção ”autocontext” no arquivo sla.conf, então essa linha de entrada no arquivo sip.conf teria o mesmo parâmetro context.

3. No telefone em si, existem varias coisas que precisam ser configurados para fazer tudo funcionar corretamente:

Digamos que esse telefone seja chamado de ”station1” no arquivo sla.conf e ele usa troncos nomeados como line1” e line2”.

a) Dois botões de linha precisam ser configurados para fazer subscribe ao estado das seguintes extensões: - station1_line1 - station1_line2.

b) Os botões de monitoração de linha seriam configurados para discar as extensões para os quais eles estão subscritos quando eles são pressionados.

c) Se você gostaria que o telefone automaticamente se conectasse a um tronco quando ele for tirado do gancho, então o telefone seria automaticamente configurado para discar ”station1” quando ele for tirado do gancho.

> Prossegue ...

3 Exemplos de Configuração

3 Exemplos de Configuração

3.1 SLA Básico

Esse é um exemplo dos mais básicos de uma instalação com SLA. Ele usa a geração automática do dialplan de sorte que a configuração é mínima.

sla.conf:

[line1]

type=trunk

device=Zap/1

autocontext=line1

[line2]

type=trunk

device=Zap/2

autocontext=line2

[station](!)

type=station

trunk=line1

trunk=line2

autocontext=sla_stations

[station1](station)

device=SIP/station1

[station2](station)

device=SIP/station2

[station3](station)

device=SIP/station3

Com esta configuração, o dialplan é gerado automaticamente. O primeiro canal zap teria seu parâmetro context definido como ”line1” e o segundo seria definido como ”line2” no arquivo zapata.conf. No arquivo sip.conf, station1, station2 e station3 teriam seus parâmetros context definido como ”sla_stations” em todos eles.

Por exemplo, aqui está o dialplan gerado automaticamente para essa situação:

[line1]

exten => s,1,SLATrunk(line1)

[line2]

exten => s,2,SLATrunk(line2)

[sla_stations]

exten => station1,1,SLAStation(station1)

exten => station1_line1,hint,SLA:station1_line1

exten => station1_line1,1,SLAStation(station1_line1)

exten => station1_line2,hint,SLA:station1_line2

exten => station1_line2,1,SLAStation(station1_line2)

exten => station2,1,SLAStation(station2)

exten => station2_line1,hint,SLA:station2_line1

exten => station2_line1,1,SLAStation(station2_line1)

exten => station2_line2,hint,SLA:station2_line2

exten => station2_line2,1,SLAStation(station2_line2)

exten => station3,1,SLAStation(station3)

exten => station3_line1,hint,SLA:station3_line1

exten => station3_line1,1,SLAStation(station3_line1)

exten => station3_line2,hint,SLA:station3_line2

exten => station3_line2,1,SLAStation(station3_line2)

> Prossegue ...