Avaliação de desempenho do PBX Asterisk

Luís António Pereira de Sousa

Dissertação para obtenção do Grau de Mestre em

Engenharia de Redes de Comunicações

Júri

Presidente: Prof. Luís Eduardo Teixeira Rodrigues

Orientador: Prof. Paulo Rogério Barreiros D'Almeida Pereira

Vogal: Prof. Fernando Corte-Real Mira da Silva

Setembro 2008�

��

�

Resumo

Actualmente, as centrais telefónicas ou PBX (Private Branch eXchange) são uma ferramenta quase indispensável no mundo empresarial. As centrais telefónicas permitem aos colaboradores efectuar ligações entre telefones internos, ou ainda efectuar chamadas para a rede externa. Com o aumento de utilização da Internet, existe o interesse em perceber quais os serviços oferecidos, saber como configurar e avaliar o desempenho de um PBX com suporte para voz sobre IP (VoIP). O Asterisk é um PBX open source e gratuito, em software, para Linux, que suporta múltiplos protocolos (SIP, SCCP, H.323, IAX2, etc).

O principal foco da dissertação incide sobre o software Asterisk, que é descrito em detalhe. São dadas instruções para a sua configuração e apresentados resultados de testes realizados com várias configurações, tendo em vista a avaliação do desempenho.

São ainda descritos os aspectos fundamentais sobre o VoIP, e analisadas algumas ferramentas para análise de tráfego IP.

Conclui-se que para um computador com um CPU a 2.6 GHz são obtidos valores capazes de satisfazer algumas empresas de dimensão baixa ou média, o PBX Asterisk pode suportar cerca de 125 chamadas G.711 ponto a ponto em simultâneo. Se houver transcodificação, o consumo de CPU aumenta e este valor baixa no pior caso 75%, para 25 chamadas simultâneas.

Uma série de outros serviços são possíveis implementar no PBX Asterisk, dos quais foram testados as chamadas em conferência, e chamadas de resposta interactiva.

Com recurso ao codec G.711 é possível efectuar uma chamada em conferência com 90 participantes, sendo o número total de chamadas simultâneas reduzido quando outras chamadas em conferência surgem, bem como no caso de se utilizar codecs mais complexos.

O número máximo de chamadas suportadas pelo sistema está assim fortemente dependente dos codecs que são utilizados e consequentemente a capacidade de processamento do computador onde está instalado o PBX Asterisk.

Palavras-chave: Voice over IP (VoIP), Asterisk, PBX, SIP.

���

�

Abstract

Currently PBX (Private Branch eXchange) are an almost indispensable tool in the enterprise world. The PBXs allow collaborators to make connections among the internal telephones of an enterprise and also connect them to the public switched telephone network (PSTN). With the increased use of Internet, there is a need to understand what are the services offered, how to configure and evaluate the performance of a PBX with support for voice over IP (VoIP). The Asterisk PBX is a cost free and open source software for Linux, which supports multiple protocols (SIP, SCCP, H.323, IAX2, etc).

The main focus of this thesis is the Asterisk software, which is described in detail. Instructions about installation and configuration are given and results of tests with various configurations with the aim of evaluating the performance of the Asterisk PBX are presented.

The key issues of VoIP are described, and some tools for analyzing IP traffic are examined.

We conclude that to a computer with a 2.6 GHz CPU the values obtained are able to meet some low and medium enterprises, the Asterisk PBX may support 125 point to point G.711 calls simultaneously. In case of transcoding, the consumption of CPU increases and that value decrease 75 % to 25 calls in worst case.

A great number of other services are possible to implement in Asterisk PBX, which were tested the conference calls and Interactive voice Response (IVR).

Using the G.711 codec, it´s possible a conference call with 90 users, with the total number of simultaneous calls reduced when other conference call arise, as well as in the case of using more complex codecs.

The maximum number of calls supported by the system is so heavily dependent on the codecs that are used and hence the ability of processing of the computer where Asterisk PBX is installed.

Keywords: Voice over IP (VoIP), Asterisk, PBX, SIP.

����

�

Índice

Resumo…………………………………………………………………………………………………….i

Abstract…………………………………………………………………………………………………….ii

Siglas……………………………………………………………………………………………………….iv

1 Introdução .................................................................................................................................. 1

2 Voice Over Internet Protocol (VoIP)........................................................................................... 2

2.1. Protocolos .......................................................................................................................... 3

2.1.1. SIP............................................................................................................................... 3

2.1.2 SDP.............................................................................................................................. 7

2.1.3 RTP: ............................................................................................................................. 8

2.2 Codecs ................................................................................................................................ 9

2.3 Terminais Utilizador .......................................................................................................... 10

2.4 Gateway/Gatekeepers VoIP ............................................................................................ 12

2.5 Servidor VoIP / IP PBX .................................................................................................... 12

3 PBX Asterisk ............................................................................................................................ 13

3.1 Características do PBX Asterisk ....................................................................................... 13

3.2 Arquitectura detalhada...................................................................................................... 14

3.3 Estrutura de organização e configuração de ficheiros...................................................... 15

4 Requisitos de sistema e considerações necessários para implementar o PBX Asterisk........ 18

5 Software para análise e captura de tráfego ............................................................................. 20

6 Avaliação de desempenho PBX Asterisk................................................................................. 22

6.1 Chamadas ponto a ponto.................................................................................................. 22

6.2 Chamadas em conferência ............................................................................................... 36

6.3 Interactive Voice Response (IVR)..................................................................................... 44

6.4 Análise global de resultados ............................................................................................. 54

7 Conclusão e trabalhos futuros…………………………….…………………………………………55

Referências ................................................................................................................................. 57

���

�

Siglas

AGI Asterisk Gateway Interface

ATA Analog Telephone Adaptor

HTTP Hyper Text Transfer Protocol

IETF Internet Engineering Task Force

ISDN Integrated Services Digital Network

ITU International Telecommunication Union

ITU-T ITU Telecommunication Standardization Sector

IVR Interactive Voice Response

MOS Mean Opinion Score

NAT Network Address Translation

PBX Private Branch eXchange

PSTN Public Switched Telephone Network

QoS Quality of Service

RTCP RTP Control Protocol

RTP Real-time Transport Protocol

SDP Session Description Protocol

SIP Session Inititation Protocol

SER SIP Express Router

SMTP Simple Mail Tranfer Protocol

UAC User Agent Client

UAS User Agent Server

UDP User Datagram Protocol

URI Uniform Resource Identifier

VoIP Voice over IP

��

�

1 Introdução �

O aumento da utilização da Internet fez com que surgissem várias tecnologias de voz sobre IP (VoIP). Em relação à telefonia tradicional (comutação de circuitos), o VoIP é actualmente mais escalável, permite a integração de novas funcionalidades e a possibilidade de redução de custos. Na perspectiva das redes de dados, o VoIP vem tornar a voz em “apenas” mais uma aplicação.

Em relação a uma central telefónica tradicional, uma central telefónica VoIP permite para além das funcionalidades tradicionais, novas funcionalidades como por exemplo, conectar colaboradores a trabalhar a partir de casa com a central telefónica do escritório sobre conexões de banda larga, conectar facilmente escritórios em localizações geográficas distintas, oferecer voicemail integrado com o email. Sendo estas funcionalidades realizadas com recurso à Internet ou através de uma rede IP privada.

Nesta tese são analisadas, com algum detalhe, questões que devem ser levadas em consideração para se implementar um sistema PBX (Private Branch eXchange) VoIP, mais concretamente o PBX Asterisk, bem como questões sobre a avaliação do seu desempenho.

O Asterisk é um PBX, em software open source e gratuito, para Linux, que suporta múltiplos protocolos (SIP, IAX, H.323, etc). O Asterisk permite tanto a utilização de telefones em software como dispositivos telefónicos VoIP.

São apresentadas várias configurações para o PBX Asterisk, utilizando vários cenários de utilização: chamadas ponto a ponto, chamadas em conferência e chamadas de resposta interactiva (interactive voice response, IVR).

Entende-se por chamada ponto a ponto a situação em que um utilizador (emissor da chamada) telefona para outro utilizador (receptor da chamada) e estabelecem uma chamada telefónica, sendo estes os únicos intervenientes da chamada, para além do PBX Asterisk. Numa chamada em conferência, a chamada pode ter vários interlocutores, permitindo a qualquer altura a sua entrada ou saída, desde que a conferência esteja activa. No cenário de chamadas de resposta interactiva, IVR, o PBX Asterisk tem a capacidade de atender as chamadas e interagir com o interlocutor através de áudio pré-gravado, permitindo, por exemplo, instruir o interlocutor das acções a tomar.

É analisado o desempenho do PBX Asterisk consoante o tipo de codificação de som utilizada, número de chamadas em simultâneo, nos vários cenários. São medidos parâmetros como: a carga na rede, utilização de recursos computacionais (cpu e memória) e tempo de resposta do PBX Asterisk.

A dissertação está organizada da seguinte forma. O próximo capítulo apresenta uma introdução do VoIP e às tecnologias associadas. O capítulo 3 descreve em detalhe o que é o PBX Asterisk e os componentes que o constituem. O capítulo 4 apresenta os requisitos necessários para se implementar o PBX Asterisk, e apresenta algumas considerações úteis. O capítulo 5 apresenta uma descrição sobre o tipo de software necessário para análise e captura de tráfego IP, bem como a apresentação de alguns exemplos. O capítulo 6 apresenta a avaliação de desempenho do PBX Asterisk e os resultados obtidos para os vários cenários de teste. No capítulo 7 são apresentadas as conclusões sobre os resultados obtidos e que trabalhos futuros são relevantes para complementar esta dissertação.

��

�

2 Voice Over Internet Protocol (VoIP)�

Voz sobre IP, ou VoIP, pode ser definido com um conjunto de tecnologias e componentes que, em conjunto, disponibilizam ao utilizador a possibilidade de estabelecer chamadas de voz através de uma rede de comutação de pacotes IP.

O uso do VoIP permite a utilizadores de redes de comutação de pacotes IP efectuar chamadas de voz para outros utilizadores VoIP e/ou para telefones tradicionais (PSTN - Public Switched Telephone Network). Através do VoIP é possível obter vários serviços adicionais para além de chamadas de voz, como voice mail, fax, IVR (Interactive Voice Response), chamadas em conferência, instant messaging, etc.

Por forma a possibilitar a existência destes serviços, estão definidos vários protocolos, dos quais se destacam o SIP (Session Initiation Protocol), um dos protocolos de sinalização mais utilizados em VoIP, e o RTP (Real Time Transport Protocol), que ajuda a assegurar a transmissão de pacotes em aplicações tempo real.

Os melhores resultados para o VoIP são garantidos utilizando redes de comutação de pacotes privadas (destinadas ao tráfego de voz), ou com recurso a fornecedores de serviços VoIP, sendo, neste caso, necessária ligação à Internet, preferencialmente de banda larga.

Para analisar de forma conveniente o desempenho de um software com suporte VoIP, como o PBX Asterisk, é necessário entender quais as condições de rede que podem afectar negativamente o desempenho para VoIP. Estas são principalmente a latência, o jitter e a perda de pacotes. A latência é o tempo que um pacote demora a viajar de um ponto A para um ponto B da rede. O jitter é a variação da latência sobre uma série de pacotes. A perda de pacotes é o número de pacotes enviados de um dado ponto A da rede que nunca alcançam o ponto B. Devido ao áudio em VoIP ser enviado em tempo real por UDP, um pacote que é recebido fora de ordem tem de ser descartado se um pacote posterior já tiver sido processado pelo receptor. [1][7]

Neste capítulo serão descritos os principais componentes VoIP, tais como o protocolo de sinalização de chamadas SIP, o protocolo de descrição de sessões, SDP, e o protocolo de transmissão de dados em tempo real, RTP. São descritos os vários tipos de terminais utilizador existentes, a importância dos codecs em VoIP, bem como outros componentes essenciais.

��

�

2.1. Protocolos

2.1.1. SIP O protocolo de iniciação de sessão SIP (Session Initiation Protocol) é um protocolo de sinalização que opera na camada de aplicação e é desenvolvido pelo Internet Engineering Task Force (IETF)(RFC 3261)[2]. O SIP permite a criação e gestão de sessões de comunicação interactivas, como voz, vídeo e mensagens de texto sobre rede IP, tipicamente sobre UDP ou TCP, onde uma sessão é considerada como troca de dados entre uma associação de participantes. Possibilitando a entrada de participantes para uma sessão estabelecida, como conferências em multicast.

O protocolo SIP é inspirado noutros protocolos de Internet com um modelo de transacção do tipo pedido/resposta semelhante ao HTTP e SMTP. Cada transacção consiste num pedido que invoca um método particular, ou uma função, no servidor e pelo menos uma resposta.

O SIP é um componente que pode ser usado com outros protocolos para construir uma arquitectura multimédia. Tipicamente, estas arquitecturas incluem protocolos como o Real-time Transport Protocol (RTP) (RFC 1889) para transporte de dados tempo real e providenciar feedback acerca da qualidade de serviço (QoS) e o Session Description Protocol (SDP) que serão descritos mais à frente.

Exemplo de cenário SIP

O exemplo seguinte mostra as funções básicas do SIP, num cenário típico, em que existe um terminal que deseja comunicar com outro, sendo necessários parâmetros de negociação de uma sessão, estabelecimento da sessão e, por fim, o encerramento da sessão.

A figura 1 mostra este exemplo típico com uma troca de mensagens SIP entre dois utilizadores, Alice e o Rui. (Cada mensagem está identificada com a letra "F" e um número para referenciar a partir do texto). Neste exemplo, Alice utiliza uma aplicação SIP no seu PC (referido como Softphone) para efectuar uma chamada para o Rui no seu telefone SIP, através da Internet. Existem ainda dois servidores proxy's SIP que actuam em nome da Alice e do Rui de forma a facilitar o estabelecimento da sessão.

��

�

Figura 1. Cenário exemplo, sessão SIP entre a Alice e o Rui.

Descrição do cenário:

A Alice telefona ao Rui (através de um softphone) utilizando a sua identidade SIP, um tipo de Uniform Resource Identifier (URI) chamado SIP URI. O SIP URI tem uma forma similar a um endereço de e-mail, tipicamente contendo o username e o hostname do utilizador. Neste caso será sip:rui@inesc.pt, onde inesc é o domínio do SIP service provider (fornecedor do serviço SIP) do Rui. A Alice tem o SIP URI sip:alice@ist.utl.pt. No exemplo da figura 1, a transacção começa quando o softphone da Alice envia um pedido INVITE endereçado para o SIP URI do Rui. INVITE é um exemplo de um método SIP que especifica a acção que o pedinte (Alice) pretende que o receptor (Rui) aceite. O pedido INVITE contém um número com os campos do cabeçalho. Os campos do cabeçalho fornecem informação adicional sobre as mensagens. Os campos presentes num INVITE incluem um identificador único da chamada, o endereço de destino, e informação sobre os tipos de sessão que a Alice gostaria de estabelecer com o Rui.

O INVITE (mensagem F1 na figura 1) será semelhante ao apresentado na figura 2:

��

�

Figura 2 – Exemplo de uma mensagem INVITE.

Arquitectura SIP

Os elementos básicos do SIP são os user agents, proxies, registrars, e redirect servers. Estes elementos são normalmente entidades lógicas. Sendo vantajoso localizá-los no mesmo computador, permitindo assim uma maior velocidade de processamento, no entanto a sua localização pode depender duma implementação e configuração em particular.

Descrição dos principais elementos SIP:

- User Agents:

User agents podem ser definidos como terminais IP que utilizam SIP para se encontrarem mutuamente e negociarem as características para se estabelecer uma sessão. User agents podem residir nos computadores dos utilizadores sobre a forma de uma aplicação ou em telemóveis, PSTN gateways, PDAs, sistemas de atendimento automático, como IVR, entre outros.

Cada User Agent é constituído por duas entidades lógicas, o User Agent Server (UAS) e o User Agent Client (UAC). UAC é a parte do user agent que envia pedidos e recebe respostas. UAS é a parte do user agent que recebe pedidos e envia respostas. Por exemplo, quando uma entidade está a iniciar uma chamada, o user agent comporta-se como UAC quando envia o pedido INVITE e recebe respostas ao pedido. Para quem recebe uma chamada, o user agent comporta-se como UAS aquando da recepção de um pedido INVITE e envia respostas.

- Proxy servers:

Na infra-estrutura de rede de um host pode ser criado um proxy server. Os proxy servers actuam como um programa intermediário, permitindo que os pedidos sejam servidos internamente ou passem para o exterior após tradução para outros servidores. Uma das funcionalidades é mapear endereços de email para uma extensão do PBX para cada chamada.

Um proxy server fornece ainda mecanismos de autenticação, de contabilidade, entre outras funções relevantes.

INVITE sip:rui@inesc.pt SIP/2.0

Via: SIP/2.0/UDP pc33.ist.utl.pt;branch=z9hG4bK776asdhds Max-Forwards: 70

To: Rui sip:rui@inesc.pt From: Alice <sip:alice@ist.utl.pt>;tag=1928301774

Call-ID: a84b4c76e66710@pc33.ist.utl.pt CSeq: 314159 INVITE

Contact: sip:alice@pc33.ist.utl.pt Content-Type: application/sdp Content-Length: 142

(SDP da Alice não apresentado)

�

�

- Registrar:

O Registrar é uma entidade SIP que recebe registos de utilizadores, extrai informação acerca da sua localização actual (endereço IP, porto, nome de utilizador, entre outros) e guarda a informação numa base de dados de localização. O propósito da base de dados de localização é fazer o mapeamento de sip:rui@inesc.pt para algo como sip:rui@1.2.3.4:5060 por exemplo.

A base de dados de localização será então usada pelo proxy server de inesc.pt. Quando o proxy recebe um pedido INVITE para sip:rui@inesc.pt a tradução do endereço será procurada na base de dados, após encontrar o endereço real sip:rui@1.2.3.4:5060, o INVITE será enviado para lá.

Cada registo tem um tempo de vida limitado. O campo do cabeçalho “Expire” ou o parâmetro “expires” do campo “Contact” do cabeçalho determinará por quanto tempo o registo será válido. Assim, o user agent deve renovar o registo periodicamente, por forma a que não fique indisponível.

- Redirect Servers:

O Redirect Server, ou servidor de redireccionamento, é uma entidade SIP que recebe um pedido e envia de volta a resposta contendo uma lista com a localização/endereços do destinatário. A sua função é fornecer resolução de nomes e localização do utilizador, recorrendo à base de dados de localização criada pelo registrar. Desta forma, o cliente poderá contactar o endereço de um utilizador directamente.

O redirect server permite reduzir o processamento no proxy server que é responsável pelo encaminhamento dos pedidos e tornar mais robusto o encaminhamento da sinalização.

Figura 3. Exemplo de fluxo de pedido e resposta SIP numa chamada.

Na figura 3 são ilustrados os fluxos de mensagens SIP, existem vários tipos mensagem de pedido e mensagem de resposta, são descritos os principais, essências para efectuar chamadas VoIP quando se utiliza como protocolo de sinalização o SIP:

Pedidos SIP:

INVITE (convidar) - mensagem utilizada quando se pretende estabelecer uma sessão.

ACK (confirmar) - mensagem utilizada para confirmar a resposta final do pedido INVITE. Indica que o utilizador está disponível para comunicar.

BYE (despedir) - mensagem utilizada para desligar de forma ordeira uma sessão. O interveniente que pretende desligar a sessão envia uma mensagem BYE à outra parte.

�

�

CANCEL (cancelar) - mensagem utilizada para cancelar uma sessão que ainda não está confirmada. Tipicamente utilizado quando um pedido a resposta a um INVITE demora demasiado.

REGISTER (registo) - o propósito desta mensagem é informar o registrar acerca da localização do utilizador. Os dados indicados são o nome, endereço IP e porto.

Respostas SIP:

Quando um user agent recebe um pedido é devolvida sempre uma resposta, à excepção do pedido ACK.

O tipo de resposta é identificado por um número inteiro entre 100 e 699 e existem 6 classes de respostas:

1xx - respostas do tipo informativa, informa que o pedido associado foi recebido mas o resultado final ainda não é conhecido.

Tipicamente os proxy servers enviam a mensagem 100 quando se inicia o processo de INVITE e o user agent enviam a mensagem “180 Ringing” que significa que o telefone do receptor da chamada está a chamar (a tocar).

2xx - respostas finais positivas, ou de confirmação. Este tipo de resposta indica que esta será a última resposta acerca do pedido feito pelo originador, e que o pedido foi processado com sucesso e aceite. Por exemplo a mensagem “200 OK” é enviada quando um utilizador aceita o convite para uma sessão (pedido INVITE).

3xx - respostas em que o objectivo é redireccionar o originador da chamada. Uma resposta deste tipo informa acerca da nova localização do utilizador ou sobre um serviço alternativo que poderá satisfazer a chamada. Geralmente enviadas por proxy servers.

O originador da chamada deve reenviar um novo pedido para a nova localização.

4xx - respostas negativas, que indicam que um pedido não foi satisfeito. Informa que o problema está do lado do originador do pedido, ou este pedido não pode ser processado porque contém sintaxe incorrecta ou não pode ser satisfeita no servidor.

5xx - resposta que indica que o problema está no servidor. O pedido é aparentemente válido, mas o servidor falhou ao tentar satisfazê-lo.

6xx - respostas deste tipo indicam que um pedido não pode ser satisfeito em nenhum servidor. Por exemplo, um user agent pode enviar uma resposta “603 Decline” quando este não quer participar numa sessão.

2.1.2 SDP

O SDP (Session Description Protocol) é um protocolo que fornece uma representação standard para a descrição dos parâmetros de inicialização para uma sessão, como por exemplo, chamadas VoIP, streaming vídeo, teleconferências multimédia. Este protocolo foi publicado pela IETF como RFC

��

�

4566[3] e é apropriado para incorporar diferentes protocolos, como o SIP (Session Initiation Protocol), RTSP (Real Time Streaming Protocol), HTTP (Hypertext Transport Protocol), entre outros.

A negociação dos parâmetros para uma sessão, em termos de conteúdo ou codificação, está fora do âmbito da descrição de sessão feita pelo SDP.

Este protocolo é utilizado em SIP para se proceder à descrição de sessão, que permite aos participantes acordarem a compatibilidade dos tipos de dados a utilizar.

Uma descrição de sessão SDP deve conter a seguinte informação:

- O tipo de dados (vídeo, áudio, etc.) - O protocolo de transporte (RTP/UDP/IP, H.320, etc.) - O formato do tipo de dados utilizado (vídeo H.261, vídeo MPEG, etc.)

Adicionalmente ao formato dos dados e ao protocolo de transporte, o SDP requer o endereço e porto utilizados.

Uma descrição de sessão SDP consiste num conjunto de linhas de texto na seguinte forma:

<tipo>=<valor>

Exemplo de descrição SDP:

c=IN IP4 193.136.143.77 m=audio 38060 RTP/AVP 0

O exemplo mostra a informação, transmitida no payload de uma mensagem INVITE de SIP, para uma conexão de voz, que se pretende estabelecer. É indicado o endereço IP de origem, onde o emissor pretende receber a transmissão de voz e o tipo de dados (áudio), número do porto, protocolo e lista de formatos de dados suportados, segundo a sintaxe:

c=<network type> <address type> <connection address> m=<media> <port>/<number of ports> <transport> <fmt list>

Existem vários parâmetros para descrever uma sessão no caso de uma chamada VoIP (parâmetros opcionais marcados com “*”):

m= nome do media e endereço para transporte. i=* designação do media. c=* informação sobre a conexão. b=* informação sobre largura de banda. k=* chave de cifra a=* atributos do media.

2.1.3 RTP

O RTP (Real-time Transport Protocol), é um protocolo de rede da camada de aplicação utilizado para transferência de dados de tempo real, tais como áudio e vídeo. O RTP é geralmente o protocolo utilizado para transmitir o fluxo de voz para VoIP, oferecendo mecanismos de associação de

��

�

numeração de sequência, identificação do formato de codificação e informação temporal. O RTP deixa o processamento desta informação a cargo da aplicação, não oferecendo por si mecanismos de garantia de entrega, sequência ou QoS.

Este protocolo foi publicado pela IETF com o RFC 3550[4] e pode ser usado sobre qualquer protocolo de transporte, sendo normalmente utilizado sobre UDP, multicast ou unicast.

Associado ao protocolo RTP está associado o protocolo RTCP (RTP Control Protocol), utilizado para monitorizar a qualidade de serviço e para transmitir informações sobre os participantes numa sessão em curso.

A quantidade de largura de banda utilizada pelo RTCP deve ser pequena, de forma a não comprometer o transporte dos dados de tempo real. Especificações do IETF recomendam que a fracção de largura de banda usada pelo RTCP deve ser 5% da banda utilizada pelo RTP.

A mensagem RTP possui um cabeçalho com um mínimo de 12 bytes contendo informação referente aos dados contidos no pacote, sendo ainda necessário passar informação de controlo através dos cabeçalhos dos protocolos utilizados para transportar o pacote RTP.

No caso de se utilizar UDP, o pacote UDP (incluindo o pacote RTP) é encapsulado num pacote IP, possuindo por sua vez um cabeçalho do MAC (media access control) utilizado, conforme o exemplo da figura 3.

Figura 3. Ilustração de uma mensagem RTP.

2.2 Codecs No âmbito VoIP, codec (abreviatura de coder/decoder), pode ser definido como um algoritmo usado para codificar e descodificar fluxos de voz. A voz e o som como nós o ouvimos é analógico e tem de ser convertido (ou codificado) para o formato digital, de forma a poder ser transmitido numa rede de comutação de pacotes IP. Da mesma forma, no extremo oposto (receptor) é necessário descodificar a voz para que o utilizador possa ouvir o que foi transmitido. Existem diversas formas de codificar e descodificar os fluxos de voz, muitas das quais utilizam compressão de forma a reduzir a largura de banda necessária para uma conversação VoIP. Para possibilitar uma compressão elevada, torna-se necessário agrupar blocos de amostras e processar estes blocos. Estas duas operações introduzem atrasos na conversação. Um bom codec deve codificar e descodificar o fluxo de voz no menor tempo possível, mantendo a qualidade nos fluxos de voz. O objectivo dos vários algoritmos de codificação é alcançar o melhor compromisso qualidade/eficiência.

Dado que largura de banda é sempre finita, o número de chamadas de voz simultâneas que uma conexão permite está directamente relacionada com o tipo de codec utilizado.

Alguns codecs suportam a detecção/supressão de silêncio, permitindo uma diminuição na utilização da rede quando não há som para transmitir. Pode ser utilizada geração de ruído de conforto(Comfort Noise Generation), o “comfort noise” é utilizado para que os utilizadores não pensem que a chamada caiu. Geralmente corresponde a uma transmissão a um ritmo muito mais baixo.

� �

�

Existem vários codecs disponíveis, destacando-se: G.711, G.726, G.723.1, G.729A, GSM, iLBC, Speex, MP3.[5]

A tabela 1 mostra os parâmetros principais dos codecs utilizados em chamadas VoIP. A frequência de amostragem corresponde ao dobro da frequência mais elevada do som que pode ser reproduzida, de acordo com o teorema da amostragem. O atraso algorítmico corresponde ao atraso que obteríamos no som ligando directamente um codificador a um descodificador, se o processamento das amostras fosse instantâneo. O “Mean Opinion Score” corresponde à opinião média sobre a qualidade do som produzido pelo codec, sendo 5 o valor máximo e 1 o mínimo. A capacidade de processamento necessária para o codec funcionar é dada como o número de milhões de instruções por segundo.

Atraso algorítmico Processamento

Codec Algoritmo

Freq. amostragem (KHz)

Ritmo binário (kbit/s) (ms)

Mean Opinion Score (MIPS)

G.711 PCM 8 64 0.125 4.3 0.01

G.722 ADPCM 16 48/56/64 0.125 4.1 5

G.722.1 Siren7 16 24/32 40

G.723.1 ACELP 16 5.3/6.3 37.5 3.8 16

G.726 ADPCM 8 16/24/32/40 0.125 4.0 a 32 kbit/s

10

G.728 LD_CELP 8 16 0.625 3.9 30

G.729A ACELP 8 8 15 4.0 20

GSM-FR

RPE-LTP 8 13 20 3.5-3.9 5-6

GSM-EFR

ACELP 8 12.2 20 3.8

4.14 GSM-AMR

ACELP e outras

8 4.75-12.2 20-25

(a 12.2 kbit/s)

iLBC LPC 8 13.33/15.2 20-30 4.14 20

Speex CELP 8/16/32 2.15-24.6 30

Tabela 1. Síntese dos principais codecs utilizados em VoIP.[6]

2.3 Terminais Utilizador Os sistemas terminais VoIP, constituem a interface pessoa máquina, permitindo ao utilizador efectuar chamadas VoIP e utilizar todos os serviços disponíveis. [1][5][7][8]

Existem diversos tipos de terminais utilizador:

���

�

- ATA (analog telephone adaptor) - É um adaptador para telefones analógicos, que permite converter sinais analógicos para digitais. Permitindo assim ligar um telefone standard (analógico) a um computador ou à ligação de rede IP para utilizar VoIP.

Figura 4. Adaptador para telefones analógicos da marca Cisco.

- Telefones IP – Têm um aspecto semelhante aos telefones tradicionais (analógicos), mas ao invés de terem um conector RJ-11, os telefones IP têm um conector RJ-45 Ethernet, ou USB. Podem ser ligados directamente a um router e possuem todo o software e hardware necessário para efectuar uma chamada de voz sobre a rede IP.

Figura 5. Telefone IP da marca Cisco.

- Softphones – São aplicações software, que quando instaladas num computador permitem utilizar os serviços VoIP. Para além do software é necessário hardware adicional como: placa de som, dispositivos de saída áudio (altifalantes) e microfone, geralmente utiliza-se um headset ligado à placa de som. Neste caso os componentes de áudio in/out são utilizados para controlar a voz, ou seja, são a interface física do telefone.

Figura 6. Softphone xTen a correr em Windows XP.

���

�

2.4 Gateway/Gatekeepers VoIP Os gateways VoIP permitem que sejam efectuadas chamadas entre terminais que normalmente não poderiam inter-operar (SIP/ISDN, IPv4/IPv6, diferentes sistemas de codificação de voz). Os gateways mais utilizados são os que ligam telefones IP aos telefones tradicionais (comutação de circuitos).

Gatekeepers são responsáveis pela admissão de chamadas e controlo de largura de banda. [1][7]

2.5 Servidor VoIP / IP PBX Um Servidor VoIP/IP PBX é um sistema onde são processadas as chamadas de voz, bem como os serviços adicionais, como por exemplo: chamadas em conferência, integração do sistema de mensagens voicemail/e-mail, presença, redireccionamento/forking, IVR, instant messaging, etc. Estes serviços podem estar em máquinas diferentes. Um PBX (Private Branch Exchange ou ainda PABX para Private Automatic Branch Exchange) pode ser definido como um sistema de troca automática de ramais privados, e centro de distribuição telefónica privada, isto numa rede tradicional (circuitos comutados). De modo análogo, um IP PBX fornece todas as funções que um PBX tradicional oferece, mas neste caso também suporta VoIP. Um IP PBX é baseado em software, que pode correr em diversas plataformas, como Linux e Windows. [1][7]

���

�

3 PBX Asterisk

O Asterisk é um software open source gratuito para Linux, desenvolvido por Mark Spencer. Este software apresenta todas as funcionalidades de um PBX (Private Branch eXchange) tradicional, bem como funcionalidades adicionais como o IVR (Interactive Voice Response). O Asterisk é essencialmente um PBX VoIP que suporta múltiplos protocolos utilizados em VoIP (SIP, SCCP, H.323, IAX2, etc). Permite tanto a utilização de telefones em software como dispositivos telefónicos VoIP. Sendo também possível inter-operar com os sistemas de telefonia tradicionais, sendo neste caso necessário hardware adicional. [5][8][9][12][13]

3.1 Características do PBX Asterisk - Distribuição de chamada recebida:

O Asterisk permite receber uma chamada telefónica, olhar para os atributos da mesma e tomar decisões de encaminhamento com base no seu conteúdo. Exemplos de como encaminhar uma chamada podem ser: enviar para uma extensão única, um grupo de extensões, gravar a chamada, entre outros.

- Informação detalhada de chamada:

O Asterisk mantém o registo completo de detalhe de chamadas. Esta informação pode ser guardada num flat file, ou em base de dados permitindo uma apresentação mais formatada e com maior facilidade de análise. A partir desta informação podemos monitorizar a utilização do Asterisk, podendo detectar padrões ou anomalias.

- Sistema IVR:

O Asterisk permite configurar um sistema IVR (Interactive Voice Response), este permite que seja programado de forma flexível o atendimento de chamadas, de forma a dar algum tipo de resposta às mesmas sem interacção humana. Sendo o emissor da chamada a escolher uma das opções que lhe são expostas.

O Asterisk permite que este sistema reproduza ficheiros áudio, faça leitura de texto, e até devolver informação a partir de uma base de dados. Através do toque em teclas do telefone é possível interagir com sistema, por exemplo um sistema de votação via telefone, ou aceder a uma conta no banco, inserindo o número de conta e palavra secreta através do teclado, seguindo ordens do sistema telefónico.

- Sistema de correio de voz:

O Asterisk inclui um sistema de voice mail completo. São suportados contextos, permitindo que múltiplas entidades possam estar hospedadas no mesmo servidor. Suporta diferentes fusos horários permitindo aos utilizadores perceber quando as chamadas chegaram ao voice mail. Existe também a capacidade de notificar o destinatário sobre uma nova mensagem de voz por email, com a possibilidade de anexar a mensagem áudio gravada.

���

�

- SIP Proxy limitado:

Através do Asterisk podem ser efectuadas e recebidas chamadas SIP. Em SIP, os dispositivos registam-se num servidor SIP. E este servidor permite aos dispositivos localizarem-se mutuamente para estabelecer comunicações. Quando um número elevado de dispositivos SIP é utilizado, um proxy SIP é implementada para manipular os registos e conexões de forma eficiente. Contudo, o Asterisk, não actua como SIP Proxy. Os dispositivos SIP podem registar-se com o Asterisk, mas com o aumento do número de dispositivos SIP, o Asterisk não escala de forma conveniente. Por exemplo, para um sistema com cerca de 100 dispositivos SIP, o Asterisk não será apropriado.[8]

O Asterisk pode ser configurado para utilizar um proxy para registos. Um dos proxys SIP mais utilizadas é o SER (SIP Express Router).[21] O SER é um proxy SIP open source que permite ao Asterisk escalar em instalações de larga escala.

3.2 Arquitectura detalhada

O núcleo do Asterisk manipula os seguintes componentes internamente:

- PBX Switching:

A essência do Asterisk é o Private Branch Exchange Switching system, permitindo interconexão de chamadas para os vários utilizadores e automação de tarefas. O Switching Core conecta de forma transparente as chamadas efectuadas em várias interfaces hardware e software.

- Application Launcher:

O Application Launcher é responsável por lançar aplicações que executam serviços, como o voice mail e playback de ficheiros.

- Codec Translator:

O componente Codec Translator utiliza o módulo codec para codificar e descodificar vários formatos de compressão existente na indústria telefónica.

- Scheduler and I/O Manager:

Este componente é um calendarizador de input, output e é responsável por manipular as tarefas de baixo nível agendadas e pela gestão do sistema de forma a optimizar o desempenho para todas as condições de carga.

No Asterisk estão definidas quatro APIs para os módulos carregáveis, facilitando a abstracção ao nível de protocolos e hardware. Com os módulos carregáveis, o núcleo Asterisk não tem de se “preocupar” com os detalhes sobre como o emissor de uma chamada se está a conectar, que codec está a utilizar, etc.

- Channel API:

O Channel API manipula o tipo de conexões que o emissor de uma chamada efectua, seja esta uma conexão VoIP, ISDN, PRI, ou através de outra tecnologia. Módulos dinâmicos são carregados para manipular os detalhes da camada inferior destas conexões. Cada chamada em Asterisk é feita sobre uma interface num canal distinto.

���

�

- Application API:

A API de aplicação permite que várias aplicações como voice mail, chamada em conferência, transmissão de dados, chamada em espera, entre outras, sejam carregadas a partir de módulos específicos consoante a aplicação.

- Codec Translator API:

A API de tradução de codec’s, é responsável por carregar os módulos de codecs, tornando possível traduzir o sinal de voz a processar para outro formato desejado. Existem vários formatos de codificação áudio como o GSM, G.711, G.722, mp3, etc.

- File Format API:

A API de formato de ficheiros permite a manipulação de ficheiros de vários formatos para leitura e escrita, e para armazenamento de dados fisicamente no sistema. Por exemplo, ficheiros áudio podem ser utilizados como toques de chamada, para música em espera ou para utilizar no voice mail. O Asterisk permite ler e reproduzir sons em diferentes formatos entre os quais, WAV, AU, e MP3.

3.3 Estrutura de organização e configuração de ficheiros A flexibilidade do Asterisk é controlada através de ficheiros de configuração em formato ASCII, localizados na directoria /etc/asterisk. Estes ficheiros apresentam uma sintaxe fácil de entender. Tendo um formato muito similar ao formato win.ini utilizado no antigo Microsoft Windows 3.1.

Os ficheiros de configuração estão divididos em secções, em que o nome da secção se encontra entre parêntesis rectos. Um simples exemplo da sintaxe dos ficheiros de configuração é apresentado na figura 7.

Figura 7. Ficheiro de configuração exemplo.

Embora todos os ficheiros de configuração Asterisk partilhem a mesma sintaxe, existem pelo menos três grupos gramaticais distintos tipicamente usados:

Grupos simples: O formato de ficheiros de configuração nos grupos simples é o formato mais simples que podemos encontrar de entre os grupos gramaticais, no qual os objectos são declarados com todas as opções

; Um ficheiro de configuração deve ; começar pelo nome da secção ; excepto se for um comentário

[seccao1] identificador = valor ; atribuir valor a uma variável

[seccao2] identificador = valor objecto => valor ; declaração de objectos

�

��

�

na mesma linha. Fazem parte deste grupo os seguintes ficheiros: extensions.conf, meetme.conf, voicemail.conf, entre outros.

Entidades complexas: Neste grupo gramatical estão os ficheiros de configuração iax.conf, sip.conf. Neste tipo de ficheiros de configuração existem várias opções, que tipicamente não partilham configurações. As opções são então guardadas na declaração de uma secção específica, à qual chamamos contexto.

Herança de opções de objectos: Este formato é utilizado pelos ficheiros zapata.conf, phone.conf, mgcp.conf, alsa.conf, modem.conf, oss.conf e outras interfaces em que existem diversas opções, mas na maioria das interfaces ou objectos as opções partilham os mesmos valores.

Descrição dos principais ficheiros de configuração:

asterisk.conf

O ficheiro asterisk.conf contém informação relevante do sistema como:

- Localização das várias directorias utilizadas pelo Asterisk para armazenar os ficheiros de configuração, log, bibliotecas e scripts.

- Opções de linha de comando predefinidas.

modules.conf

No ficheiro de configuração modules.conf está contida a lista de módulos que devem ser carregados quando o Asterisk inicia.

logger.conf

No ficheiro logger.conf está a configuração sobre onde devem ser guardados os ficheiros de log e que nível de detalhe devem ter.

voicemail.conf

O ficheiro voicemail.conf é onde a configuração de parâmetros do sistema de correio de voz deve estar localizada, alguns parâmetros de caixas de correio de voz são: nome do utilizador da caixa de correio, endereço de email e número correspondente.

sip.conf

No ficheiro sip.conf estão localizados os parâmetros relacionados com a configuração SIP para o PBX Asterisk. Os clientes SIP devem estar configurados neste ficheiro de forma a poderem efectuar e receber chamadas através do Asterisk.

extensions.conf

O ficheiro extensions.conf contém os dial-plan, permitindo a configuração do dispositivo telefónico de cada utilizador, e contém as instruções para processamentos de chamadas e comportamentos predefinidos.

Neste ficheiro encontra-se uma entidade relevante do Asterisk, o dial plan.

��

�

O dial plan é responsável por encaminhar cada chamada no sistema, desde a origem através das várias aplicações, até ao destino final. Todas as aplicações, desde o voice mail, chamadas em conferência, IVR, etc. são configuradas no dial plan.

Figura 8. Sintaxe utilizada para o dial plan.

A figura 8 ilustra a sintaxe utilizada para o dial plan no ficheiro extensions.conf, em que o contexto é uma label definida pelo administrador do sistema que permite separar as extensões e pode ser descrito como contexto de extensões, cada contexto pode possuir um conjunto de extensões. Cada contexto num dado dial plan tem sempre um nome único associado. Exten: em Asterisk uma extensão é uma cadeia de caracteres, que acciona um aplicação através da execução de um <comando>. As extensões pertencem sempre a um determinado contexto. O campo <identificador> representa a cadeia de caracteres que identifica a extensão, nos telefones tradicionais é o número de telefone. No caso de uma extensão ter o mesmo identificador, um <comando> vai ser executado consoante a <prioridade> definida. A prioridade é representada através de um algarismo numérico, no qual o menor número representa a maior prioridade.

O <comando> representa o nome da aplicação a executar, uma aplicação específica executará uma acção no canal de voz, como sendo, reproduzir um som, correr o voice mail, atender a chamada, desligar a chamada, entre outras.

Na figura 9 é ilustrado um exemplo de um dial plan, em que existe um contexto com o nome “teste”, três extensões “1000”, neste caso o primeiro comando a ser executado será o “Answer”, pois apresenta o valor, prioridade, mais pequeno: “1”.

Figura 9. Exemplo de dial plan.

[<contexto>]

exten => <identificador>, <prioridade>, <comando>

[teste]

exten => 1000,1,Answer exten => 1000,2,Playback(goodbye) exten => 1000,3,Hangup

���

�

4 Requisitos de sistema e considerações necessários para implementar o PBX Asterisk O Asterisk é um software bastante flexível, sendo possível a sua instalação na maioria das distribuições Linux, bem como em grande parte de plataformas não Linux. Nesta secção são feitas algumas considerações que devem ser tidas em conta de forma a se obter um sistema fiável, robusto e eficiente.[5]

Os recursos necessários para o Asterisk são similares aos consumidos por uma aplicação embebida de tempo real. Isto deve-se à necessidade de acesso prioritário ao processador e ao bus do sistema. É também necessário que todas as tarefas a correr no sistema que não estão relacionadas com o processamento de chamadas do Asterisk, tenham prioridade baixa.

Quando a carga do sistema aumenta, este terá maiores dificuldades em manter conexões. Para um PBX, esta situação é desastrosa, os requisitos de desempenho são um factor crítico no processo de escolha de uma plataforma.

A tabela 2 mostra o sistema mínimo recomendado, ao nível de hardware, com base no tipo de utilização pretendido. [5]

Finalidade Número de canais

Sistema mínimo recomendado

Hobby system Até 5 400-MHz x86, 256 MB RAM

SOHO[1] system

De 5 a 10 1-GHz x86, 512 MB RAM

Small business system

De 10 a 15 3-GHz x86, 1 GB RAM

Medium to large system

Mais de 15 Dual CPUs, possibly also multiple

Tabela 2. Requisitos de sistema recomendados.

Para instalações de Asterisk de grande dimensão é comum desenvolver funcionalidades em vários servidores. Uma ou mais unidades centrais dedicadas ao processamento de chamadas complementado por um ou mais servidores auxiliares para manipular serviços, como, base de dados, voice mail, billing, interface Web, firewall, etc.

O Asterisk é um software bastante personalizável, permitindo configurar tudo o que necessitamos, mas existe uma curva de conhecimento associada. Aquando da alteração de um atributo no sistema telefónico é necessário considerar o seu impacto.

De forma a construir uma plataforma adequada, é necessário entender como é que o Asterisk utiliza o sistema de forma a fazer decisões inteligentes sobre que recursos vão ser necessários.

����������������������������������������������������������������� ����� ��������� ��� ������

�

���

�

Para implementar um sistema Asterisk é necessário considerar vários factores:

- Número máximo de conexões concorrentes que é esperado o sistema suportar. Cada conexão irá aumentar a carga do sistema.

- A percentagem de tráfego que irá requerer processamento intensivo, Digital Signal Processing (DSP) de codecs comprimidos, como por exemplo, G.729 e GSM.

O processamento DSP que o Asterisk executar em software terá impacto no número de chamadas concorrentes que irão ser suportadas. Um sistema que manipule com facilidade 50 chamadas concorrentes que utilizam G.711 pode ser afectado negativamente por um pedido de chamada em conferência levada a cabo por 10 utilizadores que utilizam o codec G.729 de canais comprimidos.

- Que actividade está prevista para as chamadas em conferência? O sistema será sobrecarregado?

As chamadas em conferência requerem que o sistema transcodifique e misture cada fluxo de áudio recebido em múltiplos fluxos de saída. Misturar múltiplos fluxos áudio praticamente em tempo real pode gerar uma enorme carga de CPU.

- Existência de aplicações (ou scripts) externas invocadas pelo Asterisk

Sempre que o Asterisk tem de passar o controlo para um programa exterior, existem penalizações de desempenho. Toda a lógica que for necessária deve ser feita no dial plan. Se scripts externos são utilizados, podem ser desenvolvidos tendo em conta o desempenho.

- Outros processos que correm concorrentemente no sistema:

Sendo baseado em Unix, o Linux permite diferentes processos a correr “simultaneamente”. O problema surge quando um dos processos (como o Asterisk) requer um alto nível de resposta por parte do sistema. Por predefinição, o Linux irá distribuir equitativamente os recursos por todas as aplicações que os requisitem. No caso de coexistirem várias aplicações no sistema, o sistema deverá ser optimizado para o Asterisk, no que diz respeito às prioridades das várias aplicações.

- Versão de Kernel Linux

O Asterisk é oficialmente suportado pela versão 2.6 do Linux.

O impacto destes factores é desconhecido com exactidão. Sendo apenas conhecidos em termos gerais. Existem muitas variáveis em causa, como a potência do CPU, o chipset da motherboard, o carregamento de tráfego no sistema, optimizações no kernel Linux, tráfego na rede.

� �

�

5 Software para análise e captura de tráfego

Uma das formas de avaliação de desempenho do PBX Asterisk, é recorrer a ferramentas, geralmente em software, que permitem a captura de pacotes (sniffers). No entanto, sem uma interpretação, os pacotes capturados podem parecer consistir de dados em formato binário gerados aleatoriamente. Por forma a entender o tráfego (dados) capturado, há outro tipo de ferramentas que complementam os programas de captura de pacotes: os analisadores de protocolos e os monitores de rede. Estes permitem visualizar o tráfego capturado de forma estruturada e legível para o olho humano. O recurso a estes tipo de ferramentas permite ainda diagnosticar erros, produzir estatísticas e ter uma visão gráfica do fluxo do tráfego de dados (no caso do PBX Asterisk, tráfego de dados maioritariamente VoIP) que passa na rede.[19]

O Tcpdump [14] é uma ferramenta em software, de captura de pacotes. Esta fornece estatísticas sumárias e reporta o número de pacotes perdidos. Após capturar tráfego, é possível redireccionar este para um ficheiro e analisar posteriormente noutras ferramentas de análise como por exemplo o wireshark [16] e o tcptrace [15]. O Tcpdump é uma ferramenta de software geralmente utilizada em computadores com ambiente text-only ou em computadores remotos.

Uma ferramenta software bastante completa para captura e análise de tráfego de dados é o Wireshark [16]. Este utiliza o mesmo motor de captura do tcpdump e os ficheiros gerados podem ser gravados neste mesmo formato. O Wireshark suporta dois tipos de filtros: filtros de captura, baseados no tcpdump; e filtros de amostragem, utilizados para controlar o que se está a observar.

O Wireshark possui uma interface gráfica simples e intuitiva, podendo no entanto ser também utilizado em ambiente text-only.

O VoIP envolve uma série de protocolos que o Wireshark pode descodificar e relacionar. Por exemplo, o estabelecimento de uma chamada envolve um protocolo diferente do utilizado para o tráfego de voz propriamente dito: SIP e RTP/RTCP, respectivamente.

O Wireshark tem a capacidade de utilizar a informação de sinalização referente ao estabelecimento de uma chamada para melhor compreender o fluxo de voz. Tendo esta informação, será mais fácil a despistagem em caso de erro, por exemplo.

É possível actualizar a lista de pacotes capturados em tempo real de forma a verificar se o tráfego que está a ser gerado está de acordo com o esperado.

Uma das funções do SIP é o estabelecimento do fluxo RTP entre dois terminais. Isto é feito através do SDP (Session Description Protocol). Esta “negociação” que permite ao VoIP funcionar, é feita pelo PBX VoIP, que funciona como intermediário. Todo este processo pode ser analisado no Wireshark graficamente.[17]

Para testar o PBX Asterisk ao nível de desempenho para SIP existem várias ferramentas software, como o SIPP [18], esta foi desenvolvida pela HP, e as suas principais características são: cenários básicos SIP incluídos, possibilidade de se criar cenários complexos, bastando para isso alterar ficheiros em formato XML, produção de um conjunto de estatísticas em tempo real, transporte TCP e UDP, carga de chamadas ajustável dinamicamente e a possibilidade de enviar tráfego RTP.

Existe ainda outro tipo de ferramentas software que permitem simular condições mais adversas ao nível de intensidade de tráfego numa rede de dados, estas permitem carregar a rede com padrões de

���

�

tráfego diversificado. O MGEN [20] é uma ferramenta software com estas capacidades, em que são utilizados sripts para emular padrões de tráfego UDP/IP unicast e/ou multicast.

Para se efectuar a avaliação de desempenho do PBX Asterisk será necessário ter em conta vários factores de natureza distinta, conforme descrito anteriormente. Desde analisar condições de rede que podem afectar negativamente o desempenho do sistema, bem como os protocolos, codecs, tipo de terminal utilizador utilizados. Será necessário avaliar que aplicações Asterisk se pretende utilizar (conferência, voice mail, IVR, etc.) e como varia o consumo de recursos para cada uma. A avaliação da dimensão e carga esperada que o sistema irá ter é necessária para se escolher o hardware e software apropriado a cada caso. No fundo, será necessário fazer uma avaliação de desempenho com recurso a várias configurações.

Só estudando estes pontos será possível identificar de forma rigorosa quais os parâmetros que contribuem para o desempenho do Asterisk.

���

�

6. Avaliação de desempenho do PBX Asterisk

6.1 Chamadas ponto a ponto No cenário de chamadas ponto a ponto, quando um utilizador efectua uma chamada para uma dada extensão, o PBX Asterisk encaminha a chamada para o receptor previamente configurado em sistema e “negoceia” o codec que o receptor pretende utilizar, de forma independente das opções sobre codecs que o emissor apresenta. Actua assim como intermediário na chamada.

Pretende-se perceber qual o número máximo de chamadas simultâneas que o PBX Asterisk suporta, e qual o impacto quando é necessário o PBX Asterisk efectuar transcodificação, ou seja, tornar possível a comunicação entre dois terminais mesmo que estes não utilizem o mesmo codec para o tráfego de voz.

Ambiente de teste:

Para avaliar o desempenho para as chamadas ponto a ponto foram efectuados testes de carga. Foram utilizados 5 computadores, ligados em rede através de um hub de 8 portas 10/100 Mbps.

A primeira série de teste foi realizada tendo por base a instalação do PBX Asterisk num computador com um processador 2.6 GHz Pentium Celeron. Seguidamente foram realizados testes com recurso a um computador mais fraco, um Pentium 350 MHz. A configuração dos restantes elementos de rede manteve-se. Um computador que gera chamadas Sip, com recurso à aplicação SIPp, por forma a sobrecarregar o PBX Asterisk. Outro computador que actua como receptor de chamadas Sip, correndo a aplicação SIPp. Por último existe ainda um computador que captura todo o tráfego na rede. A figura 10 ilustra a configuração de rede utilizada bem como as características de cada computador.

���

�

Figura 10. Ilustração das ligações de rede e características dos computadores utilizados nos testes de avaliação de desempenho para as chamadas ponto a ponto.

Configuração do PBX Asterisk:

Ficheiro: extension.conf ; Sempre que seja efectuada uma chamada para a extensão 222333444 ; o PBX Asterisk irá encaminhar a chamada para o utilizador ; sippuas [sipp_pp] exten => 222333444,1,Dial(SIP/sippuas) ; Quando existe uma chamada em linha para a extensão 222333444, esta ; chamada é encaminhada para o cliente sippuas Ficheiro: sip.conf ; Para que um utilizador consiga efectuar uma chamada para o terminal ; sippuas necessita de utilizar o perfil [sipp], que contém o ; contexto sipp_pp (context= sipp_pp). [sipp] type=friend ; indica que este perfil pode receber e efectuar chamadas username=sipp

���

�

; nome do utilizador host=dynamic ; Localização do cliente, no caso de ser “dynamic” o cliente pode ; registar-se de forma independente do endereço IP utilizado context=sipp_pp ; contexto no qual pode participar, segundo o ficheiro de ; configuração extension.conf que contem o dial plan canreinvite=no ; Por predefinição o PBX Asterisk tenta redireccionar o tráfego media ; RTP (áudio) para ir directamente do emissor para o receptor. ; alguns dispositivos ou aplicações VoIP não suportam esta ; funcionalidade, como é o caso da aplicação SIPp insecure=very ; Indica que este perfil não utiliza autenticação, nem serão ; verificados o ip e número de porto nat=no ;�Network Address Translation ; Como os testes apenas serão efectuados numa rede interna, não há ; necessidade de tradução de endereços IP da rede interna para a rede ; pública [sippuas] type=friend username=sippuas host=192.168.0.3 ; Localização do cliente, neste caso com IP estático, para poder ser ; contactado pelo PBX Asterisk, uma vez que a aplicação SIPp não ; regista automaticamente os clientes. context=sipp_pp insecure=very canreinvite=no nat=no

�

Estrutura do teste:

Nos testes de carga realizados, a aplicação SIPp está configurada de forma a gerar chamadas SIP em um dos computadores e configurada como receptor de chamadas SIP noutro computador distinto. A figura 11 ilustra o fluxo de mensagens SIP e RTP, conforme os testes de carga realizados para as chamadas ponto a ponto.

���

�

�

Figura 11. Fluxos de mensagens SIP e RTP, para os testes de carga nas chamadas ponto a ponto.

Quando o emissor (gerador de chamadas SIP) efectua uma chamada para a extensão 222333444, é encaminhado para o receptor (receptor de chamadas SIP), o emissor transmite então tráfego RTP de voz durante 60 segundos, que poderá estar codificado de várias formas, em G711a, Gsm, iLBC ou speex. O receptor recebe o tráfego de voz e ecoa de volta para o emissor. O PBX Asterisk permite que o codec utilizado pelo emissor para transmitir o tráfego de voz RTP seja diferente do utilizado/suportado, neste caso o PBX Asterisk encarrega-se de efectuar a transcodificação de codec.

Nos testes de carga para este cenário são geradas três chamadas a cada segundo. Sendo o número de chamadas simultâneas o parâmetro variável. O número de chamadas simultâneas serve para testar qual o limite para o qual não há retransmissão de mensagens devido a timeout, por falta de resposta do PBX Asterisk. No caso do gerador de chamadas, as mensagens para as quais o PBX Asterisk deverá sempre responder são a “INVITE” e “BYE”. No caso do receptor de mensagens, o PBX Asterisk deverá responder sempre às mensagens “200 OK”. Conforme a figura 11. Para que a aplicação Sipp transmita o tráfego de voz é necessário que exista um ficheiro com a extensão .pcap, que contenha o tráfego de voz RTP no codec que se pretende utilizar para simular uma chamada de voz, este ficheiro é então carregado pelo Sipp, conforme a descrição contida no ficheiro .xml respectiva.(anexo) Para este teste foi capturado tráfego durante 1 minuto utilizando o Wireshark, o tráfego foi capturado tendo por base uma chamada entre dois softphones xten, em que o emissor da chamada reproduziu um diálogo retirado de uma série televisiva com a duração de 1 minuto. O softphone xten foi configurado com a supressão de silêncio desligada ("Transmit Silence"=YES) conforme as indicações no ficheiro de configuração sip.conf no PBX Asterisk. Este procedimento foi repetido, utilizando sempre o mesmo diálogo para vários codecs: g711a, gsm, ilbc e speex. Posteriormente o tráfego foi filtrado no Wireshark de forma a que o ficheiro com a extensão .pcap apenas contivesse o tráfego de voz e na direcção em que foi emitido.

��

�

Pretende-se: 1º Testar qual o número máximo de chamadas ponto a ponto simultâneas que o PBX Asterisk suporta, ou seja, o número máximo para o qual não há retransmissão de mensagens devido a timeout por falta de resposta do PBX Asterisk. 2º Para o mesmo número de chamadas em simultâneo, utilizando o mesmo codec no emissor e no receptor, verificar quais as diferenças e principais as vantagens e desvantagens da utilização de cada codec. 3º Testar o impacto do uso de diferentes codecs na transmissão do tráfego de voz RTP, em ambos os terminais (emissor e receptor) numa chamada ponto a ponto, obrigando o PBX Asterisk a efectuar transcodificação para que os terminais consigam comunicar. 4º Qual o desempenho do PBX Asterisk quando instalado num computador com recursos (CPU e memória) limitados, no cenário de chamadas ponto a ponto. Para avaliar o desempenho do PBX Asterisk ao nível de número de chamadas recebidas e correctamente tratadas foram utilizados vários parâmetros ao nível do cliente Sipp, sendo o parâmetro variável o limite máximo de chamadas simultâneas, sendo que são geradas três chamadas por segundo. Para a monitorização do sistema onde está instalado o PBX Asterisk foi utilizada a aplicação Statgrab[2], que permite visualizar todas as estatísticas disponibilizadas pela biblioteca libstatgrab. A biblioteca libstatgrab fornece uma plataforma de acesso às estatísticas sobre o sistema a correr. As estatísticas incidem sobre utilização do CPU, de memória, disco rígido, contabilização de processos, tráfego de rede, entre outros.

Para se obter dados mais precisos sobre o tráfego gerado e recebido no servidor PBX Asterisk foram recolhidas as estatísticas do comando ifconfig de Linux, para além da captura do tráfego efectuada por outro computador a correr o Wireshark em modo promíscuo ligado na mesma rede através de um hub. A captura tem a duração de aproximadamente 65 segundos, constituindo assim uma amostra do tráfego na rede, a partir do qual foi analisada a latência, o jitter e as perdas nos fluxos RTP. Apenas foi recolhida uma amostra devido aos recursos consumidos pela captura de tráfego de voz, que quando muito extensa fica com processamento moroso, sendo por vezes impossível a análise da captura.

Procedimento: PC com PBX Asterisk instalado IP:192.168.0.1 1 – Executar PBX Asterisk: > sudo /usr/sbin/asterisk –vc 2 – Execução de um script perl que faz o reset às estatísticas apresentadas pelo comando ifconfig e executa o programa statgrab, escrevendo os resultados obtidos para um ficheiro após a execução do teste. PC Receptor chamadas SIP, aplicação Sipp : IP:192.168.0.3:

��

�

3– Executar a aplicação Sipp como receptor de chamadas SIP, isto é, em modo servidor, indicando os parâmetros como, nome do ficheiro .xml que contém o cenário a utilizar no teste, activar a opção para ecoar o tráfego RTP de voz recebido. PC Receptor chamadas SIP, aplicação Sipp : IP:192.168.0.2: 4– Executar a aplicação Sipp como gerador de chamadas SIP, isto é, em modo cliente, a partir de um script que recebe como parâmetros os dados essenciais como, número máximo de chamadas em simultâneo, número de chamadas geradas por segundo, duração do teste (em minutos) e o nome do ficheiro .xml que contém o cenário a utilizar no teste. Conforme o codec utilizado para transmitir o tráfego RTP de voz, o cenário é diferente, pois os parâmetros do payload da mensagem Invite SIP, o SDP (Session Description Protocol), diferem.

PC de captura de tráfego: IP:192.168.0.4: 5- Captura de tráfego utilizando o Wireshark.

Resultados:

Foram efectuados diversos testes com duração de aproximadamente 3 minutos. Este valor não é exacto pois o cliente SIPp (gerador de chamadas SIP) “espera” que todas as chamadas pendentes terminem (soft exit). A variável utilizada para testar a carga do sistema foi o número máximo de chamadas em simultâneo. Sendo que são geradas em todos os testes três chamadas por segundo. Cada chamada tem a duração aproximada de 1 minuto em áudio de voz RTP mais sinalização SIP, em média 01:00:027 minutos por chamada.

Os valores encontrados para o número máximo de chamadas em simultâneo que o PBX Asterisk suporta são considerados apenas os valores “estáveis” máximos, ou seja, para os quais não há retransmissão ou timeout de mensagens SIP. No entanto pode haver perdas ao nível de pacotes RTP, devido à carga elevada na rede.

Com o máximo de 100 chamadas simultâneas para chamadas ponto a ponto com o mesmo codec no emissor e no receptor, g771a, gsm, speex e ilbc. Foram obtidos os resultados da tabela 12. Na tabela 13, são apresentados os valores máximos “estáveis” obtidos, para as chamadas ponto a ponto para diversos codecs (g711a, gsm, speex e ilbc), no PC Normal. Na tabela 14, são apresentados os valores máximos “estáveis” obtidos, quando o emissor de uma chamada utiliza um codec diferente do receptor, caso em que o PBX Asterisk efectua transcodificação para que os terminais comuniquem. Na tabela 15 são apresentados os valores de vários parâmetros obtidos, para o número máximo de chamadas em simultâneo, quando o PBX Asterisk é executado no PC limitado. Nos gráficos 1, 2, 3 e 4 são apresentadas comparações de alguns valores obtidos.

���

�

Notar que nos valores obtidos não são apresentados valores para o Jitter no caso do codec iLBC e Speex, pois o Wireshark não os calcula correctamente (uma limitação do software).

Codec G711a Speex Gsm iLBC Max. Chamadas simultâneas 100 100 100 100

Duração do teste (segundos) 214,22 214,23 214,57 214,09

Total de chamadas 300 300 300 300

Estatísticas de rede Downlink (MB) 366,8 172,6 149,7 119,7

Uplink (MB) 366,1 172,2 149,5 119,7

DownLink 14,37 6,76 5,85 4,69 Carga na rede (Mbit/s) UpLink 14,34 6,74 5,85 4,69

Estatísticas sobre fluxos de áudio de voz RTP Média 5,61 - 4,4 -

Max. 7,53 - 6,59 - Jitter (ms)

Min. 0,8 - 1,25 -

Média 45,3 54,07 45,95 60,57

Max. 62,78 67,05 59,69 66,22 Latência (ms)

Min. 26,63 22,65 20,23 40,01

Número fluxos RTP analisados 256 296 304 276

Nº de fluxos RTP com perdas 18 64 109 0

% média de perda por fluxo RTP 0,22 0,44 0,29 0

Utilização média do sistema % CPU 60,1 56 55,02 36,77

PBX Asterisk % Memória RAM 48 49,7 49 49,2

Tabela 12. Resultados obtidos para o teste de carga para 100 chamadas em simultâneo no computador normal.

��������������� ����� ��!������"� ��!���#$ ������� ����� �!�%�%�� "�&'(��%�(��#��(��� ����

���

�

�

Codec G711a Speex Gsm iLBC Max. Chamadas simultâneas 125 130 130 145

Duração do teste (segundos) 223,02 226,75 224,58 229,55

Total chamadas 375 390 390 435

Estatísticas de rede Downlink (MB) 457,90 224,00 193,90 172,70

Uplink (MB) 456,9 223,4 193,4 172,3

DownLink 17,23 8,29 7,25 6,31 Carga na rede (Mbit/s) UpLink 17,19 8,27 7,23 6,30

Estatísticas sobre fluxos de áudio de voz RTP Média 5,59 - 6,74 -

Max. 6,68 - 17,9 - Jitter (ms)

Min. 0,8 - 1,25 -

Média 44,86 276,45 73,3 76,34

Max. 56,16 303,87 228,81 120,73 Latência (ms)

Min. 26,49 256,49 20,47 35,79

Número fluxos RTP analisados 328 518 400 824

Nº de fluxos RTP com perdas 28 518 196 414

% média de perda por fluxo RTP 0,2 2,77 0,51 4,7

Utilização média do sistema % CPU 74,1 70,41 72,23 65,42 PBX Asterisk % Memória RAM 47,13 50,13 48,82 49,86

Tabela 13. Resultados obtidos para o teste de carga para testar o máximo de chamadas em simultâneo suportadas pelo PBX Asterisk no computador normal.

��������������� ����� ��!������"� ��!���#$ ��������� �)�� ���%&�����!������ �!�%�%�� "�&'(��%�(��#��

(��� ����

� �

�

Codec emissor <-> Codec receptor

G711a <->

Gsm

G711a <->

iLBC

G711a <->

Speex

Gsm <->

iLBC

Gsm <->

Speex

iLBC <->

Speex Max. Chamadas simultâneas 50 35 20 25 15 15

Duração do teste (segundos) 198,05 192,96 187,49 189,32 185,77 185,79

Total chamadas 150 105 60 75 45 45

Estatísticas de rede Downlink (MB) 129,7 85,5 51,3 27 22,1 16,5

Uplink (MB) 129,4 85,1 51,2 27,1 22,2 16,5

DownLink 5,50 3,72 2,30 1,20 1,00 0,75 Carga na rede (Mbit/s) UpLink 5,48 3,70 2,29 1,20 1,00 0,75

Estatísticas sobre fluxos de áudio de voz RTP Média 18,76 - - - - -

Max. 32,16 - - - - - Jitter (ms)

Min. 5,67 - - - - -

Média 185,78 61,96 50 74,37 65,5 72

Max. 280,36 90,61 71,3 119,88 92,12 135,48 Latência (ms)

Min. 44,55 43,55 42,99 47,91 47,95 61,3

Número fluxos RTP analisados 200 140 80 100 60 60

Nº de fluxos RTP com perdas 49 0 0 0 0 0

% média de perda por fluxo RTP 1,12 0 0 0 0 0

Utilização média do sistema % CPU 89,72 93,11 87,9 72,32 78,4 77

PBX Asterisk % Memória RAM 49 49 48,82 49,23 49 49,21

Tabela 14. Resultados obtidos para o teste de carga para testar o máximo de chamadas em simultâneo suportadas pelo PBX Asterisk no computador normal, quando o emissor e o receptor utilizam codecs diferentes.

�Gráfico 3. Número máximo de chamadas simultâneas obtidas para os vários codecs, com o PBX Asterisk a correr num PC normal.

���

�

������ G711a Speex Gsm iLBC � ������ ��� � �� ����� ���� � 55 55 55 65 ������������� ����� ������ �� ���*��� ���*��� ���*��� � �*���

���������� ��� �� 165 165 165 195 � ���� ���� ���������

��� �������� �� � �*� ��*�� ��*�� *��

!"������� �� � �*�� ��� ��*�� *��

��� �#���� �*��� �* �� �*��� �*������������

������

�� $��% �� ! "#���� �*��� �* � �*�� �*���

� ���� ���� � �$���&��� ����'��������(�)�*�+�

� ,���� *��� +� �*�� +�

� �� �*��� +� ��*��� +�-�������� ��

� ��� �*� +� �*��� +�

� ,���� � *�� ��*�� �*��� ���*���

� �� �*��� ���*��� �*��� ���#��.������� ��

� ��� ��*��� ��* �� ��*�� �*���

/ 0� ����&��� �*�+������ ��� � �� � �� � �� � � �

/ 1����&��� �*�+���� �"���� � � � � �

% média de perda por fluxo RTP� � � � �

!����)��������� � ��� ��

2 ��+! � �*�� �*��� *��� *���+ 3�4 ���� ��

2 �� �� 5����*4� � �� ��*��� ��� ���

Tabela 15. Resultados obtidos para o teste de carga para testar o máximo de chamadas em simultâneo suportadas pelo PBX Asterisk no computador limitado.

������������, -� ����� �)�� ��!������ �!�%�%�� "�&'(��%��.&�!�%�������%������%���!��%*���� ���#/0�

1%&���%2����������("� �#����� �&�!���

���

�

Resultados dos tempos de resposta do PBX Asterisk obtidos para as chamadas ponto a ponto

No cenário de chamadas ponto a ponto estão instalados dois contadores no gerador de chamadas SIP (aplicação SIPp em modo cliente). O primeiro contador é inicializado quando se envia a mensagem INVITE do protocolo SIP e termina quando é recebida uma resposta confirmação do PBX Asterisk, a mensgem 200 OK. E pretende contabilizar o tempo que o PBX Asterisk demora a responder a um pedido de chamada para uma determinada extensão. O segundo contador é inicializado quando o gerador de chamadas SIP pretende terminar a chamada e envia a mensagem BYE do SIP. Este termina quando recebe a mensagem 200 OK do SIP, enviada pelo PBX Asterisk. Os resultados para estes contadores são apresentados na tabela 7, para os testes realizados com o PBX Asterisk instalado no PC normal. Na tabela 8 é apresentada a distribuição dos tempos de resposta obtidos para o PC limitado.

Distribuição do Tempo de resposta Asterisk – Gerador chamadas SIP

Invite Bye

Codec < 50 ms 50 � x < 200 � 200 ms < 50 ms 50 � x < 200 � 200 ms Total

Teste limite 100 chamadas em simultâneo G711a 299 1 0 300 0 0 300

Speex 292 6 2 300 0 0 300

Gsm 297 3 0 300 0 0 300

iLBC 300 0 0 300 0 0 300

Teste limite máximo de chamadas em simultâneo sem transcodificação G711a 199 176 0 375 0 0 375

Speex 179 210 1 390 0 0 390

Gsm 293 95 2 390 0 0 390

iLBC 435 0 0 435 0 0 435

Teste limite máximo de chamadas em simultâneo com transcodificação G711a <-> Gsm 61 86 3 150 0 0 150

G711a <-> iLBC 69 33 3 104 1 0 105

G711a <-> Speex 59 1 0 60 0 0 60

Gsm <-> iLBC 75 5 0 75 0 0 75

Gsm <-> Speex 45 0 0 45 0 0 45

iLBC <-> Speex 45 0 0 45 0 0 45 Tabela 16 Distribuição dos tempos de resposta obtidos para as mensagens SIP, Invite e Bye, para o PC Normal.

Tempo resposta Asterisk - Gerador chamadas SIPP

Invite Bye

Codec < 50 ms 50 � x < 200 � 200 ms < 50 ms 50 � x < 200 � 200 ms Total

G711a 158 7 0 165 0 0 165

Speex 120 45 0 165 0 0 165

Gsm 119 37 9 165 0 0 165

iLBC 171 14 10 194 1 0 195 Tabela 17. Tempos de resposta obtidos para as mensagens SIP, Invite e Bye, para o PC limitado.

���

�

No receptor de chamadas SIP, aplicação SIPp em modo servidor, foi instalado um contador, que é inicializado aquando do envio da mensagem 200 OK do protocolo SIP, como resposta à mensagem INVITE, e termina quando recebe a mensagem ACK do SIP, por parte do PBX� Asterisk. Os resultados para este contador são apresentados na tabela 18, para os testes realizados com o PBX Asterisk instalado no PC normal. Na tabela 19 é apresentada a distribuição dos tempos de resposta obtidos para o PC limitado.

Tempo resposta Asterisk - Receptor chamadas SIP 200 OK

Codec < 30 ms 30 � x < 200 � 200 ms Total

Teste limite 100 chamadas em simultâneo

G711a 300 0 0 300

Speex 300 0 0 300

Gsm 299 1 0 300

iLBC 300 0 0 300 Teste limite máximo de chamadas em simultâneo sem transcodificação G711a 372 3 0 375

Speex 386 4 0 390

Gsm 435 0 0 390

iLBC 377 13 0 435 Teste limite máximo de chamadas em simultâneo com transcodificação

G711a <-> Gsm 145 5 0 150

G711a <-> iLBC 105 0 0 105

G711a <-> Speex 60 0 0 60

Gsm <-> iLBC 74 1 0 75

Gsm <-> Speex 45 0 0 45

iLBC <-> Speex 45 0 0 45 Tabela 18. Distribuição dos tempos de resposta obtidos para a mensagem SIP, 200 OK, para o PC normal.

Tempo resposta Asterisk - Receptor chamadas SIPP

200 OK

Codec < 30 ms 30 � x < 200 � 200 ms Total

G711a 165 0 0 165

Speex 164 1 0 165

Gsm 163 2 0 165

iLBC 191 4 0 195 Tabela 19. Tempos de resposta obtidos para a mensagem SIP, 200 OK, para o PC limitado.

���

�

Análise dos resultados obtidos

� O uso de diferentes codecs no emissor e no receptor, implica o aumento significativo de processamento devido à necessidade de o PBX Asterisk ter de transcodificar o tráfego de voz para que os interlocutores consigam comunicar. O maior processamento implica maior consumo de recursos (principalmente CPU) no computador onde se onde está a correr o PBX Asterisk. Com o maior consumo de CPU para efectuar transcodificação de codec’s, o número de chamadas simultâneas suportadas pelo PBX Asterisk diminui drasticamente.

� Pela análise da tabela 13, vemos que quando se utiliza apenas o codec g711a para efectuar chamadas ponto a ponto, o PBX Asterisk suporta, isto é, efectua o encaminhamento de chamadas de forma a que os interlocutores consigam comunicar de forma estável, para o máximo de 125 chamadas simultâneas. No caso em que o emissor utiliza o codec g711a e o receptor o codec gsm (ou vice versa), tabela 14, o número de chamadas simultâneas suportadas pelo PBX Asterisk é 50. Ou seja, 60% menos chamadas.

� Quando os interlocutores utilizam o mesmo codec, g711a, speex, gsm ou iLBC, é possível verificar que o maior número de chamadas simultâneas que o PBX Asterisk suporta está relacionado com o número de bytes necessários para transmitir a informação de voz, ou seja, um codec menos complexo comprime menos o áudio de voz, logo consome maior largura de banda para transmitir a informação de voz. Na tabela 13 é possível verificar que com maior carga de rede, no caso de se utilizar o codec g711a numa chamada, o PBX Asterisk suporta 125 chamadas em simultâneo. Mas se for utilizado um codec mais complexo, isto é, que comprime mais o áudio de voz, como é o caso do codec iLBC, o PBX Asterisk suporta 145 chamadas simultâneas, mais 13,8%, através dos dados da tabela 13.

� Através da tabela 13 e da tabela 15, é possível verificar qual a diferença encontrada no que diz respeito ao número máximo de chamadas em simultâneo sem transcodificação obtido no PC normal e no PC limitado. Os valores obtidos no PC normal são cerca de 56% superiores em relação ao PC limitado. No entanto, o desempenho no PC limitado é satisfatório, visto que ter um PBX que consegue números na ordem da meia centena para chamadas ponto a ponto em simultâneo, é suficiente, por exemplo num pequeno escritório. Isto quando ambos os interlocutores utilizam o mesmo codec.

� Ao nível dos fluxos RTP, o Jitter (variação do atraso entre pacotes sucessivos de dados) nunca ultrapassou os 15 ms. Para reduzir o efeito do jitter, a aplicação no receptor deve criar um buffer, por forma a manter a taxa de entrega constante. O buffer a utilizar pode ter tamanho fixo ou dinâmico, que permite suportar as variações das condições dos jitters. No entanto a utilização de um buffer para compensar o jitter irá gerar atraso adicional. Como exemplo, um buffer para compensar a variação do atraso até 50 milissegundos irá introduzir em média mais 25 milissegundos de atraso. [22]

Para a latência (atraso) foram obtidos valores médios na ordem dos 70 milissegundos, sendo este valor ultrapassado no caso do codec speex, 276,45 milissegundos, e na chamada com transcodificação g711 para gsm, 185,18 milissegundos. À partida, o facto de se estar a utilizar transcodificação faz com que a latência aumente na comunicação. Segundo a recomendação ITU G.114 [22], o limite máximo é de 400 milissegundos para a latência e é recomendado um valor não superior a 150ms para que a latência não seja notada pelo utilizador.

���

�

Na tabela 12 e 13 é possível verificar que a perda de pacotes num fluxo RTP teve como pior resultado 4,7% para o caso do codec ilbc. As perdas de pacotes encontradas devem-se possivelmente ao congestionamento na rede. No entanto, não chega a um valor crítico de perdas.

� Através das tabelas 16, 17, 18 e 19 é possível constatar que o PBX Asterisk tem tempos de resposta às mensagens SIP na ordem dos milissegundos.

�

��

�

6.2 Chamadas em conferência

No cenário de chamadas em conferência, quando um utilizador efectua uma chamada para uma dada extensão, o PBX Asterisk encaminha a chamada para uma “sala” de conferência previamente configurada no sistema, dependendo da configuração para uma determinada extensão poderá ser solicitado ao emissor da chamada a inserção de um código para ter acesso à conferência.

Nos testes efectuados, quando um dado utilizador entra numa conferência, permanece conectado durante 1 minuto, durante o qual é gerado tráfego de voz. Estamos perante o pior caso possível, e que na realidade não poderia acontecer numa conferência, pois os interlocutores não se entenderiam se falassem todos em simultâneo. Para complementar este teste são utilizados codecs distintos nos vários testes.

Pretendem-se perceber qual o desempenho do PBX Asterisk num cenário com chamadas em conferência. Determinar qual o número máximo de chamadas simultâneas, ou seja, número máximo de participantes que o PBX Asterisk suporta numa “sala” de conferência. E também o que acontece quando existe mais do que uma “sala” de conferência em simultâneo.

Para efectuar as chamadas em conferência no PBX Asterisk é utilizado o módulo MeetMe, que necessita do suporte de um temporizador (time source) para funcionar. Existem dispositivos hardware desenvolvidos no âmbito do projecto Zaptel[23], próprio para o efeito. No entanto, é possível criar um temporizador virtual, ztdummy[24],que utiliza recursos do kernel para obter o mesmo efeito apenas com software.

Ambiente de teste:

Para avaliar o desempenho para as chamadas em conferência foram efectuados testes de carga. Foram utilizados 4 computadores, ligados em rede através de um hub de 8 portas 10/100 Mbps.

Os testes foram efectuados tendo por base a instalação do PBX Asterisk num computador com um processador 2.6 Ghz Pentium Celeron. Para gerar chamadas SIP são utilizados dois computadores, correndo no total até 4 instâncias da aplicação SIPp. Conforme o cenário das chamadas ponto a ponto existe ainda um computador que captura todo o tráfego na rede. A figura 12 ilustra a configuração de rede utilizada bem como as características de cada computador.

�

��

�

�

Figura 12. Ilustração das ligações de rede e características dos computadores utilizados nos testes de avaliação de desempenho para as chamadas em conferência.�

Configuração do PBX Asterisk:

Ficheiro: meetme.conf [rooms] ; ; Criação de “salas” de conferência: ; ; Utilização: conf => numero_conferencia[,pin][,pin_administrador] ; conf => 1234 conf => 1235 conf => 1236 conf => 1237 Ficheiro: extension.conf ; Sempre que seja efectuada uma chamada para a extensão 8500, 8600, ; 8700 ou 8800, o PBX Asterisk irá criar/adicionar um utilizador à ; chamada em conferência na “sala” 1234, 1235, 1236 e 1237 ; respectivamente. [conferencia]

���

�

exten => 8500,1,Meetme(1234) exten => 8600,1,Meetme(1235) exten => 8700,1,Meetme(1236) exten => 8800,1,Meetme(1237) Ficheiro: sip.conf ; Para que um utilizador consiga participar em uma das “salas” de ; conferência, necessita de utilizar o perfil [sipp], que contém o ; contexto conferência (context=conferencia). [sipp] type=friend ; indica que este perfil pode receber e efectuar chamadas context=conferencia ; contexto no qual pode participar, segundo o ficheiro de ;configuração extension.conf host=dynamic ; Localização do cliente, no caso de ser “dynamic” este cliente pode ; registar-se a partir de qualquer endereço IP username=sipp ; Nome de utilizador canreinvite=no ; Por predefinição o PBX Asterisk tenta redireccionar o tráfego media ; RTP (áudio) para ir directamente do emissor para o receptor. ; alguns dispositivos ou aplicações VoIP não suportam esta ; funcionalidade, como é o caso da aplicação sipP insecure=very ; Indica que este perfil não utiliza autenticação, nem serão ; verificados o ip e número de porto nat=no ; Como os testes apenas serão efectuados numa rede interna, não hà ; necessidade de tradução de endereços da rede interna para a rede ; pública de IP Estrutura do teste:

Foram efectuados testes de carga ao PBX Asterisk recorrendo à aplicação Sipp. Neste teste são geradas duas chamadas a cada segundo. Do memo modo do que nas chamadas ponto a ponto, foi limitado o número de chamadas simultâneas, por forma a testar qual o limite para o qual não há retransmissão de mensagens SIP(INVITE ou BYE) devido a timeout, por falta de resposta do PBX Asterisk. Quando o emissor (gerador de chamadas SIP, aplicação SIPp em modo cliente) efectua uma chamada para a extensão 8500, 8600, 8700 ou 8800, é encaminhado para uma “sala” de conferência. Caso seja o único participante na conferência, o emissor é avisado pelo PBX Asterisk desse facto, caso já existam outros participantes na conferência apenas se escuta um sinal sonoro.

���

�

O sinal sonoro é enviado igualmente para todos os participantes, aquando da entrada ou saída de um participante na chamada em conferência a decorrer. A figura 13 ilustra o fluxo de mensagens SIP e RTP, conforme os testes de carga realizados para as chamadas em conferência. O tráfego de voz RTP transmitido para o PBX Asterisk foi colectado da forma anteriormente explicada nas chamadas ponto a ponto. Pretende-se: 1º Testar para uma conferência o número máximo de chamadas simultâneas para o qual não há retransmissão de mensagens devido a timeout por falta de resposta do PBX Asterisk. Efectuar este teste com tráfego de voz RTP, codificado em g711a, gsm, ilbc e speex. 2º Testar qual o número máximo de chamadas simultâneas numa situação em que há mais do que uma conferência a decorrer em simultâneo. Efectuar este teste com tráfego de voz RTP, codificado em g711a, gsm, ilbc e speex.

�

Figura 13. Fluxos de mensagens SIP e RTP, para os testes de carga nas chamadas ponto a ponto.

Para avaliar o desempenho do PBX Asterisk ao nível de número de chamadas recebidas e correctamente tratadas foram utilizados vários parâmetros ao nível do cliente Sipp, sendo o parâmetro variável, o limite máximo de chamadas simultâneas, sendo que são geradas duas chamadas por segundo.

A monitorização do PBX Asterisk e da rede foi efectuada na mesma forma que nas chamadas ponto a ponto.

Procedimento: PC com PBX Asterisk instalado IP:192.168.0.1

� �

�

1 – Executar PBX Asterisk: > sudo /usr/sbin/asterisk –vc 2 – Execução de um script perl que faz o reset às estatísticas apresentadas pelo comando ifconfig e executa o programa statgrab, escrevendo os resultados obtidos para um ficheiro após a execução do teste. PC com cliente Sipp: IP:192.168.0.2 e 192.168.0.3: 3– Executar cliente Sipp, a partir de um script que recebe como parâmetros os dados essenciais como, número máximo de chamadas em simultâneo, número de chamadas geradas por segundo, duração do teste (em minutos) e o nome do ficheiro .xml que contém o cenário a utilizar no teste. Conforme o codec utilizado para transmitir o tráfego RTP de voz, o cenário é diferente, pois os parâmetros do payload da mensagem Invite SIP, o SDP (Session Description Protocol), diferem. PC de captura de tráfego: IP:192.168.0.4: ��

4-�Captura de tráfego utilizando o Wireshark.

Resultados:

Foram feitos testes com duração de aproximadamente 3 minutos. Este valor não é exacto pois o cliente SIPP “espera” que todas as chamadas pendentes terminem (soft exit). A variável utilizada para testar a carga do sistema foi o número máximo de chamadas em simultâneo. Sendo que são geradas em todos os testes duas chamadas por segundo. Cada chamada tem a duração aproximada de 1 minuto em áudio de voz RTP mais sinalização SIP, em média 01:00:027 minutos por chamada, conforme o teste das chamadas ponto a ponto.

São apresentados os valores encontrados para o número máximo chamadas em simultâneo que o PBX Asterisk suporta num cenário de chamadas em conferência para vários codecs. São apresentados apenas os valores “estáveis” máximos, ou seja, para os quais não há retransmissão ou timeout de mensagens SIP, Invite e/ou Bye, por parte do cliente (emissor da chamada) o que significa que o PBX Asterisk se encontra acessível e não sobrecarregado. No entanto podem existir perdas ao nível dos pacotes RTP.

���

�

Carga na rede

(Mbit/s)

Nº Conferências

em simultâneo Codec

Max. Chamadas

simultâneas obtido Total

Bytes Recebidos

(Mb)

Bytes Transmitidos

(Mb) DownLink UpLink

Duração do teste

(seg.) 1 G711a 90 270 166.4 153 6,13 5,63� 228 1 Gsm 50 150 37,7 36,2 1,53 1,47 206,57 1 iLBC 30 90 18 17,6 0,77 0,76 196,18 1 Speex 20 60 17,4 14,6 0,77 0,64 191,13 2 G711a 40 240 147,9 134,6 6,16 5,61 201,4 2 Gsm 20 120 30,2 28,9 1,33 1,27 191,09 2 iLBC 15 90 18,1 17,7 0,8 0,79 189,18 2 Speex 10 60 17,4 14,5 0,79 0,65 186,12 3 G711a 25 225 138,5 128,3 6 5,56 193,69 3 Gsm 15 135 34 32,6 1,51 1,45 188,9 3 iLBC 10 90 18,1 17,5 0,82 0,79 186,21 3 Speex 5 45 13 10,6 0,6 0,49 183,62 4 G711a 15 180 110,9 104 4,93 4,63 188,62 4 Gsm 10 120 30,2 29 1,36 1,31 186,2 4 iLBC 5 60 12,1 11,9 0,55 0,54 183,62 4 Speex 5 60 17,4 14,1 0,8 0,65 183,65

Tabela 20. Estatísticas de rede obtidas pela informação do comando ifconfig e resumo da aplicação Sipp.

Jitter (ms) Latência (ms)

Nº Conferências

em simultâneo CODEC Média Max Min Média Max Min

Número fluxos RTP

analisados

Nº de fluxos RTP com

perdas 1 G711a 5,71 3,71 0,13 35,9 49,51 13,46 208 3 1 Gsm 3,66 5,92 0,08 37,9 54,66 21,06 108 3 1 iLBC - - - 53,30 77,33 26,38 77 4 1 Speex - - - 50,29 89,04 21,67 54 2 2 G711a 3,60 6,42 0,39 38,40 61,4 22,37 186 7 2 Gsm 3,16 6,39 0,49 36,93 49,99 22,39 110 8 2 iLBC - - - 52,13 78,45 28,26 115 4 2 Speex - - - 44,73 89,03 20,07 80 7 3 G711a 5,69 7,87 1,51 45,54 60,3 20,22 168 4 3 Gsm 3,44 6,14 1,11 35,57 53,33 20,23 110 5 3 iLBC - - - 54,08 77,37 24,68 83 8 3 Speex - - - 47,38 93,82 17,96 50 3 4 G711a 3,63 6,94 1,25 37,38 57,88 19,99 145 5 4 Gsm 3,24 5,2 1,03 35,97 49,95 18,64 105 6

���

�

4 iLBC - - - 52.58 86,08 30,34 68 5 4 Speex - - - 53,44 89,04 22,68 120 12

Tabela 21. Estatísticas sobre fluxos de áudio de voz RTP, obtidas através da aplicação Wireshark

Nº Conferências

em simultâneo

Codec Max.

Chamadas simultâneas

obtido

Total de chamadas

Utilização média CPU

(%)

Utilização média

Memória RAM (%)

1 G711a 90 270 63,47 47,26 1 Gsm 50 150 83,85 46,35 1 iLBC 30 90 79,64 37,1 1 Speex 20 60 89,2 46,1 2 G711a 40 240 77,78 66,14 2 Gsm 20 120 85,7 66,4 2 iLBC 15 90 90,4 66,53 2 Speex 10 60 93 66,79 3 G711a 25 225 80 66,4 3 Gsm 15 135 86,9 66,66 3 iLBC 10 90 87,27 66,8 3 Speex 5 45 68,4 66,66 4 G711a 15 180 79,04 66,53 4 Gsm 10 120 81,4 66,67 4 iLBC 5 60 68,53 66,7 4 Speex 5 60 92,63 66,92

Tabela 22. Percentagem média de utilização de CPU e memória RAM, na máquina onde está instalado o PBX Asterisk, para os diferentes testes.

�

Grafico 5. Comparação da percentagem utilização de CPU na máquina onde está instalado o PBX Asterisk, no caso de apenas uma conferência, conforme os dados da tabela 22.

���

�

�

Gráfico 6. Comparação do número de chamadas simultâneas obtidas consoante o número de conferências em simultâneo. �

Análise dos resultados obtidos

� As chamadas em conferência requerem que o sistema transcodifique o áudio recebido das várias fontes em PCM linear, misture depois todos os fluxos de áudio, para por fim recodificar para os múltiplos fluxos de saída. Se o codec é mais complexo, ou seja, comprime mais o áudio de RTP de voz, será maior o processamento necessário neste processo, conforme demonstrado na tabela 20. Os codecs que utilizam maior compressão (apresentam menor carga na rede), mas o número de chamadas suportadas em simultâneo numa conferência é menor.

� Com o aumento do número de conferências em simultâneo, o número total de chamadas no PBX Asterisk diminui, o que pode ser compreendido atendendo que cada conferência exige algum processamento próprio. Mesmo no caso em que apenas existe uma conferência os resultados no que diz respeito ao número de chamadas em simultâneo são significativamente menores do que os valores obtidos no cenário de chamadas ponto a ponto, para os codecs, g711a, gsm, speex, ilbc, temos menos 28%, 61,5%, 84,61% e 79,31% chamadas simultâneas, respectivamente. Esta diferença pode ser explicada com o processamento necessário para as chamadas em conferência apresentado no primeiro ponto. � Na comparação efectuada no gráfico 5 e no gráfico 6 é possível concluir que a limitação principal do número de chamadas simultâneas é a capacidade de processamento do PC. O factor que contribui mais para o aumento do processamento é a complexidade do codec.

���

�

6.3 Interactive Voice Response (IVR) �

No cenário Interactive Voice Response (IVR) configurado para avaliar o desempenho do PBX Asterisk, quando o utilizador efectua uma chamada para uma determinada extensão, é o próprio PBX Asterisk a atender a chamada. Através de uma gravação áudio, são dadas ao utilizador várias opções de escolha, um menu de voz, que podem ser seleccionadas utilizando os tons DTMF (Dual-Tone Multi-Frequency) (teclas do telefone).

Neste cenário os testes estão divididos em duas partes. Na primeira parte, o cenário IVR utilizado apenas necessita que seja enviado um tom DTMF (tecla de telefone 1) para que seja seleccionada a opção pretendida no menu. Na segunda parte, para seleccionar a opção é necessário enviar cinco tons DTMF, o 54321 (as teclas de telefone 5, 4, 3, 2 e 1). Pretende-se assim verificar qual o impacto causado quando são utilizados vários tons DTMF num contexto IVR em VoIP. O cenário IVR em que se utilizam vários tons DTMF é muito utilizado na vida real, por exemplo, para o número de utilizador e/ou password para aceder a um determinado serviço via telefone.

Neste cenário de teste apenas se utilizará o codec g711a para o tráfego de voz RTP.

O cenário IVR parametrizado no gerador de chamadas SIP, aplicação Sipp em modo cliente, tem a seguinte estrutura:

Quando o cliente Sipp efectua a conexão à extensão 2000, o PBX Asterisk devolve o seguinte menu de voz:

- “Main menu” - “Press zero for help” - “To hear your account balance” - “Press one”

Na primeira parte do teste: o cliente Sipp selecciona o tom DTMF 1. Na segunda parte do teste: o cliente Sipp selecciona os tons DTMF 54321. - “The balance of your account is”.

Ambiente de teste:

Para avaliar o desempenho para as chamadas IVR foram efectuados testes de carga. Foram utilizados 4 computadores, ligados em rede através de um hub de 8 portas 10/100 Mbps.

A primeira série de teste foi realizada tendo por base a instalação do PBX Asterisk num computador com um processador 2.6 Ghz Pentium Celeron. Seguidamente foram realizados testes com recurso a um computador mais fraco, um Pentium 350 Mhz. A configuração dos restantes elementos de rede manteve-se. Um computador que gera chamadas Sip, com recurso à aplicação SIPp, por forma a sobrecarregar o PBX Asterisk. Por último, conforme os testes anteriores, existe ainda um computador que captura todo o tráfego na rede. A figura 10 ilustra a configuração de rede utilizada bem como as características de cada computador

�

���

�

�������������

� ����������������� � ��������

������� �!" � #

���������

$��%������

� ��&��� ���'��� "�(��

��(��)�'

� � ��*��+���,����� �&

�-+�.��������/� # �0

������� �!" � �

���������

$��%������

�1�2��'�&

�� ���'�1�&��� �� !��(��

0!"���)�'

+��� ���0 ��

3� �4�5�� �&�� ! ��

(����������%��'�����6��

6���/� � ��'����%&�� ��

������� �!" � �

���������

$��%������

� ��&��� ���'��� 0�(��

7�����)�'

8�� ���" �#

3� �4�5�� �&�� ! �#

Figura 14. Ilustração das ligações de rede e características dos computadores utilizados nos testes de avaliação de desempenho para as chamadas IVR.�

Configuração do PBX Asterisk:

São necessárias as seguintes configurações ao nível do PBX Asterisk, no ficheiro sip.conf e extension.conf:

sip.conf ; Para que um utilizador consiga efectuar uma chamada IVR ; necessita de utilizar o perfil [sippuac], que contém o ; contexto teste_IVR (context=teste_IVR). [sippuac] type=friend ; indica que este perfil pode receber e efectuar chamadas username=sippuac host=dynamic context=teste_IVR ; contexto(secção) no qual pode participar, segundo o ficheiro de ; configuração extension.conf dtmfmode=rfc2833 ; Especifica o formato que deve ser seguido para o payload dos pacotes ; RTP no caso dos dígitos DTMF (teclas do telefone) insecure=very ; Indica que este perfil não utiliza autenticação, nem serão ; verificadoso ip e número de porto canreinvite=no ; Por predefinição o PBX Asterisk tenta redireccionar o tráfego media ; RTP (áudio) para ir directamente do emissor para o receptor. ; alguns dispositivos ou aplicações VoIP não suportam esta

��

�

; funcionalidade, como é o caso da aplicação sipP nat=no ; Como os testes apenas serão efectuados numa rede interna, não há ; necessidade de tradução de endereços da rede interna para a rede ; pública de IP extension.conf [teste_IVR] exten => 2000,1,Answer() ; Atende a chamada em linha para a extensão 2000 exten => 2000,2,Background(/etc/asterisk/sounds/main-menu) ; A função “Background” reproduz uma gravação áudio ; áudio main menu: “Main menu” exten => 2000,3,Background(/etc/asterisk/sounds/dictate/forhelp) ; áudio forhelp: “Press zero for help” exten => 2000,4,Background(/etc/asterisk/sounds/to-hear-your-account-balance) ; áudio to-hear-your-account-balance: “To hear your account balance” exten => 2000,5,Background(/etc/asterisk/sounds/press-1) ; áudio press-1: “Press one” exten => 2000,6,Background(/etc/asterisk/sounds/silence/1) ; reprodução de um segundo em silêncio exten => 2000,7,Goto(2) ; Se entretanto não foi digitado nenhum tom DTMF, o menu é reproduzido ; novamente. exten => 0,1,Goto(t_help,200,1) ; Redireccionado para a secção [t_help] NOTA: Na primeira parte do teste utilizou-se 1 dígito para a extensão “alvo”. exten => 1,1,Goto(acc_bal,100,1) ; Redireccionado para a secção [acc_bal] NOTA: Na segunda parte do teste, a extensão “alvo” tem 5 dígitos. exten => 54321,1,Goto(acc_bal,100,1) ; Redireccionado para a secção [acc_bal] exten => i,1,Background(/etc/asterisk/sounds/sorry) ; Qualquer outro tom DTMF é “apanhado” pela extensão i ; áudio sorry: “we’re sorry” exten => i,2,Background(/etc/asterisk/sounds/silence/1) ; reprodução de um segundo em silêncio exten => i,3,Goto(2000,2) ; o menu é reproduzido novamente a partir do passo 2

��

�

[acc_bal] exten => 100,1,Playback(/etc/asterisk/sounds/astcc-balance-of-account-is) ; áudio acc_bal: “The balance of your account is” exten => 100,2,Hangup() ; A chamada é desligada [t_help] exten => 200,1,Playback(/etc/asterisk/sounds/helpdesk) ; áudio acc_bal: “Helpdesk”

exten => 200,2,Hangup() ; A chamada é desligada

� ������������� ��6�

Nos testes de carga realizados, a aplicação SIPp está configurada de forma a gerar chamadas SIP. A figura 15 e 16 ilustram o fluxo de mensagens SIP e RTP, conforme os testes de carga realizados para as chamadas IVR.

O tempo de pausa, PAUSE[6s] e PAUSE[1,4s], refere-se ao tempo para o qual o gerador de chamadas está a receber áudio RTP do PBX Asterisk, durante 6 segundos e durante 1,4 segundos respectivamente. O tempo de pausa, PAUSE[0,2s], pretende simular o tempo que seria necessário esperar entre a digitação dos tons DTMF. Neste caso 0,2 segundos.

�

���

�

Figura 15. Fluxos de mensagens SIP e RTP, para os testes de carga nas chamadas IVR, no caso de um tom DTMF.

�

Figura 16. Fluxos de mensagens SIP e RTP, para os testes de carga nas chamadas IVR, no caso de 5 tons DTMF.

Foi possível configurar o cenário IVR descrito anteriormente utilizando o wireshark para ajustar a interacção da aplicação Sipp com o PBX Asterisk de forma a assemelhar-se a uma utilização real de um sistema IVR, conforme ilustra a figura 17.

���

�

�

Figura 17. Visão global de estatísticas VoIP no Wireshark.

Pretende-se:

1º Testar o número máximo de chamadas IVR por segundo que o PBX Asterisk suporta.

2º Comparar o número máximo de chamadas IVR por segundo obtidas quando se usa um tom DTMF e cinco tons DTMF para seleccionar uma opção no menu de voz.

Para avaliar o desempenho do PBX Asterisk ao nível de número de chamadas recebidas e correctamente tratadas foram utilizados vários parâmetros ao nível do cliente Sipp, sendo o parâmetro variável, o número de chamadas geradas por segundo. O teste é cancelado quando há retransmissões de mensagens INVITE ou BYE devido a falta de resposta por parte do PBX Asterisk.

A monitorização do PBX Asterisk e da rede foi efectuada da mesma forma que nas chamadas ponto a ponto e chamadas em conferência.

Procedimento: PC com PBX Asterisk instalado IP:192.168.0.1 1 – Executar PBX Asterisk: > sudo /usr/sbin/asterisk –vc 2 – Execução de um script perl que faz o reset às estatística apresentadas pelo comando ifconfig e executa o programa statgrab, escrevendo os resultados obtidos para um ficheiro. Durante a execução do teste. PC com cliente Sipp: IP:192.168.0.2:

� �

�

3– Executar cliente Sipp, a partir de um script que recebe como parâmetros os dados essenciais como, número máximo de chamadas em simultâneo, número de chamadas geradas por segundo, duração do teste (em minutos) e o nome do ficheiro .xml que contem o cenário a utilizar no teste. PC de captura de tráfego: IP:192.168.0.4: 4- Captura de tráfego utilizando o Wireshark.

�

���

�

Resultados:

Primeira parte, teste IVR com um tom DTMF:

Foram feitos testes com duração de aproximadamente 3 minutos. Este valor não é exacto pois o cliente SIPP espera que todas as chamadas pendentes terminem (soft exit). A variável utilizada para testar a carga do sistema foi o número de chamadas por segundo. A primeira parte do teste consistiu num cenário IVR simples, onde apenas é necessário utilizar um tom DTMF para seleccionar uma opção do menu.

Chamadas por segundo 3 6 9 12 15 16 17

Número de chamadas efectuadas 539 1078 1619 2159 2699 1878 3059

Chamadas por segundo obtidas 2,873 5,745 8,62 11,489 14,366 15,314 16,281 Pico de chamadas simultâneas obtido 24 48 72 101 122 131 142

Duração do teste (segundos) 187,57 187,57 187,79 187,88 187,85 187,88 187,87

Estatísticas de rede Bytes Recebidos (MB) 1 2,1 3,1 4,2 5,2 5,6 5,9

Bytes Transmitidos (MB) 44,5 88,9 133.5 178.0 220,5 234,3 247,5

Downlink 0,05 0,09 0,14 0,19 0,24 0,24 0,25 Carga na rede (Mbit/s) Uplink 1,99 3,97 5,97 7,95 9,81 9,85 10,46

Estatísticas sobre fluxos de áudio de voz RTP Média 3,71 3,84 3,95 4,06 4,05 3,98 3,99

Max. 7,35 7,37 7,74 7,73 7,6 7,68 8,16 Jitter (ms)

Min. 0,17 0,26 0,31 0,58 0,57 0,59 0,74

Média 21,76 22,31 23,09 23,49 23,21 23,42 23,37

Max. 28,92 29,89 30,87 32 44,95 35,36 64,25 Latência (ms)

Min. 20 20,02 19,64 19,88 20,04 20,04 20,06

Utilização média do sistema CPU (%) 34,7 62,8 79,4 95,19 95,41 95,06 96,43

PBX Asterisk Memória RAM (%) 53,51 54 54,55 55,4 48,56 48,95 49,34

3�.��������4%&�&5%&���%��.&�!�%�������%�&�%&�%�678�9��:3; <=�(��#��, ��� ����

���

�

Segunda parte, teste IVR com cinco tons DTMF:

Na segunda parte do teste ao cenário IVR, o ficheiro extensions.conf do Asterisk foi modificado, de forma que o comprimento da extensão necessária para alcançar a opção do menu desejada passe a ser de 5 dígitos DTMF (54321) em vez de 1 dígito DTMF (1).

PBX Asterisk em PC normal:

No PC Normal, o máximo de chamadas simultâneas atingidas (até se obter retransmissões de mensagens SIP no cliente Sipp) foi 14, sendo que como seria de esperar houve um ligeiro aumento no tráfego da rede, no sentido cliente Sipp para o PBX Asterisk, pois para cada chamada são necessários mais 4 tons DTMF, sendo que cada tom DTMF é constituído por 10 pacotes, valor obtido nas estatísticas VoIP do Wireshark.

Nas tabelas 24 são apresentadas as obtidas estatísticas para este teste.

Chamadas por segundo 3 6 9 12 13 14 Número de chamadas efectuadas 539 1079 1619 2159 2339 2519

Chamadas por segundo obtidas 2,856 5,712 8,568 11,424 12,376 13,321

Pico de chamadas simultâneas obtido 28 55 86 118 123 147

Duração do teste (segundos) 188,69 188,86 188,92 188,96 188,96 189,07

Estatísticas de rede Bytes Recebidos (MB) 2,3 4,5 6,8 9,1 9,9 10,7

Bytes Transmitidos (MB) 46,2 92,5 138,9 184,5 199,6 213,1

Downlink 0,10 0,20 0,31 0,41 0,44 0,48 Carga na rede (Mbit/s) Uplink 2,06 4,11 6,17 8,19 8,86 9,46

Estatísticas sobre fluxos de áudio de voz RTP Média 65,22 64,9 66,27 24,89 65,74 66,13

Max. 143,75 143,73 144,73 145,48 145,03 147,52 Jitter (ms)

Min. 0,21 0,11 0,38 0,36 0,21 0,57

Média 22,79 22,63 24,01 24,89 24,46 24,3

Max. 28,86 30,72 33,02 35,84 36,68 41,57 Latência (ms)

Min. 20,02 18,5 20 20 20,01 19,53

Utilização do sistema CPU (%) 40,29 74,38 87,7 92,82 95,98 96,51 PBX Asterisk Memória RAM (%) 54,9 55,98 56 57,4 57,94 58,33

Tabela 24. Estatísticas obtidas para os testes IVR (5 DTMF) no PC Normal.

���

�

Comparação de resultados obtidos

Gráfico 7. Percentagem de utilização do CPU em função do número de chamadas por segundo geradas.

Análise dos resultados obtidos

� Pela análise da tabela 23 e 24 e do gráfico 7, é possível verificar que o teste de carga feito ao cenário IVR em que se utiliza apenas um tom DTMF para seleccionar uma opção no menu permite mais 3 chamadas por segundo do que o cenário que se utilizam 5 tons DTMF. Este facto deve-se a facto de o processamento de 1 tom DTMF ser menor do que colectar os 5 tons DTMF e interpretar, fazendo com que se atinja o limite mais cedo do PBX Asterisk.

� Os valores de na ordem dos 100 ms encontrados na tabela 25 foram encontrados na transmissão dos tons DTMF, fazendo com que a média do Jitter suba. No entanto, os resultados para o jitter e latência obtidos na tabela 23 e 24 são bastante satisfatórios e aceitáveis para VoIP, conforme explicado na análise de resultados para as chamadas ponto a ponto.

���

�

6.4 Análise global de resultados

Como resumo dos 3 cenários de teste efectuados, temos que para um computador com um processador Pentium Celerom 2.6 GHz, 768 MB Ram, interface de rede Ethernet 10/100 Mbps:

� 125,130,130 e 145 chamadas simultâneas utilizando os codecs g711a, speex, gsm, ilbc respectivamente, no caso de chamadas ponto a ponto.

� 50, 35, 20, 20, 25, 15 e 15 chamadas simultâneas quando o emissor e receptor utilizam codecs distintos, g711a<->gsm , g711a<->ilbc, g711a<->speex, gsm<-> ilbc, gsm<->speex, ilbc<->speex respectivamente, no caso de chamadas ponto a ponto.

Para estes valores, o tempo de resposta do PBX Asterisk às mensagens de sinalização SIP foi menor que 100 milisegundos para 90% das chamadas.

� Quando existe uma chamada em conferência a decorrer o PBX Asterisk suporta numa sala de conferência, 90, 50, 30, 20 chamadas simultâneas consoante o codec, g711a, gsm, speex, ilbc respectivamente.

� Para 4 chamadas em conferência simultâneas, o número de chamadas possíveis de efectuar em simultâneo em cada sala é de 15, 10, 5, 5, consoante o codec, g711a, gsm, speex, ilbc respectivamente.

� Um sistema IVR instalado no PBX Asterisk suporta 17 chamadas por segundo caso a opção a seleccionar seja apenas constituída por um tom DTMF.

� Um sistema IVR instalado no PBX Asterisk suporta 14 chamadas por segundo caso a opção a seleccionar seja constituída por cinco tons DTMF.

Para um computador com um processador Pentium II 350 GHz, 128 MB Ram, interface de rede ethernet 10/100 Mbps:

� 55, 55, 55 e 65 chamadas simultâneas utilizando os codecs g711a, speex, gsm, ilbc respectivamente, no caso de chamadas ponto a ponto.

���

�

7. Conclusão e trabalhos futuros �

Através da realização destes testes é possível ter uma noção do potencial que o PBX Asterisk apresenta enquanto PBX VoIP.

O principal factor a ter em conta no que diz respeito às chamadas VoIP é perceber que percentagem de tráfego irá requerer processamento intensivo devido a codecs com grande compressão/complexidade, no caso dos testes de desempenho realizados, os codecs gsm, speex e ilbc. Um CPU a 2.6 GHz suporta 125 chamadas G.711 sem transcodificação, valor que pode subir para 145 para codecs que requeiram menor largura de banda, no caso o codec ilbc. Se houver transcodificação, o processamento no PBX Asterisk aumenta significativamente e o número de chamadas suportadas são 50 no caso de os codecs a transcodificar sejam G711 para Gsm, baixando para 15 no caso de se transcodificar áudio numa chamada com ilbc e speex, dois codecs com baixas taxas de transferência de bits, o que implica maior processamento para comprimir o áudio. Se houver uma conferência, o número de chamadas G.711 suportadas desce para 90, descendo para 20 quando se utiliza o codec speex que requer menor largura de banda, mas obriga a maior processamento. Caso surja uma outra conferência paralelamente, o número de chamadas G.711 suportadas em cada conferência é 40 e 10 para speex. Este número decresce se mais conferências surgirem, atendendo a que cada conferência exige algum processamento próprio. Quando o PBX Asterisk dispõe de serviços IVR, é possível aceitar 17 novas chamadas G.711 por segundo num caso em que apenas é necessário 1 tom DTMF para seleccionar uma opção. No caso de serem necessários 5 tons DTMF para seleccionar uma opção, o número de novas chamadas por segundo decresce para 14. No caso de um computador limitado com um CPU a 350 MHz, temos que são suportadas 55 chamadas G.711 e para um codec que requer menor largura de banda, ilbc, obtemos 65 chamadas.

O número máximo de chamadas suportadas pelo sistema suportar está assim fortemente dependente dos codecs que são utilizados.

Com a tecnologia existente actualmente, computadores com maior poder de processamento (CPU’s com 2 e 4 núcleos), os valores encontrados são facilmente ultrapassados, uma vez que o recurso de sistema mais solicitado é o processador.

Sendo o PBX Asterisk um sofware open source, com grande aceitação, existe uma grande comunidade de utilizadores e variados testemunhos de implementações concretas de sistemas Asterisk que podem ser encontrados na Internet. Contribuindo para o aumento da documentação existente e para a correcção de eventuais bugs existentes na aplicação, bem como o desenvolvimento de novos módulos para incrementar funcionalidades, como exemplo, módulos que permitem monitorizar o que acontece no PBX Asterisk via interface Web, módulo que permite a criação de um plano de chamadas (dialplan) graficamente de forma simples, arrastando icons.

Um ponto importante que não é focado nesta dissertação é o Mean Opinion Score (MOS) – medir a qualidade de voz, nos diferentes pontos de carga do sistema. Este é um tópico bom para trabalho futuro. Outro tópico de interesse que não foi testado devido às características da aplicação SIPp, é analisar o desempenho para chamadas ponto a ponto em que o áudio é enviado directamente entre os telefones, permitindo reduzir a carga no PBX Asterisk, isto quando não for necessária transcodificação.

��

�

Integrando o PBX Asterisk com o SER [21], terá interesse a análise de desempenho do Asterisk tendo o SER para processamento da sinalização. No caso de existir mais do que um servidor Asterisk, a integração com o SER também é interessante pois permite, gerir o balanceamento de carga, permitindo criar um sistema redundante e encarrega-se de efectuar os registos SIP de forma escalável.

Como complemento pode ainda ser realizada a ligação do PBX Asterisk a um operador VoIP sobre internet de banda larga, que permita chamadas para a rede de telefones pública. E verificar o desempenho do PBX para chamadas externas, para além das chamadas internas testadas nesta dissertação. Bem como analisar o desempenho para outros cenários além dos três aqui abordados.

��

�

Referências

1. Switching to VoIP, Theodore Wallingford, O’Reilly, 30/06/2005

2. SIP: Session Initiation Protocol, J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. IETF RFC 3261, Junho de 2002, http://www.faqs.org/rfcs/rfc3261.html

3. SDP: Session Description Protocol, M. Handley, V. Jacobson, C. Perkins, IETF RFC 4566, Julho de 2006, http://www.faqs.org/rfcs/rfc4566.html

4. RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. IETF RFC 3550. Julho de 2003., http://www.faqs.org/rfcs/rfc3550.html

5. Asterisk: The Future of Telephony, Jared Smith, Jim Van Meggelen, Leif Madsen, O´Reilly, 2005

6. Multimedia Communication: Directions and Innovation, Jerry D. Gibson, Academic Press, Outubro de 2000

7. Voice over IP Fundamentals, Jonathan Davidson, James Peters, Manoj Bhatia, Satish Kalidindi, Sudipto Mukherjee, Cisco Press, Agosto de 2006

8. Building Telephony Systems with Asterisk, D Gomillion, B Dempster, Packt Publishing, 30/09/2005

9. VOIP Wiki - a reference guide to all things VOIP, http://www.voip-info.org/wiki-Asterisk

10. Homepage Asterisk - http://www.asterisk.org

12. Netweb’s Asterisk Guide for Newbies, http://www.iareaphone.com/Downloads/Asterisk_config.pdf

13. The Asterisk handbook version 2, www.digium.com, 2003

14. Tcpdump - www.tcpdump.org

15. Tcptrace - http://jarok.cs.ohiou.edu/software/tcptrace

16. Wireshark - http://www.wireshark.org

17. Sean Walberg, Expose VoIP Problems Using Wireshark, Linux Jornal, 01/03/2007,

18. Sipp - http://sipp.sourceforge.net

19. Network Troubleshooting Tools, Joseph D. Sloan, O'Reilly, 2001

20. Mgen - http://cs.itd.nrl.navy.mil/work/mgen/index.php

21. SER - http://www.iptel.org/ser.

22. One-way transmission time. ITU-T Recommendation G.114, Maio de 2003.

23. Zaptel (Zapata Telephony) - http://www.voip-info.org/wiki/view/Zaptel

24. Asterisk timer ztdummy - http://www.voip-info.org/wiki-Asterisk+timer+ztdummy