GDG Cloud Southlake 32: Kyle Hettinger: Demystifying the Dark Web
Â
Appear.in premium walkthrough
1. The making of appear.in
premium
Dag-Inge Aas
Tech lead
2. What is appear.in?
⢠Web-based video chat with
no download, signup or login
⢠An internal, independent
startup in Telenor
⢠Team of 20 people from 8
nationalities
3. Agenda
⢠How we started creating premium
⢠A little about how we work
⢠How we went about solving our problem
⢠What we ended up with
appear.in/awesome-cat
5. Monetizing appear.in
⢠Had lots of requests from people wanting to pay
⢠We wanted to prove to ourselves that we were worth paying for
⢠Some clear needs emerged
⢠More people in the room
⢠Customization options
⢠Better screen sharing
⢠Improved quality
appear.in/awesome-cat
6. Companies wanted to use us
⢠We saw a lot of standup rooms
⢠Bigger corporations wanted to buy enterprise
licenses
⢠Support for town hall meetings,â¨
broadcasting scenarios
8. What are the users problems?
⢠Users want to pay for appear.in, but canât
⢠There isnât enough room for the entire team in a
single appear.in room
⢠The quality is unreliable and unacceptableâ¨
in group calls
appear.in/awesome-cat
9. Users want to pay for appear.in
⢠Luxury problem when you get these requests
⢠User wonât pay out of the good of their hearts
10. There isnât enough room for the entire team
⢠A clear need for 8+ calls
⢠How many is many? When does a meeting stop being a
meeting and start being a broadcast?
⢠Are the people spectatorsâ¨
or participants?
⢠We canât solve this without solvingâ¨
our third problem
11. Quality is unreliable and unacceptable
in group calls
⢠The core issue we were facing
⢠No use adding more people, if we couldnât solve this
⢠No use charging money, if we couldnâtâ¨
solve this
appear.in/awesome-cat
12. What is quality?
⢠Quality can be any number of things, is it the number
of pixels of video you send? A function of latency and
jitter?
⢠We deďŹne latency as the experience the user has
during a conversation.
⢠Does it ďŹow naturally, does it feel real? Does it work as
if you are in the same room?
13. What is bad quality?
⢠Latency in itself isnât such a huge issue, the human
brain is amazing
⢠Variable latency is killer, the brain canât adjust, social
clues break down
⢠So-so, mm, ja. We depend on small clues to keep
conversation ďŹowing
15. We are peer-to-peer based
⢠We believed peer-to-peer was
the superior technology
⢠Really wanted to solve the
problem without going for the
âobviousâ
16. How can we improve quality?
⢠The Internet is inherently variable
⢠Jitter saves us most of the time, but when it gets too
bad, things start to fail
⢠Chrome estimates bandwidth by saturating the link,
leading to packet loss
⢠PeerConnections compete in a full-mesh network
17. RTCStats
⢠https://github.com/opentok/rtcstats-server
⢠Queries on getStats() and creates aggregates. Currently at
500 features per peer connection.
⢠Syncs to redshift for querying big datasets
⢠https://medium.com/the-making-of-appear-in/webrtc-
connection-times-and-the-power-of-playing-around-with-
data-ab11312737e9#.vrqtr3mlq
19. Network link conditioner to the rescue
⢠Find the limits in a controlled environment
⢠Not always enough, link conditioner is too static, we
are looking for big events, not constant losses
20. Idea: Controlling bandwidth
⢠b=AS:<bitrate>
⢠Can be set dynamically on the receiving end
⢠Set bitrate based on number of people in the room
21.
22. Partial success
⢠We were able to set the bandwidth, and even network-
constrained endpoints worked. After 256kbit/s it was
more or less unusable for video
⢠Supersize looked bad, screen sharing ruined displayed
resolution-based bitrate modiďŹcation
⢠Huge realisation when we compared our results to an
SFU-based model
23. Solution: Selective forwarding
⢠Support for more people in rooms
⢠Handles supersize
⢠Lower CPU requirement
⢠Better stability and ďŹow in group calls
⢠It costs a lot more money
24.
25. Our home-grown SFU
⢠Written in JavaScript with some C-bindings
⢠First working version was only 3000 lines
⢠Globally distributed, uses full-mesh for
discoverability of streams on diďŹerent hosts
⢠Multiple servers in each AWS region
26. Advantages of building your own
⢠Full control and understanding of the component
⢠Can build custom scaling, simulcast rules
⢠Simulcast based on both network and displayed
resolution
⢠âControl your own core technologyâ
27. Disadvantages of building your own
⢠You have to build it all yourself
⢠There is a whole bunch of issues you didnât think
about beforehand
⢠Learning how to count
⢠From ďŹrst prototype to ďŹrst production use took us
10 months
28. Architecture
⢠Each SFU provides signalling
⢠Every user connects to their closest SFU using latency-
based DNS (sfu.appear.in)
⢠Global mesh network for peer discovery on publish/
subscribe
⢠SFU requests stream, forwarded through Amazon network
to closest exit node
31. appear.in/awesome-cat
appear.in premium
Upgrade your room to get extra features:
⢠Up to 12 people in conversation
⢠Better quality and stability
⢠Improved screen sharing
⢠Branding of room
â¨
$12 per room/month