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

Sam Dutton

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

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

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

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

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

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

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

JSEP आर्किटेक्चर का डायग्राम
जेएसईपी का आर्किटेक्चर

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

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
…

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

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

सिग्नल करने के लिए कोड 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 देखें. साथ ही, एक पेज पर वीडियो चैट के उदाहरण के लिए, कंसोल लॉग देखें. अगर आपको और जानकारी चाहिए, तो WebRTC सिग्नल और आंकड़ों का पूरा डंप डाउनलोड करें. इसके लिए, Google Chrome के about://webrtc-internals पेज या Opera में Opera://webrtc-internals पेज पर जाएं.

मिलते-जुलते ऐप्लिकेशन को खोजने की सुविधा

यह पूछने का एक बढ़िया तरीका है, "मैं बात करने के लिए किसी को कैसे ढूंढूं?"

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

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

सिग्नल सेवा कैसे तैयार की जा सकती है?

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

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

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

सर्वर से क्लाइंट को संदेश पुश करें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इस उदाहरण में कोई 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);

  });

});

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

इस ऐप्लिकेशन को localhost पर चलाने के लिए, आपको Node, Socket.IO, और node-static इंस्टॉल करना होगा. नोड को Node.js से डाउनलोड किया जा सकता है (इसे इंस्टॉल करना आसान और तेज़ है). Socket.IO और नोड-स्टैटिक इंस्टॉल करने के लिए, अपनी ऐप्लिकेशन डायरेक्ट्री के टर्मिनल से 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 डेवलपर टूल से कंसोल को ऐक्सेस किया जा सकता है.

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

वॉकचा का सिग्नल देना

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

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

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

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

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

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

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

"सुरक्षा का मतलब ही है, कुछ भी न करने देना."

सलमान रशदी

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

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

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

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

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

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

आसान पीयर टू पीयर कनेक्शन
NAT और फ़ायरवॉल से सुरक्षित दुनिया

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

NAT और फ़ायरवॉल से सुरक्षित
असल दुनिया

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

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

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

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

STUN और/या टर्न सर्वर के यूआरएल, WebRTC ऐप्लिकेशन की मदद से iceServers कॉन्फ़िगरेशन ऑब्जेक्ट में तय किए जाते हैं. यह 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, पीयर के बीच सबसे अच्छा पाथ बनाने के लिए, ICE फ़्रेमवर्क का इस्तेमाल करता है. साथ ही, यह STUN और TURN सर्वर के साथ ज़रूरत के मुताबिक काम करता है.

सनसनीखेज़

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

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

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

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

STUN सर्वर का इस्तेमाल करके पीयर-टू-पीयर कनेक्शन
सार्वजनिक आईपी:पोर्ट पते पाने के लिए, STUN सर्वर का इस्तेमाल करना

चालू करें

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

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

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

STUN सर्वर का इस्तेमाल करके पीयर-टू-पीयर कनेक्शन
द फ़ुल मॉन्टी: एसटीयूएन, टर्न, और सिग्नलिंग

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

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

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

CANNOT TRANSLATE यहां Compute Engine पर रेस्टोरेंट सेट अप करने के निर्देश दिए गए हैं.

  1. tcp=443, udp/tcp=3478 के लिए, ज़रूरत के हिसाब से फ़ायरवॉल खोलें.
  2. चार इंस्टेंस बनाएं, हर सार्वजनिक आईपी के लिए एक, Standard Ubuntu 12.06 इमेज.
  3. लोकल फ़ायरवॉल कॉन्फ़िगरेशन सेट अप करें (किसी भी तरह के कॉन्फ़िगरेशन को अनुमति दें).
  4. टूल इंस्टॉल करें: shell sudo apt-get install make sudo apt-get install gcc
  5. creytiv.com/re.html से ली गई लाइब्रेरी इंस्टॉल करें.
  6. creytiv.com/restund.html से रेस्टोरेंट को फ़ेच करें और अनपैक करें./
  7. wget hancke.name/restund-auth.patch और patch -p1 < restund-auth.patch से आवेदन करें.
  8. लिबर और रेस्टोरेंट के लिए 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

सेवाओं को चालू करने के लिए REST API के लिए, जस्टिन Uberti के प्रस्तावित आईईटीएफ़ मानक पर एक नज़र भी डाली जा सकती है.

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

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

मेश: छोटा N-वे कॉल
फ़ुल मेश टोपोलॉजी: सभी लोग, सभी से जुड़े होते हैं

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

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

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

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

एक पूरा MCU हार्डवेयर पैकेज खरीदा जा सकता है या अपना खुद का हार्डवेयर बनाया जा सकता है.

Cisco MCU5300 के पीछे का व्यू
Cisco MCU का पिछला हिस्सा

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

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

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

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

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

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

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

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

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

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

WebRTC के तकनीकी लीड, जस्टिन Uberti के साथ 2013 से Google I/O WebRTC प्रज़ेंटेशन

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

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

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

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

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