History #

Ketika mempelajari WebRTC, developer sering merasa frustrasi dengan kompleksitasnya. Mereka melihat fitur WebRTC yang tidak relevan dengan proyek mereka saat ini dan berharap WebRTC lebih sederhana. Masalahnya adalah bahwa setiap orang memiliki set kasus penggunaan yang berbeda. Komunikasi real-time memiliki sejarah yang kaya dengan banyak orang yang berbeda membangun banyak hal yang berbeda.

Bab ini berisi wawancara dengan penulis protokol yang membentuk WebRTC. Ini memberikan wawasan tentang desain yang dibuat saat membangun setiap protokol, dan diakhiri dengan wawancara tentang WebRTC itu sendiri. Jika Anda memahami niat dan desain dari perangkat lunak, Anda dapat membangun sistem yang lebih efektif dengannya.

RTP #

RTP dan RTCP adalah protokol yang menangani semua transpor media untuk WebRTC. Ini didefinisikan dalam RFC 1889 pada Januari 1996. Kami sangat beruntung memiliki salah satu penulis Ron Frederick berbicara tentang itu sendiri. Ron baru-baru ini mengunggah Network Video tool ke GitHub, sebuah proyek yang menginformasikan RTP.

Dengan kata-katanya sendiri #

Pada Oktober 1992, saya mulai bereksperimen dengan kartu frame grabber Sun VideoPix, dengan ide menulis alat konferensi video jaringan berdasarkan multicast IP. Ini dimodelkan setelah “vat” – alat konferensi audio yang dikembangkan di LBL, karena menggunakan protokol sesi lightweight yang serupa untuk pengguna bergabung ke konferensi, di mana Anda cukup mengirim data ke grup multicast tertentu dan menonton grup itu untuk lalu lintas apa pun dari anggota grup lainnya.

Agar program benar-benar berhasil, ia perlu mengompresi data video sebelum menempatkannya di jaringan. Tujuan saya adalah membuat stream data yang terlihat dapat diterima yang akan masuk dalam sekitar 128 kbps, atau bandwidth yang tersedia pada jalur ISDN rumah standar. Saya juga berharap menghasilkan sesuatu yang masih dapat ditonton yang masuk dalam setengah bandwidth ini. Ini berarti saya memerlukan faktor kompresi sekitar 20 untuk ukuran gambar dan frame rate tertentu yang saya kerjakan. Saya dapat mencapai kompresi ini dan mengajukan paten untuk teknik yang saya gunakan, kemudian diberikan sebagai paten US5485212A: Kompresi video perangkat lunak untuk konferensi telepon.

Pada awal November 1992, saya merilis alat konferensi video “nv” (dalam bentuk biner) ke komunitas Internet. Setelah beberapa pengujian awal, itu digunakan untuk videocast bagian dari Internet Engineering Task Force November ke seluruh dunia. Sekitar 200 subnet di 15 negara mampu menerima siaran ini, dan sekitar 50-100 orang menerima video menggunakan “nv” di beberapa titik dalam minggu itu.

Selama beberapa bulan berikutnya, tiga workshop lain dan beberapa pertemuan yang lebih kecil menggunakan “nv” untuk menyiarkan ke Internet secara luas, termasuk Australian NetWorkshop, workshop MCNC Packet Audio and Video, dan workshop MultiG tentang realitas virtual terdistribusi di Swedia.

Rilis source code dari “nv” mengikuti pada Februari 1993, dan pada Maret saya merilis versi alat di mana saya memperkenalkan skema kompresi berbasis wavelet yang baru. Pada Mei 1993, saya menambahkan dukungan untuk video berwarna.

Protokol jaringan yang digunakan untuk “nv” dan alat konferensi Internet lainnya menjadi dasar dari Realtime Transport Protocol (RTP), distandarisasi melalui Internet Engineering Task Force (IETF), pertama kali diterbitkan dalam RFC 1889-1890 dan kemudian direvisi dalam RFC 3550-3551 bersama dengan berbagai RFC lain yang mencakup profil untuk membawa format audio dan video tertentu.

Selama beberapa tahun berikutnya, pekerjaan berlanjut pada “nv”, mem-port alat ke sejumlah platform perangkat keras dan perangkat pengambilan video tambahan. Ini terus digunakan sebagai salah satu alat utama untuk menyiarkan konferensi di Internet pada saat itu, termasuk dipilih oleh NASA untuk menyiarkan liputan langsung misi shuttle secara online.

Pada 1994, saya menambahkan dukungan dalam “nv” untuk mendukung algoritma kompresi video yang dikembangkan oleh orang lain, termasuk beberapa skema kompresi perangkat keras seperti format CellB yang didukung oleh kartu pengambilan video SunVideo. Ini juga memungkinkan “nv” untuk mengirim video dalam format CUSeeMe, untuk mengirim video ke pengguna yang menjalankan CUSeeMe pada Mac dan PC.

Versi yang dirilis secara publik terakhir dari “nv” adalah versi 3.3beta, dirilis pada Juli 1994. Saya sedang mengerjakan rilis “4.0alpha” yang dimaksudkan untuk memigrasikan “nv” ke versi 2 dari protokol RTP, tetapi pekerjaan ini tidak pernah selesai karena saya pindah ke proyek lain. Salinan kode 4.0 alpha disertakan dalam arsip Network Video tool untuk kelengkapan, tetapi tidak lengkap dan ada masalah yang diketahui dengannya, terutama dalam dukungan RTPv2 yang tidak lengkap.

Framework yang disediakan dalam “nv” kemudian menjadi dasar konferensi video dalam proyek “Jupiter multi-media MOO” di Xerox PARC, yang akhirnya menjadi dasar untuk perusahaan spin-off “PlaceWare”, kemudian diakuisisi oleh Microsoft. Ini juga digunakan sebagai dasar untuk sejumlah proyek konferensi video perangkat keras yang memungkinkan pengiriman video berkualitas siaran NTSC penuh melalui Ethernet dan jaringan ATM bandwidth tinggi. Saya juga kemudian menggunakan beberapa kode ini sebagai dasar untuk “Mediastore”, yang adalah layanan perekaman dan pemutaran video berbasis jaringan.

Apakah Anda ingat motivasi/ide orang lain di draft? #

Kami semua adalah peneliti yang bekerja pada multicast IP, dan membantu membuat Internet multicast backbone (alias MBONE). MBONE diciptakan oleh Steve Deering (yang pertama kali mengembangkan multicast IP), Van Jacobson, dan Steve Casner. Steve Deering dan saya memiliki penasihat yang sama di Stanford, dan Steve akhirnya pergi bekerja di Xerox PARC ketika ia meninggalkan Stanford, saya menghabiskan musim panas di Xerox PARC sebagai intern yang bekerja pada proyek terkait multicast IP dan terus bekerja untuk mereka paruh waktu saat di Stanford dan kemudian penuh waktu. Van Jacobson dan Steve Casner adalah dua dari empat penulis pada RFC RTP awal, bersama dengan Henning Schulzrinne dan saya sendiri. Kami semua memiliki alat MBONE yang kami kerjakan yang memungkinkan berbagai bentuk kolaborasi online, dan mencoba untuk menghasilkan protokol dasar umum yang dapat digunakan semua alat ini adalah yang mengarah pada RTP.

Multicast sangat menarik. WebRTC sepenuhnya unicast, bisakah Anda menjelaskan tentang itu? #

Sebelum sampai ke Stanford dan belajar tentang multicast IP, saya memiliki sejarah panjang bekerja pada cara menggunakan komputer sebagai cara bagi orang untuk berkomunikasi satu sama lain. Ini dimulai pada awal 80-an untuk saya di mana saya menjalankan sistem bulletin board dial-up di mana orang dapat masuk dan meninggalkan pesan untuk satu sama lain, baik pribadi (semacam setara dengan e-mail) dan publik (grup diskusi). Sekitar waktu yang sama, saya juga belajar tentang penyedia layanan online CompuServe. Salah satu fitur keren pada CompuServe adalah sesuatu yang disebut “CB Simulator” di mana orang dapat berbicara satu sama lain secara real-time. Itu semua berbasis teks, tetapi memiliki gagasan tentang “saluran” seperti radio CB nyata, dan beberapa orang dapat melihat apa yang diketik orang lain, selama mereka berada di saluran yang sama. Saya membangun versi CB saya sendiri yang berjalan pada sistem timesharing yang saya miliki akses ke yang memungkinkan pengguna pada sistem itu mengirim pesan satu sama lain secara real-time, dan selama beberapa tahun berikutnya saya bekerja dengan teman-teman untuk mengembangkan versi yang lebih canggih dari alat komunikasi real-time pada beberapa sistem komputer dan jaringan yang berbeda. Bahkan, salah satu dari sistem itu masih beroperasi, dan saya menggunakannya untuk berbicara setiap hari kepada orang-orang yang saya kuliah bersama 30+ tahun yang lalu!

Semua alat itu berbasis teks, karena komputer pada saat itu umumnya tidak memiliki kemampuan audio/video apa pun, tetapi ketika saya sampai ke Stanford dan belajar tentang multicast IP, saya tertarik dengan gagasan menggunakan multicast untuk mendapatkan sesuatu yang lebih seperti “radio” nyata di mana Anda dapat mengirim sinyal keluar ke jaringan yang tidak ditujukan kepada siapa pun khususnya, tetapi semua orang yang menyetel ke “saluran” itu dapat menerimanya. Kebetulan, komputer tempat saya mem-port kode multicast IP adalah generasi pertama SPARC-station dari Sun, dan itu sebenarnya memiliki perangkat keras audio berkualitas telepon bawaan! Anda dapat mendigitalkan suara dari mikrofon dan memutarnya kembali melalui speaker bawaan (atau melalui output headphone). Jadi, pikiran pertama saya adalah untuk mencari tahu bagaimana mengirim audio itu keluar ke jaringan secara real-time menggunakan multicast IP, dan melihat apakah saya dapat membangun setara “radio CB” dengan audio aktual alih-alih teks.

Ada beberapa hal rumit yang harus diselesaikan, seperti fakta bahwa komputer hanya dapat memutar satu stream audio pada satu waktu, jadi jika beberapa orang berbicara Anda perlu secara matematis “mencampur” beberapa stream audio menjadi satu sebelum Anda dapat memutarnya, tetapi itu semua dapat dilakukan dalam perangkat lunak setelah Anda memahami bagaimana pengambilan sampel audio bekerja. Aplikasi audio itu membawa saya untuk bekerja pada MBONE dan akhirnya berpindah dari audio ke video dengan “nv”.

Apakah ada yang tertinggal dari protokol yang Anda harap Anda tambahkan? Apakah ada dalam protokol yang Anda sesali? #

Saya tidak akan mengatakan saya menyesalinya, tetapi salah satu keluhan besar yang akhirnya dimiliki orang tentang RTP adalah kompleksitas mengimplementasikan RTCP, protokol kontrol yang berjalan paralel dengan lalu lintas data RTP utama. Saya pikir kompleksitas itu adalah bagian besar mengapa RTP tidak lebih banyak diadopsi, terutama dalam kasus unicast di mana tidak ada banyak kebutuhan untuk beberapa fitur RTCP. Karena bandwidth jaringan menjadi kurang langka dan kemacetan bukan masalah besar, banyak orang hanya akhirnya streaming audio & video melalui TCP biasa (dan kemudian HTTP), dan secara umum itu bekerja “cukup baik” sehingga tidak layak berurusan dengan RTP.

Sayangnya, menggunakan TCP atau HTTP berarti bahwa aplikasi audio dan video multi-pihak harus mengirim data yang sama melalui jaringan beberapa kali, ke setiap peer yang perlu menerimanya, membuatnya jauh kurang efisien dari perspektif bandwidth. Saya kadang-kadang berharap kami telah mendorong lebih keras untuk mendapatkan multicast IP yang diadopsi di luar hanya komunitas penelitian. Saya pikir kami bisa melihat transisi dari televisi kabel dan siaran ke audio dan video berbasis Internet jauh lebih cepat jika kami melakukannya.

Hal-hal apa yang Anda bayangkan dibangun dengan RTP? Apakah Anda memiliki proyek/ide RTP keren yang hilang dalam waktu? #

Salah satu hal yang menyenangkan yang saya bangun adalah versi dari permainan klasik “Spacewar” yang menggunakan multicast IP. Tanpa memiliki jenis server pusat apa pun, beberapa klien dapat masing-masing menjalankan binary spacewar dan mulai menyiarkan lokasi kapal mereka, kecepatan, arah yang dihadapi, dan informasi serupa untuk “peluru” apa pun yang telah mereka tembakkan, dan semua instance lain akan mengambil informasi itu dan merendernya secara lokal, memungkinkan pengguna untuk semua melihat kapal dan peluru satu sama lain, dengan kapal “meledak” jika mereka menabrak satu sama lain atau peluru mengenai mereka. Saya bahkan membuat “puing-puing” dari ledakan objek hidup yang dapat mengeluarkan kapal lain, kadang-kadang mengarah ke reaksi berantai yang menyenangkan!

Dalam semangat permainan asli, saya merendernya menggunakan grafik vektor yang disimulasikan, jadi Anda dapat melakukan hal-hal seperti memperbesar tampilan Anda masuk & keluar dan semuanya akan naik/turun skala. Kapal-kapal itu sendiri adalah sekelompok segmen garis dalam bentuk vektor yang saya minta beberapa rekan saya di PARC bantu saya desain, jadi kapal setiap orang memiliki tampilan unik padanya.

Pada dasarnya, apa pun yang dapat mengambil manfaat dari stream data real-time yang tidak memerlukan pengiriman in-order yang sempurna dapat mengambil manfaat dari RTP. Jadi, selain audio & video kami dapat membangun hal-hal seperti shared whiteboard. Bahkan transfer file dapat mengambil manfaat dari RTP, terutama dalam hubungannya dengan multicast IP.

Bayangkan sesuatu seperti BitTorrent tetapi di mana Anda tidak memerlukan semua data yang berjalan point-to-point antara peer. Seeder asli dapat mengirim stream multicast ke semua leeche sekaligus, dan kehilangan paket apa pun di sepanjang jalan dapat dengan cepat dibersihkan oleh retransmisi dari peer apa pun yang berhasil menerima data. Anda bahkan dapat membatasi permintaan retransmisi Anda sehingga beberapa peer di dekatnya mengirimkan salinan data, dan itu juga dapat di-multicast ke orang lain di wilayah itu, karena kehilangan paket di tengah jaringan akan cenderung berarti sekelompok klien downstream dari titik itu semua melewatkan data yang sama.

Mengapa Anda harus membuat kompresi video Anda sendiri. Tidak ada yang tersedia pada saat itu? #

Pada saat saya mulai membangun “nv”, satu-satunya sistem yang saya tahu yang melakukan konferensi video adalah perangkat keras khusus yang sangat mahal. Misalnya, Steve Casner memiliki akses ke sistem dari BBN yang disebut “DVC” (dan kemudian dikomersialisasikan sebagai “PictureWindow”). Kompresi memerlukan perangkat keras khusus, tetapi dekompresi dapat dilakukan dalam perangkat lunak. Apa yang membuat “nv” agak unik adalah bahwa baik kompresi dan dekompresi dilakukan dalam perangkat lunak, dengan satu-satunya persyaratan perangkat keras adalah sesuatu untuk mendigitalkan sinyal video analog yang masuk.

Banyak konsep dasar tentang cara mengompresi video ada pada saat itu, dengan hal-hal seperti standar MPEG-1 muncul tepat pada waktu yang sama dengan “nv”, tetapi pengkodean real-time dengan MPEG-1 jelas TIDAK mungkin pada saat itu. Perubahan yang saya buat adalah semua tentang mengambil konsep dasar itu dan memperkirakan mereka dengan algoritma yang jauh lebih murah, di mana saya menghindari hal-hal seperti transformasi kosinus dan floating point, dan bahkan menghindari perkalian integer karena itu sangat lambat pada SPARC-station. Saya mencoba melakukan semua yang saya bisa dengan hanya penambahan/pengurangan dan masking dan shifting bit, dan itu mendapatkan kembali cukup kecepatan untuk masih terasa agak seperti video.

Dalam satu atau dua tahun setelah rilis “nv”, ada banyak alat audio dan video yang berbeda untuk dipilih, tidak hanya di MBONE tetapi di tempat lain seperti alat CU-SeeMe yang dibangun di Mac. Jadi, itu jelas merupakan ide yang waktunya telah tiba. Saya sebenarnya akhirnya membuat “nv” interoperasi dengan banyak alat ini, dan dalam beberapa kasus alat lain mengambil codec “nv” saya, jadi mereka dapat berinteroperasi ketika menggunakan skema kompresi saya.

WebRTC #

WebRTC memerlukan upaya standardisasi yang mengerdilkan semua upaya lain yang dijelaskan dalam bab ini. Ini memerlukan kerja sama di dua badan standar yang berbeda (IETF dan W3C) dan ratusan individu di banyak perusahaan dan negara. Untuk memberi kami pandangan ke dalam motivasi dan upaya monumental yang diperlukan untuk membuat WebRTC terjadi kami memiliki Serge Lachapelle.

Serge adalah product manager di Google, saat ini melayani sebagai product manager untuk Google Workspace. Ini adalah ringkasan saya dari wawancara.

Apa yang membawa Anda untuk bekerja pada WebRTC? #

Saya telah bersemangat tentang membangun perangkat lunak komunikasi sejak saya di perguruan tinggi. Pada tahun 90-an teknologi seperti nv mulai muncul, tetapi sulit digunakan. Saya membuat proyek yang memungkinkan Anda untuk bergabung dengan panggilan video langsung dari peramban Anda. Saya juga mem-port-nya ke Windows.

Saya membawa pengalaman ini ke Marratech, sebuah perusahaan yang saya ikut dirikan. Kami membuat perangkat lunak untuk konferensi video grup. Secara teknologi lanskap sangat berbeda. Ujung tombak dalam video didasarkan pada jaringan multicast. Pengguna dapat bergantung pada jaringan untuk mengirimkan paket video ke semua orang dalam panggilan. Ini berarti bahwa kami memiliki server yang sangat sederhana. Ini memiliki kelemahan besar meskipun, jaringan harus dirancang untuk mengakomodasi itu. Industri bergerak menjauh dari multicast ke packet shuffler, lebih umum dikenal sebagai SFU.

Marratech diakuisisi oleh Google pada 2007. Saya kemudian akan bekerja pada proyek yang akan menginformasikan WebRTC.

Proyek Google pertama #

Proyek pertama yang dikerjakan oleh tim WebRTC masa depan adalah chat suara dan video Gmail. Mendapatkan audio dan video ke dalam peramban bukanlah tugas yang mudah. Ini memerlukan komponen khusus yang harus kami lisensikan dari perusahaan yang berbeda. Audio dilisensikan dari GIPs, video dilisensikan untuk Vidyo dan jaringan adalah libjingle. Keajaibannya kemudian membuat semuanya bekerja bersama.

Setiap subsistem memiliki API yang sangat berbeda, dan mengasumsikan Anda memecahkan masalah yang berbeda. Untuk membuat semuanya bekerja bersama Anda memerlukan pengetahuan kerja tentang jaringan, kriptografi, media dan banyak lagi. Justin Uberti adalah orang yang mengambil pekerjaan ini. Dia membawa komponen-komponen ini bersama untuk membuat produk yang dapat digunakan.

Rendering real-time di peramban juga sangat sulit. Kami harus menggunakan NPAPI (Netscape Plugin API) dan melakukan banyak hal cerdas untuk membuatnya bekerja. Pelajaran yang kami pelajari dari proyek ini sangat mempengaruhi WebRTC.

Chrome #

Pada saat yang sama proyek Chrome dimulai di dalam Google. Ada begitu banyak kegembiraan, dan proyek ini memiliki tujuan besar. Ada pembicaraan tentang WebGL, Offline, kemampuan Database, input latensi rendah untuk permainan hanya untuk beberapa nama.

Bergerak menjauh dari NPAPI menjadi fokus besar. Ini adalah API yang kuat, tetapi datang dengan konsekuensi keamanan yang besar. Chrome menggunakan desain sandbox untuk menjaga pengguna tetap aman. Operasi yang berpotensi tidak aman dijalankan dalam proses yang berbeda. Bahkan jika sesuatu yang salah terjadi, penyerang masih tidak memiliki akses ke data pengguna.

WebRTC lahir #

Bagi saya WebRTC lahir dengan beberapa motivasi. Digabungkan mereka melahirkan upaya.

Seharusnya tidak sesulit ini untuk membangun pengalaman RTC. Begitu banyak upaya terbuang mengimplementasikan ulang hal yang sama oleh developer yang berbeda. Kami harus menyelesaikan masalah integrasi yang membuat frustrasi ini sekali, dan fokus pada hal-hal lain.

Komunikasi manusia harus tidak terhalangi dan harus terbuka. Bagaimana oke untuk teks dan HTML menjadi terbuka, tetapi suara saya dan gambar saya secara real-time tidak?

Keamanan adalah prioritas. Menggunakan NPAPI bukan yang terbaik untuk pengguna. Ini juga adalah kesempatan untuk membuat protokol yang aman secara default.

Untuk membuat WebRTC terjadi Google mengakuisisi dan Open Source komponen yang telah kami gunakan sebelumnya. On2 diakuisisi untuk teknologi videonya dan Global IP Solutions untuk teknologi RTC-nya. Saya bertanggung jawab atas upaya mengakuisisi GIPS. Kami bekerja menggabungkan ini dan membuatnya mudah digunakan di dalam dan di luar peramban.

Standardisasi #

Standardisasi WebRTC adalah sesuatu yang benar-benar kami ingin lakukan, tetapi bukan sesuatu yang pernah saya lakukan sebelumnya maupun siapa pun di tim langsung kami. Untuk ini kami benar-benar beruntung memiliki Harald Alvestrand di Google. Dia telah melakukan pekerjaan ekstensif di IETF sudah dan memulai proses standardisasi WebRTC.

Pada musim panas 2010 makan siang informal dijadwalkan di Maastricht. Developer dari banyak perusahaan datang bersama untuk mendiskusikan apa yang seharusnya WebRTC. Makan siang memiliki engineer dari Google, Cisco, Ericsson, Skype, Mozilla, Linden Labs dan lainnya. Anda dapat menemukan kehadiran penuh dan slide presenter di rtc-web.alvestrand.com.

Skype juga memberikan beberapa panduan hebat karena pekerjaan yang mereka lakukan dengan Opus di IETF.

Berdiri di bahu raksasa #

Ketika bekerja di IETF Anda memperluas pekerjaan yang telah datang sebelum Anda. Dengan WebRTC kami beruntung bahwa begitu banyak hal ada. Kami tidak harus mengambil setiap masalah karena mereka sudah terpecahkan. Jika Anda tidak suka teknologi yang sudah ada sebelumnya, itu bisa membuat frustrasi. Harus ada alasan yang cukup besar untuk mengabaikan pekerjaan yang ada, jadi membuat sendiri bukan pilihan.

Kami juga secara sadar tidak mencoba untuk standarisasi ulang hal-hal seperti signaling. Ini sudah diselesaikan dengan SIP dan upaya non-IETF lainnya, dan terasa seperti bisa berakhir sangat politik. Pada akhirnya itu hanya tidak terasa seperti ada banyak nilai untuk ditambahkan ke ruang.

Saya tidak tetap terlibat dalam standardisasi seperti Justin dan Harald, tetapi saya menikmati waktu saya melakukannya. Saya lebih bersemangat tentang kembali membangun hal-hal untuk pengguna.

Masa depan #

WebRTC berada di tempat yang bagus hari ini. Ada banyak perubahan berulang terjadi, tetapi tidak ada yang khususnya yang telah saya kerjakan.

Saya paling bersemangat tentang apa yang dapat dilakukan cloud computing untuk komunikasi. Menggunakan algoritma canggih kami dapat menghapus kebisingan latar belakang dari panggilan dan membuat komunikasi mungkin di mana tidak mungkin sebelumnya. Kami juga melihat WebRTC memperluas jauh melampaui komunikasi… Siapa yang tahu bahwa itu akan menggerakkan gaming berbasis cloud 9 tahun kemudian? Semua ini tidak akan mungkin tanpa fondasi WebRTC.