Digium e Skype Se Unem Pra Levar o Skype aos Sistemas Clientes Empresarial

Colaboração Digium e Skype pra Levar o Skype aos Sistemas de Telefonia Empresariais


Programa beta Skype For Asterisk inicia hoje, adicionando funcionalidades Skype a soluções baseadas no Asterisk



Fonte da informação o "Press Releases" da Digium em:
http://www.digium.com/en/mediacenter/viewpress/Digium-and-Skype-Collaborate-to-Bring-Skype-to-Business-Phone-Systems



GLENDALE, Arizona (AstriCon 2008) — Setembro 25, 2008— A Digium®, e Skype™, a companhia líder das comunicações pela Internet Global, anunciaram hoje o lançamento da versão Beta do Skype para o Asterisk, que permitirá a integração das funcionalidades do Skype no Asterisk da Digium e que capacitará aos clientes fazer, receber e transferir ligações Skype a partir dos sistemas de telefonia Asterisk.


“A história individual de cada um de nós, Skype e Asterisk, foi fazer ruptura completamente com os métodos tradicionais de comunicações através de soluções inovadoras e com custo benefício”, disse Stefan Öberg, vice-presidente e gestor geral da Skype Telecom e Skype para Empresas. “Nós estamos excitados em trabalhar junto com a Digium no sentido de oferecer as pequenas e médias empresas uma solução de comunicações de fato muito poderosa para atingir o mercado empresarial de âmbito mundial”.


Especificamente, a versão beta do “Skype For Asterisk” é um módulo de driver de canal acrescentável para integrar chamadas Skype pela Internet aos produtos de telefonia baseados no Asterisk. O “Skype For Asterisk” também complementa os serviços existentes dos usuários de pequenas e médias empresas fornecendo baixa tarifa para ligações fixas e móveis ao redor do mundo.


“Trabalhando junto com a Skype, nosso objetivo é ajudar a impulsionar a produtividade das empresas e ganhar o prêmio de software de telefonia rico de funcionalidades, e dessa forma economizando uma quantidade substancial de dinheiro”, disse Danny Windham, CEO da Digium, a empresa criadora e patrocinadora do Asterisk. “O software Beta ‘Skype For Asterisk’ é o primeiro passo na direção de poder adicionar as funcionalidades do Skype aos sistemas de telefonia baseados no Asterisk e possibilitá-los atingir mais de 338 milhões de usuários Skype”.


A versão Beta do “Skype For Asterisk” capacitará os usuários empresariais a:

• Fazer, receber e transferir ligações Skype a partir dos sistemas de telefonia Asterisk, usando o hardware existente.;

• Complementar os serviços existentes com baixas tarifas Skype globais (tão baixo quanto 2.1US¢ por minuto para mais de 35 paises de variadas parte do mundo);

• Economizar dinheiro com soluções de ligações entrantes tal como o liberar “click-to-call’ de um website, bem como ligações entrantes da rede pública de telefonia tradicional (RTPC) através de números Skype que ficam online;

• Gerenciar ligações Skype usando aplicações Asterisk tais como: roteamento de chamada, estabelecimento de conferência, menus telefônicos e voicemail.


Depois de passado o período Beta quando o produto já estiver liberado, o ‘Skype For Asterisk’ será vendido e distribuído pela Digium e pela sua rede mundial de revendedores.


Ao Vivo na AstriCon
Stefan Öberg fará a primeira demonstração pública do ‘Skype For Asterisk’ durante sua palestra agendada pra hoje na AstriCon, a conferência anual de usuários e desenvolvedores do Asterisk. As atendentes da AstriCon também serão convidadas a experimentarem e fazer uma demonstração do ‘Skype For Asterisk’ no stand Skype no piso da exposição.


Programa Beta “Skype For Asterisk”
O programa Beta do ‘Skype For Asterisk’ começa hoje; usuários Asterisk, administradores de sistemas e desenvolvedores estão convidados a visitar o site: http://www.astricon.net/skype. A versão beta inicial está limitada a um número selecionado de usuários, desenvolvedores e integradores.

Como Conectar Dois Servidores Asterisk

Conectando Dois Servidores Asterisk



Visão Geral

Claro que você pode também usar o SIP ou H.323 (mas não o MGCP) para interligar dois servidores Asterisk, contudo o IAX é a abordagem mais comum de interligação. A fim de distribuir um dialplan, você pode:

• Inteligentemente projetar o dialplan em cada servidor de sorte que isso se torne instantaneamente transparente quando uma extensão em outro servidor é discada, por exemplo, use 3XXX para o servidor A, 4XXX para o servidor B e 5XXX para as extensões no servidor C;

• Use a declaração “switch” para fazer o servidor A olhar no servidor B extensões desconhecidas localmente (ambas as caixas precisam estar permanentemente online, se este não for o caso você vai experimentar atraso sensível quando discando!);

• use DUNDi: Distributed Universal Number Directory (DUNDi);

• Use EnumLookup (E.164).



Métodos SIP

Diferentemente do IAX não existe uma distinção clara entre type=peer e type=user quando isso vem do sip.conf. Você pode partir com o parâmetro type=friend em ambos os lados, e se você conseguir que funcione você vai desejar provavelmente dividir as entradas dentro do sip.conf em um peer e um user. Também preste atenção nos parâmetros “insecure=very” e talvez “autocreatepeer=yes” do sip.conf.

• Servidor A com o endereço IP estático, o servidor B com endereço IP dinâmico: Registre o servidor B com o servidor A no sip.conf;

• Ambos os servidores com o endereço IP estático: Não precisa registrar nada;

• Ambos servidores com o endereço IP dinâmico: Isso dá uma boa dor de cabeça, você necessitará recorrer a um serviço como do dyndns.org para ser capaz de registrar os servidores entre si; em qualquer caso, isso não é uma boa configuração porque durante a mudança do endereço IP, a conectividade será perdida até a atualização tenha se propagado através do dyndns;

• Ambos os servidores atrás de seus NAT próprios: Não use o SIP, em vez disso volte-se para IAX2.



Detalhes da Configuração do IAX

Uma conexão IAX entre dois servidores Asterisk é configurado nos passos seguintes:

• Configure os servidores Asterisk em ambas as pontas no arquivo iax.conf, um como peer e o outro como user;

• Defina o dialplan do user no arquivo extensions.conf de forma que chamadas podem ser feitas do user para o peer;

• Opcionalmente, registre o peer com o user (para quando o endereço IP do peer for dinâmico e assim desconhecido pelo user);

• Repita os passos anteriores na ordem inversa (inverta peer por user) se você quer ser capaz de fazer chamadas em ambas as direções.


Declaração do user no IAX2

Um peer recebe chamadas. A parte seguinte seria necessário no arquivo iax.conf da máquina peer para verificar (autenticar) a identidade do user antes de dá permissão a chamadas deste user.

[username]
type=user
auth=md5
secret=secretword
context=iax2users

O parâmetro “context" é importante porque ele define o contexto local no qual colocar quaisquer chamadas entrantes deste user (veja o extensions.conf).

Esta configuração permite o user remoto registra-se ao seu sistema a partir de qualquer host. Se você quer restringir algum endereço IP ou hostname do user remoto de se conectar, acrescente os parâmetros permit ou deny quando descrevendo no arquivo iax.conf do peer.



Declaração do peer IAX2

Um user faz chamadas. O pedaço seguinte seria necessário no arquivo iax.conf da máquina user para se identificar (autenticar) ao peer antes que o peer vá fazer a chamada.


[peername]
type=peer
host=hostname.domain.tld (or "dynamic" which would then require a "register" command by the peer.)
auth=md5
secret=secretword ; redundant when already embedded in Dial string
username=username-at-the-peer ; redundant when already embedded in Dial string


Favor observe que:
• Um type=user é para autenticar uma chamada entrante;
• Um type=peer é para quem você envia uma chamada;
• type=friend, claro, é para ambos.


Usando type=friend torna as coisas mais fáceis, mas isso é tratado como um atalho. Se você acrescentar ambos os parâmetros type=friend e host=hostname.domain.ext você limita os hosts a partir do seu peer que podem fazer chamadas, o que pode ser o que você não deseja.

Para instruções sobre o uso do parâmetro auth=rsa, veja a página do wiki Asterisk IAX RSA authentication.

Agora que nós temos completado os passos 1 e 2, a única coisa que resta é planejar o dialplan. Leia os exemplos abaixo de como fazer isso.



Conectando os Planos de Discagem


Exemplo 1
extensions.conf:
exten => _7XXX,1,Dial(IAX2/myserver:passwordA@IAXserverA/${EXTEN:1},30,r)
exten => _7XXX,2,Dial(SIP/myserver:passwordA@SIPserverA/${EXTEN:1},30,r)
exten => _7XXX,3,Congestion

exten => _8XXX,1,Dial(IAX2/myserver:passwordB@IAXserverB/${EXTEN:1},30,r)
exten => _8XXX,2,Dial(SIP/myserver:passwordB@SIPserverB/${EXTEN:1},30,r)
exten => _8XXX,3,Congestion


Claro que nós necessitaremos fazer batimento com entradas como [IAXserverA] etc. no arquivo iax.conf e no arquivo sip.conf na ordem acima para que funcione como esperado. O exemplo usa o SIP como um fallback no caso quando nós temos problemas com a sua conexão IAX.

Observe que nesta abordagem o username e a password serão mostrados nos registros do CDR (você pode querer usar o segundo exemplo ou verificar o uso de chaves em vez de uma combinação (username/ password)!



Exemplo 2
Este exemplo não mostra os parâmetros username e secret no CDR.
Note que se for a versão 1.0.9 este atalho ainda não é parte do Braço Estável do Asterisk, portanto ainda requer o user e a password como parte da string de discagem no arquivo extensions.conf. Por exemplo,


exten => _7XXX,1,Dial(IAX2/username:pass@serverB/${EXTEN:1},30,r)


(serverA)
iax.conf
[general]
register => :@

[serverB]
type=friend
user=
secret=
host=

extensions.conf
exten => _7XXX,1,Dial(IAX2/serverB/${EXTEN:1},30,r)
exten => _7XXX,2,Congestion


(serverB)
iax.conf
[serverA]
type=friend
user=
secret=
host= |

extensions.conf
exten => _8XXX,1,Dial(IAX2/serverA/${EXTEN:1},30,r)
exten => _8XXX,2,Congestion


Em alguns casos o serverA e o serverB, serão os usernames dos servidores.



Exemplo 3
Com o objeto Switch no arquivo extensions.conf você pode conectar dois servidores Asterisk e o plano de discagem de outros servidores. Neste caso, nosso próprio “servidor C” se conectará tanto ao "servidor A" quanto ao "servidor B":


[default]
exten => _801XXX,1,Goto,srvA|${EXTEN}|1
exten => _802XXX,1,Goto,srvB|${EXTEN}|1

[srvA]
exten => _801XXX,1,StripMSD,3
exten => _XXX,2,Goto,1
switch => IAX/serverA

[srvB]
exten => _802XXX,1,StripMSD,3
exten => _XXX,2,Goto,1
switch => IAX/serverB



Observações: Você pode não estabelecer links circulares fazendo o chaveamento do serverA para o serverB e do serverB para o serverA! Também verifique no (novo) parâmetro do iax.conf, "autokill=" para evitar um travamento mais logo quando o servidor remoto estiver fora do ar ou desconectado.




Exemplo 4
No arquivo extensions.conf: (no master)


[outbound]
switch => IAX2/master:secret@iax-gw1.company.net/outbound


No arquivo iax.conf (no master):

[slave]
type=user
auth=plaintext
context=outbound
context=outbound2 ; (can have multiple if you want)
secret=secret
host=dynamic
callerid="slave"
trunk=yes
notransfer=yes

[slave]
type=peer
auth=plaintext
context=outbound-nuphone
secret=secret
host=dynamic
trunk=yes
notransfer=yes



No arquivo extensions.conf (escravo):


[assigned-dids]
; uncomment a dial mechanism, first one goes to specific extension
; other one goes to dial parameter s.

;exten => 7046446999,1,Dial,IAX2/master@slave/${EXTEN}
;exten => 7046446999,1,Dial,IAX2/master@slave



No arquivo iax.conf (escravo):

register => slave:secret@iax-gw1.company.net

[master]
type=peer
host=iax-gw1.company.net
secret=secret
context=outbound
trunk=yes
canreinvite=no


[master]
type=user
secret=secret
context=acontext
trunk=yes
canreinvite=no



Método do Comando Switch

A instrução SWITCH permite a um servidor compartilhar/distribuir o seu dialplan com outro servidor. Use com cuidado instruções switch Recíprocas. Não é permitido (por exemplo: como em, A -> B e B -> A), no processo de comutação os servidores necessitam estar online ou, do contrário, a discagem pode sofrer severamente com atraso.

Switch:
Uma instrução switch declarada no plano de discagem permite a um servidor Asterisk buscar por extensões fora do seu dialplan local. O único uso implementado até agora é o comando switch sobre o protocolo IAX, embora o uso dessa funcionalidade esteja planejada para os outros protocolos. O switch IAX usa o protocolo IAX para buscar por extensões em outro dialplan remoto e conecta-se a elas.

Se um chamador disca uma extensão que não consta no dialplan local, e caso uma declaração switch estiver presente no contexto atual dos usuários chamadores, a extensão será feita à verificação de existência da mesma contra os servidores remotos ou servidores especificados. A declaração switch inclui como argumento um contexto, que será o contexto onde será verificado ou buscado no dialplan remoto.


Exemplos
Buscando uma extensão usando o protocolo IAX no servidor remota:

switch => IAX/username:password@server/context

Alternativamente, se a chave RSA estiver ativada (veja iax.conf) você pode substituir a password por uma keyname, a qual seria a chave enviada ao servidor remoto.


switch => IAX/username:[password]@server/context

O comando witch basicamente consulta os seus pares para ver a possibilidade de poder completar uma chamada a partir do contexto que recepcionou o pedido de ligação no qual o comando switch está declarado. No contexto que você compartilha a instrução switch, você coloca todas as combinações de testes possíveis, e/ou uma aplicação AGI que execute as combinações de testes possíveis.

O uso normal da instrução switch é rotear a chamada através da máquina a qual você requisitou para comutar seu pedido de chamada. O truque aqui é que o IAX é realmente bom para ser capaz de fazer o handoff da chamada e sair do caminho do tráfego de media. Portanto, tão logo o switch tenha feito à discagem, ele será capaz de sair do caminho se assim você desejar.

A intenção por trás do comando switch é que todo servidor saiba o que ele pode alcançar localmente a extensão discada. E então fazer a 'comutação' para os servidores remotos se o número chamado não pôde ser achado localmente.

Se você deseja manter este dados em um DB e consultá-los a partir de um script AGI, você pode testar todas combinações, e então decidir para onde fazer a requisição. E mais, você pode usar qualquer uma das suas ferramentas favorita de replicação de DB que você desejar.


[iaxprovider]
switch => IAX2/user:[key]@myserver/mycontext



O Comando register

Quando o endereço IP do peer for desconhecido, um user não tem como colocar uma chamada (por exemplo, quando um office/user chama um teleworker/peer em casa, onde o teleworker tem somente um endereço IP dinâmico ou estiver atrás de NAT). Para compensar isso, o teleworker/peer ativamente se registra com o office/user fornecedendo sua identidade e seu endereço IP para localização.

No peer, na seção [general] do arquivo iax.conf, deve-se acrescentar uma linha para registro:


register => user:password@hostname.domain.ext

Atualiza continuamente o user de forma que ele sempre saberá como alcançar o peer mesmo se o endereço IP do peer mude.

A declaração "register" somente funciona se você deseja se vincular a um servidor com um endereço IP dinâmico a um servidor com um endereço IP estático (publico) IP, ou seja, no lado do user você precisa acrescentar "host=dynamic" no arquivo iax.conf para aquele peer. Se ambos os servidores são conhecidos, os endereços IP’s estáticos então não existe necessidade para uma declaração register porque você usaria host=hostname em ambos as pontas.




Referência: http://www.voip-info.org/wiki/view/Asterisk+-+dual+servers, acessado em janeiro de 2007.

Sabe o Que é SOA ou AOS no Mundo de TI?

Conceito Rápido de SOA
Como um usuário final, você muito provavelmente esteja familiarizado com a Arquitetura Orientada a Serviço (AOS). Se você simplesmente adquiriu alguma coisa on-line e um programa de computador conversou com um outro programa de computador para verificar se o item que você requisitou existia em estoque, assim você entrou no mundo da Arquitetura Orientada a Serviço. Muito simples, o AOS especifica o modo como duas entidades computacionais vão interagir quando trabalhando juntas. De acordo com o Gartner Group, em 2008, mais de 60 por cento das empresas usarão arquitetura orientada a serviço como “o princípio norteador” quando forem criar aplicações importantes ou de missão crítica.



SOA no Contexto das Comunicações/TI
Usando protocolos baseados em padrões abertos e em serviços web, as SOAs prometem trazer junto com aplicações feitas para estoque em um pacote transparente de interoperabilidade, serviços compartilhados que possibilitará as empresas melhor adequar tanto as demandas dos clientes quanto melhorar os processos de fluxo de trabalho; definitivamente, tornando mais eficiente e menos complicado a forma com que os gestores podem combinar processos empresariais diversos com as comunicações fornecendo assim uma entrada e uma interface únicas ao consumidor no sistema.

Isso significa o ambiente de rede precisa seguir padrões universais estabelecidos rigorosamente baseado no padrão da pilha TCP/IP. Assim o Switch Ethernet do fabricante A precisar ser totalmente compatível com o Switch do fabricante B, C e D. O mesmo princípio vale para roteadores, firewall’s e servidores.

Esse conceito não poderia ser diferente em uma parte fundamental desse processo, o sistema de telefonia. Dentro dessa realidade, os sistemas de telefonia/PABX tradicional não fazem mais o menor sentido. Quero dizer com isso que a telefonia IP é base fundamental de tudo devido a sua enorme flexibilidade e facilidade de integração com todos os sistemas de comunicações (e-mail, mensagens instantâneas, entre outros.) para formar as comunicações unificadas (UC).

Assim, telefones IP e servidores de processamento de chamadas têm que seguir padrões rigorosamente. O protocolo de sinalização SIP, se tornou um padrão de fato para sinalização de telefonia IP e o RTP para transmissão de fluxo de voz. Assim, telefone de diferentes fabricantes precisam se comunicar sem qualquer problema de interoperabilidade, bem como os sistemas de processamento de chamadas, permitindo as funcionalidades dos sistemas sejam transparentes aos usuários.

A SOA, usada em conjunção com padrões abertos, vai tornar ambientes com múltiplos fornecedores mais gerenciáveis e possibilitará reduzir a complexidade da segurança e questões associada ao gerenciamento de identidade.

Se você for gestor de TI precisa ter isso em mente. Se no seu processo de contratação, um fornecedor não estiver aderente a essas premissas, você deve considerar excluí-lo do seu processo. A tecnologia é que precisa se moldar ao seu negócio, e não o seu negócio se moldar a tecnologia oferecida. Assim, eu entendo...



Impacto no Negócio Proporcionado pelo SOA
Processos Empresariais que são Potencializados pelos sistemas de Comunicações (PEPC) ganham um peso elevado entre as várias atratividades impulsionadas pelas funcionalidades das comunicações IP unificadas. O PEPC fornece um meio de conectar ou convergir processos empresariais com as comunicações de uma forma holística nas empresas para ajudar a alavancar tecnologias de comunicações com o objetivo de flexibilizar seus processos empresariais. Arquiteturas Orientadas a Serviço muito provavelmente será uma parte importante nessa visão de comunicações e aplicações empresariais unificadas.


Os SOAs também possibilita a integração de novos processos empresariais entre redes de voz e dados ativando tarefas comuns em aplicações de serviços web reusáveis e abrindo novas oportunidades para que as comunicações unificadas (UC) possa melhorar o fluxo de trabalho e a forma como as corporações fazer negócio.



Cléviton Mendes de Araújo