Meu Blog traz notícias, tutorias, dicas, howTo, configurações e manuais a respeito de Tecnologias de Voz sobre IP como Asterisk e OpenSER, e também de quebra inclui o Linux.
Prezado Leitor, a proposta desse Blog é compartilhar conhecimento com as pessoas que trabalham com Linux, Asterisk, OpenSER, e com tecnologia de voz sobre a rede IP em geral, através de tutoriais, dicas, howto, notícias entre outros assuntos.
Atente para termo de uso do conteúdo do blog no rodapé da página.
07 junho 2010 - Shenzhen, China - OpenVox Communication Co. Ltd., um fornecedor global de soluções de hardware e software para telefonia open source em Asterisk®, anunciou hoje que o primeiro projeto industrial da placa-mãe IPC100 embedded da indústria para Asterisk foi liberado à comunidade Open Source. As placas-mãe da série IPC100 pode funcionar perfeitamente com os cartões Mini PCI A400M/B100M/B200M/B400M da OpenVox, bem como com qualquer combinação para construir um IPABX embarcado completo.
As placas-mãe IPC100 da OpenVox são placas com fator forma pequeno (15cm*15cm) otimizadas para IPABX e aplicações de segurança de rede. O projeto sem ventoinha, potência nominal muito baixa igual 6W, permite maior confiabilidade ao sistema e capacidade para operar em ambientes industriais agressivos. Integrada com até 3 portas Ethernet, as placas-mãe IPC100 fornecem uma opção flexível para diferentes aplicações dos usuários. Com os cartões Mini-PCI da OpenVox, pequenas e médias empresas podem facilmente ter os seus sistemas telefônicos montados sobre a IPC100. Instalando dois cartões B400M OpenVox na IPC100, os usuários podem ter até 100 chamadas simultâneas em um único sistema.
"Nem sempre é tarefa fácil conseguir uma placa-mãe que possa funcionar com Asterisk e outros softwares open-source de telefonia. O lançamento das placas-mãe embarcadas IPC100 OpenVox quebrou esse mito!", Disse Lin Miao, o presidente da OpenVox, "As placas-mãe da série IPC100 foram projetadas especialmente para o Asterisk®. Elas são placas-mãe que devem-funcionar-com-Asterisk em sistemas embarcados. Ao equipar a placa-mãe IPC100 com processadores de baixo consumo de energia e de alto desempenho, nós estamos introduzindo a primeira placa-mãe Embarcada da indústria para o Asterisk® com Selo Verde para a nossa comunidade Open Source".
As placas-mãe IPC100 OpenVox vêm com processadores Intel® Atom da série Z5XXP mais recente de até 1,6 GHz. A memória de sistema pode ser equipada com soquete SDRAM 200 com pinos DDR2 400/533 (até 2 GB). Há combinações flexíveis de armazenamento de dados para IPC100 como Compact Flash, de 44 pinos cabeçote IDE e conector SATA que pode atender às demandas de quaisquer sistemas operacionais e aplicativos. Além disso, ela consiste de dois soquetes Mini-PCI que permitem aos usuários combinar quaisquer cartões Mini-PCI da OpenVox, cartão LAN wireless Mini PCI e outras expansões facilmente.
A IPC100 suporta os softwares PABX mais populares como o Asterisk®, Askozia®, Elastix, FreePBX, FreeSWITCHTM, ISDN4BSD, PABX em Flash, trixbox®, pfSense e assim por diante.
O Google anunciou nesta terça-feira, 18, a compra da Global IP Solutions, empresa norueguesa de telefonia via internet (VoIP) e vídeo on-line, por US$ 68,2 milhões. De acordo com observadores do mercado, a aquisição vai permitir uma concorrência mais direta do site de busca com o Skype e operadoras tradicionais de telecomunicações. O acordo também dá ao Google uma tecnologia própria para disputar com os serviços de mensagens instantâneas rivais, como o Yahoo, AOL e Baidu.
Em comunicado, o Google informou que a cifra representa um prêmio de 27,5% sobre o preço de fechamento da ação da companhia na Bolsa de Oslo, na Noruega, no dia 14 de maio, data anterior a conclusão do acordo. O valor significa ainda um prêmio de 54,6% em relação ao preço médio das ações da empresa norueguesa nos últimos três meses.
A conclusão do negócio está sujeita a aprovação dos detentores de ao menos 90% das ações da Global IP Solutions. Segundo o Google, o negócio não necessita do sinal verde de órgãos reguladores. A empresa disse ainda que caso a oferta não satisfaça os acionistas ou estes renunciem a ela até o dia 31 de agosto, a proposta será anulada.
Um documento de oferta de compra das ações começará a ser distribuído aos acionistas no dia 20 deste mês. A proposta foi recomendada pelo conselho de administração da Global IP Solutions e, segundo o Google, alguns acionistas, incluindo a Kistefos AS e Venture Capital Kistefos, que detêm cerca de 50% das ações da empresa, se mostraram propensos a aceitar a proposta
Endereços de internet estão se esgotando, diz presidente da Icann
da Reuters, em Moscou
O mundo logo esgotará o número de endereços de internet disponíveis, por conta da explosão no número de aparelhos conectados com a web, a menos que as organizações adotem uma nova versão do Internet Protocol, declarou o presidente da organização que aloca os endereços IP.
Rod Beckstrom, o presidente da Icann, disse que apenas 8% a 9% dos endereços ipv4 ainda estão disponíveis, e que as companhias precisam adotar o novo padrão ipv6 o mais rápido possível.
"Estão se esgotando", declarou em entrevista. "A mudança realmente precisa ser realizada; estamos chegando ao final de um recurso escasso."
Mundo logo esgotará o número de endereços de internet disponíveis, por conta do número de aparelhos na web. Governo e outras organizações internacionais serão capazes de designar funcionários para um comitê de diretores da Icann.
O ipv4, usado desde que a internet se tornou pública, nos anos 80, foi criado com espaço para apenas alguns bilhões de endereços, enquanto a capacidade do ipv6 é da ordem dos trilhões.
Uma multiplicidade de aparelhos, entre os quais câmeras, players de música e consoles de games, estão se somando aos computadores e celulares na conexão à web, e cada um deles precisa de um endereço IP próprio.
Hans Vestberg, presidente-executivo da fabricante de equipamentos para telecomunicações Ericsson, previu no começo do ano que haveria 50 bilhões de aparelhos conectados, até 2020.
Beckstrom disse que "é uma grande tarefa administrativa e de operações de rede... mas terá de ser realizada, porque nós, seres humanos, estamos inventando tamanho número de aparelhos que usam a internet, agora."
Beckstrom estava em Moscou para a entrega formal do primeiro nome de domínio internacional em alfabeto cirílico para a Rússia. Em lugar de ter de usar o domínio ".ru", expresso no alfabeto latino, as organizações russas agora poderão empregar seu equivalente em cirílico.
A Icann aprovou a introdução gradual de nomes de domínio internacionalizados no ano passado. Países podem solicitar nomes de domínio nacionais em outras formas de alfabeto, como o arábico ou o chinês, e isso no futuro será expandido para todos os nomes de domínio da internet.
Até o momento, Rússia, Egito, Arábia Saudita e Emirados Árabes Unidos obtiveram aprovação da Icann para usar seus alfabetos nacionais no domínio de primeiro nível, a parte do endereço que vem depois do ponto.
Nessa seção nós vamos descrever os mecanismos de autenticação utilizados em redes baseada no SIP. Primeiro vamos descrever os conceitos básicos da autenticação Digest, porquanto nas próximas seções vamos dar uma breve visão geral de como a Autenticação Digest se aplica às mensagens SIP, quando ela deve ser ou não usada.
Visão Geral daAutenticação Digest
A Autenticação Digest é um mecanismo de autenticação simples desenvolvido originalmente para o protocolo HTTP (que é frequentemente chamado de HTTP digest) que está descrito na RFC2671. O mecanismo de autenticação é muito simples. É baseado em hashes criptográficas para evitar a transferência de senha do usuário em texto claro.
A autenticação Digest verifica isso se ambas as partes que se comunicam conhecem um segredo (secret) comum (uma senha).
Quando um servidor quer autenticar um usuário, ele gera desafio digest e o envia ao usuário. Um desafio digest típico se parece com isso:
Ele consiste de um conjunto de parâmetros que são enviados ao usuário. O usuário então usa esses parâmetros para gerar a resposta digest adequada e a devolve ao servidor. O significado dos parâmetros no desafio digest é o seguinte:
realm: O parâmetro realm é obrigatório e precisa estar presente em todos os desafios.
Seu objetivo é identificar credenciais dentro de uma mensagem SIP. No caso do SIP, ele é normalmente definido igual ao domínio do servidor proxy no qual é responsável.
Agentes usuários SIP são supostos exibir o conteúdo do parâmetro ao usuário quando eles os perguntam pelo nome e senha de usuário de sorte que ele possa usar o nome e senha de usuário apropriados (desse servidor).
nonce: é uma string de dadosespecificada pelo servidor que é gerada exclusivamente toda vez que um servidor lança um desafio digest. O parâmetro nonce é construído geralmente igual ao hash MD5 a partir de alguns dados. Os dados geralmente inclui carimbo de tempo e uma frase secreta do servidor gerador. Isso garante que cada tagnonce tenha vida útil limitada (ou seja, expira depois de algum tempo e não pode ser mais usada depois) e também é única (isto é, nenhum outro servidor será capaz de gerar o mesmo nonce).
Os clientes usam o parâmetro nonce para gerar uma resposta digest e, portanto, o servidor receberá de volta o conteúdo nonce em umaresposta digest. Ele geralmente verifica a validade da tag nonce antes que ele possa verificar o resto da resposta digest.
Dessa forma, basicamente, nonce é uma espécie de identificador que garante que as credenciais digest recebidas foram realmente geradas por um desafio digest particular, e também limita a vida útil da resposta digest, evitando assim ataques de repetição futuros.
opaque: é uma string de dados opaco passado ao usuário em um desafio. O usuário passará de volta a string de dados ao servidor em uma resposta digest. Isso permite que servidores não mantenham estado. Se houver algum estado que necessita ser mantido entre o desafio e a resposta, eles podem passá-lo ao cliente usando esse parâmetro e o lê novamente depois, quando uma resposta digest chegar.
algorithm: algoritmo usado para calcular hashes. Atualmente só o MD5 é suportado.
qop: A qualidade da proteção. O parâmetro especifica quais os esquemas de proteção o servidor pode suportar. Um cliente vai escolher um da lista. O valor auth "indica apenas autenticação", já o valor auth-int "indica autenticação com alguma proteção de integridade". Para uma descrição mais detalhada, consulte RFC2617.
Após receber o desafio digest, um agente usuário perguntará ao usuário pelo username e senha (se não estiver pré-configurado), gera uma resposta digest e enviar a resposta ao servidor. A resposta digest pode ter essa aparência:
Como podemos ver, a resposta digest é similar ao desafio digest. Aqueles parâmetros que são iguais possuem o mesmo significado de antes quando do desafio digest. Nós vamos descrever apenas os novos parâmetrosbrevemente:
uri - O parâmetro contém a URI que os clientes desejam acessar.
qop - O nível de proteção escolhida pelo cliente.
nc - Contagem de nonce, o valor é o número de contagem hexadecimal do número de requisições (incluindo a requisição atual) que o cliente tem enviado com o valor nonce nessa requisição. Por exemplo, na primeira requisição enviada em resposta a um determinado valor nonce, o cliente envia "nc=00000001". O objetivo dessa diretiva é permitir ao servidor detectar repetições de requisições, mantendo sua própria cópia dessa contagem - se o mesmo valor for visto duas vezes, então a requisição é uma repetição.
cnonce - O valor é um valor string opaco marcada fornecida pelo cliente e usado tanto pelo cliente quanto pelo servidor para evitar ataques devido a escolha de texto plano, para fornecer autenticação mútua, e fornecer alguma proteção de integridade da mensagem.
response - Uma string computada pelo agente usuário que tenta provar que o usuário conhece uma senha.
Quando da recepção de uma resposta digest, o servidor recalcula o valor do parâmetro response para fins de comparação, usando os atributos fornecidos pelo cliente e a senha armazenada no servidor. Se o resultado for idêntico a resposta recebida do cliente, então, o cliente provou conhecer a senha e ele é autenticado.
Autenticação Digest e o SIP
Nós temos descrito em como o desafio e a resposta digest se parecem, mas ainda não descrevemos como são usados em mensagens SIP. Como o mecanismo de autenticação foi originalmente desenvolvido para o protocolo HTTP e como o SIP é muito semelhante a esse protocolo, mapear desafio e resposta digest para as mensagens SIP é tarefa fácil e simples. Ela é descrita na RFC3261.
Quando um servidor SIP recebe uma requisição SIP e quer verificar a autenticidade do usuário antes de processar as requisições, ele examina se a requisição contém credenciais digest. Se não houver credenciais na requisição SIP, ele vai gerar uma resposta negativa final e incluir o desafio digest na resposta.
Quando um cliente recebe a resposta (contendo o desafio digest), é suposto que ele vai calcular uma resposta digest adequada e envia novamente a requisição, dessa vez incluindo as credenciais digest que foram calculadas.
O servidor então verifica a resposta digest e processa a requisição quando a verificação for bem sucedida.
Os servidores proxy usam aresposta "407 Proxy Authentication Required" e incluem o desafio digest no campo do cabeçalho "Proxy-Authenticate". Um exemplo de tal desafio pode ter essa aparência:
Agentes usuários SIP (incluindo registradores e agentes usuários back-to-back) usam aresposta "401 Unauthorized" para o desafio digest. Um exemplo de tal desafio poderia ser:
Respostas 407 são usadas pelos elementos SIP (principalmente servidores SIP proxy), que não sejam o destino final para a requisição e após a autenticação irá encaminhar outras requisições. Respostas 401 são usadas pelos elementos SIP que sejam o destino final para a requisição e após a autenticação irá gerar uma resposta final.
Quando incluindo a resposta digest os clientes adicionam o campo cabeçalho "Authorization" ou "Proxy-Authorization" que contém a resposta digest. O exemplo seguinte mostra uma mensagem REGISTER que contém credenciais digest.
Nós descrevemos em como autenticação digest se parece e como desafios e respostas digest são aplicadasem mensagens SIP. Nesse capítulo, nós vamos estudar quais mensagens SIP podem ou não ser desafiadas. Nós iremos descrever também duas situações mais comuns em que a Autenticação Digest é usada.
Quando um agente usuário SIP recebe um desafio digest, é suposto re-enviar a mesma requisição de novo, mas dessa vez com as credenciais digest apropriadas. Isso também significa que o agente usuário precisa incrementar o número CSeq na requisição a fim de evitar tratar a nova requisição como uma retransmissão pelo servidor.
Como desafiar uma requisição significa que a requisição será enviado novamente com CSeq superior, não é possível desafiar requisições ACK e CANCEL. Ambas as requisições precisam ter o mesmo CSeq que da requisição inicial e, portanto, não podem ser desafiadas.
Todas as outras requisições podem ser desafiadas, embora de tempos em tempos surjam implementações que parecem ter problemas com o desafiar requisições SIP nãomuito comuns.
Há dois casos em que são implementados frequentemente e merece uma descrição mais detalha: autenticação de mensagens REGISTER e autenticação de mensagens INVITE. Nós vamos descrevê-las em partes separadas.
Autenticação de Registro
Autenticação de mensagens REGISTER é muito importante e precisa ser feita por cada servidor SIP proxy. Com mensagens REGISTER SIP, agentes usuários estão informando ao servidor de sua localização atual de sorte que o servidor sabe onde enviar as demais requisições.
Se um servidor não autenticar requisições REGISTER então qualquer um pode registrar qualquer contato para algum usuário, assim seqüestrando chamadas dessa pessoa. Autenticação é obviamente muito importante para proteger contra isso e, portanto, a autenticação de mensagens REGISTER deve estar sempre habilitado.
Autenticação de Invite
Autenticação de requisições INVITE realmente não é necessária, mas é uma boa prática fazê-lo. Um servidor SIP proxy pode apenas desafiar requisições que são provenientes de usuários que pertencem a um domínio administrativo pelo qual o servidor proxy é responsável. Isso significa que um proxy responsável, por exemplo, pelo domínio iptel.org só pode desafiarrequisições que tenha iptel.org no campo cabeçalho "From".
Requisições provenientes de usuários estrangeiros não podem ser desafiados, porque os usuários estrangeiros geralmente não possuem um nome e senha (username e password) de usuário registrados nesse servidor. Exigência de autenticação tornará impossível chamadas entrantes de usuários estrangeiros.
Script Perl de Register SIP
O script seguinte pode ser usado para resolução de problema. Ele fará um registro SIP em algum Servidor SIP Proxy:
sh: highlight: command not found
Você precisará especificar uma linguagem como essa: ...
