ZIC - Compilador de Horário de Zona (Fuso Horário)

Precisei gerar o arquivo localtime conforme instruções do bom tutorial do site da rede nacional de pesquisa (RNP) em http://www.rnp.br/cais/alertas/2008/cais-alr-20081003.html, que atendeu a minha necessidade. Contudo, achei necessário ler a página manual do comando ZIC que só encontrei em inglês. O resultado foi então essa versão em português.

Correções são muito bem-vindas!

ZIC(8)                                                                       ZIC(8)

NOME
zic - time zone compiler – compilador de horário de zona (de fuso horário).


SINOPSIS

zic  [ -v ] [ -d directory ] [ -l localtime ] [ -p posixrules ] [ -L
leapsecondfilename ] [ -s ] [ -y command ] [ filename ... ]

DESCRIÇÃO
O programa zic lê o texto do(s) arquivo(s) denominado na linha de comando e cria arquivos de informação para a conversão de tempo especificado nessa entrada. Se um filename for substituído por‘-‘, então a entrada padrão é lida.

Essas opções estão disponíveis:

-d directory

Cria os arquivos de informação de conversão de tempo no diretório denominado em vez do diretório padrão denominado abaixo.

-l timezone

Usa o timezone (fuso horário) dado como tempo local. O comando zic vai agir como se a entrada contivesse uma linha link da forma:

Link      timezone      localtime

-p timezone

Usa as regras de timezones (fusos horários) quando manipulando variáveis de ambiente timezone no formato POSIX. O comando zic agirá como se a entrada contivesse uma linha link da forma:

Link     timezone     posixrules

-L leapsecondfilename

Lê a informação do Segundo de salto do arquivo com o nome dado. Se essa opção não for usada, nenhuma informação do segundo de salto aparecerá nos arquivos de saída.

-v Reclama se um year (ano) que aparece em um arquivo de dados está fora da faixa de anos representáveis por valores de time(2).

-s Limita valores de tempo armazenados nos arquivos de saída para valores que são os mesmos se eles forem tomados ser sinalizados ou não. Você pode usar essa opção para gerar arquivos compatíveis SVVS.

-y command

Usa o comando dado em vez de yearistype quando verificando tipo ano (veja a seguir).

As linhas de entrada são compostas de campos. Os campos são separados entre si por qualquer número de caracteres espaços em branco. Espaço em branco na cabeça e no rabo nas linhas de entrada é ignorado. Um caractere cerquilho (#) não entre aspa dupla na entrada introduz um comentário que expande até o final da linha que aparece o caractere cequilho. Caracteres espaço em branco e cerquilho (#) podem ser fechados entre aspas duplas (“”), se eles forem usados como parte de um campo. Qualquer linha que esteja em branco (após suprimir comentário) será ignorada. Linhas não em branco são esperadas ser uma de três tipos: linha de regras, linhas de zona e linhas de link.


Uma linha de regra (rule) tem a forma:

Rule   NAME    FROM   TO   TYPE   IN   ON   AT   SAVE  LETTER/S

Por exemplo:

Rule    US    1967 1973   -     Apr lastSun 2:00 1:00 D

Os campos que compõe uma linha de regra são:


NAME

Fornece o nome (arbitrário) do conjunto de regras da qual essa regra é parte.

FROM

Fornece o primeiro ano no qual a regra se aplica. Qualquer inteiro pode ser fornecido; o calendário Gregoriano é assumido. A palavra minimum (ou uma abreviação) significa que o ano mínimo que pode ser representado como um inteiro. A palavra maximum (ou uma abreviação) significa o ano máximo que pode ser representado como inteiro. As Regras podem descrever tempos que não são representáveis como valores de tempo, os tempos que não puderem ser representados serão ignorados; isso permite que as regras sejam portáveis entre hosts com tipos de valor de tempo diferentes.

TO

Fornece o ano final no qual a regra se aplica. Em adição as palavras minimum e maximum (como explicado acima), a palavra only (ou uma abreviação) pode ser usada para repetir o valor do campo FROM.

TYPE

Fornece o tipo de ano no qual a regra se aplica. Se TYPE for ‘-‘, então a regra se aplica em todos os anos entre FROM e TO inclusive. Se TYPE for algo diferente, então zic executa o comando yearistype tipo de ano para verificar o tipo de ano: um status de saída igual a zero é tomado para significar que o ano é do tipo dado; um status de saída 1 é tomado para significar que o ano não é do tipo fornecido.

IN

Nomeia o mês no qual a regra tem efeito. Nomes dos meses podem ser abreviados.

ON

Fornece o dia no qual a regra tomará efeito. Formas reconhecidas incluem:

5	No quinto dia do mês.
lastSun	No último Domingo do mês.
lastMon	Na última Segunda do mês.
Sun>=1	No primeiro Domingo logo após ou igual ao dia primeiro do mês, ou seja, no primeiro Domingo do mês.
Sun>=8	No primeiro Domingo logo após o dia 8 ou igual ao oitavo dia do mês, ou seja, no segundo domingo do mês.
Sun>=15	No primeiro Domingo logo após o dia 15 ou igual ao décimo quinto dia do mês, ou seja, no terceiro domingo do mês.
Sun>=22	No primeiro Domingo logo após o dia 22 ou igual ao vigésimo segundo dia do mês, ou seja, no quarto domingo do mês.
Sun<=25	No último Domingo antes do dia 25 ou no domingo igual ao vigésimo quinto dia do mês.

Nomes de dias da semana podem ser abreviados ou colocados completos. Observe que não pode haver nenhum espaço dentro do campo ON.

AT

Fornece a hora do dia na qual a regra toma efeito. Formas reconhecidas incluem:

2	Tempo em horas.
2:00	Tempo em horas e minutos.
15:00	Tempo no formato 24-horas (para horário vespertino).
1:28:14	Tempo em horas, minutos, e segundos.

Onde 0 hora é meia noite no começo do dia, e 24 horas é meia noite no final do dia. Qualquer dessas formas pode ser seguida pela letra w se a hora dada for à hora local “wall clock”, s se a hora dada for à hora local “Standard”, ou u (ou g ou z) se a hora dada for à hora do tempo universal; na ausência de um indicador, a hora do relógio local será assumido.

SAVE

Fornece a quantidade de tempo a ser adicionada à hora local padrão quando a regra tomar efeito. Esse campo tem o mesmo formato que o campo AT (embora, claro, os sufixos w e s não sejam usados).

LETTER/S

Fornece a "parte variável" (por exemplo, o "S" ou "D" em "EST" ou "EDT") das abreviações de timezone (fuso horário) a ser usado quando essa regra tomar efeito. Se esse campo for ‘-‘, a parte variável é nula.

Uma linha de zona (zone line) possui a forma:

Zone  NAME   GMTOFF   RULES/SAVE   FORMAT  [UNTIL]

Por exemplo:

Zone Australia/Adelaide 9:30  Aus  CST  1971 Oct 31 2:00

Os campos que compõem uma linha de zona são:

NAME

O nome do timezone (fuso horário). Esse é o nome usado na criação do arquivo de informação de conversão de tempo para o fuso horário.

GMTOFF

A quantidade de tempo a adicionar ao horário UTC para obter a hora padrão nessa zona (fuso). Esse campo possui o mesmo formato que o dos campos AT e SAVE das linhas de regra; inicie o campo com um sinal menos se a hora precisa ser subtraída do horário UTC.

RULES/SAVE

O nome da(s) regra(s) que se aplica no timezone (fuso horário) ou, alternativamente, uma quantidade de tempo a adicionar ao horário local padrão. Se esse campo for ‘-‘, então o horário padrão sempre se aplica nesse timezone (fuso horário).

FORMAT

O formato para abreviação de timezone (fuso horário) nesse fuso. O par de caracteres ‘%s’ é usado para mostrar onde entra a “parte variável” da abreviação do fuso horário. Alternativamente, uma barra (/) separa abreviações do horário padrão e do horário daylight.

UNTIL

O horário no qual o offset UTC ou a(s) regra(s) mudam para uma localização. É especificado como um ano, um mês, um dia, e uma hora do dia. Se isso for especificado, a informação de timezone (fuso horário) é gerada do offset UTC dado e a regra alterada até o tempo especificado. O mês, dia, e hora do dia possui o mesmo formato que o formato das colunas IN, ON, e AT de uma regra; colunas finais podem ser omitidas, e é padronizado com o valor mais antigo possível das colunas faltantes.

A linha seguinte precisa ser uma linha “continuação”; essa tem a mesma forma que de uma linha de zona exceto que a string “Zone” e o nome sejam omitidos, porque a linha continuação colocará a informação no início do tempo especificado como o campo UNTIL na linha anterior no arquivo usado pela linha anterior. Linhas de continuação podem conter um campo UNTIL, justamente como faz as linhas de zona, indica que a próxima linha é uma continuação adicional.


Uma linha link possui a forma:

Link LINK-FROM   LINK-TO

Por exemplo:

Link Europe/Istanbul Asia/Istanbul

O campo LINK-FROM deve parecer igual ao campo NAME em toda linha de zona; o campo LINK-TO é usado como um nome alternativo para essa zona (fuso horário).

Exceto para linha de continuação, as linhas podem aparecer em qualquer ordem na entrada.


Linhas no arquivo que descrevem os segundos de salto têm a seguinte forma:

Leap    YEAR    MONTH     DAY    HH:MM:SS    CORR    R/S

Por exemplo:

Leap 1974 Dec    31   23:59:60 +     S

Os campos YEAR, MONTH, DAY, e ‘HH:MM:SS’ informa quando o segundo de salto aconteceu. O campo CORR deve ser “+”, se um Segundo foi adicionado ou “-“ se um segundo foi saltado. O campo R/S deve ser (uma abreviação para) “Stationary", se o tempo do segundo de salto dado pelo outros campos deve ser interpretado como UTC ou (uma abreviação para) “Rolling”, se o tempo do segundo de salto dado pelos outros campos deve ser interpretado como hora local.


OBSERVAÇÃO:
Para as áreas com mais de dois tipos de horário local, você pode precisar usar a hora local padrão no campo AT da regra de tempos de transição anterior para assegurar que o tempo de transição anterior gravado no arquivo compilado esteja correto.


ARQUIVO
/usr/share/zoneinfo – diretório padrão usado pelos arquivos.


VEJA TAMBÉM

ctime(3), dump(1)                                                           ZIC(8)

Visualização de Atividade de Linha Compartilhada

Visualização de Atividade de Linha Compartilhada

Fonte: http://www.voip-info.org/wiki/view/Asterisk+SLA, em 12/12/2007


Shared Line Appearances (SLA) permitem a você colocar uma ligação na espera em um dado aparelho e recuperá-la de forma fácil em outro aparelho. SLA é também conhecido como SCA (Shared Call Appearance). Você pode se juntar à conversação existente pressionando o botão da linha correspondente. Tipicamente, os telefones vão ter botões dedicados com LED’s dispostos sobre si para cada uma das linhas compartilhadas.

Bridged Line Appearance (BLA) permite que múltiplos dispositivos compartilhem um único número de diretório (não implementado ainda no Asterisk e, portanto, não descrito aqui).



Appearance é a palavra da língua inglesa que se refere: ao estado, a condição, a impressão, ao aspecto exterior, a aparência, ou a indicação do modo como uma pessoa ou alguma coisa se apresenta. Aqui no contexto de telefonia Appearance possui o significado do mecanismo de monitoração do estado/situação (se ringando, disponível, indisponível, na espera, ocupado) de outros usuários (ramais) do sistema que seja do interesse de um determinado usuário. Esse recurso é implementado através de led´s dispostos sobre o seu aparelho telefônico que sinalizam/indicam para esse usuário sobre os estados daqules outros usuários (ramais) monitorados.



Isso parece ser uma questão de gosto – e da expectativa do usuário baseado nos antigos sistemas de telefonia – se você preferir a abordagem SLA/BLA, ou se você preferir seguir a abordagem usando os recursos BLF/transferência/ estacionamento/hint que são mecanismos mais típicos do Asterisk e os dos dispositivos SIP. Em geral, SLA somente funcionará bem somente se estiver disponível um número muito limitado de linhas.


Detalhes
Junho 2007
P: Como eu transfiro de extensão SLA para outra extensão não definido no arquivo sla.conf?

R: Não existe nenhum conceito de transferência em uma instalação SLA. A forma tradicional de fazer isso seria colocar uma chamada na espera e pedir a outra pessoa para pegar essa linha (dê uma olhada no bug 9459).

Janeiro 2007 (Quando do lançamento do Asterisk 1.4.0)
P: Kevin consegue fazer uma descrição rápida do que é shared lines (em oposição a extensões compartilhadas)?

R: O recurso Shared Line Appearance é essencialmente equivalente ao key system. Botões nos telefones são mapeados para troncos de linhas reais e reflete o status destas linhas tronco, incluindo a capacidade de poder se junta a ela (conferência), reter a ligação e recuperá-la em outro telefone, etc.

As Extensões Compartilhadas (Shared Extensions) são diferentes... Embora exista um monte de similaridades e ainda que possamos ser capazes de usar nosso código SLA para conseguir implementar Extensões Compartilhadas, não é algo ainda na qual estamos trabalhando atualmente.

P: Beleza! Mas o que eu faço quando a extensão 3 estiver sendo usada em um telefone, o outro possa ver seu status, e quando a extensão for colocada na espera então ela consiga ser recuperada no outro telefone apenas apertando o botão correspondente a linha em questão?

R: Nós não damos suporte para extensão compartilhada. Você pode ter o status de ocupado/ tocando em outro telefone usando o mecanismo hints, embora tal recurso não funcione muito bem se o botão de linha no telefone for usado para uma indicação de linha real.

Em outras palavras... O Asterisk atualmente não tem o que você deseja.



Implementações Usando Aparelhos do fornecedor SNOM


Soluções Chefe–Secretária Similares sem SLA

Nós estamos rodando uma instalação Asterisk (1.2) com aproximadamente 80 telefones SNOM (300,320,360). Agora nós temos a demanda por uma configuração especial do tipo chefe - secretária para alguns ramais. Uma vez que SLA não está disponível na versão Asterisk 1.2. Eu gostaria de saber como implementar isso...

O que precisamos é que o gerente possa decidir se ele deseja pegar ou não as ligações. Se ele não desejar, ele precisar ter a possibilidade de redirecionar todas as ligações entrantes para a sua secretária. A secretária por si atende todas as ligações e decide se a ligação é importante o suficiente para passar ao gerente. Se for então, ela transfere a ligação ao gerente. Assim a secretária pode filtrar as ligações para o gerente...

A única forma que eu pude imaginar até o momento é via um redirecionamento usando o AstDB no ramal do gerente. Os telefones dos gerentes têm duas linhas diferentes – a oficial e uma secreta somente para uso da secretária...


A instalação mais óbvia para atender essa demanda seria:
- ter contas SIP, por exemplo, sip123 associada ao telefone da secretária. E as contas SIP sip456 e sip789 associadas ao telefone do gerente.
- e um número "oficial/público/DDR" de ramal para o gerente que poderia ser "4321". Portanto:

exten => 4321,1,Dial(SIP/sip123&SIP/sip456)

Tocaria tanto o telefone da secretária quanto o telefone do gerente com a identificação "pública" (o que muito provavelmente poderia se ter um tom de sirene diferenciado para identificar essa chamada "privada"). Você desejaria também um ramal "privado" igual a:

exten => 4901,1,Dial(SIP/sip789)

para a secretária poder alcançar o gerente.


Algumas idéias: O parâmetro callerid tanto para a secretária quanto para o chefe deveria ser "4321", não importando através da qual linha o chefe vai escolher ligar pra fora.

- Não escolha números privados óbvios, como 4321 e 4322;
- Você pode escolher ainda um número "real longo", que é apenas disponível somente aos telefones internos, e colocá-los em um botão speeddial no telefone da secretária.


Se você deseja que o gerente não possa ser seletivamente perturbando por ligações de "números públicos", mas somente pela secretária dele, alguma lógica com o AstDB poderia entrar em cena. Isso pode ser altamente dinâmico, ou você simplesmente configura algumas ramais na mão para fazer exatamente isso:

exten => 770/4321,1,Set(DB(list/4321)=SIP/sip123&SIP/sip456)
exten => 770/4321,2,Playback(feature-donotdisturb-off)
exten => 771/4321,1,Set(DB(list/4321)=SIP/sip123)
exten => 771/4321,2,Playback(feature-donotdisturb-on)
exten => 4321,1,Dial(${DB(list/4321)})

Assim, tanto o chefe quanto a secretária podem ativar a função DO-NOT-DISTURB discando 771 e para desativá-la disca 770. Apenas como um exemplo; escolha aqueles códigos em uma faixa que não esteja em uso como ramais; na minha configuração, a numeração interna 2*/3*/4*/5*/6* são para dispositivos SIP, dispositivos OOH, dispositivos IAX etc. e ramais temporários, 8* sendo para aplicações (como o número 888, da aplicação hora certa), 9* experimental e 0* para chamadas PSTN como nos anos 80! Rsrs!. De alguma forma uma função (desviar para o VoiceMail, um atraso em segundos pode ser definido a partir de qualquer telefone, entre 0 e 60 segundos) está disponível aqui como 811x. Escolha o que melhor lhe adequar.


Claro, alguém pode imaginar também que o número do telefone do gerente NÃO toque na secretária enquanto o gerente estiver lá e pronto para atender ligações – apenas edite as linhas 770/771 (ou adicione 772 para esta função). Neste caso, a secretária poderia fazer uso de um número de ramal pra ela, já que o telefone dela também possui várias linhas, então porque não?.


Funcionalidade adicional: Use 'hint' combinado tanto com app_devstate (de bristuff para os Asterisk 1.2 e 1.4) ou func_devstate (nativa no Asterisk 1.6 ou adicionar essa funcionalidade da versão 1.6 no Asterisk 1.4) para acender e/ou apagar um LED de botão para a extensão 770/771. Dessa forma, tanto gerente quanto assistente tem uma indicação visual direta do status do telefone, ou seja, se todas as ligações serão "redirecionadas" ou não para a secretária.




Leituras aqui no site que complementam esse tutorial:
http://clevitonmendes.blogspot.com/2008/07/linhas-compartilhadas-no-asterisk.html
http://clevitonmendes.blogspot.com/2008/07/sla-no-asterisk-14.html
http://clevitonmendes.blogspot.com/2009/04/asterisk-presence.html
http://clevitonmendes.blogspot.com/2009/07/sip-subscriptions-blinking-lamps.html

Asterisk Presence

Asterisk Presence

Fonte: http://www.voip-info.org/wiki/view/Asterisk+presence e http://www.voip-info.org/wiki/view/Asterisk+standard+extensions, em 12/12/2007


O CVS-HEAD atual fornece algum suporte ao “SIP Presence” conforme definido na RFC 3856 – Um Pacote sobre “Presence Event” do Session Initiation Protocol (SIP). A liberação da versão Asterisk (1.0.9) tem algum suporte também.



SIP Presence tem tudo a ver com o que já foi dito aqui sobre Appearance. É o mecanismo intrínseco do próprio SIP para monitorar estado/situação (se ringando, disponível, indisponível, na espera, ocupado) de outros usuários do sistema que seja do interesse de um determinado usuário.



Para suportar tal recurso, de alguma forma, você precisa dizer para qual extensão o usuário SIP é mapeado para se ter monitoração do seu estado. A prioridade "hint" é usada para descrever isso, como neste exemplo:

exten => 100,hint,SIP/peername

(Isso diz que, para os propósitos de “SIP Presence”, a ‘presença’ de atividade da extensão 100 deve ser mapeado para o peer SIP).

- IMPORTANTE: No Asterisk 1.4, o mecanismo intrínseco da funcionalidade hint foi um tanto alterado. Agora é imperativo que você defina um limite de chamada (call-limit) (mesmo que ele seja um valor arbitrariamente alto como 100) e/ou novo limitonpeers=valor no arquivo sip.conf. O recurso de Presence não vai funcionar sem isso. Se você estiver usando o parâmetro type igual à friend em vez de peer, você vai necessitar fazer limitonpeers=yes, bem como uma declaração de limite de chamada (call-limit) para cada um dos dispositivos SIP;

- Se você não adicionar uma prioridade ‘hint’, a extensão vai ficar sempre livre ("aberta"), mais ou menos;

- Se você adicionar incominglimit=1 ao peer que está monitorado o status no arquivo sip.conf, o canal SIP vai notificá-lo quando essa extensão estiver ocupada (busy).



Prioridade Padrão hint
• A prioridade 'hint' associa uma extensão com um canal Asterisk para os propósitos de mapeamento do estado do canal para um estado da extensão.

No Asterisk, um canal (tecnologia/dispositivo) pode ter vários estados (indisponível, em uso, ocupado, tocando, etc), contudo uma extensão é apenas um rótulo para uma seqüência de comandos. No entanto, quando ocorre a troca de comunicação sobre informação de status do canal para um dispositivo externo, como, por exemplo, uma console de recepcionista, você não consegue usar os nomes de canais internos do Asterisk, mas precisa usar externamente um nome identificável de recurso, tipicamente o número de extensão.


Um dispositivo então vai se inscrever para obter o estado da extensão de interesse e iria receber as notificações de status do canal que dar suporte a tecnologia. Isso é usado no canal SIP (implementado via os mecanismos SUBSCRIBE/NOTIFY da RFC-3265) para acender os led´s de sinalização de status correspondentes dispostos sobre os telefones SIP que fica monitorando as atividades de um ramal/usuário/peer.

Isso é suportado em telefones SNOM (veja também) com suas teclas programáveis definida para o tipo "destination", bem como em telefones Polycom (500/600), Aastra (480i, 9133i) e Sayson. Também é suportado nos Gateways Handset SIP da Citel.


Considerações de Privacidade: No arquivo sip.conf você pode definir um subscribecontext=valor que determina em qual contexto o Asterisk deve procurar pela extensão correspondente quando uma requisição subscribe é recebida do telefone; contudo, se a extensão não existir neste contexto, o Asterisk vai procurá-la no contexto default! Em outras palavras: todos podem inscrever-se (subscribe) a uma extensão com prioridade "hint" que estiver definida no contexto default. A propósito, especificando um subscribecontext vazio é também uma idéia boa se o telefone não deve inscrever-se de forma alguma a nenhum contexto.


Da mesma forma, o patch/bug 5515 (pós Asterisk 1.2.0) adiciona suporte a devstate também no MGCP (até o momento o SIP, o IAX e o ZAP são os canais suportados; "show channeltypes" lhe diz quais canais no seu Asterisk suportam notificação de status de dispositivo). Uma questão: Esse patch mostra somente um dispositivo que está indisponível (por exemplo, desconectado), ou ele também mostra "busy"? Resposta: também mostra "busy" (em uso).


Também, chan_capi-cm v0.6.2 e liberações posteriores vem com suporte básico a hint. Parece, contudo, que a nomeação dinâmica de canais CAPI que inclui o número chamado faz que a monitoração de uma linha CAPI para ligações saintes seja praticamente impossível – pelo menos por agora.


Nota: Os patches Bristuff de terceiros vem com a app_devstate que permite a manipulação de estado através do dialplan.


Novidade: No Asterisk 1.6 será incluído a função func_devstate nativamente, também já existe agora um backport disponível para o Asterisk 1.4. Ele é totalmente similar ao app_devstate porque ele parte dos patches bristuff.


Comandos CLI úteis para fazer debug são:

"sip show subscriptions", "show hints", "show channeltypes" e "sip show inuse".

Exemplo 1:

 exten => 200,hint,SIP/phone1  ; this is case sensitive (!) in 1.0.9 and 1.2.0
 exten => 200,1,Macro(stdexten,SIP/phone1)

Exemplo 2: Se você deseja monitorar o estado de múltiplos telefones usando alguma speeddial, você pode fazer assim:

 exten => 200,hint,SIP/201&SIP/202&SIP/203

O Asterisk fornece uma sintaxe para permitir que mais de um canal seja mapeado para qualquer extensão particular através do mecanismo hint.


Exemplo 3: Monitorar Ligações Estacionadas (Callpark) (Asterisk 1.4 e mais recente):

 include => parkedcalls
 exten => 701,1,ParkedCall(701)
 exten => 701,hint,park:701@parkedcalls

Extensão e estado de dispositivo combinado, sem estado de usuário!

O Asterisk – com ou sem o patch – não suporta atualmente o método PUBLISH para divulgação de documentos de presence no formato Presence Information Data Format (PIDF) definido na RFC 3863, mas ele pode gerar notificação (NOTIFY) dos usuários monitorados (SUBSCRIBEd) quando ocorre o REGISTER e também quando o cliente desconecta.


Isso funciona, por exemplo, com o cliente Eyebeam da Xten, mas pode também funcionar com vários outros telefones que suportam SIP Presence. Devido à falta de suporte ao método PUBLISH, não existe qualquer suporte aos estados estendidos (Away, Do not disturb, Busy). Você pode se inscrever para estado de extensão para qualquer canal que suporte notificação de estado de dispositivo. No CVS head, o canal Agent, SIP e IAX2 suporta isso.


A fim de resolver, nós precisamos de uma abstração de usuário no Asterisk, algo que foi sanado na versão de desenvolvimento 1.3.


Telefones que é sabido funcionar com a implementação atual do SIP Presence no Asterisk


• Snom (vários modelos)
• Polycom IP30x/IP50x/IP600
• Xten EyeBeam
• Grandstream GXP2000 (Firmware >= 1.0.1.13)
• Aastra 480i
• Aastra 9133i
• Thomson ST2030
• Linksys SPA962/932 - Tutorial



Configuração Específica Telefone (Telefones Polycom)

Para ativar tronca de informações de presença no telefones Polycom, você precisa adicionar um conato ao diretório contato. O parâmetro CONTACT precisa bater com extensão do telefone que você deseja monitorar e o parâmetro WATCH BUDDY precisa ser definido como "enabled". Também, assegure que a primeira linha do Polycom seja registrada com o seu servidor Asterisk. A Polycom tende a usar a configuração da primeira linha para todas as requisições de subscriptions.

Com o SIP v1.5.2, os telefones Polycom podem "esquecer" da sua subscrição para informação de presença, e retornar um erro 450 de notificação de Presence. Não existe indicação no telefone de que isso aconteceu, exceto que o status de buddy não mais muda. A única forma de contornar isso é rebootar o telefone ou chaveando o parâmetro WATCH BUDDY para disabled, e em seguida para enabled. Esse bug não afeta outras operações do telefone.

Obs.: Existe um limite quoted de 8 (Eu encontrei um limite real de 7) watchable buddies, assim se você for comprar a solução de console para atendente, não espere que vá conseguir monitorar mais do que 7 outras extensões (ramais). (veja abaixo).

Obs.: Quando da versão do firmware 1.6.6, o limite foi aumentado no modelo 601 para 48 watchable buddies. Ainda é de 8 nos aparelhos 501. Valeu Polycom!



Estacionamento e BLF
Isso pode ser realizado no asterisk 1.2 com um patch e está embutido no asterisk 1.4.



Estacionamento BLF no Asterisk 1.2
• Patch/bug 5779 adicionou suporte hint na construção do canal Local que permite a monitoração de ligações estacionadas (parking lot/ parked) verificando a existência de uma extensão no dialplan.

• OBS.: A fim de configurar um estacionamento com BLF com esse patch no Asterisk 1.2.X, você precisa configurar o fragmento seguinte no contexto onde seu telefone SIP se registra:

exten => 701,1,ParkedCall(701)
exten => 701,hint,Local/701@ParkedCalls

Estacionamento com BLF no Asterisk 1.4
• OBS.: A fim de configurar a funcionalidade embutida de estacionamento com BLF no Asterisk 1.4, você precisa definir a seguinte coisa no contexto onde seu telefone SIP se registra...

include => parkedcalls
exten => 701,1,ParkedCall(701)
exten => 701,hint,park:701@parkedcalls

Isso difere da sintaxe originalmente descrita no relato do patch/bug para a versão 1.2 acima. Se você está usando o patch do metermaid com o Asterisk 1.2.X e decidir atualizar para 1.4 esperando que ele 'apenas funcione' você fica para um cruel e pobremente documentado surpresa.



Atualização para o Asterisk 1.6 (em desenvolvimento)

Russel da Digium implementou uma função DEVSTATE que está descrito aqui em mais detalhes. Existe uma nova versão que funciona com o Asterisk 1.4 aqui.



Mensagens de Presença atravessando os PABX’s

Nuitari escreveu um script PHP que se conecta ao manager de múltiplos PABX’s e usa devastate do Russel (Digium) para definir o BLF ao longo dos PABX’s. Você pode encontrá-lo aqui.

Impacto do 802.11n na Segurança da WLAN

Impacto do Padrão 802.11n na Segurança da Rede WLAN


Lisa Phifer
17/03/2009
SearchNetworking.com



À medida que as empresas se movem a toda força na direção de redes WLAN’s mais rápidas e mais abrangentes, vários fatores precisam ser considerados – incluindo a segurança. O padrão 802.11n promete expandir a cobertura e capacidade de rede, mas cuidados precisam ainda ser tomados para fornecer igual, ou melhor, segurança.



Antigo Padrão 802.11a/b/g

Igual ao padrão 802.11a/b/g anterior, o padrão 802.11n de elevada taxa de transferência emprega o 802.11i "robust security". Realmente, é exigido de todos os produtos Draft N dar suporte ao WiFi Protected Access version 2 (WPA2) – o programa de teste para o 802.11i do WiFi Alliance.


A boa notícia: todas as redes WLAN’s 802.11n construídas a partir do zero podem se despreocupar de invasores WEP e ataques WPA (TKIP MIC), porque todo dispositivo 802.11n pode cifrar dados com o algoritmo AES. O truque: as redes WLAN’s que precisam suportar tanto clientes antigos no padrão 802.11a/b/g quanto os novos clientes 802.11n precisam ser forçados a permitir o algoritmo TKIP. Fazendo assim torna possível aos clientes mais antigos não-AES a se conectarem seguramente. Infelizmente, o padrão 802.11n proíbe taxas de transmissão de dados elevadas quando se usa o algoritmo TKIP.


Consequentemente é melhor dividir clientes antigos 802.11a/b/g e clientes novos 802.11n em SSID’s separados: uma rede WLAN de taxa elevada de transferência exige o AES (WPA2) e uma rede WLAN legada que permita o TKIP ou o AES (WPA+WPA2). Isso pode ser feito usando duas definições SSID’s sobre um AP virtual ou dedicando diferentes portadoras sobre os AP’s dual-rádio. Contudo, isso é apenas um expediente temporário. Tão logo você possa retirar ou substituir aqueles dispositivos legados, livre-se do TKIP para melhorar tanto a velocidade quanto a segurança.



Tomando emprestado a Robustez do WPA2

O padrão 802.11n herda a robustez do WPA2 – e também os pontos fracos. Os dispositivos 802.11a/b/g e 802.11n podem usar AES para prevenir escutas de quadros de dados, falsificação e repetição da rede Wireless. Os APs 802.11a/b/g e 802.11n podem usar o padrão 802.1X para conectar usuários autenticados ao mesmo tempo que nega acesso a estranhos. Contudo, o padrão 802.11n ainda não pode evitar que intrusos envie quadros falsos de gerenciamento – um método de ataque usado para desconectar usuários legítimos ou fingir ser um AP’s "evil twin".


evil twin:
É um access point (AP) mau intencionado instalado por um atacante externo com uma facilidade com um rede wireless. O AP bandido captura beacons (sinais que anunciam sua presença) do AP legitimo da empresa e transmitem beacons idênticos, com algumas máquinas clientes internas ao prédio o qual se associa. Logo que a segurança wireless esteja habilitada, esse tipo de ataque não consegue afetar as máquinas usuárias. Contudo, ele pode causar prejuízo deixando as conexões lentas ou causando aos usuários perder conexões com rede real.



Como resultado, as novas redes padrão 802.11n precisam permanecer vigilantes a ataques oriundos do mundo de rede Wireless. Muitas redes WLAN’s pequenas podem ainda usar escaneamentos periódicos para detectar AP’s maliciosos, enquanto redes WLAN’s comerciais devem usar sistemas de prevenção de intrusão (WIPS) o tempo todo para barrar falsificadores, associações acidentais, ‘ad hoc’s não autorizados e outros tipos de ataques WiFi.


Redes WLANs existentes que implementa uma ou ambas dessas práticas de segurança, contudo, não podem ficar só dormindo em berço esplêndido. Dispositivos 802.11n possui alcance de distância duas vezes maior que seus pares 11a/b/g. AP’s maliciosos, de visinhos ou de área metropolitana que antes estavam tão distantes podem agora se tornar uma ameaça. Não apenas intrusos serão capazes de se conectarem a sua rede WLAN facilmente, mas usuários legítimos vão muito provavelmente se conectar acidentalmente a redes estranhas. Dado uma escolha entre o seu antigo AP 11a/g e um rápido AP 802.11n malicioso, os clientes promíscuos que “se conectam a qualquer rede disponível” vão tentar o tempo todo burlar.


Em resumo, a abrangência do alcance do padrão 802.11n agrava a freqüência de incidentes convencionais da segurança de rede Wireless e expõe configurações frágeis que contam com o desempenho ruim. Pior ainda, sensores WIPS existentes baseados no padrão 11a/b/g pode perder inteiramente muitos incidentes. Cada ativação de AP 802.11n deve incluir um upgrade do dispositivo WIPS para monitorar a maior cobertura das novas redes WLAN's, analisando o tráfego 11a/b/g e 11n nos canais 20MHz e 40MHz em ambas as bandas.



O Novo padrão 802.11n trás novas ameaças de segurança e complexidade

Toda tecnologia nova introduz alguns riscos não descobertos; uma inovação tão significativa quanto do padrão 802.11n não será provavelmente a exceção.

Os dispositivos 802.11n são novos produtos que podem conter alguns bugs não descobertos. Por exemplo, as primeiras versões do AP WN802T da Netgear não fazia corretamente parse dos parâmetros SSID’s (nulo) de comprimento zero (WVE-2008-0010). Drivers Atheros usados nos novos AP’s 802.11n (como o Linksys WRT350N) não tratava corretamente certos elementos de informação de gerenciamento de quadro (WVE-2008-0008). Tais vulnerabilidades não são incomuns; administradores de rede WLAN simplesmente precisam ficar atentos aos alertas quanto à segurança e de atualizações de firmware/driver.

As opções 802.11n são também consideravelmente mais complexas, aumentando as possibilidades de configurações mal feitas. Por exemplo, existem dúzias de possíveis taxas de transmissão de dados elevada, cada uma associada com uma combinação de capacidades e parâmetros que precisam bater em ambas as pontas. Em muitos casos, configuração mal feita causa desempenho parcial – isso pode não parecer uma questão de segurança, mas pode afetar a disponibilidade. Em casos extremos, um AP 802.11n mal configurado pode resultar em negação de serviço a redes WLANs vizinhas. Educação e análise no local são necessárias para descobrir e resolver esses problemas.

Finalmente, o padrão 802.11n introduz alguns quadros MAC novos, um dos quais se descobriu poder ser explorável. Especificamente, o padrão 802.11n fornece suporte mais eficiente a aplicações que trata stream pela confirmação de recebimento de vários quadros de dados usando único bloco reconhecimento (ACK). Um ataque de negação de serviço (DoS, em inglês) pode ser lançado contra redes WLAN’s 802.11n pelo envio de reconhecimentos falsos de bloco ao receptor (WVE-2008-0006). Um dispositivo WIPS que suporta o padrão 802.11n pode detectar esse ataque, mas a única forma de evitar isso é barrar o uso da funcionalidade Add Block-ACK (ADDBA).



Dando maior atenção

Felizmente, tudo das melhores práticas atuais de segurança de rede ainda se aplica ao padrão 802.11n. É importante perceber, contudo, que o padrão 802.11n também pode aumentar o risco empresarial simplesmente porque fornece suporte a mais usuários e aplicações com área de abrangência mais ampla. Em resumo, os mesmos ataques antigos podem agora ser de longe mais impactante ao seu negócio.


Por último, as redes 802.11n podem ser implementadas tão segura quanto – se não mais segura que – as redes 11a/b/g de então. Tudo isso exige está ciente e seguir com os objetivos. Nessa dica, nós exploramos as formas nas quais o padrão 802.11n pode afetar a segurança da rede WLAN. Agora é a sua chance de dar esse passo.



Sobre a autora:
Lisa Phifer é Presidente e sócia da Core Competence, uma firma de consultoria focada em uso empresarial de rede emergente e tecnologias de segurança. Na Core Competence, Lisa tem trilhado os seus 27 anos de experiência em projeto de rede, implementação, e testes para fornecer uma gama de serviços, desde estimativa de vulnerabilidade e avaliação de produto até educação de usuário e desenvolvimento de ‘white paper’. Ela tem alertado grandes e pequenas companhias a considerar o uso de tecnologias de rede e melhores práticas de segurança para gerenciar risco e adequar as necessidades empresariais. Lisa ensina e escreve exaustivamente sobre uma faixa ampla de tecnologias, desde segurança de rede móvel/wireless e prevenção a intrusão até implementação de rede privada virtual a controle de acesso a rede. Ela também é uma especialista dos sites SearchMobileComputing.com e SearchNetworking.com.

Volta ...