WebRTC ऐप्लिकेशन के लिए ज़रूरी बैकएंड सेवाएं बनाएं

सिग्नल क्या है?

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

• सेशन कंट्रोल मैसेज, जिनका इस्तेमाल बातचीत शुरू या बंद करने के लिए किया जाता है
• गड़बड़ी के मैसेज
• मीडिया का मेटाडेटा, जैसे कि कोडेक, कोडेक सेटिंग, बैंडविथ, और मीडिया टाइप
• सुरक्षित कनेक्शन बनाने के लिए इस्तेमाल किया जाने वाला मुख्य डेटा
• नेटवर्क डेटा, जैसे कि होस्ट का आईपी पता और पोर्ट, जो बाहरी दुनिया को दिखता है

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

WebRTC में सिग्नल भेजने की सुविधा क्यों नहीं है?

WebRTC स्टैंडर्ड में, सिग्नल भेजने के तरीकों और प्रोटोकॉल के बारे में नहीं बताया गया है. ऐसा इसलिए किया गया है, ताकि वेबटीसी के साथ काम करने वाली मौजूदा टेक्नोलॉजी के साथ बेहतर तरीके से काम किया जा सके. इस तरीके के बारे में JavaScript सेशन सेटअप प्रोटोकॉल (JSEP) में बताया गया है:

JSEP के आर्किटेक्चर की वजह से, ब्राउज़र को स्टेटस सेव करने की ज़रूरत नहीं पड़ती. इसका मतलब है कि उसे सिग्नल स्टेट मशीन के तौर पर काम नहीं करना पड़ता. उदाहरण के लिए, अगर हर बार पेज रीलोड होने पर सिग्नल डेटा मिट जाता है, तो यह समस्या हो सकती है. इसके बजाय, सिग्नल की स्थिति को सर्वर पर सेव किया जा सकता है.

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

v=0
o=- 7614219274584779017 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS
m=audio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:W2TGCZw2NZHuwlnf
a=ice-pwd:xdQEccP40E+P0L5qTyzDgfmW
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9c1AHz27dZ9xPI91YNfSlI67/EMkjHHIHORiClQe
a=rtpmap:111 opus/48000/2
…

क्या आपको यह जानना है कि एसडीपी के इस टेक्नोलॉजी का क्या मतलब है? इंटरनेट इंजीनियरिंग टास्क फ़ोर्स (IETF) के उदाहरणों पर एक नज़र डालें.

ध्यान रखें कि WebRTC को इस तरह से डिज़ाइन किया गया है कि ऑफ़र या जवाब को लोकल या रिमोट ब्यौरे के तौर पर सेट करने से पहले, एसडीपी टेक्स्ट में वैल्यू में बदलाव करके उसमें बदलाव किया जा सकता है. उदाहरण के लिए, appr.tc में preferAudioCodec() फ़ंक्शन का इस्तेमाल, डिफ़ॉल्ट कोडेक और बिटरेट सेट करने के लिए किया जा सकता है. JavaScript की मदद से एसडीपी में बदलाव करना थोड़ा मुश्किल है. इस बारे में चर्चा की जा रही है कि क्या WebRTC के आने वाले वर्शन में JSON का इस्तेमाल किया जाना चाहिए. हालांकि, एसडीपी का इस्तेमाल जारी रखने के कुछ फ़ायदे हैं.

RTCPeerConnection एपीआई और सिग्नल: ऑफ़र, जवाब, और उम्मीदवार

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

इस प्रोसेस को शुरू करने के लिए, RTCPeerConnection के पास दो टास्क हैं:

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

इस लोकल डेटा की पुष्टि हो जाने के बाद, इसे रिमोट पीयर के साथ सिग्नल देने वाले तरीके से शेयर किया जाना चाहिए.

मान लें कि ऐलिस, ईव को कॉल करने की कोशिश कर रही है. यहां ऑफ़र/जवाब देने की पूरी प्रोसेस के बारे में पूरी जानकारी दी गई है:

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

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

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

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

सिग्नलिंग के लिए WebRTC कोड करना

यहां दिया गया कोड स्निपेट, W3C कोड का उदाहरण है. इसमें सिग्नल भेजने की पूरी प्रोसेस के बारे में बताया गया है. कोड में, SignalingChannel जैसे सिग्नल देने वाले किसी तरीके के मौजूद होने का अनुमान लगाया गया है. सिग्नल भेजने के बारे में ज़्यादा जानकारी बाद में दी गई है.

// 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);
  }
};

// After 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);
  }
};

ऑफ़र/जवाब और उम्मीदवारों के बीच डेटा एक्सचेंज करने की प्रोसेस को देखने के लिए, simpl.info RTCPeerConnection देखें. साथ ही, एक पेज वाली वीडियो चैट के उदाहरण के लिए, कंसोल लॉग देखें. अगर आपको ज़्यादा जानकारी चाहिए, तो Google Chrome में about://webrtc-internals पेज या Opera में opera://webrtc-internals पेज से, WebRTC सिग्नल और आंकड़ों का पूरा डंप डाउनलोड करें.

पीयर डिस्कवरी

यह "मुझे बात करने के लिए कोई व्यक्ति कैसे मिल सकता है?" सवाल पूछने का एक शानदार तरीका है.

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

WebRTC, पीयर डिस्कवरी के तरीकों को तय नहीं करता. साथ ही, आपको यहां विकल्पों के बारे में जानकारी नहीं मिलती. यह प्रोसेस उतनी ही आसान हो सकती है जितनी कि किसी यूआरएल को ईमेल या मैसेज करना. Talky, tawk.to, और Browser Meeting जैसे वीडियो चैट ऐप्लिकेशन के लिए, लोगों को कॉल में शामिल होने का न्योता देने के लिए, कस्टम लिंक शेयर किया जाता है. डेवलपर क्रिस बॉल ने एक दिलचस्प serverless-webrtc प्रयोग बनाया है. इसकी मदद से, WebRTC कॉल में हिस्सा लेने वाले लोग अपनी पसंद की किसी भी मैसेजिंग सेवा, जैसे कि इंस्टैंट मैसेज, ईमेल या होमिंग पिजन से मेटाडेटा शेयर कर सकते हैं.

सिग्नल भेजने की सेवा कैसे बनाई जा सकती है?

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

शुक्र है कि सिग्नल देने वाले मैसेज छोटे होते हैं और ज़्यादातर कॉल की शुरुआत में ही भेजे जाते हैं. वीडियो चैट सेशन के लिए appr.tc के साथ टेस्टिंग में, सिग्नल सेवा ने कुल 30 से 45 मैसेज मैनेज किए. सभी मैसेज का कुल साइज़ करीब 10 केबी था.

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

सर्वर से क्लाइंट पर मैसेज भेजना

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

हाल ही में, EventSource एपीआई को बड़े पैमाने पर लागू किया गया है. इससे सर्वर से भेजे गए इवेंट चालू होते हैं. ये ऐसे इवेंट होते हैं जो एचटीटीपी के ज़रिए, वेब सर्वर से ब्राउज़र क्लाइंट पर भेजे जाते हैं. EventSource को एकतरफ़ा मैसेजिंग के लिए डिज़ाइन किया गया है. हालांकि, सिग्नल मैसेज का आदान-प्रदान करने के लिए सेवा बनाने के लिए, इसका इस्तेमाल XHR के साथ किया जा सकता है. सिग्नल सेवा, कॉल करने वाले व्यक्ति से मिला मैसेज, EventSource के ज़रिए कॉल पाने वाले व्यक्ति को भेजती है. यह मैसेज, XHR अनुरोध की मदद से डिलीवर किया जाता है.

WebSocket एक बेहतर समाधान है. इसे क्लाइंट-सर्वर के बीच फ़ुल डुपलेक्स कम्यूनिकेशन के लिए डिज़ाइन किया गया है. इसकी मदद से, एक ही समय पर दोनों दिशाओं में मैसेज भेजे और पाए जा सकते हैं. पूरी तरह से WebSocket या सर्वर से भेजे गए इवेंट (EventSource) की मदद से बनाई गई सिग्नलिंग सेवा का एक फ़ायदा यह है कि इन एपीआई के बैकएंड को कई तरह के वेब फ़्रेमवर्क पर लागू किया जा सकता है. ये फ़्रेमवर्क, PHP, Python, और Ruby जैसी भाषाओं के लिए, ज़्यादातर वेब-होस्टिंग पैकेज में आम तौर पर इस्तेमाल किए जाते हैं.

Opera Mini को छोड़कर, सभी मॉडर्न ब्राउज़र WebSocket के साथ काम करते हैं. सबसे अहम बात यह है कि WebRTC के साथ काम करने वाले सभी ब्राउज़र, डेस्कटॉप और मोबाइल, दोनों पर WebSocket के साथ काम करते हैं. सभी कनेक्शन के लिए TLS का इस्तेमाल किया जाना चाहिए, ताकि यह पक्का किया जा सके कि मैसेज को एन्क्रिप्ट (सुरक्षित) किए बिना न तो पढ़ा जा सके और न ही उसे इंटरसेप्ट किया जा सके. साथ ही, प्रॉक्सी ट्रैवल से जुड़ी समस्याओं को कम करने के लिए भी ऐसा करना चाहिए. (WebSocket और प्रॉक्सी ट्रैवल के बारे में ज़्यादा जानकारी के लिए, इल्या ग्रिगोरिक की हाई परफ़ॉर्मेंस ब्राउज़र नेटवर्किंग में WebRTC चैप्टर देखें.)

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

स्केल सिग्नलिंग

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

• एक्सटेंसिबल मैसेजिंग और प्रज़ेंस प्रोटोकॉल (XMPP), जिसे मूल रूप से Jabber कहा जाता है. यह इंस्टैंट मैसेजिंग के लिए बनाया गया एक प्रोटोकॉल है. इसका इस्तेमाल सिग्नल भेजने के लिए किया जा सकता है. सर्वर के लिए, ejabberd और Openfire का इस्तेमाल किया जाता है. Strophe.js जैसे JavaScript क्लाइंट, दोतरफ़ा स्ट्रीमिंग को एमुलेट करने के लिए BOSH का इस्तेमाल करते हैं. हालांकि, कई वजहों से हो सकता है कि BOSH, WebSocket के मुकाबले उतना असरदार न हो और इन वजहों से, हो सकता है कि यह अच्छी तरह से स्केल न हो.) Jingle, XMPP एक्सटेंशन है. इसका इस्तेमाल करके, वॉइस और वीडियो कॉल की सुविधा चालू की जा सकती है. WebRTC प्रोजेक्ट, libjingle लाइब्रेरी के नेटवर्क और ट्रांसपोर्ट कॉम्पोनेंट का इस्तेमाल करता है. यह लाइब्रेरी, Jingle को C++ में लागू करती है.)

• ओपन सोर्स लाइब्रेरी, जैसे कि ZeroMQ (TokBox ने अपनी Rumour सेवा के लिए इसका इस्तेमाल किया है) और OpenMQ (NullMQ, वेब प्लैटफ़ॉर्म पर ZeroMQ के कॉन्सेप्ट लागू करता है. इसके लिए, यह WebSocket पर STOMP प्रोटोकॉल का इस्तेमाल करता है.)

• व्यावसायिक क्लाउड-मैसेजिंग प्लैटफ़ॉर्म, जो WebSocket का इस्तेमाल करते हैं. हालांकि, ये लंबी पोलिंग का इस्तेमाल कर सकते हैं. जैसे, Pusher, Kaazing, और PubNub. PubNub में WebRTC के लिए एपीआई भी है.

• व्यावसायिक WebRTC प्लैटफ़ॉर्म, जैसे कि vLine

(डेवलपर फ़िल लेगगटर की रीयल-टाइम वेब टेक्नोलॉजी गाइड में, मैसेज सेवाओं और लाइब्रेरी की पूरी सूची दी गई है.)

Node पर Socket.io की मदद से सिग्नलिंग सेवा बनाना

यहां एक आसान वेब ऐप्लिकेशन का कोड दिया गया है. यह Node पर Socket.io की मदद से बनाई गई सिग्नलिंग सेवा का इस्तेमाल करता है. Socket.io के डिज़ाइन की मदद से, मैसेज शेयर करने की सेवा को आसानी से बनाया जा सकता है. साथ ही, Socket.io खास तौर पर WebRTC सिग्नल के लिए सही है, क्योंकि इसमें रूम का कॉन्सेप्ट पहले से मौजूद है. इस उदाहरण को, प्रोडक्शन-ग्रेड सिग्नल सेवा के तौर पर स्केल करने के लिए डिज़ाइन नहीं किया गया है. हालांकि, यह कम उपयोगकर्ताओं के लिए समझने में आसान है.

Socket.io, फ़ॉलबैक के साथ WebSocket का इस्तेमाल करता है: AJAX लॉन्ग पोलिंग, AJAX मल्टीपार्ट स्ट्रीमिंग, फ़ॉरएवर इंफ़्रेम, और JSONP पोलिंग. इसे कई बैकएंड पर पोर्ट किया गया है. हालांकि, यह इस उदाहरण में इस्तेमाल किए गए Node वर्शन के लिए सबसे ज़्यादा जाना जाता है.

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

यहां क्लाइंट index.html है:

<!DOCTYPE html>
<html>
  <head>
    <title>WebRTC client</title>
  </head>
  <body>
    <script src='/socket.io/socket.io.js'></script>
    <script src='js/main.js'></script>
  </body>
</html>

यहां क्लाइंट में रेफ़र की गई JavaScript फ़ाइल main.js दी गई है:

const isInitiator;

room = prompt('Enter room name:');

const socket = io.connect();

if (room !== '') {
  console.log('Joining room ' + room);
  socket.emit('create or join', room);
}

socket.on('full', (room) => {
  console.log('Room ' + room + ' is full');
});

socket.on('empty', (room) => {
  isInitiator = true;
  console.log('Room ' + room + ' is empty');
});

socket.on('join', (room) => {
  console.log('Making request to join room ' + room);
  console.log('You are the initiator!');
});

socket.on('log', (array) => {
  console.log.apply(console, array);
});

यहां पूरा सर्वर ऐप्लिकेशन दिया गया है:

const static = require('node-static');
const http = require('http');
const file = new(static.Server)();
const app = http.createServer(function (req, res) {
  file.serve(req, res);
}).listen(2013);

const io = require('socket.io').listen(app);

io.sockets.on('connection', (socket) => {

  // Convenience function to log server messages to the client
  function log(){
    const array = ['>>> Message from server: '];
    for (const i = 0; i < arguments.length; i++) {
      array.push(arguments[i]);
    }
      socket.emit('log', array);
  }

  socket.on('message', (message) => {
    log('Got message:', message);
    // For a real app, would be room only (not broadcast)
    socket.broadcast.emit('message', message);
  });

  socket.on('create or join', (room) => {
    const numClients = io.sockets.clients(room).length;

    log('Room ' + room + ' has ' + numClients + ' client(s)');
    log('Request to create or join room ' + room);

    if (numClients === 0){
      socket.join(room);
      socket.emit('created', room);
    } else if (numClients === 1) {
      io.sockets.in(room).emit('join', room);
      socket.join(room);
      socket.emit('joined', room);
    } else { // max two clients
      socket.emit('full', room);
    }
    socket.emit('emit(): client ' + socket.id +
      ' joined room ' + room);
    socket.broadcast.emit('broadcast(): client ' + socket.id +
      ' joined room ' + room);

  });

});

इसके लिए, आपको node-static के बारे में जानने की ज़रूरत नहीं है. इस उदाहरण में इसका इस्तेमाल किया गया है.)

इस ऐप्लिकेशन को localhost पर चलाने के लिए, आपके पास Node, Socket.IO, और node-static इंस्टॉल होना चाहिए. Node को Node.js से डाउनलोड किया जा सकता है. इसे इंस्टॉल करना आसान और तेज़ है. Socket.IO और node-static इंस्टॉल करने के लिए, अपनी ऐप्लिकेशन डायरेक्ट्री में टर्मिनल से Node Package Manager चलाएं:

npm install socket.io
npm install node-static

सर्वर शुरू करने के लिए, अपनी ऐप्लिकेशन डायरेक्ट्री में टर्मिनल से यह कमांड चलाएं:

node server.js

अपने ब्राउज़र में, localhost:2013 खोलें. किसी भी ब्राउज़र में नया टैब या विंडो खोलें और localhost:2013 को फिर से खोलें. यह देखने के लिए कि क्या हो रहा है, कंसोल देखें. Chrome और Opera में, Ctrl+Shift+J (या Mac पर Command+Option+J) का इस्तेमाल करके, Google Chrome डेवलपर टूल से Console को ऐक्सेस किया जा सकता है.

सिग्नल भेजने के लिए कोई भी तरीका चुनें, आपके बैकएंड और क्लाइंट ऐप्लिकेशन को कम से कम इस उदाहरण जैसी सेवाएं देनी होंगी.

सिग्नलिंग से जुड़ी समस्याएं

• RTCPeerConnection तब तक उम्मीदवारों को इकट्ठा नहीं करेगा, जब तक setLocalDescription() को कॉल नहीं किया जाता. JSEP IETF ड्राफ़्ट में, यह ज़रूरी है.
• Trickle ICE का फ़ायदा लें. उम्मीदवारों के पहुंचते ही, addIceCandidate() को कॉल करें.

पहले से तैयार सिग्नलिंग सर्वर

अगर आपको खुद का सिग्नल सर्वर नहीं बनाना है, तो ऐसे कई WebRTC सिग्नल सर्वर उपलब्ध हैं जो पिछले उदाहरण की तरह Socket.IO का इस्तेमाल करते हैं. साथ ही, ये WebRTC क्लाइंट JavaScript लाइब्रेरी के साथ इंटिग्रेट होते हैं:

• webRTC.io, WebRTC के लिए बनी पहली एब्स्ट्रैक्शन लाइब्रेरी में से एक है.
• Signalmaster एक सिग्नलिंग सर्वर है. इसे SimpleWebRTC JavaScript क्लाइंट लाइब्रेरी के साथ इस्तेमाल करने के लिए बनाया गया है.

अगर आपको कोई कोड नहीं लिखना है, तो vLine, OpenTok, और Asterisk जैसी कंपनियों के पास, पूरी तरह से व्यावसायिक WebRTC प्लैटफ़ॉर्म उपलब्ध हैं.

जानकारी के लिए बता दें कि WebRTC के शुरुआती दिनों में, Ericsson ने Apache पर PHP का इस्तेमाल करके सिग्नलिंग सर्वर बनाया था. यह अब कुछ हद तक पुराना हो गया है, लेकिन अगर आपको कुछ ऐसा करना है, तो कोड को देखना ज़रूरी है.

सिग्नलिंग की सुरक्षा

"सुरक्षा, कुछ भी न होने का तरीका है."

सलमान रुश्दी

सभी WebRTC कॉम्पोनेंट के लिए, डेटा को एन्क्रिप्ट करना ज़रूरी है.

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

सिग्नल को सुरक्षित रखने के लिए, एचटीटीपीएस और WSS (उदाहरण के लिए, TLS) जैसे सुरक्षित प्रोटोकॉल का इस्तेमाल करना सबसे ज़रूरी है. इससे यह पक्का होता है कि मैसेज को एन्क्रिप्ट (सुरक्षित) किए बिना नहीं पढ़ा जा सकता. साथ ही, सिग्नल भेजने वाले मैसेज को इस तरह से ब्रॉडकास्ट न करें कि उसी सिग्नल सर्वर का इस्तेमाल करने वाले दूसरे कॉलर उसे ऐक्सेस कर सकें.

सिग्नल देने के बाद: NAT और फ़ायरवॉल से निपटने के लिए, आईसीई का इस्तेमाल करें

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

आसान शब्दों में कहें, तो हर WebRTC एंडपॉइंट का एक यूनीक पता होता है. सीधे तौर पर बातचीत करने के लिए, यह पता दूसरे पीयर के साथ शेयर किया जा सकता है.

असल में, ज़्यादातर डिवाइस NAT की एक या उससे ज़्यादा लेयर के पीछे होते हैं. कुछ डिवाइसों में एंटीवायरस सॉफ़्टवेयर होता है, जो कुछ पोर्ट और प्रोटोकॉल को ब्लॉक करता है. साथ ही, कई डिवाइसों को प्रॉक्सी और कॉर्पोरेट फ़ायरवॉल के पीछे रखा जाता है. फ़ायरवॉल और NAT, दोनों को एक ही डिवाइस से लागू किया जा सकता है. जैसे, होम वाई-फ़ाई राऊटर.

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

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

दूसरे शब्दों में, किसी बाहरी नेटवर्क का पता पाने के लिए STUN सर्वर का इस्तेमाल किया जाता है. साथ ही, डायरेक्ट (पीयर-टू-पीयर) कनेक्शन काम न करने पर, ट्रैफ़िक को रिले करने के लिए TURN सर्वर का इस्तेमाल किया जाता है.

हर TURN सर्वर, STUN के साथ काम करता है. TURN सर्वर, STUN सर्वर होता है. इसमें पहले से मौजूद रिले करने की सुविधा भी होती है. आईसीई, एनएटी सेटअप की जटिलताओं को भी हल करता है. असल में, NAT होल-पंचिंग के लिए, सिर्फ़ सार्वजनिक आईपी:पोर्ट पते की ज़रूरत नहीं होती.

STUN और/या TURN सर्वर के यूआरएल, iceServers कॉन्फ़िगरेशन ऑब्जेक्ट में WebRTC ऐप्लिकेशन से तय किए जाते हैं. हालांकि, ऐसा करना ज़रूरी नहीं है. यह RTCPeerConnection कन्स्ट्रक्टर का पहला आर्ग्युमेंट होता है. appr.tc के लिए, वैल्यू इस तरह दिखती है:

{
  'iceServers': [
    {
      'urls': 'stun:stun.l.google.com:19302'
    },
    {
      'urls': 'turn:192.158.29.39:3478?transport=udp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    },
    {
      'urls': 'turn:192.158.29.39:3478?transport=tcp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    }
  ]
}

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

STUN

NATs, किसी डिवाइस को निजी लोकल नेटवर्क में इस्तेमाल करने के लिए आईपी पता देते हैं. हालांकि, इस पते का इस्तेमाल बाहरी नेटवर्क में नहीं किया जा सकता. सार्वजनिक पते के बिना, WebRTC पीयर के बीच बातचीत करने का कोई तरीका नहीं है. इस समस्या को हल करने के लिए, WebRTC STUN का इस्तेमाल करता है.

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

STUN सर्वर को ज़्यादा काम करने या ज़्यादा जानकारी याद रखने की ज़रूरत नहीं होती. इसलिए, कम स्पेसिफ़िकेशन वाले STUN सर्वर, ज़्यादा अनुरोधों को हैंडल कर सकते हैं.

Webrtcstats.com के मुताबिक, ज़्यादातर WebRTC कॉल, STUN का इस्तेमाल करके कनेक्ट होते हैं. इनमें से 86% कॉल सफल होते हैं. हालांकि, फ़ायरवॉल और जटिल एनएटी कॉन्फ़िगरेशन के पीछे मौजूद पीयर के बीच होने वाले कॉल के लिए, यह संख्या कम हो सकती है.

TURN

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

हम फिर से बताना चाहते हैं कि TURN का इस्तेमाल, पीयर के बीच ऑडियो, वीडियो, और डेटा स्ट्रीमिंग को रिले करने के लिए किया जाता है, न कि सिग्नल डेटा के लिए!

TURN सर्वर के पास सार्वजनिक पते होते हैं, ताकि पीयर उनसे संपर्क कर सकें. भले ही, पीयर फ़ायरवॉल या प्रॉक्सी के पीछे हों. TURN सर्वर का काम, स्ट्रीम को रिले करना होता है. हालांकि, STUN सर्वर के उलट, ये बहुत ज़्यादा बैंडविड्थ का इस्तेमाल करते हैं. दूसरे शब्दों में, TURN सर्वर को बेहतर बनाने की ज़रूरत है.

इस डायग्राम में, TURN को इस्तेमाल करने का तरीका दिखाया गया है. प्योर STUN काम नहीं कर रहा था, इसलिए हर पीयर, TURN सर्वर का इस्तेमाल करता है.

STUN और TURN सर्वर को डिप्लॉय करना

जांच के लिए, Google एक सार्वजनिक STUN सर्वर, stun.l.google.com:19302 चलाता है. इसका इस्तेमाल appr.tc करता है. प्रोडक्शन STUN/TURN सेवा के लिए, rfc5766-turn-server का इस्तेमाल करें. STUN और TURN सर्वर का सोर्स कोड GitHub पर उपलब्ध है. यहां आपको सर्वर इंस्टॉल करने के बारे में जानकारी देने वाले कई सोर्स के लिंक भी मिल सकते हैं. Amazon Web Services के लिए VM इमेज भी उपलब्ध है.

restund एक अन्य TURN सर्वर है. यह सोर्स कोड के तौर पर और AWS के लिए भी उपलब्ध है. Compute Engine पर रिफ़ंड सेट अप करने का तरीका यहां बताया गया है.

1. ज़रूरत के हिसाब से, tcp=443, udp/tcp=3478 के लिए फ़ायरवॉल खोलें.
2. चार इंस्टेंस बनाएं, हर सार्वजनिक आईपी के लिए एक. ये इंस्टेंस, स्टैंडर्ड Ubuntu 12.06 इमेज पर आधारित होने चाहिए.
3. लोकल फ़ायरवॉल कॉन्फ़िगरेशन सेट अप करें (किसी भी डिवाइस से किसी भी डिवाइस को अनुमति दें).
4. टूल इंस्टॉल करें: shell sudo apt-get install make sudo apt-get install gcc
5. creytiv.com/re.html से libre इंस्टॉल करें.
6. creytiv.com/restund.html से रिफ़ंड फ़ेच करें और उसे अनपैक करें./
7. wget hancke.name/restund-auth.patch और patch -p1 < restund-auth.patch के साथ लागू करें.
8. libre और restund के लिए, make, sudo make install चलाएं.
9. restund.conf को अपनी ज़रूरतों के हिसाब से बदलें (आईपी पते बदलें और पक्का करें कि उसमें वही शेयर किया गया सीक्रेट पासवर्ड हो) और /etc में कॉपी करें.
10. restund/etc/restund को /etc/init.d/ में कॉपी करें.
11. रिफ़ंड कॉन्फ़िगर करना:
    1. LD_LIBRARY_PATH सेट करें.
    2. restund.conf को /etc/restund.conf में कॉपी करें.
    3. सही 10 का इस्तेमाल करने के लिए, restund.conf सेट करें. आईपी पता.
12. रिफ़ंड की प्रोसेस शुरू करना
13. रिमोट मशीन से स्टंड क्लाइंट का इस्तेमाल करके टेस्ट करें: ./client IP:port

एक-से-एक बातचीत के अलावा: मल्टीपार्टी WebRTC

TURN सेवाओं को ऐक्सेस करने के लिए REST API के लिए, जस्टिन उबर्टी के सुझाए गए IETF स्टैंडर्ड पर भी एक नज़र डालें.

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

WebRTC ऐप्लिकेशन, कई RTCPeerConnections का इस्तेमाल कर सकता है, ताकि हर एंडपॉइंट, मेश कॉन्फ़िगरेशन में हर दूसरे एंडपॉइंट से कनेक्ट हो सके. talky.io जैसे ऐप्लिकेशन इसी तरीके का इस्तेमाल करते हैं. यह तरीका, कुछ ही पीयर के लिए काफ़ी अच्छा काम करता है. इसके अलावा, प्रोसेसिंग और बैंडविड्थ की खपत बहुत ज़्यादा हो जाती है. खास तौर पर, मोबाइल क्लाइंट के लिए.

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

Chrome 31 और Opera 18 के बाद, एक RTCPeerConnection के MediaStream का इस्तेमाल, दूसरे के इनपुट के तौर पर किया जा सकता है. इससे ज़्यादा सुविधाजनक आर्किटेक्चर का इस्तेमाल किया जा सकता है, क्योंकि यह वेब ऐप्लिकेशन को कॉल-रूटिंग को मैनेज करने में मदद करता है. इसके लिए, यह यह चुनता है कि किस दूसरे पीयर से कनेक्ट करना है. इसे काम करते हुए देखने के लिए, WebRTC के सैंपल, पीयर कनेक्शन रिले और WebRTC के सैंपल, एक से ज़्यादा पीयर कनेक्शन देखें.

मल्टीपॉइंट कंट्रोल यूनिट

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

आपके पास पूरा MCU हार्डवेयर पैकेज खरीदने या खुद का हार्डवेयर बनाने का विकल्प है.

का पिछला हिस्सा

ओपन सोर्स वाले कई MCU सॉफ़्टवेयर उपलब्ध हैं. उदाहरण के लिए, Licode (पहले इसे Lynckia कहा जाता था) WebRTC के लिए ओपन सोर्स एमसीयू बनाता है. OpenTok में Mantis है.

ब्राउज़र के अलावा: VoIP, टेलीफ़ोन, और मैसेजिंग

WebRTC के स्टैंडर्ड होने की वजह से, ब्राउज़र में चल रहे WebRTC ऐप्लिकेशन और किसी दूसरे कम्यूनिकेशन प्लैटफ़ॉर्म पर चल रहे डिवाइस या प्लैटफ़ॉर्म के बीच कम्यूनिकेशन सेट अप किया जा सकता है. जैसे, टेलीफ़ोन या वीडियो कॉन्फ़्रेंसिंग सिस्टम.

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

पब्लिक स्विच्ड टेलीफ़ोन नेटवर्क (पीएसटीएन), सभी "सामान्य" एनालॉग टेलीफ़ोन का सर्किट-स्विच किया गया नेटवर्क है. WebRTC वेब ऐप्लिकेशन और टेलीफ़ोन के बीच कॉल करने के लिए, ट्रैफ़िक को पीएसटीएन गेटवे से जाना होगा. इसी तरह, WebRTC वेब ऐप्लिकेशन को Jingle एंडपॉइंट, जैसे कि आईएम क्लाइंट के साथ बातचीत करने के लिए, किसी मध्यस्थ XMPP सर्वर की ज़रूरत होती है. Google ने Jingle को XMPP के एक्सटेंशन के तौर पर डेवलप किया था, ताकि मैसेजिंग सेवाओं के लिए वॉइस और वीडियो की सुविधा चालू की जा सके. फ़िलहाल, WebRTC को C++ libjingle लाइब्रेरी के साथ लागू किया जा रहा है. यह लाइब्रेरी, Jingle का एक वर्शन है, जिसे शुरुआत में Talk के लिए डेवलप किया गया था.

कई ऐप्लिकेशन, लाइब्रेरी, और प्लैटफ़ॉर्म, बाहरी दुनिया के साथ बातचीत करने के लिए WebRTC की सुविधा का इस्तेमाल करते हैं:

• sipML5: ओपन सोर्स JavaScript SIP क्लाइंट
• jsSIP: JavaScript SIP लाइब्रेरी
• Phono: प्लग इन के तौर पर बनाया गया, ओपन सोर्स JavaScript फ़ोन एपीआई
• Zingaya: एक ऐसा फ़ोन विजेट जिसे एम्बेड किया जा सकता है
• Twilio: वॉइस और मैसेज सेवा
• Uberconference: कॉन्फ़्रेंसिंग

sipML5 डेवलपर ने webrtc2sip गेटवे भी बनाया है. Tethr और Tropo ने OpenBTS सेल का इस्तेमाल करके, आपदा के दौरान कम्यूनिकेशन के लिए एक फ़्रेमवर्क "ब्रीफ़केस में" दिखाया है. इससे, WebRTC की मदद से फ़ीचर फ़ोन और कंप्यूटर के बीच कम्यूनिकेशन की सुविधा मिलती है. यह टेलीफ़ोन सेवा है, जिसमें मोबाइल और इंटरनेट सेवा देने वाली कंपनी की ज़रूरत नहीं होती!

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

WebRTC कोडलैब में, Node पर चलने वाली Socket.io सिग्नलिंग सेवा का इस्तेमाल करके, वीडियो और टेक्स्ट चैट ऐप्लिकेशन बनाने का तरीका बताया गया है.

Google I/O 2013 में WebRTC के बारे में दिया गया प्रज़ेंटेशन. इसमें WebRTC के टेक्नोलॉजी लीड, जस्टिन उबर्टी ने हिस्सा लिया था

क्रिस विल्सन का SFHTML5 प्रज़ेंटेशन - WebRTC ऐप्लिकेशन के बारे में जानकारी

350 पेजों की WebRTC: एपीआई और HTML5 रीयल-टाइम वेब के RTCWEB प्रोटोकॉल वाली किताब में, डेटा और सिग्नल पाथवे के बारे में काफ़ी जानकारी दी गई है. साथ ही, इसमें नेटवर्क टोपोलॉजी के कई ज़्यादा जानकारी वाले डायग्राम शामिल हैं.

WebRTC और सिग्नलिंग: दो सालों में हमें क्या सीखने को मिला - TokBox की ब्लॉग पोस्ट, जिसमें बताया गया है कि सिग्नलिंग को स्पेसिफ़िकेशन से बाहर रखना क्यों एक अच्छा फ़ैसला था

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

इल्या ग्रिगोरिक की बेहतर परफ़ॉर्मेंस वाली ब्राउज़र नेटवर्किंग में, WebRTC चैप्टर में WebRTC के आर्किटेक्चर, इस्तेमाल के उदाहरणों, और परफ़ॉर्मेंस के बारे में पूरी जानकारी दी गई है.