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 में लोकप्रिय हुई. इसके बाद, Google ने 2011 में Hangouts को लॉन्च किया. यह सुविधा, Gmail की तरह ही Talk का इस्तेमाल करती है. Google ने GIPS को खरीदा है. यह एक ऐसी कंपनी है जिसने आरटीसी के लिए ज़रूरी कई कॉम्पोनेंट डेवलप किए हैं. जैसे, कोडेक और गूंज को कम करने की तकनीकें. Google ने GIPS की ओर से विकसित की गई टेक्नोलॉजी को ओपन सोर्स किया है. साथ ही, इंडस्ट्री की सहमति पक्का करने के लिए, इंटरनेट इंजीनियरिंग टास्क फ़ोर्स (आईईटीएफ़) और वर्ल्ड वाइड वेब कंसोर्टियम (डब्ल्यू3सी) के स्टैंडर्ड बॉडी के साथ काम किया है. मई 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 के सैंपल देखें या क्रिस विल्सन के शानदार उदाहरण आज़माएं. इनमें वेब ऑडियो के लिए इनपुट के तौर पर getUserMedia का इस्तेमाल किया गया है.

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

RTCDataChannel: इसे काम करते हुए देखने के लिए, WebRTC के सैंपल देखें. इनमें से किसी एक डेटा-चैनल के डेमो को देखें.

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

आपका पहला WebRTC

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

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

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

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

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

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

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

MediaStream API को समझने का सबसे आसान तरीका है, इसे इस्तेमाल करते हुए देखना:

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

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

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

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

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

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

getUserMedia का इस्तेमाल, वेब ऑडियो एपीआई के लिए इनपुट नोड के तौर पर भी किया जा सकता है:

// 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() के लिए, अनुमति सिर्फ़ एक बार देनी होती है. पहली बार, ब्राउज़र के infobar में 'अनुमति दें' बटन दिखता है. Chrome ने 2015 के आखिर में, getUserMedia() के लिए एचटीटीपी ऐक्सेस की सुविधा बंद कर दी थी. इसकी वजह यह है कि इसे बेहतर सुविधा के तौर पर रखा गया था.

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

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

• 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 की मदद से स्क्रीन शेयर करना देखें. यह लेख कुछ साल पुराना है, लेकिन अब भी दिलचस्प है.)

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

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

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

इसके बजाय, WebRTC ऐप्लिकेशन डेवलपर अपने हिसाब से कोई भी मैसेजिंग प्रोटोकॉल चुन सकते हैं. जैसे, एसआईपी या एक्सएमपीपी. साथ ही, वे डुप्लीक्स (दोतरफ़ा) कम्यूनिकेशन चैनल भी चुन सकते हैं. appr.tc के उदाहरण में, सिग्नल भेजने के तरीके के तौर पर XHR और Channel API का इस्तेमाल किया गया है. कोडलैब, नोड सर्वर पर चलने वाले 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. ऐलिस, वेबसोकेट या किसी अन्य तरीके जैसे सिग्नल चैनल का इस्तेमाल करके, बॉब को सीरियलाइज़ किया गया उम्मीदवार का डेटा भेजती है.
3. जब बॉब को ऐलिस से उम्मीदवार का मैसेज मिलता है, तो वह उम्मीदवार को रिमोट पीयर के ब्यौरे में जोड़ने के लिए addIceCandidate को कॉल करता है.

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

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

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

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 सेशन सेटअप प्रोटोकॉल या JSEP कहा जाता है. (WebRTC को पहली बार लागू करने के लिए, Ericsson के डेमो वीडियो में सिग्नल भेजने और स्ट्रीम करने की प्रोसेस के बारे में बताने वाला एक बेहतरीन ऐनिमेशन है.)

सिग्नल भेजने की प्रोसेस पूरी होने के बाद, डेटा को सीधे पीयर-टू-पीयर, कॉल करने वाले और कॉल पाने वाले के बीच स्ट्रीम किया जा सकता है. अगर ऐसा नहीं हो पाता है, तो डेटा को किसी इंटरमीडियरी रिले सर्वर के ज़रिए स्ट्रीम किया जा सकता है. इस बारे में ज़्यादा जानकारी बाद में दी जाएगी. स्ट्रीमिंग की सुविधा 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 );

कॉली

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/फ़ायरवॉल ट्रैवर्सल
• पीयर-टू-पीयर कम्यूनिकेशन के काम न करने पर, रिले सर्वर

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

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

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

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

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

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

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

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

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

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

RTCDataChannel एपीआई<

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

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

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

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

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

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

सिंटैक्स को send() तरीके और message इवेंट के साथ, WebSocket जैसा बनाया गया है:

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 से निपटने के लिए, होल-पंचिंग के दौरान रिले (TURN) सर्वर की ज़रूरत पड़े.

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 एडिटर का ड्राफ़्ट
• W3C एडिटर का ड्राफ़्ट: मीडिया कैप्चर और स्ट्रीम (इसे 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 के साथ काम करने की सुविधा के साथ); Chrome for Android 29 और इसके बाद के वर्शन
• Opera 18 और उसके बाद के वर्शन में स्टेबल वर्शन (और Firefox के साथ इंटरऑपरेबिलिटी) और Opera for Android 20 और उसके बाद के वर्शन
• Firefox 22 और उसके बाद के वर्शन (डिफ़ॉल्ट रूप से चालू)

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

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