Web rtc infrastructure the hard parts v4
•Télécharger en tant que PPTX, PDF•
1 j'aime•766 vues
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Web rtc infrastructure the hard parts v4
Similaire à Web rtc infrastructure the hard parts v4 (20)
Web rtc infrastructure the hard parts v4
- 1. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.1 COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED. WebRTC Infrastructure: THE HARD PARTS WebRTC Global Summit
- 2. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.2 Why Terminate Media? NAT Traversal: TURN Gateway Media Server
- 3. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.3 NAT Traversal: TURN Gateway Media Server Why Terminate Media? TURN Server TURN for NAT Traversal
- 4. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.4 NAT Traversal: TURN Gateway Media Server Why Terminate Media? Gateway for Interworking Web signaling WebRTC media SIP VoIP media GW SIP
- 5. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.5 NAT Traversal: TURN Gateway Media Server Why Terminate Media? Media Servers for…
- 6. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.6 Many Reasons for a Media Server Conferencing InterworkingTranscoding Stream processingRecording Person-to-machine
- 7. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.7 Why process media server-side?
- 8. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.8 Many Reasons for a Media Server Conferencing Conferencing
- 9. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.9 Mesh model does not scale Distributed peer-to-peer mesh Centralized with media server
- 10. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.10 Many Reasons for a Media Server Transcoding Transcoding Transcoding: because we live in an imperfect world
- 11. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.11 Many Reasons for a Media Server Server Side Media-Processing Server-side media handling for: Application work-flows Security Compliance Performance Reliability Stream processingRecording Person-to-machine
- 12. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.12 Add value to terminated media + Today • Audio & video conferencing • Multi-camera switching • Compliance recording • Speech detection • Audio/video insertion • Speech recognition • Automated IVR navigation • Speaker CDR analytics Not too far away • Live RTC stream distribution • Facial recognition • Voice fingerprinting • Health biometrics • Object detection • Machine vision • Sentiment analysis • Augmented reality
- 13. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.13 Many Reasons for a Media Server Conferencing Conferencing
- 14. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.14 Traditional MCU Resource Usage Worst-case process: 1. Each stream decoded at the MCU 2. MCU mixes each conferee 3. MCU encodes individual mix for each conferee MCU 1 1 2 2 3 3 4 45 5 6 6 Ingress streams 6 Egress streams 6 MCU decodes 6 MCU encodes 6
- 15. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.15 Efficient MCU Resource Usage Efficient process: 1. Each stream decoded at the MCU 2. MCU mixes each conferee 3. MCU shares same encoder for all conferees MCU 1 2 3 4 5 6 Ingress streams 6 Egress streams 6 MCU decodes 6 MCU encodes 1 1 30%-50% reduction in compute resources
- 16. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.16 Newer Approach: SFU SFU Selective Forwarding Unit (SFU) routing Clients send one & receive many Client can instruct SFU which streams to send High throughput Can be lots of downlink bandwidth Low latency
- 17. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.17 Newer Approach: SFU SFU Selective Forwarding Unit (SFU) routing Clients send one & receive many Client can instruct SFU which streams to send High throughput Can be lots of downlink bandwidth Low latency
- 18. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.18 New WebRTC Approach: Simulcast SFU High bitrate Low bitrate Selective Forwarding Unit (SFU) with Simulcast Clients send multiple streams to SFU one high-bit rate one or more lower-bit Client directs SFU which streams to receive Reduces bandwidth vs. SFU Simulcast in WebRTC coming
- 19. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.19 Future Approach with VP9 – SVC? SFU MediumHigh LowLayered bitrates: Selective Forwarding Unit (SFU) with Scalable Video Coding (SVC) Clients send layered stream to SFU Layers have varying bitrates – time, size, quality SFU directs who gets what Coming to WebRTC eventually
- 20. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.20 Media server network model Load BalancerMRB Client Client Client Client Client Client App Server App Server App Server Media Server Media Resource Broker: Intelligent load balancer & orchestration for media servers
- 21. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.21 Pseudo Call-flow with a media server AS MRB MS1 MS2 Client Call signaling Media control MS1 status MS2 status Media control Media
- 22. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.22 Pseudo Call-flow – traditional fail-over with RE-INVITE AS MRB MS1 MS2 Client Call signaling – REINVITE with new addresses Media control MS1 status MS2 status Media control + call states Media
- 23. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.23 Pseudo Call-flow – fail-over the cloud/NFV way AS MRB MS1 MS2 Client Media control MS1 status MS2 status New container Media Memcache & Virtual IP Address
- 24. COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.24 Conclusions Terminating media isn’t cheap, so avoid it if you can Like it or not, you will probably need server-side media sometimes If you need server-side media, maximize the value you get from it Architectures are evolving to make media-processing more efficient & scalable
Notes de l'éditeur
- Signaling issues heavily discussed My focus is on media Why terminate media?
- Sometimes you have to for NAT traversal Traversal Using Relay NAT (TURN)
- If you want to Gateway to an existing telephony network, you need to terminate the media so you can change it
- And then there are a bunch of applications where you may need to terminate media for your server-side application or just because it works better that way
- Some of these other media server use cases include: Traditional video conferencing multi-point control unit (MCU) for bridging multiple parties Transcoding from one audio or video codec to another Interworking WebRTC media with standard VoIP medis Recording a stream or conversation Analyzing or processing a stream in real time, such as inserting an image or video, performing call analytics, or simply adding DTMF Any kind of person to machine or machine to machine that might not involve another person at all like today’s IVRs and speech recognition systems or the emerging computer vision systems for future applications
- Do I really need a media server? More server infrastructure = servers, bandwidth, more DevOps = more $$ & more latency Can I do it on the client ? One advantage of today’s fast processors and the web model is that processing can be done in the client or server in many cases. However, there are important trade-offs.
- Let’s take a closer look at when server-side media processing makes sense, starting with multi-party conferencing
- In most WebRTC design is additional bi-directional stream is added for each party. Each end-point must fully encode and decode the stream for each party. This actually works very well if there is only a couple parties – usually not more than 3 or 4.
- In an ideal you could always update your clients with whatever codec you need We live in an imperfect world, so unfortunately transcoding will probably always be needed Transcoding – VP8 to H.264 Mobile – OPUS to AMR-WB OPUS to EVS How about OPUS to AAC
- There are many other reasons than TURN for requiring a media server. These include: Traditional video conferencing multi-point control unit (MCU) for bridging multiple parties Transcoding from one audio or video codec to another Interworking WebRTC media with standard VoIP medis Recording a stream or conversation Analyzing or processing a stream in real time, such as inserting an image or video, performing call analytics, or simply adding DTMF Any kind of person to machine or machine to machine that might not involve another person at all like today’s IVRs and speech recognition systems or the emerging computer vision systems for future applications
- Now let’s talk briefly about how to effectively scale your media
- The downside the the MCU approach is that is very processor intensive on the server, especially when dealing with HD video. The reason is each stream needs to be individually encoded and decoded.
- A more efficient, higher-capacity approach is a technique we call encoder sharing. If several devices are receiving the same stream, rather than fully encode each one, you can dramatically increase capacity by encoding only once and sharing that stream.
- A newer approach is known as a Selective Forwarding Unit (SFU) In this architecture, each client sends only one stream to the SFU.
- The SFU then redirects the stream to only the end points that want to see it. The main task for the SFU is managing the encryption and decryption of the streams No server-side encoding or decoding is required, so the SFU can handle a lot of clients.
- An enhancement to this approach is known as simulcast. Rather than just sending one stream, each client sends 2 or more streams – usually one high bitrate and one low bitrate. Often times only a single high-bit rate – i.e. HD video – stream is sent for the active talker and the low bit-rate stream is sent for the others. If a low power or bandwidth limited device is connected then the SFU can forward just the low-bitrate stream.
- There is one additional approach called Scalable Video Coding or SVC. Like simulcast, SVC sends multiple streams of varying quality from each client and a centralized SFU does the routing. Unlike simulcast where independent streams are sent, SVC uses a layering approach in a single stream. Like simulcast, the mechanisms for signaling the SFU are not standardized and wide-scale, WebRTC-based systems have yet to emerge.
- Fine for a few calls Run into CPS problems with many