Antes da implementa¸c˜ao da aplica¸c˜ao VoIP foi necess´ario adicionar funcionalidades ao overlay para dar suporte `a sinaliza¸c˜ao da chamada entre peers. Para isso foram adicio- nados trˆes novos tipos de mensagens:
• Peer Invite - envio de um INVITE para o peer a contactar
• Peer Ack - envio do ACK ap´os receber confirma¸c˜ao positiva do peer a contactar.
• Peer Bye - mensagem de sinaliza¸c˜ao de fim de chamada originado por qualquer um dos peers da chamada.
Ap´os adicionar estas funcionalidades foram estudadas trˆes alternativas na implementa¸c˜ao do P2PSIPVoIP. Numa primeira implementa¸c˜ao foi utilizado o overlay apenas para a descoberta de recursos, isto ´e, apenas para saber qual o IP e porta no qual o agente SIP destinat´ario se encontra. A sinaliza¸c˜ao da chamada e transmiss˜ao dos dados s˜ao efetuados diretamente pela rede f´ısica (fora do overlay). A vantagem desta solu¸c˜ao ´e o facto dos peers n˜ao precisarem de nenhum algoritmo de procura de um peer, ou v´arios, que lhe reencaminhem os dados, o que torna a aplica¸c˜ao mais leve. As desvantagens ´e a dificuldade em atravessar NATs e firewalls, o fraco desempenho quando h´a um elevado tr´afego na liga¸c˜ao direta1, n˜ao tirando assim partido do overlay.
Na figura 4.1 est´a ilustrado um exemplo desta solu¸c˜ao, onde o host1 comunica com o host2. Os hosts (host 1 e host 2) come¸cam por se registar no overlay. O registo destes no overlay est´a ilustrado como um Put, no qual leva o URI e IP-porta no qual o seu agente SIP est´a ativo. Posteriormente, o host1 faz um Get para saber qual o IP-porta do agente SIP do destinat´ario, dado o seu URI. Ap´os obter a resposta trata de enviar um INVITE para o host2 que este aceita e a transmiss˜ao de dados ´e feita diretamente entre eles. Na figura ´e o host1 que origina o BYE que indica fim de chamada mas pode ser qualquer um dos peers a faze-lo.
1
Figura 4.1: Exemplo do funcionamento da aplica¸c˜ao VoIP sem reencaminhamento
Na segunda implementa¸c˜ao, o overlay n˜ao foi apenas utilizado para descoberta de re- cursos mas tamb´em para reencaminhar a media por um peer interm´edio. Nesta solu¸c˜ao o peer emissor deve ter a no¸c˜ao se a liga¸c˜ao direta est´a congestionada ou n˜ao e tomar a decis˜ao por onde envia os dados. O peer interm´edio vai apenas reencaminhar os dados de uma forma simples para o destinat´ario como vai ser explicado mais `a frente. A vanta- gem desta solu¸c˜ao ´e o facto de encontrar um caminho alternativo para a transmiss˜ao dos dados quando a liga¸c˜ao direta est´a congestionada e o facto de aproveitar o overlay para atravessar NATs e firewalls. Em contra ponto, a aplica¸c˜ao tem como processamento adicional descobrir um peer interm´edio e tomar a decis˜ao se deve mandar os dados di- retamente para o recetor ou para o peer interm´edio. Na figura 4.2 est´a ilustrado um diagrama de sequˆencia que exemplifica esta implementa¸c˜ao.
O registo dos peers est´a ilustrado como um Put, o qual contem o URI e IP-porta do agente SIP de cada um. Ap´os se registarem, o host1 faz um Get com o URI do host2 com o objetivo de descobrir qual o IP-porta para enviar o INVITE, que segue pela liga¸c˜ao direta tal como na implementa¸c˜ao anterior. Ap´os o host2 aceitar a chamada e admitindo que a liga¸c˜ao direta est´a congestionada, os dados s˜ao encaminhados por um peer denominado por host3. Este peer interm´edio est´a ilustrado na figura como sendo o mesmo encaminhador em ambas as dire¸c˜oes mas cada um dos hosts poder usar um peer diferente como intermedi´ario. No exemplo ´e o host1 que envia a mensagem BYE para sinalizar o fim de chamada mas pode ser qualquer um dos peers a faze-lo.
A terceira implementa¸c˜ao ´e muito semelhante `a segunda, com a diferen¸ca que nesta o n´umero m´aximo de peers interm´edios a ser utilizado ´e definido pelo utilizador. Esta
Figura 4.2: Exemplo do funcionamento da aplica¸c˜ao VoIP com um peer interm´edio
solu¸c˜ao n˜ao restringe o algoritmo a um s´o salto, tornando assim maiores as hip´oteses dos dados chegarem ao recetor quando existe um grande congestionamento na liga¸c˜ao direta, bem como nas liga¸c˜oes vizinhas. A desvantagem desta solu¸c˜ao ´e o facto de obrigar os peers interm´edios a manterem em cache uma tabela de encaminhamento tal como vai ser explicado mais `a frente. Al´em disso, a procura de peers para reencaminhar os dados vai gerar mais tr´afego no overlay. Na figura 4.3 est´a ilustrado um diagrama de sequˆencia que exemplifica esta implementa¸c˜ao.
O registo dos peers est´a ilustrado como um Put tal como nos exemplos anteriores. Ap´os se registarem, o host1 faz um Get com o URI do host2 com o objetivo de descobrir qual o IP-porta. Nesta solu¸c˜ao a sinaliza¸c˜ao da chamada tamb´em ´e feita pelo caminho direto entre ambos os hosts. Ap´os o host2 aceitar a chamada e admitindo que a liga¸c˜ao direta est´a congestionada, os dados s˜ao encaminhados, neste caso, por dois peers que s˜ao o host3 e o host4. Estes peers interm´edios est˜ao ilustrados na figura como sendo os mesmos encaminhadores em ambas as dire¸c˜oes mas n˜ao implica que tem de ser obrigatoriamente os mesmos, podem ser estes dois numa das dire¸c˜oes e quaisquer outros n˜ao representados na figura na dire¸c˜ao oposta. No exemplo ´e o host1 que envia a mensagem BYE para sinalizar o fim de chamada mas pode ser qualquer um dos peers a faze-lo.
Figura 4.3: Exemplo do funcionamento da aplica¸c˜ao VoIP com n peers interm´edios