Este caso de teste pretende demonstrar a inicialização de uma Owned Meeting Room por um participante WebRTC e a coexistência de participantes WebRTC e SIP na mesma sala de conferência. Neste cenário o participante WebRTC inicia a sala de conferência e posteriormente dois participantes, um SIP e outro WebRTC, junta-se à conferência. O plano de execução obedece à seguinte sequência de passos:
• O participante 1 é um participante WebRTC e inicia a sua sala de conferência. • O participante 2 é um participante WebRTC e acede à sala de conferência através
do link da sala do Participante 1.
• O participante 3 é um participante SIP e junta-se à sala telefonando para um DDI e digitado o identi cador SIP da sala do participante 1.
Figura 30: OneMeetingServerManager no caso de teste 3
Na Figura 30 está apresentado o OneMeetingServerManager durante a execução deste cenário de teste. As linhas relevantes são:
• Linha 2 "22:28:35.229 INFO Receive Request Ctx: TCPInfoPoint/10.0.0.4:46648/1"- O OneMee-
tingServerManager recebe o pedido do primeiro participante vindo do OneMee- tingWebRTCServices (a camada de serviços que serve de proxy aos participan- tes WebRTC) que se encontra em execução na máquina com o endereço de IP 10.0.0.4.
• Linha 3 "22:28:35.298 INFO Room 5ab6d0681406d417b493f0ab created at pool 20612a3b-6390-4aac-82a4- a35f11f5767d. SipAccessCode: 987654 | WebRTCToken: AQIAOTkAxG6G6D47oUmSPmDLL4gM9A"- Esta
linha indica que a sala do participante 1 foi criada e tem o identi cador SIP "987654"e o token de acesso aos participantes WebRTC é o "AQIAOTkAxG6G6D47oUmSPmDLL4gM9A".
• Linha 9 "22:28:58.581 INFO Receive Request Ctx: TCPInfoPoint/10.0.0.4:50389/1"- O OneMeeting-
ServerManager recebe o pedido do participante 2 vindo do OneMeetingWebRTC- Services.
• Linha 10"22:28:58.581 INFO Requested room to WebRTCToken 'AQIAOTkAxG6G6D47oUmSPmDLL4gM9A' runs in room 5ab6d0681406d417b493f0ab"- Esta linha indica que o participante 2 pediu a
sala de conferência com o token "AQIAOTkAxG6G6D47oUmSPmDLL4gM9A"e que a sala se encontra em execução.
• Linha 15"22:29:16.882 INFO Receive Request Ctx: TCPInfoPoint/10.0.0.6:50662/1"- O OneMeeting-
ServerManager recebe o pedido do participante 3 vindo do IVR.
• Linha 16"22:29:16.882 INFO Requested room to SipAccesCode '987654' runs in room 5ab6d0681406d417b493f0ab"-
O participante 3 faz um pedido para o identi cador SIP "987654"e a sala já se encontra em execução.
Figura 31: Participante WebRTC
Na Figura 31 está uma aplicação cliente desenvolvida especi camente para se ligar ao OneContactMeetingServer mas que não é objeto de deste projeto. Esta imagem é a
aplicação do participante 1 e onde se pode ver três vídeos diferentes. O vídeo maior é o vídeo principal e que mostra o participante que está a falar em cada momento. Os outros dois são os vídeos secundários que correspondem a cada um dos participantes, incluindo o próprio. No canto superior esquerdo está a lista de todos os participantes onde se pode notar que estão ligados três participantes, dois dos quais são participantes WebRTC e o outro é o participante SIP que só participa com áudio.
5.4 Síntese
Este capítulo expôs três cenários de teste que pretendem demonstrar e comprovar o funcionamento do OneContactMeetingServer. O primeiro cenário comprova a possibi- lidade de existir múltiplas OneMeetingPools registadas no OneMeetingServerManager proporcionando ao sistema um mecanismo de escalabilidade importante para servir um grande número de utilizadores. O segundo teste demonstra a criação de duas salas e que o OneMeetingServerManager faz a distribuição correta das salas pelas OneMee- tingPools disponíveis. O terceiro e último teste pretende comprovar o suporte para a coexistências de participantes SIP e WebRTC na mesma sala de conferência.
6. Conclusão
O objetivo principal deste projeto foi conseguido, o desenvolvimento de um servidor de videoconferência capaz de suportar endpoints SIP e WebRTC. O produto desenvolvido responde aos requisitos e necessidades da Collab, criando uma solução cloud-ready, escalável e exível que serve diferentes casos de utilização. Para além do suporte aos endpoints SIP e WebRTC era também objetivo a coexistência deste dois tipos de endpoint na mesma sala de conferência, objetivo esse que também foi conseguido. Foi também desenvolvido neste servidor, as funcionalidade que permitem a criação e gestão de salas de conferência de diferente tipos e que servem a diferentes propósitos. Foram também desenvolvidas diferentes formas de interagir com o servidor criando várias APIs e bibliotecas de fácil utilização para que os sistemas externos, como o caso do OneContactPBX, facilmente consigam integrar esta solução.
Ao longo do desenvolvimento foram ultrapassadas várias di culdades. A maior di cul- dade deveu-se à variedade de protocolos necessários para implementação deste servidor. Tanto o protocolo SIP como a tecnologia WebRTC são complexos e fazem uso de mui- tos outros protocolos auxiliares para conseguirem atingir os objetivos a que se prepõe. A intercomunicação entre estas duas tecnologias exigiu o conhecimento profundo des- tas e de tudo o que elas envolvem. Também os requisitos não funcionais, destinados a oferecer melhor suporte na Cloud no modelo Saas, como por exemplo, a redundância, escalabilidade horizontal, tolerância a falhas, zero down time do serviço, entre outras, apresentaram múltiplos desa os na arquitetura do produto e, posteriormente, no seu desenvolvimento.
Outro desa o encontrado foi o facto de o WebRTC ser ainda um standard com baixo nível de maturidade que está em constante mudança e que cada browser tem diferentes implementações, principalmente no que diz respeito à negociação de várias streams de vídeo e áudio.
Apesar das di culdades apresentadas, no nal resulta um produto servidor de videocon- ferência, o OneContactMeetingServer, capaz de satisfazer todos os requisitos de nidos.
Bibliogra a
Baugher, M., D. McGrew, M. Naslund, E. Carrara, and K. Norrman (2004, March). The Secure Real-time Transport Protocol (SRTP). RFC 3711, RFC Editor.
Bosse, J. G. V. and F. U. Devetak (2007). Signaling in telecommunication networks. Camarillo, G. and H. Schulzrinne (2010, June). The session description protocol (sdp)
grouping framework. RFC 5888, RFC Editor.
Engineering, L. (1997). 5 analog and sampled time domain plot sampled signal fre- quency plot 5 analog and NRZ sampling time plots 5 analog and sampled signal dierence frequency plot for NRZ sampling magifying the frequncy plot X2 over- sampling time plot X2 oversampling dierenc.
Firestone, S., T. Ramalingam, and S. Fry (2007). Voice and Video Conferencing Fun- damentals.
Fischl, J., H. Tschofenig, and E. Rescorla (2010, May). Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS). RFC 5763, RFC Editor.
H. Schulzrinne, S. Casner, R. F. and V. Jacobson (2003, July). RTP: A Transport Protocol for Real-Time Applications. RFC 3550, RFC Editor.
Hentschel, T. and G. Fettweis (2001). Sample rate conversion for software radio. Soft- ware Radio Technologies: Selected Readings, 389397.
Holmberg, C., H. Alvestrand, and C. Jennings (2017, December). Negotiating me- dia multiplexing using the session description protocol (sdp). Internet-Draft draft- ietf-mmusic-sdp-bundle-negotiation-47, IETF Secretariat. http://www.ietf.org/ internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiation-47.txt. Holmberg, C. and R. Shpount (2017, October). Session description pro-
tocol (sdp) oer/answer considerations for datagram transport layer secu- rity (dtls) and transport layer security (tls). Internet-Draft draft-ietf- mmusic-dtls-sdp-32, IETF Secretariat. http://www.ietf.org/internet-drafts/ draft-ietf-mmusic-dtls-sdp-32.txt.
J. Rosenberg, R. Mahy, P. M. and D. Wing (2008, October). Session Traversal Utilities for NAT (STUN). RFC 5389, RFC Editor.
Johnston, A. B. (2009). SIP : Understanding the Session Iniation Protocol.
Johnston, A. B. and D. C. Burnett (2014). WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web, Volume 1.
Lavry, D. (2004). Sampling Theory For Digital Audio. Lavry Engineering, Inc. Avai- lable online: http://www. lavryengineering. com/documents/Sampling\_Theory. pdf (checked 24.5. 2010), 127.
M. Handley, V. J. and C. Perkins (2006, July). SDP: Session Description Protocol. RFC 4566, RFC Editor.
Marquardt, F. (2001). An introduction to the basics of video conferencing. (August), 118.
McGrew, D. and E. Rescorla (2010, May). Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP). RFC 5764, RFC Editor.
Oracle. JsonRTC protocol reference. https://docs.oracle.com/cd/E40972_01/doc. 70/e40977/xt_wse_protocol_ref.htm. Accessed: 2018-02-11.
Painter, T. and A. Spanias (2000). Perceptual coding of digital audio. Proceedings of the IEEE 88 (4), 451512.
Pan, D. Y. (1993). Digital Audio Compression. Digital Technical Journal 5 (2), 114. Perkins, C. and M. Westerlund (2010, April). Multiplexing rtp data and control packets
on a single port. RFC 5761, RFC Editor.
R. Mahy, P. M. and J. Rosenberg (2010, April). Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). RFC 5766, RFC Editor.
Rosenberg, J. (2010a, April). Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Oer/Answer Protocols. RFC 5245, RFC Editor.
Rosenberg, J. (2010b, April). Interactive Connectivity Establishment (ICE): A Pro- tocol for Network Address Translator (NAT) Traversal for Oer/Answer Protocols. RFC 5245, RFC Editor.
Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler (2002, June). SIP: Session Initiation Protocol. RFC 3621, RFC Editor.
Sheet, N. A. and V. A. Sheet (2008). Videoconferencing. pp. 14.
Uberti, J. (2013, May). Plan b: a proposal for signaling multiple media sources in webrtc. Internet-Draft draft-uberti-rtcweb-plan-00, IETF Secretariat. http://www. ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt.
Weinstein, I. M. (2012). Real world options for multipoint videoconferencing. (April), 111.
Yon, D. and G. Camarillo (2005, September). TCP-Based Media Transport in the Session Description Protocol (SDP). RFC 4145, RFC Editor.