PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ ESCOLA POLITÉCNICA CURSO DE ENGENHARIA ELÉTRICA - TELECOMUNICAÇÕES GILSON EVANDRO JUST JUNIOR

Tamanho: px
Começar a partir da página:

Download "PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ ESCOLA POLITÉCNICA CURSO DE ENGENHARIA ELÉTRICA - TELECOMUNICAÇÕES GILSON EVANDRO JUST JUNIOR"

Transcrição

1 PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ ESCOLA POLITÉCNICA CURSO DE ENGENHARIA ELÉTRICA - TELECOMUNICAÇÕES GILSON EVANDRO JUST JUNIOR FERRAMENTA DIDÁTICA PARA OPERAR COMO MEDIA GATEWAY CONTROLLER Projeto de Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Engenharia Elétrica - Telecomunicações da Pontifícia Universidade Católica do Paraná, como requisito parcial à obtenção do título de Engenheiro em Telecomunicações. Orientador: Prof. Dr. Ricardo C. Nabhen. CURITIBA 2012

2 GILSON EVANDRO JUST JUNIOR FERRAMENTA DIDÁTICA PARA OPERAR COMO MEDIA GATEWAY CONTROLLER Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Engenharia Elétrica - Telecomunicações da Pontifícia Universidade Católica do Paraná, como requisito parcial à obtenção do título de Engenheiro em Telecomunicações. COMISSÃO EXAMINADORA Prof. Dr. Ricardo Cassiano Nabhen (ORIENTADOR) PUC-PR Prof. Dr. James Alexandre Baraniuk PUC-PR Prof. Eng. Marcos Fernando Ferreira de Souza PUC-PR Curitiba, 30 de novembro de 2012.

3 RESUMO O projeto tem a finalidade de desenvolver uma ferramenta que atua como um Media Gateway Controller (MGC) comandando um ou mais Media Gateways (MG) registrados a este controlador, também com o intuito de dispor de uma ferramenta de análise com um perfil didático, que pdoe vir a ser utilizada por professores, ou mesmo corporações, facilitando a interpretação e visualização das mensagens MEGACO e SIP trocadas entre tais equipamentos, buscando sempre melhorar o processo de ensino tanto em sala de aula, quanto nas empresas que trabalham com essa tecnologia. O projeto foi desenvolvido em parceria com o laboratório da empresa americana Genband localizada no tecnoparque da PUC-PR, visando a utilização de seus equipamentos Media Gateways o desenvolvimento do controlador. O desenvolvimento da ferramenta didática que atua como um MGC na rede da Genband foi totalmente desenvolvida em linguagem C/C++, sobre uma topologia Cliente-Servidor para comunicação e troca das mensagens para comandar os Media Gateways a fim de estabelecer sessões entre assinantes. Palavras-Chaves: Media Gateway Controller, Interface didática, MEGACO.

4 LISTA DE ILUSTRAÇÕES Figura 1: Representação estrutural do que ocorre num Media Gateway ao criar contextos com diferentes terminações Figura 2: Representação da estrutura do protocolo MEGACO Figura 3: Representação gráfica das principais mensagens acima trocadas entre os MG e o controlador MGC Figura 4: Representação em diagrama de blocos do sistema desenvolvido até o presente momento Figura 5: Representação da arquitetura utilizada pelos protocolos referidos até o momento sobre o modelo OSI de camadas Figura 6: Exemplo da sinalização trocada entre duas partes através do serviço de localização dos servidores SIP Figura 7: Representação dos agentes/usuários SIP registrando-se no Media Gateway Controller, e atualizando sua localização na rede através do método de registro, desenvolvido em linguagem C++ no IDE QT Creator Figura 8: Diagrama de fluxo de dados da função de Registro do MGC, desenvolvido em linguagem C++ no IDE QT Creator Figura 9: Diagrama de fluxo de dados do tratamento da função de INVITE do MGC, desenvolvido em linguagem C++ no IDE QT Creator Figura 10: Cenário criado para realização dos testes com o softswitch desenvolvido Figura 11: Topologia criada para desenvolver o MGC no laboratório Genband Figura 12: Sequencia de comandos ServiceChange trocandos entre MG e MGC para o início da utilização das terminações do MG G Figura 13: Fluxograma para os comandos ServiceChange representando o funcionamento do Media Gateway Controller desenvolvido Figura 14: Fluxograma para os comandos de Notify enviados pelo MG para tratamento no MGC Figura 15: Fluxograma para os comandos de Notify enviados pelo MG para tratamento no MGC no caso de terminação colocada no gancho Figura 16: Representação do estabelecimento de uma sessão controlada pelo Media Gateway Controller através do comando Modify Figura 17: Representação do estabelecimento de uma sessão controlada pelo

5 Media Gateway Controller Figura 18: Visão geral da aplicação desenvolvida para os protocolos H.248 e SIP, representado por duas threads para tratamento das mensagens Figura 19: Cronograma apresentado no primeiro bimestre Figura 20: Novo cronograma proposto para realização do projeto Figura 21: Procedimentos de testes e avaliação do funcionamento do projeto... 60

6 LISTA DE ABREVIATURAS E SIGLAS ATM Asynchronous Transfer Mode DTMF Dual Tone Multi-Frequency GW Gateway IP Internet Protocol MG Media Gateway MGC Media Gateway Controller PRI Primary Rate Interface PSTN Public Switched Telephone Network QOS Quality of Service RTP Real-Time Transport Protocol SCN Switched Circuit Network SG Signaling Gateway SS7 Signalling System No. 7 ITU-T Telecommunication Standardization Sector of the International Telecommunications Union IETF Internet Engineering Task Force SIP Session Initialization Protocol SDP Session Description Protocol OSI Open Systems Interconnection URI Uniform Resource Identifier VoIP Voice over Internet Protocol CPE Costumer Premisses Equipment

7 SUMÁRIO 1 INTRODUÇÃO REFERENCIAL TEÓRICO MEGACO/H MEGACO/H.248 ServiceChange PROTOCOLO DE INICIALIZAÇÃO DE SESSÃO SIP DETALHAMENTO DO PROJETO DESENVOLVIDO SIP PROTOCOLO DE INICIALIZAÇÃO DE SESSÃO REGISTRO INVITE INÍCIO DE SESSÃO TRATAMENTO DAS MENSAGENS SIP MEGACO MEDIA GATEWAY CONTROLLER (H.248) CRONOGRAMA PROCEDIMENTOS DE TESTES E AVALIAÇÕES DO PROJETO CONCLUSÃO REFERÊNCIAS APÊNDICE A TUTORIAL DE CONFIGURAÇÃO DOS CLIENTES SIP APENDICE B CONFIGURAÇÃO MEDIA GATEWAY G2 GENBAND APENDICE C FLUXO DE MENSAGENS PELO MGC DESENVOLVIDO... 96

8 8 1 INTRODUÇÃO Em ambientes universitários está cada vez mais presente a parceria entre Universidade-Empresa, das quais as empresas fornecem, e/ou dedicam laboratórios e profissionais para capacitarem alunos, enquanto a universidade forma alunos que possam vir a serem futuros funcionários qualificados para trabalharem nessas empresas, com certo conhecimento ou experiência acadêmica de seus produtos, o que facilitará o processo de contratação de mão de obra qualificada atuante no mercado de tecnologia. A forma de ensino e a tecnologia sempre caminharam juntas ao formar alunos em ambientes acadêmicos, pois a tecnologia auxilia professores e instrutores de modo a facilitar demonstrações, simulações, e análises, tornando muitas vezes o que pode ser algo complicado em algo fácil de ser absorvido pelos alunos. Com base nisso, a proposta do projeto é a criação de um Media Gateway Controller (MGC) com uma interface didática, para auxiliar o ensino e análise da tecnologia aos alunos e também funcionários em treinamento, transformando algo muitas vezes abstrato, de difícil absorção em algo didático e visual, como a análise das mensagens trocadas entre o MGC e seus Media Gateways (MG). O MGC atuante como ferramenta didática na rede, será capaz de estabelecer sessões, gerenciar e finalizar sessões através da troca de sinalização MEGACO/H.248 [RFC3015] e SIP [RFC3261] com os MG associados a este MGC. O protocolo MEGACO/H248 foi definido em conjunto, através da união dos esforços da ITU-T e IETF a fim de disponibilizar um padrão de comunicação entre tais equipamentos para que gerenciem corretamente uma rede de telecomunicações com uma única linguagem para todos os equipamentos, mesmo de fabricantes diferentes. Para o nosso projeto, através da parceria entre a PUC-PR e a Genband, esteve disponível o laboratório de telecomunicações da Genband localizado no tecnoparque da PUC-PR, onde foi possível configurar os equipamentos, desenvolver a ferramenta didática e utilizá-la juntamente com os equipamentos da Genband. A Genband é uma empresa que foi fundada em Dallas, localizada no estado do Texas, Estados Unidos no ano de 1999 tendo seu nome original de fundação General Bandwidth, que em 2006 passou a ser conhecida formalmente como Genband. Dentro desses 13 anos de história no mercado de telecomunicações, e

9 9 através de várias aquisições, tais como a Siemens DCO Business em 2006, a TEKELEC Switching Solutions Group em 2007, NextPoint Networks em 2008, a Nokia Siemens Network Product Units em 2009, Nortel Carrier Voice and Applications Solutions em 2010, tornando nesses mesmo ano a maior fornecedora de soluções de softswitches, Media Gateways, Session Border Controllers, Media Servers and Application. A Genband está presente em mais de 50 países e possui mais de 2000 funcionários. Presente em 80 das 100 maiores redes de operadoras do mundo, possuindo a maior rede de nova geração (NGN Next Generation Network) do mercado com mais de 240 milhões de terminações IP. [Genband, 2012]. Abaixo uma imagem do laboratório da Genband instalado no tecnoparque da Universidade em Curitiba.

10 10 2 REFERENCIAL TEÓRICO 2.1 MEGACO/H.248 Equipamentos surgiram com a finalidade de comutar a rede tradicional com a nova rede IP, e novos protocolos surgiram para que essa tradução de telefonia comutada por circuito para telefonia comutada por pacote, e vice-versa pudesse ocorrer, houve a necessidade de novos equipamentos são conhecidos como Media Gateways (MG) e Media Gateway Controller (MGC), e novos protocolos de comunicação surgiram. Assim surgiu o protocolo MGCP - Media Gateway Control Protocol, que logo depois evoluiu para o MEGACO, através da união de esforços da ITU-T e IETF, com a intenção de diminuir a quantidade de protocolos em uso na rede, que é o principal protocolo de comunicação entre MGC e MG na rede. A função de um Media Gateway é converter o tráfego de voz de um tipo de rede, para o formato necessário de outro tipo de rede. Por exemplo, um MG pode criar uma terminação proveniente do tráfego de um timeslot E1 sendo de telefonia comutada por circuito juntamente com uma terminação proveniente de uma rede comutada por pacote, voz sobre IP. Esse gateway pode ser capaz de processar tanto áudio, como vídeo além de outros protocolos de dados tais como T30, T38 e T120, em qualquer combinação destes, além de funções de URA, e conferência entre diferentes partes Legado/IP [RFC3015]. Já o Media Gateway Controller tem a função de controlar os estados que dizem respeito ao controle da conexão para as terminações existente os Media Gateways [RFC3015]. Um exemplo do funcionamento, o MG está sempre monitorando algum evento de fora do gancho que ocorre quando um assinante retira o monofone do aparelho telefônico do gancho. Quando isso ocorre, o MG detecta esse evento e avisa o MGC que poderá responder ao MG um comando para que envie tom de discar a linha ao assinante que retirou o monofone do gancho, e ficar monitorando eventos de discagem DTMF, indicando o número discado pelo assinante. Após o MGC receber o número discado do usuário, o MGC determina qual deverá ser a rota para chegar ao assinante de destino utilizando sinalização entre MGC, tais como SIP, H323 para contatar o MGC apropriado para enviar sinal de

11 11 chamar para o assinante discado. Quando o MG percebe que o assinante destino retirou o monofone do gancho atendendo a chamada, os dois MG instruídos por seus MGC estabelecem uma rota bidirecional pela rede. Assim esse protocolo tem maneiras de perceberem condições e notificarem o MGC de suas ocorrências enviando sinais, tais como tom de discar, tom de chamar, tom de ocupado, e criar sessões entre terminais localizados em diferentes tecnologias de rede. Segundo o exemplo acima, muitos desenvolvedores de produtos, e tecnologia determinaram que é mais prático desenvolver grandes switches comutadores separando a sinalização das chamadas dos canais de mídia devido à grande densidade de interconexões entre esses switches. Assim, removendo a sinalização para um servidor mais rápido (MGC) do que tentar integrá-la ao MG. Também por retirar a sinalização de um MG local, os operadores de rede possuem um maior controle sobre o tráfego na rede, tendo todo esse trafego de controle centralizado no que resulta em maior confiabilidade, pois não se trata mais de vários equipamentos mandando sinalizações para vários outros equipamentos, e sim de um único equipamento Mestre (MGC) mandando mensagens para vários outros equipamentos escravos (MG). No MEGACO/H.248 existem dois grandes conceitos que devem ser tratados aqui: terminações e contextos. Terminações representam streaming de voz ou vídeo entrando ou saindo do MG, por exemplo, linhas telefônicas analógicas, pacotes de voz ou mesmo de uma vídeo-conferência. Terminações possuem propriedades tais como tamanho máximo de jitter, que pode ser inspecionado e modificado por um MGC. Para uma terminações existe um nome, ou uma identificação (TerminationID) dada pelo MG. Algumas terminações geralmente representam portas de um gateway, assim como timeslots de um E1, ou linhas analógicas onde são nomeadas pelo MG quando inicializado e permanece ativa o tempo todo. Outras terminações são criadas quando existe a necessidade, são utilizadas e podem ser descartadas em seguida. Existe o caso de algumas terminações serem chamadas de efêmeras são usadas para representar fluxos de pacotes de rede tais como voz sobre IP, ou mesmo vídeo sobre IP (RTP), não se trata basicamente de uma terminação física como um timeslot proveniente de um E1, por exemplo.

12 12 Terminações podem ser colocadas em Contextos dos quais são definidos como uma ou mais fluxos/terminações que são interconectados juntos. Normalmente um contexto pode ser uma terminação digamos física, vinda do mundo comutado por circuito como um timeslot, ou linha analógica, e uma efêmera, tais como um fluxo de pacotes de voz, vinda do mundo comutado por pacotes (RTP). Os contextos são criados e terminados pelo MG, sob o comando do MGC. Uma vez criados, ao contexto é dado um nome ou uma identificação (ContextID) e pode ser composto por terminações adicionadas e removidas dele. Um contexto é criado ao ser adicionada primeira terminação, e é destruído quando removida a última terminação. Uma única ligação pode ter duas terminações por contexto, sendo uma terminação representada por um dispositivo final, tal como um telefone analógico e outra terminação representada por um fluxo RTP vinda pela rede. Já uma conferência pode ter dezenas de terminações, sendo cada terminação uma das pernas da conferência. Também é possível ter um contexto com apenas uma terminação digamos numa conferência onde o originador está em conversação com outras duas partes, cada parte sendo representadas por sua única terminação, todas dentro de um mesmo contexto, e o originador pressiona a tecla flash do aparelho para adicionar uma quarta parte, ou utilizar alguma outra facilidade permitida durante a chamada. Uma terminação pode ser constituída de um ou mais fluxos, assim como um contexto pode ser multi-terminações. Audio, video e dados (como por exemplo, T-120 quadro-branco compartilhado) possuem fluxo de pacotes contendo várias terminações. Abaixo uma figura representativa do que ocorre num Media Gateway e seus vários contextos constituídos por terminações provenientes de diferentes tipos (Figura 1). Uma terminação (TerminationID) pode ser especificada por um grupo de tronco, e um tronco específico dentro desse grupo.

13 13 Figura 1: Representação estrutural do que ocorre num Media Gateway ao criar contextos com diferentes terminações. Fonte: Elaboração Própria (2012) Existe um tipo especial de contexto, que é o contexto nulo, que contém todas as terminações que não estão associadas a nenhuma outra terminação, ou seja, todas as terminações que estão livres estão em um contexto nulo ou inexistente. Terminações dentro de um contexto nulo podem ter seus parâmetros examinados ou modificados, e podem ter eventos detectados sobre elas. O asterisco em cada contexto na figura acima representa a associação lógica das terminações em cada contexto. Além de criar conexões basicamente por associar terminações dentro de um contexto, MGs podem também estar aptos a gerar tons, anúncios, toque de chamar,

14 14 e outros sinais que usuários possam escutar. O protocolo MEGACO também inclui facilidades e serviços que permitem que URAs possa ser ligadas e serem controladas, e também possuem indicações de controle de chamadas. Eventos assíncronos, tais como tirar o telefone do gancho, ou pressionar dígitos DTMF podem ser percebidos no MG e relatados ao MGC. Ao utilizar uma notação abreviada conhecida como um Mapa de Dígitos os MG podem ser programados para aguardar pela discagem completa número telefônico e enviar um único número para o MGC como um único evento, reduzindo a quantidade de pacotes enviados desnecessariamente ao MGC, dando mais flexibilidade e agilidade ao sistema. O protocolo MEGACO utiliza um conjunto de comandos para manipular terminações, contextos, eventos e sinais. São esses os principais [RFC3015]: add adiciona uma terminação a um contexto e também pode ser utilizado para criar um contexto ao mesmo tempo. Se o MGC não especificar a qual contexto uma terminação será adicionada, o MG criará um novo contexto automaticamente. subtract remove uma terminação de um contexto e pode resultar de um contexto ser destruído se nenhuma outra terminação restar. Move tem a função de mover uma terminação de um contexto a outro. Modify altera o estado de uma terminação. AuditValue e AuditCapabilities retornam informações sobre terminações, contextos e estados gerais do Media Gateway. ServiceChange cria uma associação de controle, ou em outras palavras, um registro, entre o MG e o MGC e também gerencia situações de falha entre eles. Notify notificação de eventos ocorridos, por exemplo, discagem DTMF in-band. Todos esses comandos são enviados do MGC para o MG, com exceção do ServiceChange que também pode ser enviado pelo MG. Uma terminação apenas pode existir em apenas um contexto de cada vez, e ela poderá ser movida de um contexto a outro através do comando move.

15 15 Todos esses comandos são agrupados em transações dos quais existem uma determinada estrutura e ordem para envio, sempre recebendo respostas, e essas transações podem ser enviadas através das camadas de transporte TCP, UDP ou SCTP. O MGC então envia um acknowledgement, juntamente com as respostas para cada comando para o MG. Abaixo (Figura 2) a estrutura o pacote MEGACO trocado entre MGC e MG. Figura 2: Representação da estrutura do protocolo MEGACO Fonte: [MEGACO User Guide, 2012] Abaixo um exemplo de sequência de mensagens MEGACO trocadas entre MGC e MG [RFC3015]: Mensagem 1: Um MG se registra no MGC utilizando o comando ServiceChange: Sentido: MG1 MGC MEGACO/1 [ ] Transaction = 9998 { Context = - { ServiceChange = ROOT { Services { Method=Restart, ServiceChangeAddress=55555, Profile=ResGW/1

16 16 Mensagem 2: O MGC envia uma resposta: Sentido: MGC MG1 MEGACO/1 [ ]:55555 Reply = 9998 { Context = - {ServiceChange = ROOT { Services { ServiceChangeAddress=55555, Profile=ResGW/1 Mensagem 3: O MGC envia uma resposta: O MGC programa uma terminação em contexto nulo. O ID da terminação (terminationid) é A4444 e o ID do stream (streamid) é 1.O mid é o identificador de quem enviou esta mensagem, nesse caso o endereço IP e porta [ :5555]. O modo para esse fluxo está configurado para SendReceive. al é o pacote de supervisão de linha analógica. Sentido: MGC MG1 MEGACO/1 [ ]:55555 Transaction = 9999 { Context = - { Modify = A4444 { Media { Stream = 1 { LocalControl { Mode = SendReceive, tdmc/gain=2, tdmc/ec=on, Local { v=0 c=in IP4 $ m=audio $ RTP/AVP 0 a=fmtp:pcmu VAD=X-NNVAD, Events = 2222 {al/of

17 17 Mensagem 4: O MG1 aceita o comando Modify com a resposta abaixo: Sentido: MG1 MGC MEGACO/1 [ ]:55555 Reply = 9999 { Context = - {Modify = A4444 Mensagem 5: Uma troca de mensagens similar também ocorre entre o MG2 e o MGC, resultando em uma Terminação em estado livre (idle) chamada A5555. Sentido: MG2 MGC Coletando os dígitos do Originador de Inicializando a Terminação Mensagem 6: O MG1 detecta um evento de fora do gancho do assinante 1, e relata ao MGC através do comando Notify. Sentido: MG1 MGC MEGACO/1 [ ]:55555 Transaction = { Context = - { Notify = A4444 { ObservedEvents =2222 { T :al/of Mensagem 7: O Notify é confirmado pelo MGC. Sentido: MGC MG1 MEGACO/1 [ ]:55555 Reply = { Context = - {Notify = A4444

18 18 Mensagem 8: O MGC modifica a terminação através do comando Modify de forma a procurar por dígitos de acordo com o Plano de Discagem 0 (Dialplan0) e procurar pelo evento no-gancho. Sentido: MGC MG1 Transaction = { Context = - { Modify = A4444 { Events = 2223 { al/on, dd/ce {DigitMap=Dialplan0, Signals {cg/dt, DigitMap=Dialplan0 {(0 00 [17]xxx 8xxxxxxx Fxxxxxxx Exx 91xxxxxxxxxx 9011x.) Mensagem 9: E o comando Modify é confirmado pelo MG1. Sentido: MG1 MGC MEGACO/1 [ ]:55555 Reply = { Context = - {Modify = A4444 Mensagem 10: Em seguida, os dígitos são acumulados no MG1 enquanto são digitados pelo assinante um. O tom de discagem é interrompido ao detectar o primeiro dígito. Quando o número digitado bate com o Plano de Discagem 0 para A4444, outra notificação é enviada ao MGC. Sentido: MG1 MGC MEGACO/1 [ ]:55555 Transaction = { Context = - { Notify = A4444 { ObservedEvents =2223 { T :dd/ce {ds=" ",meth=fm

19 19 Mensagem 11: E o Notify é confirmado pelo MGC. Sentido: MGC MG1 MEGACO/1 [ ]:55555 Reply = { Context = - {Notify = A4444 Mensagem 12: O MGC então analisa os dígitos e determina que uma conexão precisa ser criada entre MG1 e MG2. Ambas as terminações TDM A4444, e a terminação RTP são adicionadas a um contexto no MG1. O modo é ReceiveOnly enquanto os valores da descrição da sessão do assinante remoto não serem especificados ainda. A preferência dada na ordem dos codecs são especificadas pelo que for configurado no MGC. Sentido: MGC MG1 MEGACO/1 [ ]:55555 Transaction = { Context = $ { Add = A4444, Add = $ { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40, Local { v=0 c=in IP4 $ m=audio $ RTP/AVP 4 a=ptime:30 v=0 c=in IP4 $ m=audio $ RTP/AVP 0

20 20 Observação: O MGC indica uma série de parâmetros de acordo com a preferência configurada no campo SDP local. O MG completa o descritor local ($) na sua resposta. Mensagem 13: O MG1 confirma a nova terminação e completa os campos no endereço IP local e porta UDP. Ele também faz a escolha para o codec baseado nas preferências locais. O MG1 programa sua porta para Sentido: MG1 MGC MEGACO/1 [ ]:55555 Reply = { Context = 2000 { Add = A4444, Add= A4445 { Media { Stream = 1 { Local { v=0 c=in IP m=audio 2222 RTP/AVP 4 a=ptime:30 a=recvonly Mensagem 14: O MGC agora irá associar a terminação A5555 com um novo contexto no MG2, e estabelecer um fluxo RTP (A5556 será criado), com a conexão SendReceive no originador Assinante 1. O MGC também irá configurar o toque na terminação A5555. Sentido: MGC MG2 MEGACO/1 [ ]:55555 Transaction = { Context = $ { Add = A5555 { Media { Stream = 1 { LocalControl {Mode = SendReceive, Events=1234{al/of, Signals {al/ri

21 21, Add = $ { Media { Stream = 1 { LocalControl { Mode = SendReceive, nt/jit=40, Local { v=0 c=in IP4 $ m=audio $ RTP/AVP 4 a=ptime:30, Remote { v=0 c=in IP m=audio 2222 RTP/AVP 4 a=ptime:30 Mensagem 15: Esta é então confirmada com um ack. A porta desse fluxo RTP é diferente da porta de controle. Nesse caso é 1111 (na descrição do SDP). Sentido: MG2 MGC MEGACO/1 [ ]:55555 Reply = { Context = 5000 { Add = A5555, Add = A5556 { Media { Stream = 1 { Local { v=0 c=in IP m=audio 1111 RTP/AVP 4

22 22 Mensagem 16: Tanto o endereço IP quanto porta UDP precisam ser passadas ao MG1, então: Sentido: MGC MG1 MEGACO/1 [ ]:55555 Transaction = { Context = 2000 { Modify = A4444 { Signals {cg/rt, Modify = A4445 { Media { Stream = 1 { Remote { v=0 c=in IP m=audio 1111 RTP/AVP 4 Sentido: MG1 MGC MEGACO/1 [ ]:55555 Reply = { Context = 2000 {Modify = A4444, Modify = A4445 Mensagem 17: Os dois MG estão agora conectados, e o assinante um começa a escutar o tom de chamar. O MG2 aguarda até o assinante dois retirar o telefone do gancho para que assim seja estabelecida uma chamada nos dois sentidos. Sentido: MG2 MGC MEGACO/1 [ ]:55555 Transaction = { Context = 5000 { Notify = A5555 { ObservedEvents =1234 { T :al/of

23 23 Sentido: MGC MG2 MEGACO/1 [ ]:55555 Reply = { Context = - {Notify = A5555 Sentido: MGC MG2 MEGACO/1 [ ]:55555 Transaction = { Context = 5000 { Modify = A5555 { Events = 1235 {al/on, Signals { // to turn off ringing Sentido: MG2 MGC MEGACO/1 [ ]:55555 Reply = { Context = 5000 {Modify = A4445 Mensagem 18: Altera o modo do MG1 para SendReceive e para o tom de chamar. Sentido: MGC MG1 MEGACO/1 [ ]:55555 Transaction = { Context = 2000 { Modify = A4445 { Media { Stream = 1 { LocalControl { Mode=SendReceive, Modify = A4444 { Signals { Sentido: MG1 MGC MEGACO/1 [ ]:55555

24 24 Reply = { Context = 2000 {Modify = A4445, Modify = A4444 Mensagem 19: O MGC decide Auditar (Audit) a terminação RTP do MG2. Sentido: MGC MG2 MEGACO/1 [ ]:55555 Transaction = { Context = - { AuditValue = A5556{ Audit{Media, DigitMap, Events, Signals, Packages, Statistics Mensagem 20: O MG2 responde: Sentido: MG2 MGC MEGACO/1 [ ]:55555 Reply = { Context = - { AuditValue = A5556 { Media { TerminationState {ServiceStates=InService,Buffer=OFF, Stream = 1 { LocalControl { Mode = SendReceive, nt/jit=40, Local { v=0 c=in IP m=audio 1111 RTP/AVP 4 a=ptime:30, Remote { v=0 c=in IP m=audio 2222 RTP/AVP 4 a=ptime:30, Events, Signals, DigitMap, Packages {nt-1, rtp-1, Statistics { rtp/ps=1200, // packets sent

25 25 nt/os=62300, // octets sent rtp/pr=700, // packets received nt/or=45100, // octets received rtp/pl=0.2, // packet loss rtp/jit=20, // jitter ms rtp/delay=40 //avg latency Mensagem 21: Quando o MGC recebe um sinal de que o telefone foi colocado no gancho (desconexão), ele derruba a ligação. Nesse exemplo, o assinante do MG2 desligou primeiro. Sentido: MG2 MGC MEGACO/1 [ ]:55555 Transaction = { Context = 5000 { Notify = A5555 { ObservedEvents =1235 { T :al/on Sentido: MGC MG2 MEGACO/1 [ ]:55555 Reply = { Context = - {Notify = A5555 Mensagem 22: O MGC envia então aos dois MG um comando Subtract para que derrube a ligação. Cada terminação com seus próprios conjuntos de estatísticas. Um MGC pode não requisitar retorno às duas terminações. A5555 é uma terminação física, e A5556 é uma terminação efêmera, proveniente de um fluxo RTP [RFC2327]. Sentido: MGC MG2 MEGACO/1 [ ]:55555 Transaction = { Context = 5000 { Subtract = A5555 {Audit{Statistics, Subtract = A5556 {Audit{Statistics

26 26 Mensagem 23: O MGC configura então tanto o MG1 como o MG2 para estar apto a detectar o próximo evento de fora do gancho. Perceba que essa poderia ser o estado de terminação pertencente a um contexto nulo, e se fosse esse o caso, não haveria necessidade de enviar uma mensagem do MGC ao MG. Uma vez que a terminação retorna ao contexto de estado nulo, todos os seus valores retornam ao padrão para essa terminação. Na figura 3 abaixo, podemos ver claramente como as mensagens são trocadas entre cada entidade na rede (Figura 3). Figura 3: Representação gráfica das principais mensagens acima trocadas entre os MG e o controlador MGC Fonte: Elaboração própria (2012). O MEGACO/H248 é um protocolo que foi desenvolvido pela IETF e ITU-T em conjunto para criar uma norma para as mensagens trocadas entre MG e MGC. Como os fabricantes produzem famílias de equipamentos para essa finalidade são obrigatoriamente compelidos a seguirem essa norma [RFC3015], ou seja, o MGC a

27 27 ser desenvolvido pelo fato de ser baseado na norma técnica citada deverá ser capaz de receber mensagens MEGACO/H.248, trata-las e enviar respostas a qualquer outro equipamento, seja qual for o fabricante MEGACO/H.248 ServiceChange O comando ServiceChange permite que um Media Gateway avisa o MGC que uma terminação, ou grupo de terminações está para ser tirado de serviço, ou mesmo que retornaram ao serviço. A estrutura da mensagem de ServiceChange é representada no seguinte formato: TerminationID, [ServiceChangeDescriptor] ServiceChange(TerminationID, ServiceChangeDescriptor ) O parâmetro TerminationID da estrutura acima especifica as terminações que são retiradas, ou que voltaram ao serviço. É permitido mascarar a terminação, e a utilização do termo Root indica que o comando ServiceChange está afetando o MG como um todo [RFC3015, 2012]. O comando ServiceChangeDescriptor contém os seguintes parâmetros como requisito: Method Reason Delay Address Profile Version MGCID TimeStamp

28 28 O parâmetro ServiceChangeMethod especifica o tipo de ServiceChange que irá, ou já ocorreu no Media Gateway. [RFC3015, 2012]. 1) Graceful indica que uma terminação específica será retirada de serviço após um tempo especificado pelo comando ServiceChangeDelay, conexões estabelecidas não são afetadas ainda, mas o MGC deve se conter de estabelecer novas conexões e deve também, desconectar de forma padronizada as conexões existentes que o comando ServiceChange irá afetar. 2) Forced indica que as terminações especificadas foram tiradas de serviço de forma abrupta, e qualquer conexão estabelecida associada com elas foram desconectadas. O MGC é responsável por eliminar o contexto (caso ainda haja algum) que contenha alguma terminação associada. 3) Restart Indica que os serviços serão restaurados na terminação especificada após o tempo do ServiceChangeDelay expirar. 4) Disconnected sempre é aplicado sobre a terminação Root que trata-se sobre o MG como um todo, indica que o MG perdeu comunicação com o MGC, mas que logo após foi restaurada. Desde que o estado do MG possa ter sido alterado, o MGC pode utilizar o comando Audit para resincronizar o estado do MG. 5) Handoff enviado do MGC para o MG, esse motivo indica que o MGC está saindo de serviço e uma nova associação MGC deve ser estabelecida. Já quando enviado do MG para o MGC indica que um MG está tentando estabelecer uma nova associação de acordo com um Handoff recebido de um MGC com o qual está previamente associado. 6) Failover enviado do MG para o MGC para indicar que o MG primário está fora de serviço, e um secundário está assumindo. [RFC3015, 2012]. O parâmetro ServiceChangeReason especifica o motive pelo qual o ServiceChange ocorreu ou irá ocorrer.ele consiste num token alfanumérico (Registrado pelo IANA) e opcionalmente, uma string explicatória. O parâmetro opcional ServiceChangeAddress especifica o endereço para ser utilizado para comunicações subsequentes.

29 29 Um comando ServiceChange especificando a terminationid como root, e o ServicChangeMethod igual a Restart, é um comando de registro ao qual um MG anuncia sua existência ao Media Gateway Controller. O MG é configurado com o nome de um primário, e opcionalmente alguma quantidade de MGC. Um ACK do comando de ServiceChange completa o processo de registro de um MG ao MGC. O MG pode especificar um endereço no parâmetro ServiceChangeAddress da requisição incial do ServiceChange, e o MGC pode também fazê-lo no ServiceChangeReply. Em qualquer um dos casos, o recebedor deve utilizar esse endereço para toda e qualquer mensagem subsequente naquela associação. A resposta de um ServiceChange é vazia exceto quando a terminação Root é utilizada. Nesse caso, ela inclui os seguintes parâmetro como obrigatórios ServiceChangeAddress se o MGC que está respondendo deseja especificar um novo destino para as mensagens do MG para futuras associações. ServiceChangeMgcID se o MGC que está respondendo não deseja criar novas associações com o MG. ServiceChangeProfile se quem está respondendo deseja negociar o perfil que está sendo utilizado na associação. ServiceChangeVersion se quem está respondendo deseja negociar a versão do protocolo utilizado para a associação. As seguintes ServiceChangeReasons são definidas, e são registradas pelo IANA [RFC3015, 2012]. 900 Service Restored 901 Cold Boot 902 Warm Boot 903 MGC Directed Change 904 Termination malfunctioning 905 Termination taken out of service 906 Loss of lower layer connectivity (e.g. downstream sync) 907 Transmission Failure 908 MG Impending Failure

30 MGC Impending Failure 910 Media Capability Failure 911 Modem Capability Failure 912 Mux Capability Failure 913 Signal Capability Failure 914 Event Capability Failure 915 State Loss 2.2 PROTOCOLO DE INICIALIZAÇÃO DE SESSÃO SIP O protocolo SIP Session Initiation Protocol, ou protocolo de inicialização de sessão, se trata de um protocolo da camada OSI para iniciar, gerenciar e finalizar sessões, que basicamente são chamadas multimídia entre usuários, seja uma ligação telefônica ou mesmo uma vídeo-conferência entre dois ou mais assinantes. Suas funcionalidades são basicamente responsáveis por registrar usuários em servidores de registro, através desse registro futuramente será possível localizar um usuário quando requisitado. O protocolo SIP é baseado numa topologia cliente-servidor, assim como o MEGAGO/H.248 apresentado anteriormente, possui a função Cliente, que é responsável por gerar requisições aos servidores (MGC), e Servidor que recebe e responde requisições vindas de clientes. A figura 4 representa um diagrama de blocos do sistema proposto, e então desenvolvido até o presente momento. Figura 4: Representação em diagrama de blocos do sistema desenvolvido até o presente momento. Fonte: Elaboração própria (2012).

31 31 Essas requisições vindas de clientes são iniciadas por um convite INVITE que é enviado juntamente com uma descrição das suas características de transporte, endereço IP, porta, tipo de mídia suportado entre outros detalhes, ao agente de destino, que irá responder quais suas características de mídia são suportadas ao originador da chamada. O protocolo SIP utiliza servidores de registro, e servidores proxy para autenticação, para ajudar a rotear e localizar o usuário/agente SIP de destino, além de providenciarem facilidades aos agentes SIP na rede. O servidor de registro permite que o agente SIP envie sua localização a cada instante de tempo, para que quando chegue uma requisição a esse servidor de registro, ele tenha a localização atualizada de seu endereço de rede, além de servidor de proxy que é utilizado para controle de registro através de autenticação dada por usuário e senha desses usuários SIP, oferecendo um determinado nível de segurança ao sistema, ou seja, para eu me registrar num determinado servidor eu preciso provar que eu sou eu mesmo através de credenciais criptografadas em MD5. Atualmente existem várias aplicações na internet que necessitam da criação, e gerenciamento de sessões, seja uma ligação telefônica ou mesmo vídeo conferência. A facilidade que o protocolo SIP nos oferece nesse tipo sessão é a vantagem da localização de um usuário, como o mesmo está constantemente atualizando sua posição/endereço na rede, basta realizar uma consulta ao seu servidor de registro, que ele encaminhará a requisição para o agente na rede ao qual a mensagem SIP se destina. O protocolo SIP, também oferece suporte de forma transparente ao serviço de mapeamento de nomes, tais como consultas DNS, e serviços de encaminhamento de mensagens, fazendo com que um servidor de registro/proxy possa realizar consulta em outros servidores, tornando-se possível a mobilidade de agentes SIP na rede entre diversos servidores de registro, estando sempre disponível quando requisitado por outro agente SIP. Existem cinco características que o protocolo suporta que são interessantes comentarmos para entrar mais à fundo no estudo do protocolo. Localização do agente: determinação do destinatário final que será utilizado para comunicação

32 32 Disponibilidade de usuário: determinação da aptidão do usuário final na rede, o agente de destino pode estar com serviços habilitados tais como não perturbe, ou indisponível na rede para retornar esse status ao agente que está tentando originar uma sessão. Possibilidade dos usuários: o protocolo SIP trabalha juntamente com o protocolo de descrição de sessão SDP (Session Description Protocol) assim como o MEGACO/H.248, cada parte tanto originador como destino estabelecem quais as características da sessão ambas suportam para chegar a um consenso. Gerenciamento de sessão: incluindo transferências e finalização das sessões, modificando os parâmetros da sessão, além de oferecer serviços na sessão. Modificação da sessão: Através de novos comandos durante a sessão é possível alterar as características de mídia trocadas entre as partes, por exemplo, uma transmissão de fax. SIP é um protocolo que pode ser utilizado, e de fato é utilizado em conjunto com outros protocolos desenvolvidos pela IETF, para que possamos ter uma arquitetura completa para transporte multimídia. Basicamente, esses protocolos podem ser o RTP (Real-Time Transport Protocol), ou seja, protocolo de transporte de tempo real [RFC1889], para o transporte do sinal multimídia codificado e também para obter uma auditoria do QoS (Quality of Service) na rede, protocolo de descrição de sessão [RFC2327] já mencionado anteriormente, entre outros. Abaixo (Figura 5) uma visão sobre a arquitetura SIP, SDP, MEGACO e RTP organizadas no Modelo OSI (Open Systems Interconnection) para que possamos ter um melhor entendimento das tecnologias, protocolos de sinalização, controle, e transporte que utilizaremos.

33 33 Figura 5: Representação da arquitetura utilizada pelos protocolos referidos até o momento sobre o modelo OSI de camadas. Fonte: Elaboração própria (2012). Como o protocolo SIP é responsável pelo gerenciamento da sessão entre os agentes SIP na rede, vejamos então como funciona o sistema de localização básico, e estabelecimento da sessão SIP entre dois elementos da rede, localizados em servidores de registro/proxy diferentes. A Figura abaixo (Figura 6) apresenta a troca de mensagens SIP entre dois usuários, assinante A e assinante B. Nesse exemplo o assinante A utiliza uma aplicação SIP (softphone) em seu computador para ligar para o assinante B em seu aparelho telefônico SIP que se encontra na internet. Também são apresentados dois servidores de registro/proxy, que atuarão no estabelecimento da sessão entre o assinante A e B facilitando a localização entre essas partes.

34 34 Figura 6: Exemplo da sinalização trocada entre duas partes através do serviço de localização dos servidores SIP. Fonte: Elaboração própria (2012). O assinante A liga para o assinante B utilizando sua identificação SIP, que é chamada de URI Uniform Resource Identifier. O SIP URI é composto por um nome de usuário seguido de um domínio, que é basicamente a estrutura de um , como por exemplo: por exemplo, onde CWB-server.com é o domínio do provedor SIP do assinante B. O assinante A possui um SIP URI referente ao seu próprio domínio oferecido pelo seu servidor SIP, O protocolo SIP é baseado numa arquitetura requisição-resposta, onde cada transação consiste em uma requisição que chama métodos, ou funções particulares ao servidor que retornará ao menos uma resposta a cada método/requisição. No exemplo da Figura 6, a sessão é iniciada quando o assinante A envia um convite (INVITE) destinado ao assinante B (M1). O método INVITE contém uma série de cabeçalhos, informações e identificadores únicos na rede que representam aquela chamada que está para acontecer, como o endereço do assinante A e informações

35 35 sobre o tipo de sessão que ele gostaria de estabelecer com o assinante B, que é a descrição das características de mídia, tais como o endereço IP e porta para contato do assinante A. Como o softphone do assinante A não conhece a localização do assinante B, ou o domínio do servidor de registro SIP CWB-sipserver.com, o assinante A envia um pacote de INVITE (M1) ao servidor SIP POA-sipserver.com, seu próprio servidor. O servidor POA-sipserver.com então recebe o INVITE e já envia uma resposta 100 Trying (M3) ao assinante originador. Essa resposta indica que aquele INVITE foi recebido e o servidor está trabalhando para que a mensagem INVITE seja roteada para seu destino correto. Essas respostas SIP são constituídas por número de três dígitos e seguidas de uma palavra descritiva do que está ocorrendo na resposta/transação. O servidor POA-sipserver.com localiza então o servidor de CWB-sipserver.com através de uma consulta ao seu servidor DNS previamente configurado obtendo seu endereço IP referente ao DNS consultado, e reencaminha o INVITE (M4) recebido para o endereço IP do servidor SIP CWB-sipserver.com. Mas antes de encaminhar a mensagem, o servidor POA-sipserver.com adiciona ao campo via, dentro do cabeçalho do pacote INVITE um campo que contém seu próprio endereço, para que ao retornar transações elas tenham que passar por ele novamente. O servidor CWB-sipserver.com recebe então o INVITE (M4) que foi reencaminhado pelo POA-sipserver, e responde ao servidor POA-sipserver.com que recebeu o INVITE através de um 100 Trying (M5) também, indicando que recebeu a requisição e está tratando de resolvê-la. O servidor CWB-sipserver então realiza uma consulta em sua base de registros SIP, também conhecida como serviço de localização (location service), que contém o endereço IP atual do assinante B de destino, que previamente se registrou nesse servidor. O servidor CWB-sipserver.com então adiciona um valor adicional no campo via novamente, e finalmente encaminha o INVITE (M4) ao assinante B. O assinante B finalmente recebe o INVITE da chamada entrante proveniente do assinante A fazendo com que toque seu aparelho SIP. No momento em que o telefone SIP do assinante B começa a tocar, o assinante A, originador daquela chamada recebe um status 180 Ringing (M6), que indica que o assinante B foi contatado com sucesso, está disponível e também está chamando. Essa resposta

36 do assinante B para A passa pelos dois servidores SIP (M6 e M7), devido à inserção de seus endereços no campo via. Quando o assinante B decide então atender à chamada retirando o aparelho SIP do gancho, ele automaticamente envia uma mensagem 200 OK (M9) ao assinante A juntamente com a sua descrição da sessão, tipo de mídia, endereço IP e porta de conexão para que o assinante A possa se comunicar diretamente com o assinante B, utilizando uma mídia na qual as duas partes tenham decidido através das ofertas e respostas das mensagens SDP trocadas. Quando o assinante A recebe a mensagem de retorno 200 OK (M11) significa que a sessão pode ser estabelecida. O assinante A então confirma a mensagem 200 OK com um ACK (M12) concluindo assim o estabelecimento da sessão entre as duas partes. Nesse momento o fluxo de mídia RTP (M13) é trocado diretamente entre as duas partes, sem a necessidade de passar pelos servidores SIP que auxiliaram na localização entre as partes. Nesse caso a mensagem 200 OK foi roteada novamente entre os servidores SIP e recebida pelo softphone do assinante A, ao receber essa mensagem, ela envia um ACK de confirmação diretamente ao assinante B dizendo que sabe que ele atendeu a chamada, provendo comunicação direta entre as duas partes, sem necessidade de passar pelos dois servidores SIP. Isso ocorre devido aos dois dispositivos finais terem aprendido o endereço de cada um através do campo Connection Information contido dentro do conteúdo SDP enviado tanto no INVITE pelo originador da chamada, quanto no campo 200 OK quando o destino é finalmente contatado e responde ao chamado. Esse procedimento de INVITE-OK-ACK é conhecido como um handshake entre as partes para estabelecimento inicial de parâmetros da sessão. Nesse momento acontece o estabelecimento da sessão entre o assinante A e o assinante B utilizando o formato em que houve uma concordância na negociação desses parâmetros para a sessão, tais como tipo de mídia (CODECS), porta de contato, áudio/vídeo, endereço IP de conexão, entre outros parâmetros de sessão. Esses pacotes de mídia são transportados sobre o protocolo de transporte de tempo real (RTP), sobre o protocolo UDP, pois não necessita de um controle tão criterioso como o TCP. Outros protocolos oferecem suporte ao RTP, como o RTCP que oferece um determinado nível controle sobre o fluxo de mídia RTP trocado entre as partes.

37 37 Caso haja a necessidade de alterar os parâmetros da sessão estabelecida, é possível que uma das partes envie um RE-INVITE, com uma nova oferta de parâmetros de descrição de mídia (SDP) para que a parte recebida retorne um 200 OK concordando com os parâmetros recebidos alterando a sessão após o envio de um ACK, fazendo novamente o triplo handshake entre as partes. Essa oferta de RE-INVITE é muito utilizado para transmissão de fax (T30/T38), pois inicialmente tem se uma conversa inicial numa determinada sessão estabelecida, até que alguém pressiona o botão de iniciar transmissão do fax, nesse momento, percebe-se um sinal de fax na linha e as entidades enviam RE-INVITEs negociando um novo codec que dê suporte à transmissão desses dados. Ao final da chamada, o assinante B desliga a ligação e gera uma mensagem BYE (M14) que é enviada diretamente ao assinante A. O assinante A ao receber a solicitação de desconexão, escuta o tom de ocupado. Quando o assinante A colocar o telefone no gancho, enviará um 200 OK (M15) confirmando a desconexão completa da sessão.

38 38 3 DETALHAMENTO DO PROJETO DESENVOLVIDO O sistema desenvolvido até o presente momento foi baseado numa arquitetura cliente-servidor, desenvolvida em linguagem C/C++ no ambiente de desenvolvimento QT Creator [QT CREATOR, 2011] para sistema operacional Windows. O sistema cliente-servidor baseia-se numa premissa de que deve receber inicialmente registro de agentes SIP na rede, que são considerados clientes SIP, que podem ser desde SoftPhones simulando as funções de um aparelho telefônico através de um software no computador ou smarphone, hardphone que é um aparelho telefônico físico, ligado à rede que possui as funções de um cliente SIP ou mesmo Media Gateways que possuem a funções de cliente SIP podendo-se registrar-se no Media Gateway Controller desenvolvido. O protocolo SIP é um sistema desenvolvido pela IETF, baseia-se em mensagens trocadas entre cliente e servidor em texto puro, portanto são basicamente strings recebidas de agentes na rede que devem ser tratadas através de uma análise conhecida como parsing da mensagem. Ao realizar essa análise, temos basicamente uma estrutura com todas as informações importantes de cada mensagem SIP recebida na rede. 3.1 SIP PROTOCOLO DE INICIALIZAÇÃO DE SESSÃO REGISTRO O sistema de registro tem por finalidade realizar a análise do pacote SIP recebido na rede e extrair dessa mensagem as informações de Usuário, endereço IP de rede, porta de conexão do endereço IP, e tempo de registro que irá validar o usuário no Media Gateway Controller desenvolvido. O sistema desenvolvido, apesar de tratar esse dado do pacote, não possui a função de cancelar o registro de um agente SIP caso o tempo de registro expire. Ao realizar a análise (parse) da mensagem recebida o MGC salva a informação de registro numa tabela que pode ser utilizada para consulta posteriormente para consultar os dados de endereçamento de cada usuário

39 39 conhecido na rede. Essa tabela de registro é um vetor de informações das quais estão contidos todos os agentes SIP da rede, e é acessada constantemente pelo sistema no momento de encaminhar ligações para agentes, verificar se um agente existe ou não no momento de gerar uma chamada, etc. Conforme a figura 7 abaixo, uma representação do funcionamento do registro SIP entre agente e MGC e uma caracterização das requisições e respostas. Figura 7: Representação dos agentes/usuários SIP registrando-se MGC. Fonte: Elaboração própria (2012). O agente SIP pode realizar três funções básicas dentro da operação de registro, que são: REGISTRO: O agente SIP insere um novo registro na tabela de controle do MGC, enviando seu endereço de conexão, porta, nome, etc. O Media Gateway Controller faz uma verificação se o usuário em questão já xiste nas tabelas, caso ainda não exista, o MGC faz uma verificação do campo Expires: da mensagem SIP se é diferente de zero. Caso seja realmente diferente de zero, o novo registro SIP é inserido na tabela.

40 40 REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP :5060;rport;branch=z9hG4bKPjoqaxu6wbez Max-Forwards: 70 From: "IPhone" To: "IPhone" Call-ID: ejjq53yqtpcgcqa41e8w2pdmrx8xox2c CSeq: REGISTER User-Agent: isip v4.8.7/iphoneos Contact: "IPhone" Expires: 30 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 ATUALIZAR: Ao terminar o tempo de registro do cliente (Expires), o usuário reenvia uma mensagem de registro solicitando ao MGC que atualize os dados em sua tabela sobre sua localização. O MGC verifica inicialmente se já existe o usuário registrado na sua tabela. Já estando registrado, o MGC verifica se o campo Expires: é diferente de zero, sendo assim, ele reinsere os dados do registro sobre os valores anteriores, atualizando o agente em sua tabela de localização. CANCELAR REGISTRO: O usuário simplesmente se desabilita do servidor. O MGC inicialmente verifica se o usuário já está cadastrado, sendo assim ele verifica se o campo Expires: é igual a zero, o que determina a indicação de cancelamento de registro segundo a RFC3261 [RFC3261], completando assim sua ação de remoção. REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP :5060;rport;branch=z9hG4bKPjbufl3hjov Max-Forwards: 70 From: "Ipad" To: "Ipad" Call-ID: ioj4ecwkeowa4xoggxseybw.r7x61fw6 CSeq: REGISTER User-Agent: isip v4.8.7/iphoneos Contact: "Ipad" Expires: 0 Content-Length: 0 Conforme o diagrama de fluxo de dados abaixo (Figura 8) é possível ter um melhor entendimento do funcionamento do sistema de registro do MGC.

41 41 Figura 8: Diagrama de fluxo de dados da função de Registro do MGC, desenvolvido em linguagem C++ no IDE QT Creator. Fonte: Elaboração própria (2012) INVITE INÍCIO DE SESSÃO ` O MGC está aguardando requisições na porta SIP, e sempre que recebe algum dado nessa porta, significa que existe algum agente SIP precisando de algum recurso do softswitch. Ao receber dados na porta SIP, o MGC realiza uma análise da mensagem recebida para determinar qual o tipo de requisição que está sendo solicitada. Ao receber uma requisição do tipo INVITE, significa que existe um agente SIP iniciando um estabelecimento de sessão com outro agente na rede. A função do MGC nesse caso é tratar esse pacote de invite, e verificar à qual usuário de destino essa requisição será gerado.

42 42 Verificado o destino dessa mensagem, o MGC realiza uma busca em sua tabela de registros SIP para verificar se o destinatário da mensagem encontra-se registrado no sistema. Se o usuário destino não estiver cadastrado, o MGC simplesmente retorna uma mensagem de que não há agente com esse número/nome cadastrado, e retorna ao seu estado de espera normal. Caso o usuário destino seja localizado com sucesso na tabela de registros SIP do MGC, o mesmo gera uma requisição nova do tipo INVITE para o agente de destino, e retorna um Trying para o agente de origem, como se fosse uma mensagem do tipo aguarde, estou verificando sua requisição. Ao gerar o INVITE para o agente de destino, o mesmo retorna a sua disponibilidade, se está livre, em segue irá retornar ao softswitch uma mensagem do tipo 180 Ringing informando que o aparelho está tocando. Essa mensagem 180 é encaminhada ao agente de origem da requisição e, ao recebe-la, ele passa a escutar o tom de chamar ringback tone. Com isso, o agente destino está tocando, e o agente de origem está escutando o tom de chamar, como numa chamada telefônica convencional. Quando o usuário SIP de destino retira o telefone do gancho, ele retorna um 200 OK para o softswitch, e o mesmo é repassado ao agente de origem, indicando o atendimento da chamada. Note que na mensagem inicial (INVITE) o usuário de origem envia ao softswitch eu deseja estabelecer uma chamada com o usuário de destino, e juntamente com essa requisição ele envia a característica da sessão, qual seu IP de contato e quais seus codecs disponíveis. Ao receber o 200 OK do atendimento, o usuário de destino envia juntamente com o 200 OK um corpo de mensagem do tipo SDP Session Description Protocol informando a descrição da sessão, qual codec efetivamente será trabalhado, e seu endereço IP e porta de contato. Recebendo o 200 OK, o usuário origem envia um ACK de confirmação ao usuário destino e a sessão é finalmente estabelecida. Outra possibilidade é o usuário destino estar ocupado no momento em que o INVITE é reencaminhado do softswitch para o agente destino. Nisso o agente destino retorna uma mensagem do tipo 486 Busy Here para informar que a parte não está disponível no sistema, finalizando assim a requisição de sessão do usuário originador.

43 43 Abaixo um diagrama de fluxo de dados (Figura 9) ao qual o projeto foi desenvolvido, caracterizando uma requisição de estabelecimento de sessão. Figura 9: Diagrama de fluxo de dados do tratamento da função de INVITE do MGC, desenvolvido em linguagem C++ no IDE QT Creator. Fonte: Elaboração própria (2012). Os testes foram realizados com o servidor softswitch em funcionamento em computadores, aos quais dispositivos IPhone 3GS e IPad2 enviavam requisições IP ao softswitch através da rede, fazendo com que o softswitch desenvolvido gerasse as respostas corretas ao ponto de que uma sessão, ou ligação telefônica, fosse estabelecida entre as partes com sucesso. A aplicação SIP utilizada para os dispositivos foi o aplicativo Isip da empresa desenvolvedora VNET Corporation [VNET, 2012] gerando requisições de Registro e início de sessão com sucesso entre os dispositivos. Em conjunto com esses dispositivos, foi utilizado um Media Gateway do Fabricante Panasonic modelo KX-TDE600BR como cliente SIP para se registrar no

44 44 softswitch desenvolvido e com sucesso foi estabelecida uma sessão full-duplex com sucesso entre clientes SIP de fabricantes diferentes. Abaixo uma topologia do cenário (Figura 10) criado para testes do funcionamento do softswitch desenvolvido com base nas normas IETF referidas na bibliografia do projeto. Figura 10: Cenário criado para realização dos testes com o softswitch desenvolvido. Fonte: Elaboração própria TRATAMENTO DAS MENSAGENS SIP O projeto tem em sua raiz uma ferramenta de análise desenvolvida para receber e tratar o protocolo SIP entre outros relacionados, e transformar o que é uma string recebida de um buffer via socket em uma estrutura organizada das quais serão extraídas informações fundamentais para a tomada de decisão do sistema.

45 45 O método utilizado para tradução do buffer recebido em estruturas complexas é o parse da mensagem SIP, ao qual tem a finalidade de percorrer caractere à caractere e de acordo com regras estipuladas pela norma técnica do SIP [RFC3261] é interpretado o campo da mensagem. Por exemplo, uma mensagem de registro que é recebida em seu formato de texto puro é interpretada da seguinte maneira. REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP :5060;rport;branch=z9hG4bKPjbufl3hjov Max-Forwards: 70 From: "Ipad" To: "Ipad" Call-ID: ioj4ecwkeowa4xoggxseybw.r7x61fw6 CSeq: REGISTER User-Agent: isip v4.8.7/iphoneos Contact: "Ipad" Expires: 0 Content-Length: 0 A função responsável pelo parsing dessa mensagem cria um ponteiro como índice inicial (p0), e outro como índice final (p1). O parse percorre desde o caractere zero da string recebida até encontrar a primeira quebra de linha, identificada como \n ou CRLF (Carrier Return Line Feed). Assim temos: REGISTER sip: SIP/2.0 Em seguida o sistema percorre novamente a substring retornada, percorrendo cada palavra, até encontrar um espaço em branco entre elas, e gera novas substring, assim vai recortando a frase em palavras. Essas palavras vão sendo associadas a estruturas pré-definidas no softswitch dando sentido à mensagem recebida aos poucos. Assim a frase acima, é convertida para uma estrutura onde, finalmente será associada da seguinte forma: struct SIP_Overhead { string method; string sent_by_address; unsigned int port; string version;

46 46 Onde teremos após a realização do parse da linha: SIP_Overhead.method = REGISTER SIP_Overhead.sent_by_address = SIP_Overhead.port = - SIP_Overhead.version = SIP/2.0 A segunda linha sera interpretada como: Via: SIP/2.0/UDP :5060;rport;branch=z9hG4bKPjbufl3hjov struct SIP_Via { string transport; string sent_by_address; unsigned int port; string branch; string rport; ; Onde teremos após a realização do parse da linha: SIP_Via.transport = SIP/2.0/UDP SIP_Via.sent_by_address = SIP_Via.port = 5060 SIP_Via.branch = branch= z9hg4bkpjbufl3hjov SIP_Via.rport = rport E assim por diante, até finalizar a quantidade de bytes recebidos pelo buffer. A princípio isso parecer ser um processo lento e desgastante em termos de processamento, mas através de medições utilizando temporizadores no sistema desenvolvido, o tempo de processamento das mensagens ficou em todas as medições abaixo de 1ms. 3.2 MEGACO MEDIA GATEWAY CONTROLLER (H.248) Para o desenvolvimento do protocolo MEGACO/H.248 foram necessárias a criação de uma nova biblioteca de tratamento para mensagems recebidas pelos

47 47 Media Gateways da empresa desenvolvedora Genband. O desenvolvimento de uma ferramenta didática para operadora como Media Gateway Controller (MGC) na rede, dando ordens para os MG funciona numa plataforma cliente-servidor, onde o cliente gera requisições através do protocolo H.248 e o servidor responde à essas requisições, dentro de uma máquina de estado regida pela RFC3015. O cenário desenvolvido para o funcionamento do projeto, representado pela figura abaixo (Figura 11) conta com dois terminais analógicos providos de um modem que se comunica diretamente com o MG G2 via protocolo MGCP. Figura 11: Topologia criada para desenvolver o MGC no laboratório genband. Fonte: Elaboração própria Ao inicializar a aplicação de MGC desenvolvida, os terminais analógicos inclusive o MG G2 devem-se registrar-se ao MGC através de um comando SERVICECHANGE para que possam efetivamente receber e enviar mensagens H.248 para o controlador da rede. Esse processo de ServiceChange pode ser controlado através de comandos dados no próprio MG, esses comandos podem ser encontrados no tutorial em anexo para H.248. A cadeia de comandos é apresentada abaixo, na figura 12.

48 48 Figura 12: Sequencia de comandos ServiceChange trocandos entre MG e MGC para o início da utilização das terminações do MG G2. Fonte: Elaboração própria Os comandos 3 e 4 (Strict-State) que vemos acima, são enviados para as terminações não-root ou seja, apenas para os ramais analógicos providos pelo CPE. Esse comando é necessário para que o MG passe a monitorar as terminações ao serem retiradas do gancho, ou mesmo colocadas no gancho, para que o MGC possa enviar tons de discagem, ou mesmo de ocupado quando o ramal sair ou entrar no gancho. Já para a terminação root, representando o MG como um todo, não é necessário esse comando, portanto o MGC não envia quando se trata do root. Quando um terminal analógico provido pelo modem (CPE) retira o fone do gancho, o modem troca informações com o Media Gateway via protocolo MGCP, mas o MG envia um comando de notificação (NOTIFY) ao MGC inforando que uma terminação foi retidada do gancho. O MGC ao receber tal mensagem, confirma o recebimento e já aciona o MG para que envie tom de discagem para a terminação que saiu do gancho. Ao enviar o tom de discagem, o MG cria um contexto automaticamente para a terminação que saiu do gancho, além de informar o MGC de seus parâmetros SDP (Session Description Protocol) para que o tom de discagem seja gerado, e o MGC possa utilizar esses parâmetros ao inicializar uma sessão quando necessário.

49 49 Como podemos avaliar no fluxograma abaixo Figura 13, o comportamento da aplicação MGC desenvolvida para os casos de eventos recebidos pelo MGC no caso de retirar uma terminação do gancho, ou mesmo coloca-la. Figura 13: Fluxograma para os comandos ServiceChange representando o funcionamento do Media Gateway Controller desenvolvido. Fonte: Elaboração própria Após o desenvolvimento da primeira etapa, onde tratava o basicamente comandos de registro, e também o controle dos mesmos para terminações ou mesmo entidades MG que se registram no MGC passamos para o desenvolvimento dos comandos de inicialização de sessão, ou seja, o que era efetivamente necessário para estabelecer uma sessão entre as terminações do MG. Os primeiros passos envolveram retirar aparelhos do gancho, envio de tom de discagem, tratamento de mensagens através da criação de uma biblioteca de controle das mensagens H.248 e também travamento de mensagens de colocar uma terminação no gancho, por exemplo. Abaixo o fluxograma de funcionamento do protocolo H.248 desenvolvido na aplicação MGC, figura 14.

50 50 Figura 14: Fluxograma para os comandos de Notify enviados pelo MG para tratamento no MGC.. Fonte: Elaboração própria Já o comando Notify para o MG funciona para notificar o MGC das ações em que foram tomadas pelas suas termiançoes, tais como retirar um aparelho do gancho, coloca-lo no gancho, e também, nesse caso para informar que estão realizando uma discagem para algum número telefônico. Ao receber o comando Notify, o MGC verificar qual informação está contida no comando, se for um evento de aparelho fora do gancho, representado pelo sinal al/of (off-hook) o MGC confirma o recebimento do sinal e envia um comando add para o MG, informando-o que o MG deve criar um contexto para essa terminação que deseja inicar um contexto basicamente para controlar uma sessão com base nessas informações. O MG então cria o contexto e o informa para o MGC juntamente com seus parâmetros SDP que foram configurados para aquela terminação efêmera. Esses parâmetros de contexto e SDP são então salvos em memória para aquela termiançao ativa, pois serão posteriormente utilizados para o estabelecimento da chamada.

51 51 Ao receber o comando Notify, o MGC verifica qual a informação novamente está contida, se for um evento de no gancho representado pelo sinal al/on (on-hook) o MGC responde o MG confirmando o recebimento da mensagem, e automaticamente gera uma menagem de Subtract para excluir aquele contexto que foi salvo em memória para a terminação que foi ao gancho, liberando-o e também gera uma mensagem de strict-state informando o MG que o aparelho está no gancho, e deverá informar ao MGC as novas notificações que ocorrerem a partir desse momento, conforme representado pelas mensagens na figura 15. Figura 15: Fluxograma para os comandos de Notify enviados pelo MG para tratamento no MGC no caso de terminação colocada no gancho. Fonte: Elaboração própria Ao receber o comando Notify, o MGC verifica qual a informação novamente está contida, se for um evento de no gancho representado pelo sinal xdd/xce, indica que uma terminação do MG registrado ao MGC, está realizando uma ligação para um determinado número telefônico. O MGC inicialmente recebe esse número discado e o compara se é válido em primeiro lugar, evitando que uma terminação ligue para um número inexistente. Caso seja percebido um telefone inválido, ou mesmo não registrado no MGC, o MGC responde um sinal de número inválido (cg/wt) para o MG, fazendo com que o mesmo escute um tom de aviso, número incorreto. Caso seja percebido que a terminação digitou um telefone válido, o MGC dá andamento à chamada fazendo com que a terminação de origem comece a escutar

52 52 um tom de chamar (ringback-tone) e também envie um sinal de tom de chamada (al/rt) para a terminação destino, para que o aparelho telefônico comece e tocar efetivamente. Ao enviar o sinal de ringback-tone para a terminação de destino, o MG informa ao MGC os parâmetros SDP da terminação remota, como resposta ao comando add informado pelo MGC ao MG. Realizados esses passos de controle de chamada, o MGC começa a monitorar algum evento de fora do gancho por parte da terminação destino que está chamando. Recebido esse evento de atendimento/fora do gancho representado pelo sinal (al/of) o MGC percebe que ouve o atendimento efetivo da chamada, e como o MGC possui os parâmetros de contexto, tanto local quanto remoto, terminações local e remoto e também os parâmetros SDP local e remoto, o que o sistema faz é apresentar através do comando Modify a terminação originadora aos parâmetros SDP remoto, e apresentar a terminação destino aos parâmetros SDP local, fazendo com que seja finalmente estabelecida uma sessão entre as partes originadora e chamadora, full-duplex, conforme representado na figura 16 abaixo. Figura 16: Representação do estabelecimento de uma sessão controlada pelo Media Gateway Controller através do comando Modify. Fonte: Elaboração própria Após estabelecida a sessão entre as terminações origem-destino, o MGC fica atento para as notificações de desligamento por parte das terminações. Ao receber o comando Notify, ele precura por qual sinal está vindo, ou seja desligamento (al/on) e realiza a desconexão das chamadas, enviando tom de ocupado/desligamento para a terminação que não efetuou a desconexão da chamada, e o comando de subtract para a terminação que foi ao gancho, anulando o contexto que foi criado quando ele

53 53 originou a chamada, ou mesmo, atendeu a ligação. Após o comando de subtract, o MGC envia um comando de strict-state para a terminação informando o MGC para que envie notificações futuras sobre aparelho fora do gancho, atendimento, etc. Já para a terminação que ficou ouvindo o tom de ocupado, o MGC realiza o mesmo procedimento de subtract para o contexto que foi criado quando ele atendeu a ligação, e após a anulação do contexto criado para ele, o MGC já percebe que ele ainda está fora do gancho, já enviando tom de discagem para essa mesma terminação, finalizando assim o processo. Abaixo na figura 17, representa o fluxograma da aplicação desenvolvida para controle das mensagens ao realizar uma chamada. Figura 17: Representação do estabelecimento de uma sessão controlada pelo Media Gateway Controller. Fonte: Elaboração própria Ao inicializar a aplicação, o MG precisa obrigatoriamente estar registrado no MGC, para que possa receber e enviar comandos H.248, e o mesmo procedimento

54 54 deve ser executado para as terminações associadas ao MG, também devem obrigaroriamente estarem registradas no MGC. Para que isso ocorra, existem alguns comandos que devem ser dados para cancelar o vínculo criado entre MGC e MG, e Terminações-MG. Esses comandos iniciais estão detalhados no tutorial anexado ao projeto, para controle das terminações via TCP-client dos terminais do Media Gateway Genband. Ao inicializar a aplicação, já é também apresentada uma tela inicial que dará os comandos ao operador, para facilitar a utilização da aplicação MGC desenvolvida. Sucesso ao inicializar thread para protocolo SIP Sucesso ao inicializar thread para protocolo H.248 Aguardando informações nas portas UDP H.248 (2944) e SIP (5060) H.248 Media Gateway G2 Commands: telnet (username: admin / password: Genband2012) 1 - lock vmg PLG1 2 - unlock vmg PLG1 3 - lock lines v52 all 4 - unlock lines v52 all OBS: Você pode criar aliases para facilitar, ex: 'alias lock_mgc "lock vmg PLG1"' Abaixo uma representação das entidades H.248 registrados no MGC, após a finalização dos comandos digitados acima :01: Agentes H.248 Registrados Posição H.248_Register_Table[0] TransactionID: Termination: ROOT MediaGatewayID: [ ]:2944 Posição H.248_Register_Table[1] TransactionID: Termination: aaln/1 MediaGatewayID: [ ]:2944 Telefone: Posição H.248_Register_Table[2] TransactionID: Termination: aaln/2 MediaGatewayID: [ ]:2944 Telefone:

55 55 Na aplicação desenvolvida, para facilitar o acompanhamento e manuseamento das mensagens H.248 trocadas entre MGC e MG, entre requisições e respostas, foi adicionado o sentido e descrição das indentificaçõe de transações e respostas, e contexto envolvido na transação entre MG e MGC, a finalidade é facilitar o aprendizado e também a análise das mensagens num determinado cenário entre chamadas, por exemplo uma terminação tirando o aparelho do gancho. < < Transaction: / Context: - Recebido evento de fora do gancho (AL/OF) para terminação aaln/1 MEGACO/1 [ ]:2944 Transaction=10837{Context=- {Notify=aaln/1{ObservedEvents=6{ T :AL/OF{INIT=FALSE > > Reply: / Context: - Enviado reply para terminação fora do gancho: aaln/1 MEGACO/1 [ ]:2944 Reply=10837{Context=- {Notify=aaln/1{ObservedEvents=6{ T :AL/OF{INIT=FALSE > > Transaction: 9 / Context: $ Enviado comando de tom de discagem (AL/DT) para terminação: aaln/1!/1 [ ]:2944 Transaction= 9{ Context= $ { Add= aaln/1 { Media {Stream=1{LocalControl{Mode=sendonly,tdmc/ec=on, Events = 12 {al/on{strict=state,xdd/xce{mp=enhanced,bc=60,dm={t:16, (958XXXX 959XXXX 0S XXXXS 01[2-9]XXXX S 011[2-9]XXXX S [2-9]11 0[2-9]11 1[2-9]11 [2-9]XXXXXXXXX 0[2-9]XXXXXXS [2-9]XXXXXX 0[2-9]XXXXXXXXX 1[2-9]XXXXXXXXX 101S 10[02-9] E[0124-9]X 11[23]XX 11[014-9]X E[2-3]XX 101XXXX 950XXXX),Signals {cg/dt, Add = $ { Media { Local { v=0 c=in IP4 $ m=audio $ RTP/AVP $ < < Reply: 9 / Context: 583 Recebido confirmação parametros do Contexto do MG... MEGACO/1 [ ]:2944 Reply=9{Context=583{Add=aaln/1,Add=Eph000477{Media{Local{ v=0 o=genband IN IP s=c=in IP t=0 0 m=audio RTP/AVP 8

56 56 a=ptime:20-17:01:07 Terminação aaln/1 retirou o telefone do gancho... No cenário acima, podemos ver claramento o que é requisição e o que é resposta, inclusive acompanhar a montagem de um contexto, sendo indicato por uma seta com o sentido para a esquerda, o que é um recebimento e uma seta para a direita, indicando o que foi enviado para o MG. Já em relação à requisiçãoresposta, é indicado através do evento descrito abaixo da seta, tais como Transaction/Reply. De uma visão geral sobre a aplicação desenvolvida, temos a figura abaixo, Figura 18 repreentando o programa inicial, criando-se duas threads, que dão origem ao protocolo H.248 e ao protocolo SIP que já foi discutido anteriormente. Figura 18: Visão geral da aplicação desenvolvida para os protocolos H.248 e SIP, representado por duas threads para tratamento das mensagens. Fonte: Elaboração própria 2012.

Este tutorial apresenta uma breve descrição do Protocolo MeGaCo (MEdia GAteway COntrol), utilizado para a sinalização de Mídia Gateways em redes VoIP.

Este tutorial apresenta uma breve descrição do Protocolo MeGaCo (MEdia GAteway COntrol), utilizado para a sinalização de Mídia Gateways em redes VoIP. MeGaCo: Conheça o protocolo de sinalização de Mídia Gateways VoIP Este tutorial apresenta uma breve descrição do Protocolo MeGaCo (MEdia GAteway COntrol), utilizado para a sinalização de Mídia Gateways

Leia mais

Introdução ao protocolo SIP*

Introdução ao protocolo SIP* Introdução ao protocolo SIP* 1. SIP (Session Initiation Protocol) Pode se dizer que SIP trata se de um protocolo de controle referente à camada de aplicações do Modelo de Referência OSI (Open System Interconnection),

Leia mais

Protocolo de Sinalização SIP

Protocolo de Sinalização SIP Protocolos de Sinalização Protocolos com processamento distribuído e clientes/terminais inteligentes SIP - Session Initiation Protocol, desenvolvido pelo IETF para comunicação multimídia pela Internet

Leia mais

VoIP. Redes de Longa Distância Prof. Walter Cunha

VoIP. Redes de Longa Distância Prof. Walter Cunha Redes de Longa Distância Prof. Walter Cunha As principais tecnologias de Voz sobre Rede de dados: Voz sobre Frame Relay Voz sobre ATM Voz sobre IP VoIP sobre MPLS VoIP consiste no uso das redes de dados

Leia mais

Aplicações Multimídia Distribuídas. Aplicações Multimídia Distribuídas. Introdução. Introdução. Videoconferência. deborams@telecom.uff.br H.

Aplicações Multimídia Distribuídas. Aplicações Multimídia Distribuídas. Introdução. Introdução. Videoconferência. deborams@telecom.uff.br H. Departamento de Engenharia de Telecomunicações - UFF Aplicações Multimídia Distribuídas Aplicações Multimídia Distribuídas Videoconferência Padrão H.323 - ITU Padrão - IETF Profa. Débora Christina Muchaluat

Leia mais

SIP Session Initiation Protocol

SIP Session Initiation Protocol SIP Session Initiation Protocol Pedro Silveira Pisa Redes de Computadores II 2008.2 Professores: Luís Henrique Maciel Kosmalski Costa Otto Carlos Muniz Bandeira Duarte Outubro de 2008 Índice Introdução

Leia mais

05.01 Media Gateway Control

05.01 Media Gateway Control 05.01 Media Gateway Control Redes de Serviços e Comunicações Multimédia RSCM/ISEL-DEETC-SRC/2004 1 Funções de um Gateway Conversão da sinalização Depende da sinalização utilizada Linguagem utilizada para

Leia mais

H.323: Visual telephone systems and equipment for local area networks which provide a nonguaranteed

H.323: Visual telephone systems and equipment for local area networks which provide a nonguaranteed UNIVERSIDADE FEDERAL DO PARANÁ H.323: Visual telephone systems and equipment for local area networks which provide a nonguaranteed quality of service Resumo para a disciplina de Processamento Digital de

Leia mais

Tecnologias Atuais de Redes

Tecnologias Atuais de Redes Tecnologias Atuais de Redes Aula 5 VoIP Tecnologias Atuais de Redes - VoIP 1 Conteúdo Conceitos e Terminologias Estrutura Softswitch Funcionamento Cenários Simplificados de Comunicação em VoIP Telefonia

Leia mais

TP 318 Introdução às Redes Multimídia

TP 318 Introdução às Redes Multimídia Especialização em Telecomunicações TP 318 Introdução às Redes Multimídia Prof. Antônio M. Alberti Prof. José Marcos C. Brito 1 Tópicos Introdução RTP RSTP RTCP Arquitetura SIP Arquitetura OPT Referências

Leia mais

HTVix HA 211. Entrada de alimentação 12VDC / 500mA (Positivo no centro)

HTVix HA 211. Entrada de alimentação 12VDC / 500mA (Positivo no centro) 1 HTVix HA 211 1. Interfaces Entrada de alimentação 12VDC / 500mA (Positivo no centro) Conector RJ11 para conexão de aparelho telefônico analógico ou o adaptador para telefone e rede de telefonia convencional

Leia mais

Guia Técnico Inatel Guia das Cidades Digitais

Guia Técnico Inatel Guia das Cidades Digitais Guia Técnico Inatel Guia das Cidades Digitais Módulo 3: VoIP INATEL Competence Center treinamento@inatel.br Tel: (35) 3471-9330 As telecomunicações vêm passando por uma grande revolução, resultante do

Leia mais

SIP. Fabrício Tamusiunas. Comitê Gestor Internet BR

SIP. Fabrício Tamusiunas. Comitê Gestor Internet BR SIP Fabrício Tamusiunas Comitê Gestor Internet BR SIP RFC 3261 (antiga RFC 2543) Protocolo de controle que trabalha na camada de aplicação Permite que EndPoints encontrem outros EndPoints Gerencia sessões

Leia mais

Instituto Superior Técnico. Projecto VoIP. Sistema IVVR

Instituto Superior Técnico. Projecto VoIP. Sistema IVVR Instituto Superior Técnico Projecto VoIP Sistema IVVR 68239 Rui Barradas 68477 Helton Miranda 68626 Ludijor Barros 72487 Bruna Gondin Introdução O objectivo deste projecto é desenvolver um sistema de Interactive

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br CENTRO UNIVERSITÁRIO DE VOLTA REDONDA UniFOA Curso Tecnológico de Redes de Computadores Disciplina: Redes Convergentes II Professor: José Maurício S. Pinheiro

Leia mais

Revisão de Literatura

Revisão de Literatura Revisão de Literatura VoIP é um conjunto de tecnologias que usa a Internet ou as redes IP privadas para a comunicação de Voz, substituindo ou complementando os sistemas de telefonia convencionais. A telefonia

Leia mais

O Paradigma da Alta Disponibilidade e da Alta Confiabilidade do SIP

O Paradigma da Alta Disponibilidade e da Alta Confiabilidade do SIP O Paradigma da Alta Disponibilidade e da Alta Confiabilidade do SIP Visão Geral As redes convergentes trilharam um longo caminho desde a década de 1990. Novas aplicações, como as mensagens instantâneas,

Leia mais

SIP Session Initiation Protocol

SIP Session Initiation Protocol Session Initiation Protocol Carlos Gustavo A. da Rocha Session Initiation Protocol Desenvolvido pelo IETF RFC 2543 (Fev 1999) RFC 3261 (Jun 2002) É um protocolo de sinalização para sessões multimídia Negociação;

Leia mais

CONFIGURAÇÃO DO ATA ZINWELL ATA ZT-1000

CONFIGURAÇÃO DO ATA ZINWELL ATA ZT-1000 CONFIGURAÇÃO DO ATA ZINWELL ATA ZT-1000 Características Protocolos Interface de Rede Características das Chamadas Codecs Instalação Física Configuração Acessando o ATA pela primeira vez Modificações a

Leia mais

Intelbras GKM 2210T. 1. Instalação

Intelbras GKM 2210T. 1. Instalação 1 Intelbras GKM 2210T 1. Instalação 1º Conecte a fonte de alimentação na entrada PWR, o LED Power acenderá; 2º Conecte a porta WAN do GKM 2210 T ao seu acesso à internet (porta ethernet do modem). O LED

Leia mais

Manual de Configuração

Manual de Configuração Manual de Configuração Linksys SPA 2102 Versão 1.4 Guia de instalação do Linksys SPA 2102 O Linksys SPA 2102 possui: 01 Entrada de alimentação DC 5V (100-240V~) 01 Porta Ethernet (LAN) conector RJ 45 01

Leia mais

200.1045.00-4 REV 020

200.1045.00-4 REV 020 Manual do Usuário VoIP XT-50 200.1045.00-4 REV 020 Sumário 1. Introdução...3 1.1. Hardware...3 1.2. Software...4 2. Configurador WEB...4 2.1. Login...4 2.2. Informações do Sistema...5 2.3. Agenda...5 2.4.

Leia mais

Contribuição acadêmica

Contribuição acadêmica Contribuição acadêmica Origem deste trabalho em cadeiras do curso de mestrado na COPPE/UFRJ; Continuidade da contribuição acadêmica através do laboratório RAVEL: desenvolvimento de sw para apoio; intercâmbio

Leia mais

------------------------------------------------------------------------- *** Recuperação de senha através do link:

------------------------------------------------------------------------- *** Recuperação de senha através do link: YEALINK SIP-T22P SÍNTESE DE FUNCIONALIDADES VOIP Função de Teclas Permitir aos usuários o acesso ao Voice Mail; Redirecionar ligações ao se ausentar; CUIDADO; (ativa o último nº registrado na memória)

Leia mais

Transmissão de Voz em Redes de Dados (VoIP)

Transmissão de Voz em Redes de Dados (VoIP) Transmissão de Voz em Redes de Dados (VoIP) Telefonia Tradicional PBX Telefonia Pública PBX Rede telefônica tradicional usa canais TDM (Time Division Multiplexing) para transporte da voz Uma conexão de

Leia mais

A recomendação H.323 define um arcabouço (guarda-chuva) para a estruturação dos diversos

A recomendação H.323 define um arcabouço (guarda-chuva) para a estruturação dos diversos Videoconferência: H.323 versus SIP Este tutorial apresenta uma avaliação técnica e as tendências que envolvem os serviços providos pela pilha de protocolos do padrão H.323, especificados pelo ITU-T, e

Leia mais

Teia de alcance mundial (World Wide Web WWW) Web composta de

Teia de alcance mundial (World Wide Web WWW) Web composta de Web Teia de alcance mundial (World Wide Web WWW) Web composta de Agentes de usuário para a Web (browsers) Servidores Web Protocolo de transferência de hipertexto (HyperText Transfer Protocol HTTP) Web

Leia mais

REDES CONVERGENTES PROFESSOR: MARCOS A. A. GONDIM

REDES CONVERGENTES PROFESSOR: MARCOS A. A. GONDIM REDES CONVERGENTES PROFESSOR: MARCOS A. A. GONDIM Roteiro Introdução a Redes Convergentes. Camadas de uma rede convergente. Desafios na implementação de redes convergentes. Introdução a Redes Convergentes.

Leia mais

NETALARM GATEWAY. Manual do Usuário

NETALARM GATEWAY. Manual do Usuário Índice 1. Introdução...3 2. Requisitos Mínimos de Instalação...3 3. Instalação...3 4. Inicialização do Programa...5 5. Abas de Configuração...6 5.1 Aba Serial...6 5.2 Aba TCP...7 5.2.1 Opções Cliente /

Leia mais

YEALINK SIP-T22P. Função de Teclas SÍNTESE DE FUNCIONALIDADES VOIP. Permitir aos usuários o acesso ao Voice Mail;

YEALINK SIP-T22P. Função de Teclas SÍNTESE DE FUNCIONALIDADES VOIP. Permitir aos usuários o acesso ao Voice Mail; YEALINK SIP-T22P SÍNTESE DE FUNCIONALIDADES VOIP Função de Teclas Permitir aos usuários o acesso ao Voice Mail; Redirecionar ligações ao se ausentar; CUIDADO; (ativa o último nº registrado na memória)

Leia mais

Introdução à voz sobre IP e Asterisk

Introdução à voz sobre IP e Asterisk Introdução à voz sobre IP e Asterisk José Alexandre Ferreira jaf@saude.al.gov.br Coordenador Setorial de Gestão da Informática CSGI Secretaria do Estado da Saúde SES/AL (82) 3315.1101 / 1128 / 4122 Sumário

Leia mais

Protocolo SIP. Licenciatura em Engenharia de Sistemas Informáticos PL. Comunicação de Dados. Pedro Fernandes 7839 Nuno Costa 3676 1

Protocolo SIP. Licenciatura em Engenharia de Sistemas Informáticos PL. Comunicação de Dados. Pedro Fernandes 7839 Nuno Costa 3676 1 Pedro Fernandes 7839 Nuno Costa 3676 1 Protocolo SIP Licenciatura em Engenharia de Sistemas Informáticos PL Comunicação de Dados Resumo Neste documento pretende-se explicar o funcionamento do protocolo

Leia mais

Estado de Santa Catarina Prefeitura de São Cristóvão do Sul

Estado de Santa Catarina Prefeitura de São Cristóvão do Sul 1 ANEXO VII QUADRO DE QUANTITATIVOS E ESPECIFICAÇÕES DOS ITENS Item Produto Quantidade 1 Aparelhos IP, com 2 canais Sip, visor e teclas avançadas, 2 70 portas LAN 10/100 2 Servidor com HD 500G 4 GB memória

Leia mais

Serviço Corporativo de Telefonia IP

Serviço Corporativo de Telefonia IP Universidade Federal de Santa Catarina Pró-Reitoria de Planejamento Superintendência de Governança Eletrônica e Tecnologia da Informação e Comunicação Departamento de Tecnologia da Informação e Redes Serviço

Leia mais

Walter Cunha Tecnologia da Informação Redes WAN

Walter Cunha Tecnologia da Informação Redes WAN Walter Cunha Tecnologia da Informação Redes WAN Frame-Relay 1. (FCC/Pref. Santos 2005) O frame-relay é uma tecnologia de transmissão de dados que (A) opera no nível 3 do modelo OSI. (B) tem velocidade

Leia mais

2 UMTS e arquitetura all-ip

2 UMTS e arquitetura all-ip 2 UMTS e arquitetura all-ip As discussões sobre a evolução das redes de comunicação determinísticas, baseadas nas operações de modo circuito, já ocorrem há algum tempo. As redes operadas em modo circuito

Leia mais

NECESSIDADES TÉCNICAS - INTERCONEXÃO TELEFÔNICA!

NECESSIDADES TÉCNICAS - INTERCONEXÃO TELEFÔNICA! NECESSIDADES TÉCNICAS - INTERCONEXÃO TELEFÔNICA TUTORIAL NECESSIDADES TÉCNICAS - INTERCONEXÃO TELEFÔNICA NECESSIDADES TÉCNICAS - INTERCONEXÃO TELEFÔNICA AVISO LEGAL: As informações contidas neste documento

Leia mais

Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet

Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet Marcos R. Dillenburg Gerente de P&D da Novus Produtos Eletrônicos Ltda. (dillen@novus.com.br) As aplicações de

Leia mais

BlackBerry Mobile Voice System Versão: 5.0 Service pack: 1. Visão geral técnica e dos recursos

BlackBerry Mobile Voice System Versão: 5.0 Service pack: 1. Visão geral técnica e dos recursos BlackBerry Mobile Voice System Versão: 5.0 Service pack: 1 Visão geral técnica e dos recursos SWD-1031491-1025120324-012 Conteúdo 1 Visão geral... 3 2 Recursos... 4 Recursos para gerenciar contas de usuário

Leia mais

2 Fundamentação Conceitual

2 Fundamentação Conceitual Fundamentação Conceitual 19 2 Fundamentação Conceitual Este capítulo apresenta alguns conceitos importantes que são utilizados ao longo do trabalho. Primeiramente, é apresentado o Session Initiation Protocol

Leia mais

A CONVERGÊNCIA DE DADOS E VOZ NA PRÓXIMA GERAÇÃO DE REDES. Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com

A CONVERGÊNCIA DE DADOS E VOZ NA PRÓXIMA GERAÇÃO DE REDES. Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com A CONVERGÊNCIA DE DADOS E VOZ NA PRÓXIMA GERAÇÃO DE REDES Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com Introdução A convergência, atualmente um dos temas mais discutidos na indústria de redes,

Leia mais

Introdução. Funcionalidades Principais. Protótipo: Fluxo de execução do Programa Cliente

Introdução. Funcionalidades Principais. Protótipo: Fluxo de execução do Programa Cliente Introdução O protótipo de cliente IPTV proposto diferencia-se pelo módulo de sinalização utilizado em VoD, tanto para estabelecimento como a nível do controlo da sessão. O modelo de sinalização proposto

Leia mais

Videoconferência: H.323 versus SIP

Videoconferência: H.323 versus SIP Videoconferência: H.323 versus SIP Este tutorial apresenta uma avaliação técnica e as tendências que envolvem os serviços providos pela pilha de protocolos do padrão H.323, especificados pelo ITU-T, e

Leia mais

Manual básico de configuração. ATA (Adaptador de Terminal Analógico) Modelo Linksys PAP2T

Manual básico de configuração. ATA (Adaptador de Terminal Analógico) Modelo Linksys PAP2T Manual básico de configuração ATA (Adaptador de Terminal Analógico) Modelo Linksys PAP2T Índice 1 Objetivo deste documento... 3 2 Entendendo o que é um ATA... 3 3 Quando utilizar o ATA... 4 4 Requisitos

Leia mais

Mobilidade na camada de Aplicação. Session Initiation Protocol (SIP)

Mobilidade na camada de Aplicação. Session Initiation Protocol (SIP) Mobilidade na camada de Aplicação usando o Session Initiation Protocol (SIP) Referências: RFC 3261, IETF SIP Working Group http://www.radvision.com www.cs.columbia.edu/hgs/ www.networkcomputing.com Introdução

Leia mais

Autenticação modo Roteador. Após finalizar a configuração, seu computador obterá o IP e a página de configuração do ATA poderá ser acessada.

Autenticação modo Roteador. Após finalizar a configuração, seu computador obterá o IP e a página de configuração do ATA poderá ser acessada. 2. Conecte a porta WAN do GKM 2210 T ao seu acesso à internet (porta ethernet do modem). O LED WAN acenderá; 3. Conecte a porta LAN à placa de rede do PC. O LED LAN acenderá; 4. Conecte o(s) telefone(s)

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTÁTISTICA GRADUAÇÃO EM CIÊNCIAS DA COMPUTAÇÃO DISCIPLINA: COMUNICAÇÃO DE DADOS

UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTÁTISTICA GRADUAÇÃO EM CIÊNCIAS DA COMPUTAÇÃO DISCIPLINA: COMUNICAÇÃO DE DADOS UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTÁTISTICA GRADUAÇÃO EM CIÊNCIAS DA COMPUTAÇÃO DISCIPLINA: COMUNICAÇÃO DE DADOS PROFESSOR: CARLOS BECKER WESTPHALL Terceiro Trabalho

Leia mais

Um Pouco de História

Um Pouco de História Telefonia IP Um Pouco de História Uma Breve Introdução às Telecomunicações Telefonia Tradicional Conversão analógica-digital nas centrais (PCM G.711) Voz trafega em um circuito digital dedicado de 64 kbps

Leia mais

Um estudo do protocolo SIP e sua utilização em redes de telefonia móvel

Um estudo do protocolo SIP e sua utilização em redes de telefonia móvel Um estudo do protocolo SIP e sua utilização em redes de telefonia móvel Romildo Martins da Silva Bezerra 1 1 Mestrado em Redes de Computadores (UNIFACS) romildo@cdl.com.br Resumo. Este trabalho visa apresentar

Leia mais

GUIA RÁPIDO. DARUMA Viva de um novo jeito

GUIA RÁPIDO. DARUMA Viva de um novo jeito GUIA RÁPIDO DARUMA Viva de um novo jeito Dicas e Soluções para IPA210 Leia atentamente as dicas a seguir para configurar seu IPA210. Siga todos os tópicos para que seja feita a configuração básica para

Leia mais

IFB INSTITUTO FEDERAL DE BRASÍLIA TECNOLOGIA VOIP. Nome: Nilson Barros Oliveira Sergio Lopes Turma: Técnico de informática 3 Módulo

IFB INSTITUTO FEDERAL DE BRASÍLIA TECNOLOGIA VOIP. Nome: Nilson Barros Oliveira Sergio Lopes Turma: Técnico de informática 3 Módulo IFB INSTITUTO FEDERAL DE BRASÍLIA TECNOLOGIA VOIP Nome: Nilson Barros Oliveira Sergio Lopes Turma: Técnico de informática 3 Módulo Brasília, 09 de Maio de 2012 Tecnologia Voip VoIP (Voice over Internet

Leia mais

Manual do Usuário de Telefone Analógico. Revisão 1.0 Julho 2010

Manual do Usuário de Telefone Analógico. Revisão 1.0 Julho 2010 Manual do Usuário de Telefone Analógico Revisão 1.0 Julho 2010 DECLARAÇÃO DE RESPONSABILIDADE A NEC reserva-se o direito de modificar as especificações, funções ou características a qualquer hora e sem

Leia mais

OBJETIVO: Informar ao cliente como instalar e configurar o equipamento D-Link DVG-1402s para operar com o serviço da rede PhoneClub

OBJETIVO: Informar ao cliente como instalar e configurar o equipamento D-Link DVG-1402s para operar com o serviço da rede PhoneClub ASSUNTO: Manual de instalação do equipamento D-Link DVG-1402s OBJETIVO: Informar ao cliente como instalar e configurar o equipamento D-Link DVG-1402s para operar com o serviço da rede PhoneClub PÚBLICO:

Leia mais

Voz sobre IP I: A Convergência de Dados e Voz

Voz sobre IP I: A Convergência de Dados e Voz Voz sobre IP I: A Convergência de Dados e Voz A tecnologia Voz sobre IP (VoIP) permite que o tráfego de uma comunicação telefônica ocorra numa rede de dados, como a Internet. Portanto, as ligações podem

Leia mais

Um pouco sobre Pacotes e sobre os protocolos de Transporte

Um pouco sobre Pacotes e sobre os protocolos de Transporte Um pouco sobre Pacotes e sobre os protocolos de Transporte O TCP/IP, na verdade, é formado por um grande conjunto de diferentes protocolos e serviços de rede. O nome TCP/IP deriva dos dois protocolos mais

Leia mais

O protocolo H.323 UNIP. Renê Furtado Felix. rffelix70@yahoo.com.br

O protocolo H.323 UNIP. Renê Furtado Felix. rffelix70@yahoo.com.br UNIP rffelix70@yahoo.com.br Este protocolo foi projetado com o intuito de servir redes multimídia locais com suporte a voz, vídeo e dados em redes de comutação em pacotes sem garantias de Qualidade de

Leia mais

MANUAL DE INSTALAÇÃO E PROGRAMAÇÃO CONVERSOR - IP / USB / SERIAL - 317 RV1

MANUAL DE INSTALAÇÃO E PROGRAMAÇÃO CONVERSOR - IP / USB / SERIAL - 317 RV1 MANUAL DE INSTALAÇÃO E PROGRAMAÇÃO CONVERSOR - IP / USB / SERIAL - 317 RV1 SÃO CAETANO DO SUL 06/06/2014 SUMÁRIO Descrição do Produto... 3 Características... 3 Configuração USB... 4 Configuração... 5 Página

Leia mais

Arquitecturas Multimédia

Arquitecturas Multimédia Arquitecturas Multimédia FEUP/DEEC/RBL 2002/03 José Ruela Arquitecturas para Comunicações Multimédia Arquitectura Multimédia IETF» Session Initiation Protocol (SIP)» Session Announcement Protocol (SAP)»

Leia mais

Telecomunicações. Prof. André Y. Kusumoto andre_unip@kusumoto.com.br

Telecomunicações. Prof. André Y. Kusumoto andre_unip@kusumoto.com.br Telecomunicações Prof. André Y. Kusumoto andre_unip@kusumoto.com.br Rede de Telefonia Fixa Telefonia pode ser considerada a área do conhecimento que trata da transmissão de voz através de uma rede de telecomunicações.

Leia mais

FACULDADE PITÁGORAS. Prof. Ms. Carlos José Giudice dos Santos cpgcarlos@yahoo.com.br www.oficinadapesquisa.com.br

FACULDADE PITÁGORAS. Prof. Ms. Carlos José Giudice dos Santos cpgcarlos@yahoo.com.br www.oficinadapesquisa.com.br FACULDADE PITÁGORAS DISCIPLINA FUNDAMENTOS DE REDES REDES DE COMPUTADORES Prof. Ms. Carlos José Giudice dos Santos cpgcarlos@yahoo.com.br www.oficinadapesquisa.com.br Material elaborado com base nas apresentações

Leia mais

1 Introdução 1.1. Contexto Atual

1 Introdução 1.1. Contexto Atual 1 Introdução 1.1. Contexto Atual Recentemente, o mercado de telecomunicações mundial tem enfrentado muitos dilemas. Como reduzir os custos, aumentar as receitas com novos serviços e manter a base de assinantes

Leia mais

Capítulo 08 VoIP Sumário

Capítulo 08 VoIP Sumário Capítulo 08 VoIP Sumário Conceitos... 341 Funcionalidade... 341 Funcionamento... 342 Dificuldades... 343 Confiabilidade... 344 Qualidade de Serviço... 344 Chamadas de Emergência... 345 Envio de Fax...

Leia mais

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP HTTP (Hypertext Transfer Protocol ) Protocolo usado na Internet para transferir as páginas da WWW (WEB). HTTPS (HyperText Transfer

Leia mais

LGW4000 Labcom Media Gateway. Labcom Media Gateway Apresentação Geral 10/11/2011

LGW4000 Labcom Media Gateway. Labcom Media Gateway Apresentação Geral 10/11/2011 LGW4000 Labcom Media Gateway Labcom Media Gateway Apresentação Geral 10/11/2011 LGW4000 Labcom Media Gateway LGW4000 é um Media Gateway desenvolvido pela Labcom Sistemas que permite a integração entre

Leia mais

F n u d n a d ment n os o Vo V I o P Introdução

F n u d n a d ment n os o Vo V I o P Introdução Tecnologia em Redes de Computadores Fundamentos de VoIP Professor: André Sobral e-mail: alsobral@gmail.com Introdução VoIP (Voice over Internet Protocol) A tecnologia VoIP vem sendo largamente utilizada

Leia mais

GT-VOIP. Especificação de Compra de Gateways VoIP. Fevereiro de 2003

GT-VOIP. Especificação de Compra de Gateways VoIP. Fevereiro de 2003 GT-VOIP Especificação de Compra de Gateways VoIP Fevereiro de 2003 Este relatório apresenta a especificação de cenários e do hardware necessário para a implantação do piloto VOIP na Rede Nacional de Pesquisa.

Leia mais

Características... 3. Identificando a placa... 3. Esquema de ligação... 3. Parâmetros programados no painel de alarme... 4

Características... 3. Identificando a placa... 3. Esquema de ligação... 3. Parâmetros programados no painel de alarme... 4 P18640 - Rev. 0 Índice Características... 3 Identificando a placa... 3 Esquema de ligação... 3 Parâmetros programados no painel de alarme... 4 Instalação do software programador... 4 Instalação do cabo

Leia mais

Abra o software de programação. Clique na opção VOIP, depois opção configuração conforme as imagens:

Abra o software de programação. Clique na opção VOIP, depois opção configuração conforme as imagens: Caro cliente, atendendo a sua solicitação de auxílio no processo de configuração da placa VoIP na central Impacta, segue um passo-a-passo para ajudar a visualização. Abra o software de programação. Clique

Leia mais

INSTALAÇÃO PRINTERTUX Tutorial

INSTALAÇÃO PRINTERTUX Tutorial INSTALAÇÃO PRINTERTUX Tutorial 2 1. O Sistema PrinterTux O Printertux é um sistema para gerenciamento e controle de impressões. O Produto consiste em uma interface web onde o administrador efetua o cadastro

Leia mais

Manual do Radioserver

Manual do Radioserver Manual do Radioserver Versão 1.0.0 Alex Farias (Supervisão) Luiz Galano (Comercial) Vinícius Cosomano (Suporte) Tel: (011) 9393-4536 (011) 2729-0120 (011) 2729-0120 Email: alex@smartptt.com.br suporte@smartptt.com.br

Leia mais

Intelbras TIP 100. 1. Instalação

Intelbras TIP 100. 1. Instalação 1 Intelbras TIP 100 1. Instalação É necessário que o TIP 100 e seu computador estejam conectados à Internet através de banda larga. A conexão pode ser feita com hub ou switch ligado ao modem roteador ou

Leia mais

3 Execução de Chamadas no UMTS

3 Execução de Chamadas no UMTS 3 Eecução de Chamadas no UMTS Este capítulo descreve a sequência de mensagens que são trocadas entre o UE e a UTRAN para a realização de uma chamada. São abordados os casos de chamadas realizadas nos modos

Leia mais

A Camada de Transporte

A Camada de Transporte A Camada de Transporte Romildo Martins Bezerra CEFET/BA s de Computadores II Funções da Camada de Transporte... 2 Controle de conexão... 2 Fragmentação... 2 Endereçamento... 2 Confiabilidade... 2 TCP (Transmission

Leia mais

Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação. Associação dos Instrutores NetAcademy - Julho de 2007 - Página

Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação. Associação dos Instrutores NetAcademy - Julho de 2007 - Página Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação 1 Introdução à Camada de Transporte Camada de Transporte: transporta e regula o fluxo de informações da origem até o destino, de forma confiável.

Leia mais

REDES ESAF. leitejuniorbr@yahoo.com.br 1 Redes - ESAF

REDES ESAF. leitejuniorbr@yahoo.com.br 1 Redes - ESAF REDES ESAF 01 - (ESAF - Auditor-Fiscal da Previdência Social - AFPS - 2002) Um protocolo é um conjunto de regras e convenções precisamente definidas que possibilitam a comunicação através de uma rede.

Leia mais

IV. Em uma rede Frame Relay o roteamento dos quadros é de responsabilidade do protocolo IP da família de protocolos TCP/IP.

IV. Em uma rede Frame Relay o roteamento dos quadros é de responsabilidade do protocolo IP da família de protocolos TCP/IP. Exercícios: Redes WAN Prof. Walter Cunha http://www.waltercunha.com/blog http://twitter.com/timasters http://br.groups.yahoo.com/group/timasters/ Frame-Relay 1. (FCC/Pref. Santos 2005) O frame-relay é

Leia mais

VoIP. 1. Introdução. 2. Conceitos e Terminologias. Tecnologias Atuais de Redes VoIP

VoIP. 1. Introdução. 2. Conceitos e Terminologias. Tecnologias Atuais de Redes VoIP 1. Introdução Muitas empresas ao redor do mundo estão conseguindo economizar (e muito) nas tarifas de ligações interurbanas e internacionais. Tudo isso se deve a uma tecnologia chamada (Voz sobre IP).

Leia mais

Protocolo H323 vs. Protocolo SIP Utilizados na tecnologia VoIP

Protocolo H323 vs. Protocolo SIP Utilizados na tecnologia VoIP UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO ESCOLA DE INFORMÁTICA APLICADA ESTUDOS DE DOMÍNIO DE APLICAÇÃO Protocolo H323 vs. Protocolo SIP Utilizados na tecnologia VoIP por VICTOR MANAIA GONÇALVES

Leia mais

Devido aos contínuos aperfeiçoamentos dos produtos e serviços, as especificações descritas a seguir, estão sujeitas a alterações sem prévio aviso.

Devido aos contínuos aperfeiçoamentos dos produtos e serviços, as especificações descritas a seguir, estão sujeitas a alterações sem prévio aviso. Devido aos contínuos aperfeiçoamentos dos produtos e serviços, as especificações descritas a seguir, estão sujeitas a alterações sem prévio aviso. MTS Telecom 082M05R0 09/05/2008 MANUAL DE INSTALAÇÃO CGW-L

Leia mais

MANUAL DE CONFIGURAÇÃO PAP2 www.ivoz.net

MANUAL DE CONFIGURAÇÃO PAP2 www.ivoz.net Guia de Instalação ATA (Adaptador de Terminal Analógico) Modelo PAP2 MANUAL DE CONFIGURAÇÃO PAP2 www.ivoz.net Sumário Como Configurar o PAP2...03 Como acessar a página Web de configuração do PAP2...04

Leia mais

Manual para configuração. Linksys/Sipura SPA-2102

Manual para configuração. Linksys/Sipura SPA-2102 Manual para configuração Linksys/Sipura SPA-2102 Indice Guia de Instalação Sipura - Modelo SPA-2102... 3 Conhecendo o SPA... 4 Conectando a SPA... 5 Instruções para conectar a SPA... 5 Usando o menu interativo

Leia mais

1.0 Apresentação. 2.0 O que é o produto? 3.0 Do que é composto? 4.0 Como funciona? 5.0 Instalando a interface da Call Rec (Hardware)

1.0 Apresentação. 2.0 O que é o produto? 3.0 Do que é composto? 4.0 Como funciona? 5.0 Instalando a interface da Call Rec (Hardware) 1.0 Apresentação 2.0 O que é o produto? 3.0 Do que é composto? 4.0 Como funciona? 5.0 Instalando a interface da Call Rec (Hardware) 6.0 Instalando o Software Call Rec 7.0 Configuração do Software Call

Leia mais

Recursos, Características e Especificações Técnicas. Telefonia

Recursos, Características e Especificações Técnicas. Telefonia Telefonia 2 Canais de ligação 1 Conta SIP Rediscar Lista dos últimos números discados Histórico de ligações Suspender Microfone Suspender Alto-falante Hold Transferência de ligações Configuração automática

Leia mais

1.0 Apresentação. 2.0 O que é o produto? 3.0 Do que é composto? 4.0 Como funciona? 5.0 Instalando a interface da Rec-All mono (Hardware)

1.0 Apresentação. 2.0 O que é o produto? 3.0 Do que é composto? 4.0 Como funciona? 5.0 Instalando a interface da Rec-All mono (Hardware) 1.0 Apresentação 2.0 O que é o produto? 3.0 Do que é composto? 4.0 Como funciona? 5.0 Instalando a interface da Rec-All mono (Hardware) 6.0 Instalando o Software Rec-All mono 7.0 Configuração do Software

Leia mais

UniFOA - Curso Seqüencial de Redes de Computadores Disciplina: Sistemas de Telecomunicações 4º período Professor: Maurício AULA 02 Telefonia Fixa

UniFOA - Curso Seqüencial de Redes de Computadores Disciplina: Sistemas de Telecomunicações 4º período Professor: Maurício AULA 02 Telefonia Fixa Introdução UniFOA - Curso Seqüencial de Redes de Computadores Com o aparecimento dos sistemas de comunicação móvel como a telefonia celular, o termo telefonia fixa passou a ser utilizado para caracterizar

Leia mais

UMA ABORDAGEM SOBRE A INTERFACE DE PROGRAMAÇÃO DE APLICAÇÕES SOCKETS E A IMPLEMENTAÇÃO DE UM SERVIDOR HTTP

UMA ABORDAGEM SOBRE A INTERFACE DE PROGRAMAÇÃO DE APLICAÇÕES SOCKETS E A IMPLEMENTAÇÃO DE UM SERVIDOR HTTP UMA ABORDAGEM SOBRE A INTERFACE DE PROGRAMAÇÃO DE APLICAÇÕES SOCKETS E A IMPLEMENTAÇÃO DE UM SERVIDOR HTTP Alan Jelles Lopes Ibrahim, alan.jelles@hotmail.com Eduardo Machado Real, eduardomreal@uems.br

Leia mais

1 Introdução. O sistema permite:

1 Introdução. O sistema permite: A intenção deste documento é demonstrar as possibilidades de aplicação da solução INCA Insite Controle de Acesso - para controle de conexões dia-up ou banda larga à Internet e redes corporativas de forma

Leia mais

Este tutorial apresenta os conceitos básicos da Telefonia IP, suas características e aplicações.

Este tutorial apresenta os conceitos básicos da Telefonia IP, suas características e aplicações. Telefonia IP Este tutorial apresenta os conceitos básicos da Telefonia IP, suas características e aplicações. (Versão revista e atualizada do tutorial original publicado em 19/05/2003). Huber Bernal Filho

Leia mais

Modelo de Camadas OSI

Modelo de Camadas OSI Modelo de Camadas OSI 1 Histórico Antes da década de 80 -> Surgimento das primeiras rede de dados e problemas de incompatibilidade de comunicação. Década de 80, ISO, juntamente com representantes de diversos

Leia mais

H.323 E SIP - COMPARATIVO

H.323 E SIP - COMPARATIVO H.323 E SIP - COMPARATIVO Jean Seidi Ikuta Escola de Engenharia Universidade Federal Fluminense Rua Passo da Pátria, 156 São Domingos Niterói RJ 24210-040 Brasil jeanseidi@yahoo.com.br Abstract. This paper

Leia mais

Manual para configuração. Linksys RT31P2

Manual para configuração. Linksys RT31P2 Manual para configuração Linksys RT31P2 Indice Guia de Instalação ATA Linksys RT31P2... 3 Conhecendo o ATA... 4 Antes de Iniciar... 6 Analisando o seu acesso à Internet... 6 Configuração... 9 Configuração

Leia mais

Manual para configuração. Siemens Roteador VoIP SpeedStream 3610

Manual para configuração. Siemens Roteador VoIP SpeedStream 3610 Manual para configuração Siemens Roteador VoIP SpeedStream 3610 Indice Guia Rápido de Instalação customizado... 3 Tipo de acesso banda larga... 4 Procedimentos de configuração... 5 Conexões do Painel traseiro...

Leia mais

Serviço fone@rnp: descrição da arquitetura

Serviço fone@rnp: descrição da arquitetura Serviço fone@rnp: descrição da arquitetura Maio de 2005 Esse documento descreve a arquitetura do serviço fone@rnp. RNP/REF/0343a Versão Final Sumário 1. Arquitetura... 3 1.1. Plano de numeração... 5 1.1.1.

Leia mais

Transferência de Arquivos FTP

Transferência de Arquivos FTP FPROT FTP e DHCP FTP Arquitetura Transferência de Arquivos FTP Transferência de arquivos em sistemas remotos Utiliza o protocolo FTP sobre uma conexão TCP Estabelece conexão TCP com um servidor. Serviço

Leia mais

Redes de Computadores. Camada de Transporte

Redes de Computadores. Camada de Transporte Redes de Computadores Camada de Transporte Objetivo! Apresentar as características da camada de transporte da arquitetura TCP/IP! Apresentar os serviços fornecidos pela camada de transporte! Estudar os

Leia mais

VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP

VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 915 VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP Paulo C. Siécola 1, Fabio Kon 1 1 Departamento

Leia mais

INSTITUTO SUPERIOR DE TEOLOGIA APLICADA CURSO DE PÓS-GRADUAÇÃO EM REDES E SEGURANÇA DE SISTEMAS TELEFONIA IP E VOIP RESUMO

INSTITUTO SUPERIOR DE TEOLOGIA APLICADA CURSO DE PÓS-GRADUAÇÃO EM REDES E SEGURANÇA DE SISTEMAS TELEFONIA IP E VOIP RESUMO INSTITUTO SUPERIOR DE TEOLOGIA APLICADA CURSO DE PÓS-GRADUAÇÃO EM REDES E SEGURANÇA DE SISTEMAS TELEFONIA IP E VOIP RESUMO Artigo Científico Curso de Pós-Graduação em Redes e Segurança de Sistemas Instituto

Leia mais

Guia de Instalação ATA (Adaptador de Terminal Analógico) Modelo PAP2

Guia de Instalação ATA (Adaptador de Terminal Analógico) Modelo PAP2 Guia de Instalação ATA (Adaptador de Terminal Analógico) Modelo PAP2 Página 1 de 14 Guia de Instalação ATA (Adaptador de Terminal Analógico) Modelo PAP2-NA Este guia irá ajudá-lo a instalar o seu ATA,

Leia mais

Parabéns, você acaba de adquirir um produto com a qualidade e segurança Intelbras.

Parabéns, você acaba de adquirir um produto com a qualidade e segurança Intelbras. MANUAL DO USUÁRIO Parabéns, você acaba de adquirir um produto com a qualidade e segurança Intelbras. A placa VoIP Impacta é um acessório para as centrais Impacta que possibilita a comunicação através

Leia mais