WebRTC infrastructure design ideas

1. WebRTC Infrastructure
Design
- Neeraj Chandra

2. Simple P2P WebRTC working
WebRTC
Client
WebRTC
Client
Share SDP with the peer by any
means so peers can send media
1. Send SDP by Email
2. Using HTTP
3. Rest API
4. Web Sockets
Browser
Mobile device
Streaming
Browser
Mobile device
Streaming

3. P2P Connection using a server
WebRTC
Client
WebRTC
Client
Signalling
Server
Share SDP
Share SDP
TURN Server
STUN
Internet
Internet

4. For communication between a WebRTC peer to another WebRTC peer, we only
need to pass the SDP details between them so that a session can be established
Peer A STUN/TURN Signalling Server Peer B
Initiate connection
Send SDP offer
Send SDP offer
Send SDP Answer
Get ICE candidate
Send ICE candidate
Get ICE candidate
Send ICE candidate
Relay
Relay
Media

5. WebRTC Architecture
Application
Server
[APIs]
Internet
Registrar
PBX
ICE
TURN
STUN
Signalling
Media
[SRTP]
PSTN
Gateway
SBC
Monitoring &
Billing calls
HTTP
Load
Balance
r
Streaming
Analytics

6. The Application server [or Signalling server, or WebRTC router] is the core
component of this design as it manages multiple modules
a. There are a number of open source webrtc routers/gateways available that can help achieve
this design, but due to being open source there are some disadvantages like support, bugs,
etc
b. Proprietary WebRTC solutions like Dinstar, Twilio, AudioCodes can be used to come up with
such a design
c. As this involves multiple components, there is a requirement to use APIs to achieve this
without much issues on the integration side
d. There may require some coding on the API side [preferably JavaScript for handling signalling
over HTTPS/WSS and other scripts like Python,Perl,Bash etc for backend operations]

7. Click-to-call use case
Contact Center
SBC
WebRTC
Gateway
SIP
Server
PBX
SIP
Agents
SIP over HTTPS and
WebSockets [WSS]
RTP secured - DTLS-SRTP
Few SBC providers also include the WebRTC
gateway feature for integrating with a PBX

8. Simple Load Balancing
Depending on the requirements the WebRTC architecture can be
configured for auto-scaling and load balancing
Web
Server
Web
Server 1
Web
Server 2
Web
Server N
Application
Server,
SBC,
WebRTC
Gateway
Application
Server,
SBC,
WebRTC
Gateway
Application
Server
HTTPS
WSS
HTTPS
WSS
HTTP
WS APIs
APIs
Database
Registrar /
Proxy
PBX
ICE
Database
Registrar /
Proxy
PBX
ICE

9. WebRTC only Load Balancing
Containers
Application Server
1. STUN/TURN/ICE
2. SBC
3. Analytics
Application Server
1. STUN/TURN/ICE
2. SBC
3. Analytics
Application Server
1. STUN/TURN/ICE
2. SBC
3. Analytics
User 4
User 2
User 3
User 1
HTTP
Load
Balancing

10. Containers
- When designing a robust load balancing and a HA using containers, it involves another
layer of control over the flow of signalling data, media, and the application APIs. We need to
ensure the network configuration should be simple and straightforward to ensure the flow of
data is as per the design before migrating to a public cloud for testing.
- QA has to be performed to ensure the limits a particular container can handle and also to
find out which services can be combined into a container and which needs to be isolated on
a different container
- This will require detailed testing after the design is implemented

11. Security Considerations
1. Use HTTPS and Secure WebSockets for communication there by signalling traffic is
encrypted
2. Using SBC will help secure VoIP by obscuring internal network from public network and
hence issues like D-Dos, SYN flood, port scans can be prevented
3. Secure datagram packets by using DTLS-SRTP so that media streams are encrypted
between peers
4. Add ICE authentication to add another layer of security
5. Browsers and Apps should be implementing client side security by enabling Mic and
camera access only for the call

12. Performance and Monitoring
1. Based on the requirements, we can calculate the bandwidth and resources for
handling the call volume for a particular customer/tenant, cluster, etc.
2. This requires measuring latency at each point between the clients and the
server and calculate the delay
3. As the SBCs include reporting for calls towards SIP/PSTN we can include that
for performance monitoring along with the report from HTTP side
4. Each device in the network [cloud] can be monitored using SNMP on a daily
basis to find out if any particular server or device is overshooting the max
threshold