WebRTC का इस्तेमाल शुरू करें

Sam Dutton

WebRTC, खुले और बिना किसी रुकावट वाले वेब के लिए लंबे समय से चल रही लड़ाई में एक नया मोर्चा है.

ब्रेंडन आइच, JavaScript के आविष्कारक

बिना प्लगिन के रीयल-टाइम में बातचीत करना

कल्पना करें कि आपके फ़ोन, टीवी, और कंप्यूटर एक ही प्लैटफ़ॉर्म पर कम्यूनिकेट कर सकते हैं. मान लें कि आपके वेब ऐप्लिकेशन में वीडियो चैट और पीयर-टू-पीयर डेटा शेयर करने की सुविधा आसानी से जोड़ी जा सकती है. WebRTC का यही विज़न है.

क्या आप इसे आज़माना है? WebRTC की सुविधा, Google Chrome, Safari, Firefox, और Opera में डेस्कटॉप और मोबाइल पर उपलब्ध है. appr.tc पर मौजूद, वीडियो चैट करने वाले ऐप्लिकेशन का इस्तेमाल करके शुरुआत की जा सकती है:

1. अपने ब्राउज़र में appr.tc खोलें.
2. किसी चैट रूम में शामिल होने के लिए, शामिल हों पर क्लिक करें. साथ ही, ऐप्लिकेशन को वेबकैम इस्तेमाल करने की अनुमति दें.
3. पेज के आखिर में दिखने वाले यूआरएल को नए टैब में खोलें. बेहतर होगा कि आप इसे किसी दूसरे कंप्यूटर पर खोलें.

तुरंत शुरू करना

क्या आपके पास इस लेख को पढ़ने का समय नहीं है या आपको सिर्फ़ कोड चाहिए?

• WebRTC के बारे में खास जानकारी पाने के लिए, Google I/O का यह वीडियो देखें या ये स्लाइड देखें:
• अगर आपने getUserMedia एपीआई का इस्तेमाल नहीं किया है, तो एचटीएमएल5 में ऑडियो और वीडियो कैप्चर करना और simpl.info getUserMedia देखें.
• RTCPeerConnection API के बारे में जानने के लिए, यहां दिया गया उदाहरण देखें. साथ ही, 'simpl.info RTCPeerConnection' पर जाएं.
• WebRTC, सिग्नलिंग, फ़ायरवॉल, और NAT ट्रैवर्सल के लिए सर्वर का इस्तेमाल कैसे करता है, यह जानने के लिए appr.tc के कोड और कंसोल लॉग देखें.
• क्या आपको इंतज़ार नहीं करना है और अभी WebRTC आज़माना है? WebRTC JavaScript API का इस्तेमाल करने वाले 20 से ज़्यादा डेमो आज़माएं.
• क्या आपको अपनी मशीन और WebRTC में समस्या आ रही है? WebRTC समस्या हल करने वाले टूल पर जाएं.

इसके अलावा, सीधे WebRTC कोडलैब पर जाएं. इसमें सिलसिलेवार तरीके से बताया गया है कि वीडियो चैट वाला पूरा ऐप्लिकेशन कैसे बनाया जाता है. इसमें एक सामान्य सिग्नलिंग सर्वर भी शामिल है.

WebRTC के बारे में कम शब्दों में जानकारी

वेब के लिए, आखिरी बड़ी चुनौतियों में से एक यह है कि आवाज़ और वीडियो के ज़रिए लोगों को बातचीत करने की सुविधा दी जाए. इसे रीयल-टाइम बातचीत या आरटीसी कहा जाता है. वेब ऐप्लिकेशन में आरटीसी की सुविधा का इस्तेमाल करना उतना ही आसान होना चाहिए जितना टेक्स्ट इनपुट में टेक्स्ट डालना. इसके बिना, आपके पास नए-नए तरीके आज़माने और लोगों को इंटरैक्ट करने के नए तरीके उपलब्ध कराने के विकल्प सीमित हो जाते हैं.

पहले, आरटीसी को कॉर्पोरेट और जटिल माना जाता था. इसके लिए, ऑडियो और वीडियो टेक्नोलॉजी को लाइसेंस देने या उन्हें घर में ही डेवलप करने की ज़रूरत होती थी. आरटीसी टेक्नोलॉजी को मौजूदा कॉन्टेंट, डेटा, और सेवाओं के साथ इंटिग्रेट करना मुश्किल और समय लेने वाला काम है. खास तौर पर, वेब पर ऐसा करना मुश्किल होता है.

Gmail में वीडियो चैट की सुविधा 2008 में लोकप्रिय हुई थी. इसके बाद, 2011 में Google ने Hangouts लॉन्च किया था. यह Talk का इस्तेमाल करता था, जैसा कि Gmail करता था. Google ने GIPS को खरीदा था. इस कंपनी ने आरटीसी के लिए ज़रूरी कई कॉम्पोनेंट बनाए थे. जैसे, कोडेक और गूंज कम करने की तकनीक. Google ने GIPS की बनाई गई टेक्नोलॉजी को ओपन सोर्स किया. साथ ही, इंडस्ट्री के सभी लोगों की सहमति पाने के लिए, Internet Engineering Task Force (IETF) और World Wide Web Consortium (W3C) जैसी स्टैंडर्ड बॉडी के साथ मिलकर काम किया. मई 2011 में, Ericsson ने WebRTC को पहली बार लागू किया.

WebRTC ने रीयल-टाइम, प्लगिन-फ़्री वीडियो, ऑडियो, और डेटा कम्यूनिकेशन के लिए ओपन स्टैंडर्ड लागू किए. इसकी ज़रूरत थी:

• कई वेब सेवाएं आरटीसी का इस्तेमाल करती थीं. हालांकि, इसके लिए डाउनलोड, नेटिव ऐप्लिकेशन या प्लगिन की ज़रूरत होती थी. इनमें Skype, Facebook, और Hangouts शामिल थे.
• प्लगिन को डाउनलोड, इंस्टॉल, और अपडेट करना मुश्किल होता है. साथ ही, इसमें गड़बड़ियां होने की आशंका भी ज़्यादा होती है और यह काफ़ी परेशान करने वाला होता है.
• प्लगिन को डिप्लॉय करना, डीबग करना, समस्या हल करना, टेस्ट करना, और बनाए रखना मुश्किल होता है. साथ ही, इसके लिए लाइसेंस की ज़रूरत पड़ सकती है. इसके अलावा, इसे जटिल और महंगी टेक्नोलॉजी के साथ इंटिग्रेट करना पड़ सकता है. लोगों को प्लगिन इंस्टॉल करने के लिए मनाना अक्सर मुश्किल होता है!

WebRTC प्रोजेक्ट के मुख्य सिद्धांत ये हैं: इसके एपीआई ओपन सोर्स होने चाहिए, मुफ़्त होने चाहिए, स्टैंडर्ड के मुताबिक होने चाहिए, वेब ब्राउज़र में पहले से मौजूद होने चाहिए, और मौजूदा टेक्नोलॉजी से ज़्यादा बेहतर होने चाहिए.

हम अभी कहां हैं?

WebRTC का इस्तेमाल Google Meet जैसे कई ऐप्लिकेशन में किया जाता है. WebRTC को WebKitGTK+ और Qt नेटिव ऐप्लिकेशन के साथ भी इंटिग्रेट किया गया है.

WebRTC इन तीन एपीआई को लागू करता है: - MediaStream (इसे getUserMedia भी कहा जाता है) - RTCPeerConnection - RTCDataChannel

एपीआई के बारे में इन दो खास बातों में बताया गया है:

• WebRTC
• getUserMedia

ये तीनों एपीआई, मोबाइल और डेस्कटॉप पर Chrome, Safari, Firefox, Edge, और Opera के साथ काम करते हैं.

getUserMedia: डेमो और कोड के लिए, WebRTC के सैंपल देखें. इसके अलावा, Chris Wilson के बेहतरीन उदाहरण देखें. इनमें वेब ऑडियो के लिए, getUserMedia को इनपुट के तौर पर इस्तेमाल किया गया है.

RTCPeerConnection: एक आसान डेमो और पूरी तरह से काम करने वाले वीडियो-चैट ऐप्लिकेशन के लिए, क्रमशः WebRTC के सैंपल पीयर कनेक्शन और appr.tc देखें. यह ऐप्लिकेशन, adapter.js का इस्तेमाल करता है. यह एक JavaScript शिम है. इसे Google, WebRTC कम्यूनिटी की मदद से मैनेज करता है. इसका इस्तेमाल, ब्राउज़र के अंतर और स्पेसिफ़िकेशन में होने वाले बदलावों को अलग करने के लिए किया जाता है.

RTCDataChannel: इसे ऐक्शन में देखने के लिए, WebRTC के सैंपल देखें. इससे आपको डेटा-चैनल के डेमो में से एक को देखने में मदद मिलेगी.

WebRTC कोडलैब में, वीडियो चैट और फ़ाइल शेयर करने के लिए एक सामान्य ऐप्लिकेशन बनाने के लिए, तीनों एपीआई का इस्तेमाल करने का तरीका बताया गया है.

आपका पहला WebRTC

WebRTC ऐप्लिकेशन को कई काम करने होते हैं:

• ऑडियो, वीडियो या अन्य डेटा को स्ट्रीम करना.
• नेटवर्क की जानकारी पाना, जैसे कि आईपी पते और पोर्ट. साथ ही, कनेक्शन चालू करने के लिए, इस जानकारी को अन्य WebRTC क्लाइंट (जिन्हें पीयर कहा जाता है) के साथ शेयर करना. ऐसा NAT और फ़ायरवॉल के ज़रिए भी किया जा सकता है.
• गड़बड़ियों की सूचना देने और सेशन शुरू या बंद करने के लिए, सिग्नलिंग कम्यूनिकेशन को मैनेज करता है.
• मीडिया और क्लाइंट की क्षमता के बारे में जानकारी शेयर करना. जैसे, रिज़ॉल्यूशन और कोडेक.
• स्ट्रीम किए जा रहे ऑडियो, वीडियो या डेटा के बारे में जानकारी देना.

स्ट्रीमिंग डेटा को पाने और उसे भेजने के लिए, WebRTC इन एपीआई का इस्तेमाल करता है:

• MediaStream को डेटा स्ट्रीम का ऐक्सेस मिलता है. जैसे, उपयोगकर्ता के कैमरे और माइक्रोफ़ोन से मिलने वाला डेटा.
• RTCPeerConnection की मदद से, ऑडियो या वीडियो कॉल किया जा सकता है. इसमें एन्क्रिप्ट (सुरक्षित) करने और बैंडविड्थ मैनेज करने की सुविधाएं मिलती हैं.
• RTCDataChannel, सामान्य डेटा के पीयर-टू-पीयर कम्यूनिकेशन को चालू करता है.

(WebRTC के नेटवर्क और सिग्नलिंग के पहलुओं के बारे में बाद में विस्तार से बताया गया है.)

MediaStream एपीआई (इसे getUserMedia एपीआई भी कहा जाता है)

MediaStream एपीआई, मीडिया की सिंक्रनाइज़ की गई स्ट्रीम दिखाता है. उदाहरण के लिए, कैमरे और माइक्रोफ़ोन से ली गई स्ट्रीम में, वीडियो और ऑडियो ट्रैक सिंक किए गए हैं. (MediaStreamTrack को <track> एलिमेंट के साथ भ्रमित न करें, क्योंकि यह पूरी तरह से अलग है.)

MediaStream एपीआई को समझने का सबसे आसान तरीका शायद यह है कि इसे इस तरह से देखा जाए:

1. अपने ब्राउज़र में, WebRTC के सैंपल getUserMedia पर जाएं.
2. कंसोल खोलें.
3. ग्लोबल स्कोप में मौजूद stream वैरिएबल की जांच करें.

हर MediaStream में एक इनपुट होता है. यह getUserMedia() से जनरेट किया गया MediaStream हो सकता है. साथ ही, इसमें एक आउटपुट होता है. इसे वीडियो एलिमेंट या RTCPeerConnection को पास किया जा सकता है.

getUserMedia() वाला तरीका, MediaStreamConstraints ऑब्जेक्ट पैरामीटर लेता है और एक Promise दिखाता है, जो MediaStream ऑब्जेक्ट में बदल जाता है.

हर MediaStream में एक label होता है, जैसे कि 'Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ'. getAudioTracks() और getVideoTracks() तरीके, MediaStreamTrack का कलेक्शन दिखाते हैं.

getUserMedia उदाहरण के लिए, stream.getAudioTracks() एक खाली कलेक्शन दिखाता है, क्योंकि इसमें कोई ऑडियो नहीं है. साथ ही, अगर कोई वेबकैम कनेक्ट किया गया है, तो stream.getVideoTracks() एक MediaStreamTrack का कलेक्शन दिखाता है, जो वेबकैम से स्ट्रीम को दिखाता है. हर MediaStreamTrack में एक तरह का ('video' या 'audio'), एक label (जैसे कि 'FaceTime HD Camera (Built-in)') होता है. साथ ही, यह ऑडियो या वीडियो के एक या उससे ज़्यादा चैनलों को दिखाता है. इस मामले में, सिर्फ़ एक वीडियो ट्रैक है और कोई ऑडियो नहीं है. हालांकि, ऐसे कई उदाहरण हैं जहां एक से ज़्यादा ट्रैक होते हैं. जैसे, चैट ऐप्लिकेशन को फ्रंट कैमरे, रियर कैमरे, माइक्रोफ़ोन, और स्क्रीन शेयर करने वाले ऐप्लिकेशन से स्ट्रीम मिलती हैं.

srcObject एट्रिब्यूट सेट करके, किसी वीडियो एलिमेंट में MediaStream जोड़ा जा सकता है. पहले, ऐसा URL.createObjectURL() की मदद से बनाए गए ऑब्जेक्ट यूआरएल के लिए, src एट्रिब्यूट को सेट करके किया जाता था. हालांकि, अब यह सुविधा उपलब्ध नहीं है.

getUserMedia का इस्तेमाल Web Audio API के लिए इनपुट नोड के तौर पर भी किया जा सकता है:

// Cope with browser differences.
let audioContext;
if (typeof AudioContext === 'function') {
  audioContext = new AudioContext();
} else if (typeof webkitAudioContext === 'function') {
  audioContext = new webkitAudioContext(); // eslint-disable-line new-cap
} else {
  console.log('Sorry! Web Audio not supported.');
}

// Create a filter node.
var filterNode = audioContext.createBiquadFilter();
// See https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#BiquadFilterNode-section
filterNode.type = 'highpass';
// Cutoff frequency. For highpass, audio is attenuated below this frequency.
filterNode.frequency.value = 10000;

// Create a gain node to change audio volume.
var gainNode = audioContext.createGain();
// Default is 1 (no change). Less than 1 means audio is attenuated
// and vice versa.
gainNode.gain.value = 0.5;

navigator.mediaDevices.getUserMedia({audio: true}, (stream) => {
  // Create an AudioNode from the stream.
  const mediaStreamSource =
    audioContext.createMediaStreamSource(stream);
  mediaStreamSource.connect(filterNode);
  filterNode.connect(gainNode);
  // Connect the gain node to the destination. For example, play the sound.
  gainNode.connect(audioContext.destination);
});

Chromium पर आधारित ऐप्लिकेशन और एक्सटेंशन में भी getUserMedia को शामिल किया जा सकता है. मेनिफ़ेस्ट में audioCapture और/या videoCapture अनुमतियां जोड़ने से, एक्सटेंशन इंस्टॉल करते समय सिर्फ़ एक बार अनुमति का अनुरोध किया जा सकता है और अनुमति दी जा सकती है. इसके बाद, उपयोगकर्ता से कैमरा या माइक्रोफ़ोन ऐक्सेस करने की अनुमति नहीं मांगी जाती.

getUserMedia() के लिए, अनुमति सिर्फ़ एक बार देनी होती है. पहली बार, ब्राउज़र के सूचना बार में 'अनुमति दें' बटन दिखता है. Chrome ने 2015 के आखिर में, getUserMedia() के लिए एचटीटीपी ऐक्सेस बंद कर दिया था. ऐसा इसलिए किया गया था, क्योंकि इसे बेहद अहम सुविधा के तौर पर क्लासिफ़ाई किया गया था.

इसका मकसद, सिर्फ़ कैमरा या माइक्रोफ़ोन के लिए नहीं, बल्कि किसी भी स्ट्रीमिंग डेटा सोर्स के लिए MediaStream को चालू करना है. इससे, सेव किए गए डेटा या सेंसर या अन्य इनपुट जैसे डेटा सोर्स से स्ट्रीमिंग की जा सकेगी.

getUserMedia(), अन्य JavaScript API और लाइब्रेरी के साथ मिलकर काम करता है:

• Webcam Toy एक फ़ोटोबूथ ऐप्लिकेशन है. यह WebGL का इस्तेमाल करके, फ़ोटो में अजीब और शानदार इफ़ेक्ट जोड़ता है. इन फ़ोटो को शेयर किया जा सकता है या स्थानीय तौर पर सेव किया जा सकता है.
• FaceKat, चेहरा ट्रैक करने की सुविधा वाला एक गेम है. इसे headtrackr.js की मदद से बनाया गया है.
• ASCII Camera, ASCII इमेज जनरेट करने के लिए Canvas API का इस्तेमाल करता है.

कंस्ट्रेंट

getUserMedia() के लिए वीडियो रिज़ॉल्यूशन की वैल्यू सेट करने के लिए, पाबंदियों का इस्तेमाल किया जा सकता है. इससे अन्य पाबंदियों के लिए भी सहायता मिलती है. जैसे, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात); फ़ेसिंग मोड (फ़्रंट या बैक कैमरा); फ़्रेम रेट, ऊंचाई, और चौड़ाई; और applyConstraints() तरीका.

उदाहरण के लिए, WebRTC के सैंपल getUserMedia: रिज़ॉल्यूशन चुनें देखें.

अनुमति न दी गई कंस्ट्रेंट वैल्यू सेट करने पर, DOMException या OverconstrainedError मिलता है. उदाहरण के लिए, अगर अनुरोध किया गया रिज़ॉल्यूशन उपलब्ध नहीं है. इसे काम करते हुए देखने के लिए, डेमो के लिए WebRTC के सैंपल getUserMedia: रिज़ॉल्यूशन चुनें पर जाएं.

स्क्रीन और टैब कैप्चर करने की सुविधा

Chrome ऐप्लिकेशन, chrome.tabCapture और chrome.desktopCapture एपीआई की मदद से, किसी एक ब्राउज़र टैब या पूरे डेस्कटॉप का लाइव वीडियो शेयर करने की सुविधा भी देते हैं. (डेमो और ज़्यादा जानकारी के लिए, WebRTC की मदद से स्क्रीन शेयर करना लेख पढ़ें. यह लेख कुछ साल पुराना है, लेकिन यह अब भी दिलचस्प है.)

स्क्रीन कैप्चर को Chrome में MediaStream सोर्स के तौर पर भी इस्तेमाल किया जा सकता है. इसके लिए, एक्सपेरिमेंट के तौर पर उपलब्ध chromeMediaSource कंस्ट्रेंट का इस्तेमाल करें. ध्यान दें कि स्क्रीन कैप्चर करने के लिए एचटीटीपीएस की ज़रूरत होती है. साथ ही, इसका इस्तेमाल सिर्फ़ डेवलपमेंट के लिए किया जाना चाहिए. ऐसा इसलिए, क्योंकि इसे कमांड-लाइन फ़्लैग के ज़रिए चालू किया जाता है. इसके बारे में इस पोस्ट में बताया गया है.

सिग्नलिंग: सेशन कंट्रोल, नेटवर्क, और मीडिया की जानकारी

WebRTC, ब्राउज़र (इन्हें पीयर भी कहा जाता है) के बीच स्ट्रीमिंग डेटा को ट्रांसफ़र करने के लिए RTCPeerConnection का इस्तेमाल करता है. हालांकि, इसे कम्यूनिकेशन को मैनेज करने और कंट्रोल मैसेज भेजने के लिए भी एक सिस्टम की ज़रूरत होती है. इस प्रोसेस को सिग्नलिंग कहा जाता है. WebRTC, सिग्नल भेजने के तरीकों और प्रोटोकॉल के बारे में नहीं बताता है. सिग्नलिंग, RTCPeerConnection एपीआई का हिस्सा नहीं है.

इसके बजाय, WebRTC ऐप्लिकेशन के डेवलपर, अपनी पसंद के हिसाब से कोई भी मैसेजिंग प्रोटोकॉल चुन सकते हैं. जैसे, एसआईपी या एक्सएमपीपी. साथ ही, वे कोई भी डुप्लेक्स (दोनों तरफ़ से) कम्यूनिकेशन चैनल चुन सकते हैं. appr.tc के उदाहरण में, XHR और Channel API का इस्तेमाल सिग्नलिंग मैकेनिज़्म के तौर पर किया जाता है. codelab में, Node सर्वर पर चलने वाले Socket.io का इस्तेमाल किया जाता है.

सिग्नलिंग का इस्तेमाल तीन तरह की जानकारी शेयर करने के लिए किया जाता है:

• सेशन कंट्रोल मैसेज: इनका इस्तेमाल, बातचीत शुरू करने या बंद करने और गड़बड़ियों की शिकायत करने के लिए किया जाता है.
• नेटवर्क कॉन्फ़िगरेशन: बाहरी दुनिया के लिए, आपके कंप्यूटर का आईपी पता और पोर्ट क्या है?
• मीडिया की क्षमताएँ: आपका ब्राउज़र और जिस ब्राउज़र से उसे कम्यूनिकेट करना है वे कौनसे कोडेक और रिज़ॉल्यूशन हैंडल कर सकते हैं?

पीयर-टू-पीयर स्ट्रीमिंग शुरू करने से पहले, सिग्नलिंग के ज़रिए जानकारी का आदान-प्रदान पूरा होना चाहिए.

उदाहरण के लिए, मान लें कि ऐलिस को बॉब से कम्यूनिकेट करना है. यहां W3C WebRTC स्पेसिफ़िकेशन का एक कोड सैंपल दिया गया है. इसमें सिग्नलिंग प्रोसेस को काम करते हुए दिखाया गया है. इस कोड में, यह माना जाता है कि createSignalingChannel() तरीके में कुछ सिग्नलिंग मैकेनिज़्म बनाए गए हैं. यह भी ध्यान दें कि Chrome और Opera पर, फ़िलहाल RTCPeerConnection प्रीफ़िक्स किया गया है.

// handles JSON.stringify/parse
const signaling = new SignalingChannel();
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
const pc = new RTCPeerConnection(configuration);

// Send any ice candidates to the other peer.
pc.onicecandidate = ({candidate}) => signaling.send({candidate});

// Let the "negotiationneeded" event trigger offer generation.
pc.onnegotiationneeded = async () => {
  try {
    await pc.setLocalDescription(await pc.createOffer());
    // Send the offer to the other peer.
    signaling.send({desc: pc.localDescription});
  } catch (err) {
    console.error(err);
  }
};

// Once remote track media arrives, show it in remote video element.
pc.ontrack = (event) => {
  // Don't set srcObject again if it is already set.
  if (remoteView.srcObject) return;
  remoteView.srcObject = event.streams[0];
};

// Call start() to initiate.
async function start() {
  try {
    // Get local stream, show it in self-view, and add it to be sent.
    const stream =
      await navigator.mediaDevices.getUserMedia(constraints);
    stream.getTracks().forEach((track) =>
      pc.addTrack(track, stream));
    selfView.srcObject = stream;
  } catch (err) {
    console.error(err);
  }
}

signaling.onmessage = async ({desc, candidate}) => {
  try {
    if (desc) {
      // If you get an offer, you need to reply with an answer.
      if (desc.type === 'offer') {
        await pc.setRemoteDescription(desc);
        const stream =
          await navigator.mediaDevices.getUserMedia(constraints);
        stream.getTracks().forEach((track) =>
          pc.addTrack(track, stream));
        await pc.setLocalDescription(await pc.createAnswer());
        signaling.send({desc: pc.localDescription});
      } else if (desc.type === 'answer') {
        await pc.setRemoteDescription(desc);
      } else {
        console.log('Unsupported SDP type.');
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

सबसे पहले, एलिस और बॉब नेटवर्क की जानकारी शेयर करते हैं. (उम्मीदवारों का पता लगाना का मतलब, ICE फ़्रेमवर्क का इस्तेमाल करके नेटवर्क इंटरफ़ेस और पोर्ट का पता लगाना है.)

1. एलिस, onicecandidate हैंडलर के साथ एक RTCPeerConnection ऑब्जेक्ट बनाती है. यह ऑब्जेक्ट तब काम करता है, जब नेटवर्क के उम्मीदवार उपलब्ध हो जाते हैं.
2. ऐलिस, बॉब को सीरियल किया गया उम्मीदवार का डेटा भेजती है. इसके लिए, वे जिस भी सिग्नलिंग चैनल का इस्तेमाल कर रहे हैं उसका इस्तेमाल किया जाता है. जैसे, WebSocket या कोई अन्य तरीका.
3. जब बॉब को एलिस से उम्मीदवार का मैसेज मिलता है, तो वह addIceCandidate को कॉल करके, उम्मीदवार को रिमोट पीयर की जानकारी में जोड़ता है.

WebRTC क्लाइंट (इन्हें पीयर भी कहा जाता है. इस उदाहरण में, ये एलिस और बॉब हैं) को स्थानीय और रिमोट ऑडियो और वीडियो मीडिया की जानकारी का पता लगाना और उसे शेयर करना होता है. जैसे, रिज़ॉल्यूशन और कोडेक की क्षमताएं. मीडिया कॉन्फ़िगरेशन की जानकारी को एक्सचेंज करने के लिए सिग्नलिंग, सेशन डिस्क्रिप्शन प्रोटोकॉल (एसडीपी) का इस्तेमाल करके ऑफ़र और जवाब को एक्सचेंज करके की जाती है:

1. ऐलिस, RTCPeerConnection createOffer() तरीके का इस्तेमाल करती है. इससे मिलने वाला जवाब, RTCSessionDescription - ऐलिस के स्थानीय सेशन का ब्यौरा होता है.
2. कॉल बैक में, एलिस setLocalDescription() का इस्तेमाल करके स्थानीय ब्यौरा सेट करती है. इसके बाद, वह इस सेशन के ब्यौरे को बॉब को भेजती है. इसके लिए, वह सिग्नलिंग चैनल का इस्तेमाल करती है. ध्यान दें कि setLocalDescription() को कॉल किए जाने तक, RTCPeerConnection संभावित उम्मीदवारों की जानकारी इकट्ठा नहीं करेगा. इसे JSEP IETF ड्राफ़्ट में कोड के तौर पर शामिल किया गया है.
3. ऋतिक, मयंक से मिले ब्यौरे को setRemoteDescription() का इस्तेमाल करके रिमोट ब्यौरे के तौर पर सेट करता है.
4. बॉब, RTCPeerConnection createAnswer() तरीके का इस्तेमाल करता है. इसके लिए, वह ऐलिस से मिले रिमोट ब्यौरे को पास करता है, ताकि एक ऐसा लोकल सेशन जनरेट किया जा सके जो ऐलिस के सेशन के साथ काम कर सके. createAnswer() कॉलबैक को RTCSessionDescription पास किया जाता है. बॉब इसे स्थानीय जानकारी के तौर पर सेट करता है और ऐलिस को भेजता है.
5. जब ऐलिस को बॉब के सेशन का ब्यौरा मिलता है, तो वह उसे setRemoteDescription के साथ रिमोट ब्यौरे के तौर पर सेट करती है.
6. पिंग!

RTCSessionDescription ऑब्जेक्ट, ऐसे बड़े डेटा ऑब्जेक्ट होते हैं जो सेशन के ब्यौरे के प्रोटोकॉल, SDP के मुताबिक होते हैं. SDP ऑब्जेक्ट को क्रम से लगाने पर, वह ऐसा दिखता है:

v=0
o=- 3883943731 1 IN IP4 127.0.0.1
s=
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126

// ...

a=ssrc:2223794119 label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh810

नेटवर्क और मीडिया की जानकारी को एक साथ हासिल किया जा सकता है और शेयर किया जा सकता है. हालांकि, ऑडियो और वीडियो स्ट्रीमिंग शुरू करने से पहले, दोनों प्रोसेस पूरी होनी चाहिए.

ऑफ़र/जवाब के बारे में पहले बताया गया आर्किटेक्चर, JavaScript Session Establishment Protocol या JSEP कहलाता है. (Ericsson के डेमो वीडियो में, सिग्नलिंग और स्ट्रीमिंग की प्रोसेस के बारे में बेहतरीन ऐनिमेशन दिया गया है. यह वीडियो, WebRTC को पहली बार लागू करने के बारे में है.)

सिग्नल भेजने की प्रोसेस पूरी होने के बाद, डेटा को सीधे तौर पर पीयर टू पीयर स्ट्रीम किया जा सकता है. यह डेटा, कॉल करने वाले और कॉल पाने वाले के बीच स्ट्रीम किया जाता है. अगर ऐसा नहीं होता है, तो डेटा को इंटरमीडियरी रिले सर्वर के ज़रिए स्ट्रीम किया जाता है. इसके बारे में बाद में ज़्यादा जानकारी दी जाएगी. स्ट्रीमिंग की सुविधा RTCPeerConnection के ज़रिए मिलती है.

RTCPeerConnection

RTCPeerConnection WebRTC कॉम्पोनेंट है. यह पीयर के बीच स्ट्रीमिंग डेटा के स्थिर और असरदार कम्यूनिकेशन को मैनेज करता है.

यहां WebRTC के आर्किटेक्चर का डायग्राम दिया गया है. इसमें RTCPeerConnection की भूमिका के बारे में बताया गया है. जैसा कि आपको दिख रहा है, हरे रंग वाले हिस्से काफ़ी मुश्किल हैं!

JavaScript के नज़रिए से, इस डायग्राम से यह समझना ज़रूरी है कि RTCPeerConnection वेब डेवलपर को कई तरह की मुश्किलों से बचाता है. WebRTC में इस्तेमाल किए जाने वाले कोडेक और प्रोटोकॉल, रीयल-टाइम कम्यूनिकेशन को मुमकिन बनाने के लिए बहुत काम करते हैं. भले ही, नेटवर्क भरोसेमंद न हो:

• पैकेट लॉस को छिपाना
• इको को कम करने की सुविधा
• बैंडविथ के हिसाब से अडजस्ट होने की सुविधा
• डाइनैमिक जिटर बफ़रिंग
• आवाज़ को अपने आप नियंत्रित करने की सेटिंग
• शोर कम करने और उसे दबाने की सुविधा
• इमेज को साफ़ करना

पिछले W3C कोड में, सिग्नलिंग के नज़रिए से WebRTC का आसान उदाहरण दिखाया गया है. यहां WebRTC की सुविधा वाले दो ऐप्लिकेशन के बारे में बताया गया है. पहला उदाहरण, RTCPeerConnection को दिखाने के लिए एक सामान्य उदाहरण है. वहीं, दूसरा उदाहरण पूरी तरह से काम करने वाला वीडियो चैट क्लाइंट है.

सर्वर के बिना RTCPeerConnection

नीचे दिया गया कोड, WebRTC के सैंपल पीयर कनेक्शन से लिया गया है. इसमें एक वेब पेज पर लोकल और रिमोट RTCPeerConnection (और लोकल और रिमोट वीडियो) मौजूद हैं. इससे कोई खास फ़ायदा नहीं होता. कॉलर और कॉल पाने वाला व्यक्ति, दोनों एक ही पेज पर होते हैं. हालांकि, इससे RTCPeerConnection एपीआई के काम करने के तरीके के बारे में थोड़ी ज़्यादा जानकारी मिलती है. ऐसा इसलिए, क्योंकि पेज पर मौजूद RTCPeerConnection ऑब्जेक्ट, इंटरमीडियरी सिग्नलिंग मेकेनिज़्म का इस्तेमाल किए बिना, सीधे तौर पर डेटा और मैसेज शेयर कर सकते हैं.

इस उदाहरण में, pc1 लोकल पीयर (कॉल करने वाला) और pc2 रिमोट पीयर (कॉल पाने वाला) को दिखाता है.

कॉल करने वाले

1. एक नया RTCPeerConnection बनाएं और getUserMedia() से स्ट्रीम जोड़ें: ```js // Servers is an optional configuration file. (TURN और STUN के बारे में बाद में बताया गया है.) pc1 = new RTCPeerConnection(servers); // ... localStream.getTracks().forEach((track) => { pc1.addTrack(track, localStream); });

1. एक ऑफ़र बनाएं और उसे pc1 के लिए स्थानीय ब्यौरे के तौर पर और pc2 के लिए रिमोट ब्यौरे के तौर पर सेट करें. इसे सीधे तौर पर कोड में किया जा सकता है. इसके लिए, सिग्नलिंग का इस्तेमाल करने की ज़रूरत नहीं है, क्योंकि कॉल करने वाला और कॉल पाने वाला, दोनों एक ही पेज पर हैं: js pc1.setLocalDescription(desc).then(() => { onSetLocalSuccess(pc1); }, onSetSessionDescriptionError ); trace('pc2 setRemoteDescription start'); pc2.setRemoteDescription(desc).then(() => { onSetRemoteSuccess(pc2); }, onSetSessionDescriptionError );

Callee

1. pc2 बनाएं. इसके बाद, जब pc1 से स्ट्रीम जोड़ दी जाए, तो उसे वीडियो एलिमेंट में दिखाएं: js pc2 = new RTCPeerConnection(servers); pc2.ontrack = gotRemoteStream; //... function gotRemoteStream(e){ vid2.srcObject = e.stream; }

RTCPeerConnection एपीआई और सर्वर

असलियत में, WebRTC को सर्वर की ज़रूरत होती है. भले ही, यह सर्वर कितना भी आसान हो. ऐसा इसलिए होता है, ताकि ये काम किए जा सकें:

• उपयोगकर्ता एक-दूसरे को खोजते हैं और रीयल-वर्ल्ड की जानकारी शेयर करते हैं. जैसे, नाम.
• WebRTC क्लाइंट ऐप्लिकेशन (पीयर), नेटवर्क की जानकारी शेयर करते हैं.
• पीयर, मीडिया के बारे में डेटा शेयर करते हैं. जैसे, वीडियो का फ़ॉर्मैट और रिज़ॉल्यूशन.
• WebRTC क्लाइंट ऐप्लिकेशन, NAT गेटवे और फ़ायरवॉल से होकर गुज़रते हैं.

दूसरे शब्दों में कहें, तो WebRTC को सर्वर साइड पर चार तरह की सुविधाओं की ज़रूरत होती है:

• उपयोगकर्ता के बारे में जानकारी पाना और उससे कम्यूनिकेट करना
• सिग्नलिंग
• NAT/फ़ायरवॉल ट्रैवर्सल
• पीयर-टू-पीयर कम्यूनिकेशन काम न करने पर, रिले सर्वर

इस लेख में, NAT ट्रैवर्सल, पीयर-टू-पीयर नेटवर्किंग, और उपयोगकर्ता की पहचान करने और सिग्नल भेजने के लिए सर्वर ऐप्लिकेशन बनाने से जुड़ी ज़रूरी शर्तों के बारे में नहीं बताया गया है. यह कहना काफ़ी होगा कि ICE फ़्रेमवर्क, STUN प्रोटोकॉल और इसके एक्सटेंशन TURN का इस्तेमाल करता है. इससे RTCPeerConnection को NAT ट्रैवर्सल और नेटवर्क से जुड़ी अन्य समस्याओं से निपटने में मदद मिलती है.

ICE, पियर को कनेक्ट करने के लिए एक फ़्रेमवर्क है. जैसे, दो वीडियो चैट क्लाइंट. शुरुआत में, ICE, UDP के ज़रिए कम से कम लेटेन्सी के साथ पियर को सीधे तौर पर कनेक्ट करने की कोशिश करता है. इस प्रोसेस में, STUN सर्वर का सिर्फ़ एक काम होता है: NAT के पीछे मौजूद किसी पीयर को यह पता लगाने में मदद करना कि उसका सार्वजनिक पता और पोर्ट क्या है. (STUN और TURN के बारे में ज़्यादा जानने के लिए, WebRTC ऐप्लिकेशन के लिए ज़रूरी बैकएंड सेवाएं बनाना लेख पढ़ें.)

अगर यूडीपी काम नहीं करता है, तो आईसीई टीसीपी का इस्तेमाल करता है. अगर डायरेक्ट कनेक्शन काम नहीं करता है, तो ICE, इंटरमीडियरी (रिले) TURN सर्वर का इस्तेमाल करता है. ऐसा खास तौर पर एंटरप्राइज़ एनएटी ट्रैवर्सल और फ़ायरवॉल की वजह से होता है. दूसरे शब्दों में, ICE सबसे पहले UDP के साथ STUN का इस्तेमाल करके, पीयर को सीधे तौर पर कनेक्ट करता है. अगर ऐसा नहीं हो पाता है, तो यह TURN रिले सर्वर पर वापस आ जाता है. उम्मीदवारों को ढूंढना एक्सप्रेशन का मतलब, नेटवर्क इंटरफ़ेस और पोर्ट ढूंढने की प्रोसेस से है.

WebRTC इंजीनियर जस्टिन उबेर्ती ने 2013 के Google I/O WebRTC प्रज़ेंटेशन में ICE, STUN, और TURN के बारे में ज़्यादा जानकारी दी है. (प्रज़ेंटेशन की स्लाइड में, TURN और STUN सर्वर लागू करने के उदाहरण दिए गए हैं.)

वीडियो चैट करने वाला एक आसान क्लाइंट

WebRTC को आज़माने के लिए, appr.tc पर वीडियो-चैट डेमो आज़माएं. इसमें STUN सर्वर का इस्तेमाल करके, सिग्नलिंग और NAT/फ़ायरवॉल ट्रैवर्सल की सुविधा मिलती है. यह ऐप्लिकेशन, adapter.js का इस्तेमाल करता है. यह एक शिम है, जो ऐप्लिकेशन को स्पेसिफ़िकेशन में होने वाले बदलावों और प्रीफ़िक्स के अंतर से बचाता है.

इस कोड में लॉगिंग के लिए जान-बूझकर ज़्यादा शब्दों का इस्तेमाल किया गया है. इवेंट के क्रम को समझने के लिए, कंसोल देखें. यहां कोड के बारे में पूरी जानकारी दी गई है.

नेटवर्क टोपोलॉजी

फ़िलहाल, WebRTC सिर्फ़ एक-दूसरे से कम्यूनिकेट करने की सुविधा देता है. हालांकि, इसका इस्तेमाल ज़्यादा जटिल नेटवर्क के लिए किया जा सकता है. जैसे, कई पीयर एक-दूसरे से सीधे तौर पर या मल्टीपॉइंट कंट्रोल यूनिट (एमसीयू) के ज़रिए कम्यूनिकेट करते हैं. एमसीयू एक ऐसा सर्वर होता है जो बड़ी संख्या में लोगों को मैनेज कर सकता है. साथ ही, यह चुनिंदा स्ट्रीम को फ़ॉरवर्ड कर सकता है. इसके अलावा, यह ऑडियो और वीडियो को मिक्स या रिकॉर्ड भी कर सकता है.

मौजूदा समय में कई WebRTC ऐप्लिकेशन, सिर्फ़ वेब ब्राउज़र के बीच कम्यूनिकेशन की सुविधा देते हैं. हालांकि, गेटवे सर्वर की मदद से, ब्राउज़र पर चल रहे WebRTC ऐप्लिकेशन को टेलीफ़ोन (इन्हें PSTN भी कहा जाता है) और VOIP सिस्टम जैसे डिवाइसों के साथ इंटरैक्ट करने की सुविधा मिलती है. मई 2012 में, Doubango Telecom ने WebRTC और WebSocket की मदद से बनाए गए sipml5 SIP client को ओपन सोर्स कर दिया था. इससे (अन्य संभावित इस्तेमाल के साथ-साथ) iOS और Android पर चलने वाले ब्राउज़र और ऐप्लिकेशन के बीच वीडियो कॉल किए जा सकते हैं. Google I/O में, Tethr और Tropo ने आपदा के समय कम्यूनिकेशन के लिए एक फ़्रेमवर्क ब्रिफ़केस में दिखाया. इसमें OpenBTS सेल का इस्तेमाल किया गया था, ताकि WebRTC के ज़रिए फ़ीचर फ़ोन और कंप्यूटर के बीच कम्यूनिकेशन किया जा सके. बिना किसी कैरियर के टेलीफ़ोन से बातचीत!

RTCDataChannel एपीआई<

ऑडियो और वीडियो के साथ-साथ, WebRTC अन्य तरह के डेटा के लिए रीयल-टाइम कम्यूनिकेशन की सुविधा देता है.

RTCDataChannel एपीआई की मदद से, पीयर-टू-पीयर तरीके से किसी भी डेटा को कम समय में और ज़्यादा थ्रूपुट के साथ शेयर किया जा सकता है. सिंगल-पेज डेमो और फ़ाइल ट्रांसफ़र करने वाला सामान्य ऐप्लिकेशन बनाने का तरीका जानने के लिए, WebRTC के सैंपल और WebRTC कोडलैब देखें.

इस एपीआई का इस्तेमाल कई तरीकों से किया जा सकता है. जैसे:

• गेमिंग
• रिमोट डेस्कटॉप ऐप्लिकेशन
• रीयल-टाइम में टेक्स्ट चैट करने की सुविधा
• फ़ाइल ट्रांसफ़र करें
• डिसेंट्रलाइज़्ड नेटवर्क

इस एपीआई में कई सुविधाएं हैं, ताकि RTCPeerConnection का ज़्यादा से ज़्यादा फ़ायदा लिया जा सके. साथ ही, पीयर-टू-पीयर कम्यूनिकेशन को असरदार और आसान बनाया जा सके:

• RTCPeerConnection सेशन सेटअप का फ़ायदा लेना
• एक साथ कई चैनलों को प्राथमिकता के साथ देखना
• भरोसेमंद और गैर-भरोसेमंद डिलीवरी सिमैंटिक
• पहले से मौजूद सुरक्षा (डीटीएलएस) और कंजेशन कंट्रोल
• ऑडियो या वीडियो के साथ या बिना ऑडियो या वीडियो के इस्तेमाल किया जा सकता है

सिंटैक्स को जान-बूझकर WebSocket के जैसा रखा गया है. इसमें send() तरीका और message इवेंट शामिल है:

const localConnection = new RTCPeerConnection(servers);
const remoteConnection = new RTCPeerConnection(servers);
const sendChannel =
  localConnection.createDataChannel('sendDataChannel');

// ...

remoteConnection.ondatachannel = (event) => {
  receiveChannel = event.channel;
  receiveChannel.onmessage = onReceiveMessage;
  receiveChannel.onopen = onReceiveChannelStateChange;
  receiveChannel.onclose = onReceiveChannelStateChange;
};

function onReceiveMessage(event) {
  document.querySelector("textarea#send").value = event.data;
}

document.querySelector("button#send").onclick = () => {
  var data = document.querySelector("textarea#send").value;
  sendChannel.send(data);
};

इसमें ब्राउज़र के बीच सीधे तौर पर कम्यूनिकेशन होता है. इसलिए, RTCDataChannel, WebSocket से ज़्यादा तेज़ हो सकता है. भले ही, फ़ायरवॉल और NAT से निपटने के लिए होल-पंचिंग के दौरान रिले (टर्न) सर्वर की ज़रूरत हो.

RTCDataChannel की सुविधा Chrome, Safari, Firefox, Opera, और Samsung Internet में उपलब्ध है. Cube Slam गेम, गेम की स्थिति की जानकारी देने के लिए इस एपीआई का इस्तेमाल करता है. अपने दोस्त के साथ खेलें या भालू के साथ खेलें! Sharefest नाम के इनोवेटिव प्लैटफ़ॉर्म ने RTCDataChannel के ज़रिए फ़ाइल शेयर करने की सुविधा दी. साथ ही, peerCDN ने यह दिखाया कि WebRTC, पीयर-टू-पीयर कॉन्टेंट डिस्ट्रिब्यूशन को कैसे चालू कर सकता है.

RTCDataChannel के बारे में ज़्यादा जानने के लिए, IETF के प्रोटोकॉल के ड्राफ़्ट स्पेसिफ़िकेशन को देखें.

सुरक्षा

रीयल-टाइम कम्यूनिकेशन की सुविधा देने वाला कोई ऐप्लिकेशन या प्लगिन, कई तरीकों से सुरक्षा से छेड़छाड़ कर सकता है. उदाहरण के लिए:

• बिना एन्क्रिप्ट (सुरक्षित) किए गए मीडिया या डेटा को ब्राउज़र के बीच या ब्राउज़र और सर्वर के बीच रोका जा सकता है.
• कोई ऐप्लिकेशन, उपयोगकर्ता की जानकारी के बिना वीडियो या ऑडियो रिकॉर्ड और डिस्ट्रिब्यूट कर सकता है.
• ऐसा हो सकता है कि नुकसान न पहुंचाने वाले किसी प्लगिन या ऐप्लिकेशन के साथ-साथ, मैलवेयर या वायरस भी इंस्टॉल हो गए हों.

इन समस्याओं से बचने के लिए, WebRTC में कई सुविधाएं उपलब्ध हैं:

• WebRTC को लागू करने के लिए, DTLS और SRTP जैसे सुरक्षित प्रोटोकॉल का इस्तेमाल किया जाता है.
• सिग्नलिंग मैकेनिज़्म के साथ-साथ, सभी WebRTC कॉम्पोनेंट के लिए एन्क्रिप्शन ज़रूरी है.
• WebRTC कोई प्लगिन नहीं है. इसके कॉम्पोनेंट, ब्राउज़र सैंडबॉक्स में चलते हैं, न कि किसी अलग प्रोसेस में. कॉम्पोनेंट को अलग से इंस्टॉल करने की ज़रूरत नहीं होती. जब ब्राउज़र अपडेट होता है, तब ये भी अपडेट हो जाते हैं.
• कैमरा और माइक्रोफ़ोन का ऐक्सेस साफ़ तौर पर दिया जाना चाहिए. साथ ही, जब कैमरा या माइक्रोफ़ोन चालू हो, तो यूज़र इंटरफ़ेस में यह साफ़ तौर पर दिखना चाहिए.

इस लेख में, स्ट्रीमिंग मीडिया के लिए सुरक्षा से जुड़ी पूरी जानकारी नहीं दी गई है. ज़्यादा जानकारी के लिए, IETF की ओर से सुझाया गया WebRTC का सुरक्षा आर्किटेक्चर देखें.

कुल मिलाकर कहें, तो

WebRTC के एपीआई और स्टैंडर्ड, कॉन्टेंट बनाने और कम्यूनिकेशन के टूल को सभी के लिए उपलब्ध करा सकते हैं. इनमें टेलीफ़ोनी, गेमिंग, वीडियो प्रोडक्शन, संगीत बनाना, और खबरें इकट्ठा करना शामिल है.

टेक्नोलॉजी में इससे ज़्यादा बदलाव नहीं हो सकता.

ब्लॉगर फ़िल एडहोम ने कहा, "WebRTC और HTML5, रीयल-टाइम में कम्यूनिकेशन के लिए वही बदलाव कर सकते हैं जो ओरिजनल ब्राउज़र ने जानकारी के लिए किया था."

डेवलपर टूल

• चालू सेशन के लिए WebRTC के आंकड़े यहां देखे जा सकते हैं:
  • Chrome में about://webrtc-internals
  • Opera में opera://webrtc-internals पर जाएं
  • Firefox में about:webrtc

    

• अलग-अलग ब्राउज़र के लिए इंटरऑप नोट
• adapter.js, WebRTC के लिए एक JavaScript शिम है. इसे Google मैनेज करता है. इसमें WebRTC कम्यूनिटी की मदद ली जाती है. यह वेंडर प्रीफ़िक्स, ब्राउज़र के अंतर, और स्पेसिफ़िकेशन में हुए बदलावों को अलग करता है.
• WebRTC सिग्नलिंग प्रोसेस के बारे में ज़्यादा जानने के लिए, कंसोल पर appr.tc का लॉग आउटपुट देखें.
• अगर आपको यह सब बहुत मुश्किल लग रहा है, तो हो सकता है कि आपको WebRTC फ़्रेमवर्क या पूरी WebRTC सेवा का इस्तेमाल करना बेहतर लगे.
• गड़बड़ी की रिपोर्ट और सुविधा के अनुरोधों का हमेशा स्वागत किया जाता है:
  • WebRTC से जुड़ी गड़बड़ियां
  • Chrome में मौजूद गड़बड़ियां
  • Opera में मौजूद गड़बड़ियां
  • Firefox में मौजूद गड़बड़ियां
  • WebRTC डेमो से जुड़ी गड़बड़ियां
  • Adapter.js से जुड़ी गड़बड़ियां

ज़्यादा जानें

• Google I/O 2012 में जस्टिन उबेर्ती का WebRTC सेशन
• ऐलन बी॰ जॉनसन और डेनियल सी. बर्नेट ने WebRTC के बारे में एक किताब लिखी है. यह किताब अब प्रिंट और ई-बुक फ़ॉर्मैट में तीसरे एडिशन के तौर पर उपलब्ध है. इसे webrtcbook.com पर जाकर पढ़ा जा सकता है.
• webrtc.org, WebRTC के बारे में सारी जानकारी देने वाली वेबसाइट है. इसमें डेमो, दस्तावेज़, और चर्चाएं शामिल हैं.
• discuss-webrtc, WebRTC से जुड़ी तकनीकी चर्चा के लिए एक Google ग्रुप है.
• @webrtc
• Google Developers के Talk दस्तावेज़ में, NAT ट्रैवर्सल, STUN, रिले सर्वर, और कैंडिडेट इकट्ठा करने के बारे में ज़्यादा जानकारी दी गई है.
• GitHub पर WebRTC
• WebRTC के बारे में जवाब पाने और सवाल पूछने के लिए, Stack Overflow एक अच्छा प्लैटफ़ॉर्म है.

मानक और प्रोटोकॉल

• WebRTC W3C Editor's Draft
• W3C Editor's Draft: Media Capture and Streams (इसे getUserMedia भी कहा जाता है)
• IETF वर्किंग ग्रुप चार्टर
• IETF WebRTC डेटा चैनल प्रोटोकॉल ड्राफ़्ट
• IETF JSEP ड्राफ़्ट
• आईसीई के लिए आईईटीएफ़ का सुझाया गया स्टैंडर्ड
• IETF RTCWEB वर्किंग ग्रुप का इंटरनेट-ड्राफ़्ट: वेब रीयल-टाइम कम्यूनिकेशन के इस्तेमाल के उदाहरण और ज़रूरी शर्तें

WebRTC की सुविधा के बारे में खास जानकारी

MediaStream और getUserMedia एपीआई

• Chrome डेस्कटॉप 18.0.1008 और इसके बाद का वर्शन; Android के लिए Chrome 29 और इसके बाद का वर्शन
• Opera 18 और इसके बाद के वर्शन; Opera for Android 20 और इसके बाद के वर्शन
• Opera 12, Opera Mobile 12 (Presto इंजन पर आधारित)
• Firefox 17 और इसके बाद के वर्शन
• Microsoft Edge 16 और उसके बाद के वर्शन
• iOS पर Safari 11.2 और उसके बाद का वर्शन और MacOS पर 11.1 और उसके बाद का वर्शन
• Android पर UC 11.8 और उसके बाद का वर्शन
• Samsung Internet 4 और उसके बाद के वर्शन

RTCPeerConnection एपीआई

• Chrome डेस्कटॉप 20 और इसके बाद के वर्शन; Android के लिए Chrome 29 और इसके बाद के वर्शन (फ़्लैगलेस)
• Opera 18 और इसके बाद के वर्शन (डिफ़ॉल्ट रूप से चालू); Opera for Android 20 और इसके बाद के वर्शन (डिफ़ॉल्ट रूप से चालू)
• Firefox 22 और इसके बाद के वर्शन (डिफ़ॉल्ट रूप से चालू)
• Microsoft Edge 16 और उसके बाद के वर्शन
• iOS पर Safari 11.2 और उसके बाद का वर्शन और MacOS पर 11.1 और उसके बाद का वर्शन
• Samsung Internet 4 और उसके बाद के वर्शन

RTCDataChannel एपीआई

• Chrome 25 में एक्सपेरिमेंटल वर्शन, लेकिन Chrome 26 और इसके बाद के वर्शन में ज़्यादा स्टेबल (और Firefox के साथ काम करने वाला); Android के लिए Chrome 29 और इसके बाद के वर्शन
• Opera 18 और इसके बाद के वर्शन में स्टेबल वर्शन (और Firefox के साथ इंटरऑपरेबिलिटी के साथ); Opera for Android 20 और इसके बाद के वर्शन
• Firefox 22 और इसके बाद के वर्शन (डिफ़ॉल्ट रूप से चालू)

एपीआई के लिए, अलग-अलग प्लैटफ़ॉर्म पर काम करने की सुविधा के बारे में ज़्यादा जानकारी पाने के लिए, caniuse.com और Chrome Platform Status देखें. जैसे, getUserMedia और RTCPeerConnection.

RTCPeerConnection के लिए नेटिव एपीआई भी webrtc.org पर मौजूद दस्तावेज़ में उपलब्ध हैं.