DOCSLIB.ORG

Restful HTTP Webrtc Testing

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Restful HTTP Webrtc Testing RESTful HTTP WebRTC Testing HTTPFLEX TEST APPLICATION Easy-to-use, high-performance and high-capacity load testing solution to enable OMA RESTful WebRTC-compliant device, network and service testing throughout development and deployment. SPEC SHEET KEY FEATURES 1.28 million WebRTC endpoints OPUS and VP8 WebRTC codecs 1.28 million TLS and DTLS sessions STUN, TURN and ICE NAT server tests 1.28 million SRTP and SRTCP streams Both ICE-Lite and ICE-Full support HTTP and HTTPs support Policy and charging function (PCRF) emulation SRTP and SRTCP multiplexing tests IMS/VoLTE and VoIP core network emulation Real-time voice and video quality of service (QoS) for all streams Mix of VoIP, VoLTE and WebRTC service tests RESTful HTTP WebRTC Testing OVERVIEW Web real-time communications (WebRTC) technology enables real-time communication via browsers. Service providers have deployed WebRTC and are doing trials with the technology to extend their IMS services such as voice over IP (VoIP), voice over LTE (VoLTE), video over LTE (ViLTE) and rich communication services (RCS) to Internet (web) users, hence enabling real-time communication between IMS and web users such as voice, video and chat. The interworking between IMS and web users is made possible by the WebRTC gateway, which translates signaling and transcodes media between these two technology domains. TELECOM WEB SIP Web Signaling RTP/SRTP DTLS/SRTP WebRTC Gateway Figure 1. Interworking via WebRTC gateway WebRTC GATEWAY A WebRTC gateway is typically implemented and deployed in one of the two following variations: 1. Session border controller (SBC) supporting WebRTC signaling (eP-CSCF), media (e-IMS-AGW) and NAT (STUN/TURN/ICE) functions. STUN/TURN/ICE NAT Web Signaling SIP eP-CSCF DTLS-SRTP RTP eIMS-AGW SBC 2. SBC supporting only WebRTC media (eIMS-AGW) function, and a separate device supporting WebRTC signaling (WebRTC signaling gateway) and STUN/TURN/ICE (NAT) functions. STUN/TURN/ICE NAT Web Signaling WebRTC SIP SIP Sig GW P-CSCF DTLS-SRTP RTP eIMS-AGW SBC RESTful HTTP WebRTC Testing RESTFUL HTTP WebRTC specifications do not define standard web signaling protocol, leaving web application architects and developers to decide. The signaling protocol is a requirement to transmit and exchange user device capabilities such as codec and ICE credentials from one endpoint to another in order to set up the endpoint for a communication session. Despite the flexibility and freedom provided to the application designers to choose the signaling protocol, having no standard signaling protocol introduces challenges in delivering interoperable WebRTC services. To overcome the interoperatbility challenge, Open Mobile Alliance (OMA) has defined a standardized RESTful HTTP network API that allows a a web-user application (e.g., Javascript running in a WebRTC-enabled browser) to signal video, voice and data session over IP with another communication endpoint in the network. It includes common data types, naming conventions, fault definitions and namespaces. HTTPFLEX APPLICATION The httpFlex application emulates RESTful HTTP WebRTC enpoints in compliance with OMA RESTful Network API for WebRTC signaling v1.0 specifications. Its graphical user interface is flexible and easy to use, enabling customers to use out-of-box pre-canned call flows or to define their own custom call flows. It can be used to simulate real-world normal and abnormal calls during various lifecycle phases from lab testing to live network testing. The httpFlex application runs over the QualityAssurer QA-805 test platform. TEST CONFIGURATION The QualityAssurer QA-805 test platform–the industry’s leading high-performance and high-capacity platform–supports the comprehensive set of applications and features to test the WebRTC gateway as well as the network end to end. The following picture depicts both test configurations: 1) SBC supporting WebRTC signaling (eP-CSCF), media (e-IMS-AGW) and NAT (STUN/TURN/ICE) functions. In this test configuration, the httpFlex application is used together with EXFO’s volteFlex, proxyFlex, and hssFlex applications for SBC wraparound testing; httpFlex emulates WebRTC endpoints, volteFlex emulates VoIP/VoLTE/ViLTE endpoints, proxyFlex emulates CSCFs in the IMS core and hssFlex emulates the HSS and PCRF. SUT = SBC STUN/TURN/ICE NAT EXFO 4G RESTful HTTP SIP SIP eP-CSCF IMS CORE EXFO EXFO DTLS-SRTP (OPUS/VP8) RTP (G.711, H.264) WebRTC UE VoLTE UE eIMS-AGW Diameter EXFO PCRF RESTful HTTP WebRTC Testing 2) End-to-end IMS network testing with a mix of different types of endpoints, such as WebRTC, VoLTE and ViLTE endpoint. In this test configuration, httpFlex is used together with the volteFlex and hssFlex applications to test the IMS network; httpFlex emulates WebRTC endpoints, volteFlex emulates VoIP/VoLTE/ViLTE endpoints while hssFlex emulates PCRF. SUT = IMS STUN/TURN/ICE HSS AS 4G RESTful HTTP SIP PCRF CSCF EXFO EXFO RTP (G.711, H.264) WebRTC UE DTLS-SRTP (OPUS/VP8) VoLTE UE SBC Diameter EXFO PCRF KEY USE CASES Simulates millions of WebRTC enpoints and other network devices for WebRTC gateway testing, thus enabling selection of the right gateway for WebRTC deployment Tests that the WebRTC gateway is able to scale linearly to accomadate growing loads without any performance/capacity degradation Tests how many RESTful HTTP sessions the WebRTC gateway is able to set up per second, hold and maintain successfully over a period of time with different notification refresh timeout values Verifies the impact on WebRTC gateway performance as a result of resource-intensive ICE procedures that include prioritization of IP candidates and pair exchange, and order them into a checklist Validates how many concurrent signaling and media sessions WebRTC gateway (data transport layer security-secure real-time transport protocol, DTLS-SRTP/SRTCP, and DTLS-SRTP/SRTCP multiplexing) can support concurrently Verifies resource-intensive session-traversal-utilities-for-NAT (STUN) and traversal-using-relays-around-NAT (TURN) authentication using short-term ICE attributes (ice-ufrag and ice-pwd) credentials and DTLS fingerprint authentication in order to verify that the certificate presented in the DTLS handshake does not deteriorate the WebRTC gateway performance Benchmarks the maximum number of concurrent DTLS-SRTP voice and video media sessions that the WebRTC gateway is able to set up and maintain simultaneously, both with and without transcoding Generates and analyzes line rate (1G and 10G) voice and video streams with a mix of codecs, such as OPUS, VP8, H.264 and G.711 Checks that the WebRTC gateway is able to deliver expected QoS with different quality-parameter settings, such as ToS/differentiated services code point (DSCP), VLAN and MPLS Performs high-availability tests to determine resilience of the WebRTC gateway under overload conditions, security attacks, card and port failover scenarios Exercises the entire operator network infrastructure by testing end-to-end service delivery with a mix of WebRTC, VoIP, VoLTE, ViLTE and RCS/message session relay protocol (MSRP) services RESTful HTTP WebRTC Testing SPECIFICATIONS Platform QA-805 W2CM-10GbE (8 X 1 GigE and 2 X 10 GigE) W2CM-10GbE-Lite (8 X 1 GigE and 2 X 10 GigE) Modules and interfaces W2CM-4GbE (4 X 1 GigE) W2CM-Sig (8 X 1 GigE and 2 X 10 GigE, signaling only) WebRTC protocols RESTful HTTP, ICE-Full/Lite, STUN, TURN, DTLS-SRTP, SRTP and SRTCP multiplexing Transport and IP protocols TCP, TLS, IPv4, IPv6 WebRTC codecs OPUS, G.711, VP8 and H.264 RESTful HTTP WebRTC endpoint capacity 1.28 million per QA-805 platform Number of DTLS-SRTP sessions 1.28 million concurrent DTLS-SRTP and DTLS-SRTCP streams per QA-805 platform Voice (ITU-T G.107 E-Model) Quality measurements Video (RFC 4445 – VQT MDI) Jitter, loss, delay, etc. Network configuration Unique MAC addresses, VLAN tag, MPLS label, ToS and DSCP settings IP (IPv4 to IPv6) Transport (TCP to TLS to TCP/UDP/SCTP) Interworking Signaling (RESTful HTTP to SIP) Media (RTP/RTCP to SDES-SRTP/SRTCP to DTLS-SRTP/SRTCP) Note: For interworking testing volteFlex application is required Signaling trace monitor, call records, user-defined KPI, summary and call-flow statistics, table, histogram Statistics and logging and chart format, and report generation in html and .csv Create invalid WebRTC messages, create invalid and error call flow, mix valid and invalid call, Negative testing STUN/TURN inactivity and connectivity failure, etc. Automation TCL command line interface ORDERING INFORMATION For ordering information, please contact [email protected] EXFO Headquarters > Tel.: +1 418 683-0211 | Toll-free: +1 800 663-3936 (USA and Canada) | Fax: +1 418 683-2170 | [email protected] | www.EXFO.com EXFO serves over 2000 customers in more than 100 countries. To find your local office contact details, please go to www.EXFO.com/contact. EXFO is certified ISO 9001 and attests to the quality of these products. EXFO has made every effort to ensure that the information contained in this specification sheet is accurate. However, we accept no responsibility for any errors or omissions, and we reserve the right to modify design, characteristics and products at any time without obligation. Units of measurement in this document conform to SI standards and practices. In addition, all of EXFO’s manufactured products are compliant with the European Union’s WEEE directive. For more information, please visit www.EXFO.com/recycle. Contact EXFO for prices and availability or to obtain the phone number of your local EXFO distributor. For the most recent version of this spec sheet, please go to the EXFO website at www.EXFO.com/specs. In case of discrepancy, the web version takes precedence over any printed literature. SPRESTFULHTTPWEBRTC.1AN © 2016 EXFO Inc. All rights reserved. Printed in Canada 16/08.
Load more

Recommended publications
  • Mivoice Border Gateway Engineering Guidelines
    MiVoice Border Gateway Engineering Guidelines January, 2017 Release 9.4 1 NOTICE The information contained in this document is believed to be accurate in all respects but is not warranted by Mitel Networks™ Corporation (MITEL®). The information is subject to change without notice and should not be construed in any way as a commitment by Mitel or any of its affiliates or subsidiaries. Mitel and its affiliates and subsidiaries assume no responsibility for any errors or omissions in this document. Revisions of this document or new editions of it may be issued to incorporate such changes. No part of this document can be reproduced or transmitted in any form or by any means - electronic or mechanical - for any purpose without written permission from Mitel Networks Corporation. Trademarks The trademarks, service marks, logos and graphics (collectively "Trademarks") appearing on Mitel's Internet sites or in its publications are registered and unregistered trademarks of Mitel Networks Corporation (MNC) or its subsidiaries (collectively "Mitel") or others. Use of the Trademarks is prohibited without the express consent from Mitel. Please contact our legal department at [email protected] for additional information. For a list of the worldwide Mitel Networks Corporation registered trademarks, please refer to the website: http://www.mitel.com/trademarks. Product names mentioned in this document may be trademarks of their respective companies and are hereby acknowledged. MBG - Engineering Guidelines Release 9.4 January, 2017 ®,™ Trademark of Mitel Networks
    [Show full text]
  • A Case for SIP in Javascript", IEEE Communications Magazine , Vol
    Copyright © IEEE, 2013. This is the author's copy of a paper that appears in IEEE Communications Magazine. Please cite as follows: K.Singh and V.Krishnaswamy, "A case for SIP in JavaScript", IEEE Communications Magazine , Vol. 51, No. 4, April 2013. A Case for SIP in JavaScript Kundan Singh Venkatesh Krishnaswamy IP Communications Department IP Communications Department Avaya Labs Avaya Labs Santa Clara, USA Basking Ridge, USA [email protected] [email protected] Abstract —This paper presents the challenges and compares the applications independent of the specific SIP extensions alternatives to interoperate between the Session Initiation supported in the vendor's gateway. Protocol (SIP)-based systems and the emerging standards for the Web Real-Time Communication (WebRTC). We argue for an We observe that decoupled development across services , end-point and web-focused architecture, and present both sides tools and applications promotes interoperability. Today, the of the SIP in JavaScript approach. Until WebRTC has ubiquitous web developers can build applications independent of a cross-browser availability, we suggest a fall back strategy for web particular service (Internet service provider) or vendor tool developers — detect and use HTML5 if available, otherwise fall (browser, web server). Unfortunately, many existing SIP back to a browser plugin. systems are closely integrated and have overlap among two or more of these categories, e.g., access network provider Keywords- SIP; HTML5; WebRTC; Flash Player; web-based (service) wants to control voice calling (application), or three communication party calling (application) depends on your telephony provider (service). The main motivation of the endpoint approach (also I. INTRODUCTION known as SIP in JavaScript) is to separate the applications In the past, web developers have resorted to browser (various SIP extensions and telephony features) from the plugins such as Flash Player to do audio and video calls in the specific tools (browsers or proxies) or VoIP service providers.
    [Show full text]
  • A Flexible and Scalable Media Centric Webrtc
    An Oracle White Paper May 2014 Towards a Flexible and Scalable Media Centric WebRTC Towards a Flexible and Scalable Media Centric WebRTC Introduction Web Real Time Communications (WebRTC) transforms any device with a browser into a voice, video, and screen sharing endpoint, without the need of downloading, installing, and configuring special applications or browser plug-ins. With the almost ubiquitous presence of browsers, WebRTC promises to broaden the range of communicating devices to include game consoles and set-top boxes in addition to laptops, smartphones, tablets, etc. WebRTC has been described as a transformative technology bridging the worlds of telephony and web. But what does this bridging really imply and have the offerings from vendors fully realized the possibilities that WebRTC promises? In this paper we discuss the importance of WebRTC Service Enablers that help unlock the full potential of WebRTC and the architectures that these elements make possible in this new era of democratization. New Elements in the WebRTC Network Architecture While web-only communications mechanisms would require nothing more than web browsers and web servers, the usefulness of such web-only networks would be limited. Not only is there a need to interwork with existing SIP1 and IMS2 based networks, there is also a need to provide value added services. There are several products in the marketplace that attempt to offer this functionality. But most of the offerings are little more than basic gateways. Such basic gateways perform simple protocol conversions where messages are translated from one domain to another. Such a simplistic gateway would convert call signaling from JSON3, XMPP4, or SIP over WebSockets, to SIP, and might also provide interoperability between media formats.
    [Show full text]
  • The Security of Webrtc Ben Feher, Lior Sidi, Asaf Shabtai, Rami Puzis Ben-Gurion University of the Negev {Feherb, Liorsid, Shabtaia, Puzis}@Bgu.Ac.Il
    The Security of WebRTC Ben Feher, Lior Sidi, Asaf Shabtai, Rami Puzis Ben-Gurion University of the Negev {feherb, liorsid, shabtaia, puzis}@bgu.ac.il ABSTRACT primarily browser–based (though not all browsers support WebRTC is an API that allows users to share streaming WebRTC) we focus our analysis on WebRTC browser-based information, whether it is text, sound, video or files. It is impelmetations. A quick look at browser usage statistics reveals supported by all major browsers and has a flexible underlying that currently, Chrome and Firefox dominate the browser market infrastructure. In this study we review current WebRTC structure by a significant margin. In addition, these browsers also support and security in the contexts of communication disruption, key features of WebRTC technology which makes them prime modification and eavesdropping. In addition, we examine candidates for our tests. WebRTC security in a few representative scenarios, setting up and Another point for consideration in the security analysis involves simulating real WebRTC environments and attacks. the communication restrictions of the current security measure (e.g., deep packet inspection Firewalls), as well as the availability General Terms of existing tools for analyzing the WebRTC traffic. Security, Network. 2. WHAT IS WebRTC? Keywords In General, a WebRTC communication is composed of two WebRTC, DTLS-SRTP, Signaling, P2P. stages: a signaling and a communication stage. 1. INTRODUCTION 2.1 Signaling Stage Web Real-Time Communication (WebRTC) is an API aimed to The signaling stage is the conversation setup. When two clients support browser-to-browser communication. This solution is wish to communicate, they must arrange a common information designed to unify the fragmented solution cluster that has been channel.
    [Show full text]
  • Cisco Remote Expert Mobile 10.6(3) Design Guide
    Cisco Remote Expert Mobile 10.6(3) Design Guide First Published: 2015-07-31 Last Updated: 2016-01-13 Cisco Systems, Inc. www.cisco.com 1 Design Guide THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the UniVersity of California, Berkeley (UCB) as Part of UCB’s Public domain version of the UNIX oPerating system. All rights reserVed. CoPyright © 1981, Regents of the UniVersity of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
    [Show full text]
  • MRTC Gateway Can Be Hosted on Any Windows Version
    2021 MRTC Documentation MizutechMRTC WebRTC -SIPGateway gateway User Guide Mizutech WebRTC-SIP Gateway –User Guide Connecting WebRTC clients to SIP servers Mizutech 6/3/2021 Contents About ......................................................................................................................................................................................................... 3 Features ............................................................................................................................................................................................. 3 Requirements .................................................................................................................................................................................... 4 How It Works ..................................................................................................................................................................................... 4 Legal Agreement ............................................................................................................................................................................... 4 Setup and configuration ............................................................................................................................................................................ 5 Install ................................................................................................................................................................................................
    [Show full text]
  • Implementation and Evaluation of Security on a Gateway for Web-Based Real-Time Communication
    Tuukka Koistinen Implementation and Evaluation of Security on a Gateway for Web-based Real-Time Communication School of Electrical Engineering Thesis submitted for examination for the degree of Master of Science in Technology. Espoo 22.5.2014 Thesis supervisor: Prof. Jörg Ott Thesis advisor: M.Sc. (Tech.) Tuomas Erke aalto university abstract of the school of electrical engineering master’s thesis Author: Tuukka Koistinen Title: Implementation and Evaluation of Security on a Gateway for Web-based Real-Time Communication Date: 22.5.2014 Language: English Number of pages:8+65 Department of Communications and Networking Professorship: Networking Technology Code: S-38 Supervisor: Prof. Jörg Ott Advisor: M.Sc. (Tech.) Tuomas Erke Web Real-Time Communication (WebRTC) is a set of standards that are being developed, aiming to provide native peer-to-peer multimedia communication be- tween browsers. The standards specify the requirements for browsers, including a JavaScript Application Programming Interface (API) for web developers, as well as the media plane protocols to be used for connection establishment, media transportation and data encryption. In this thesis, support for Interactive Connectivity Establishment (ICE) and media encryption was implemented to an existing gateway prototype. The gateway was originally developed to connect the novel WebRTC possibilities with existing IP Multimedia Subsystem (IMS) services, but it was lacking the necessary security functionalities. The performance of the gateway was measured and analyzed in different call scenarios between WebRTC clients. Two key elements, CPU load of the gateway and packet delay, were considered in the analysis. In addition to single call scenarios, the tests included relaying of ten simultaneous HD video calls, and relaying of ten simultaneous audio calls.
    [Show full text]
  • Webrtc 2 Voip Flowroute Dids Now Support Web Originated Calls
    ClueCon 2019 WebRTC 2 VoIP Flowroute DIDs now support web originated calls Julien Chavanton Lead software engineer - voice routing - flowroute.com presentation agenda : WebRTC 2 VoIP and share some insights about the design and features. ➔ How we are using Kamailio to do our web edge-proxies, providing SIP over WebSockets, Topology hiding and SDP normalization. (With sipwise RTP-engine) ➔ JS libraries, to help our customers integrate WebRTC for inbound audio calls on Flowroute DIDs using JSSIP, we will look at our provided Javascript libraries jssip_client and jssip_ui ➔ How we are monitoring QoS stats for audio sessions and audio streams with G.711 and Opus. ➔ The current state of our platform and how we were able to reuse our multiple point of presences and APIs to enable new possibilities for our customers. Addition to carrier infrastructure using Kamailio sip-proxy Kamailio SIP over websocket rfc7118 https://kamailio.org/docs/modules/stable/modules/websocket.html 5.1. ws_handle_handshake() This function checks an HTTP GET request for the required headers and values, and (if successful) upgrades the connection from HTTP to WebSocket. Below is an example of a WebSocket handshake in which the client requests the WebSocket SIP subprotocol support from the server: GET / HTTP/1.1 Host: sip-ws.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://www.example.com Sec-WebSocket-Protocol: sip Sec-WebSocket-Version: 13 The handshake response from the server accepting the WebSocket SIP subprotocol would look as follows: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: sip Once the negotiation has been completed, the WebSocket connection is established and can be used for the transport of SIP requests and responses.
    [Show full text]
  • Load Testing of SIP and Webrtc Infrastructures Webrtc SIP and Webrtc Browsers Selenium Native Solutions Servers Lorenzo Miniero
    KamailioWorld L. Miniero Intro SIP Testing SIPp Load Testing of SIP and WebRTC Infrastructures WebRTC SIP and WebRTC Browsers Selenium Native solutions Servers Lorenzo Miniero Questions @elminiero Kamailio World 8th May 2017, Outline KamailioWorld L. Miniero 1 A brief introduction Intro SIP Testing SIPp 2 Load Testing of SIP Infrastructures WebRTC SIPp: a SIP protocol test tool SIP and WebRTC Browsers Selenium Native solutions 3 Bringing WebRTC into the picture Servers The problem: getting SIP and WebRTC to like each other Questions Testing the “pane e puparuoli” way: tabs tabs tabs! A cluster of browsers: SeleniumHQ , Native solutions: a look at Jattack Can WebRTC compliant servers help? 4 Questions/Comments You may remember me from last year! KamailioWorld L. Miniero Intro SIP Testing SIPp WebRTC SIP and WebRTC Browsers Selenium Native solutions Servers Questions What’s Meetecho? KamailioWorld L. Miniero • A company born in 2009 as an academic spin-off • Intro University research efforts brought to the market SIP Testing • Proudly brewed in sunny Napoli, Italy SIPp , WebRTC • Focus on real-time multimedia applications SIP and WebRTC Browsers • Web conferencing only, at first Selenium Native solutions • Then widened the scope to multimedia in general Servers Questions • Strong perspective on standardization and open source • WebRTC rulez! • Several activities • Consulting services • Commercial support & licenses • Streaming of live events (e.g., IETF, ACM SIGCOMM, ...) • Products (conferencing, webinar, ...) What’s Meetecho? KamailioWorld
    [Show full text]
  • Webrtc-Based Video Quality of Experience Evalua on of the Janus
    Linköping University | Department of Computer and Information Science Master thesis, 30 ECTS | Datavetenskap 2018 | LIU-IDA/LITH-EX-A--18/049--SE WebRTC-based Video Quality of Experience Evaluaon of the Janus Streaming Plugin – Integrang Video Door Systems and WebRTC-Supported Browsers Videoutvärdering av Janus streamingmodul med fokus på WebRTC-baserad Quality of Experience Raymond Leow Examiner : Niklas Carlsson External supervisor : Johan Åberg Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se Upphovsrä Dea dokument hålls llgängligt på Internet – eller dess framda ersäare – under 25 år från pub- liceringsdatum under förutsäning a inga extraordinära omständigheter uppstår. Tillgång ll doku- mentet innebär llstånd för var och en a läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och a använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsräen vid en senare dpunkt kan inte upphäva dea llstånd. All annan användning av doku- mentet kräver upphovsmannens medgivande. För a garantera äktheten, säkerheten och llgäng- ligheten finns lösningar av teknisk och administrav art. Upphovsmannens ideella rä innefaar rä a bli nämnd som upphovsman i den omfaning som god sed kräver vid användning av dokumentet på ovan beskrivna sä samt skydd mot a dokumentet ändras eller presenteras i sådan form eller i så- dant sammanhang som är kränkande för upphovsmannens lierära eller konstnärliga anseende eller egenart. För yerligare informaon om Linköping University Electronic Press se förlagets hemsida hp://www.ep.liu.se/. Copyright The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starng from the date of publicaon barring exceponal circumstances.
    [Show full text]
  • Overview: Real-Time Protocols for Browser-Based Applications
    Stream: Internet Engineering Task Force (IETF) RFC: 8825 Category: Standards Track Published: January 2021 ISSN: 2070-1721 Author: H. Alvestrand Google RFC 8825 Overview: Real-Time Protocols for Browser-Based Applications Abstract This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC). Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8825. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Alvestrand Standards Track Page 1 RFC 8825 WebRTC Overview January 2021 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.
    [Show full text]
  • Webrtc for Dummies®, 2Nd Sonus Special Edition Published by John Wiley & Sons, Inc
    These materials are © 2015 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. WebRTC 2nd Sonus Special Edition By Justin Hart These materials are © 2015 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. WebRTC For Dummies®, 2nd Sonus Special Edition Published by John Wiley & Sons, Inc. 111 River St. Hoboken, NJ 07030‐5774 www.wiley.com Copyright © 2015 by John Wiley & Sons, Inc. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the Publisher. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748‐6011, fax (201) 748‐6008, or online at http://www.wiley.com/go/permissions. Trademarks: Wiley, For Dummies, the Dummies Man logo, The Dummies Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. Sonus and the Sonus logo are registered trademarks of Sonus. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book. LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE.
    [Show full text]