WebRTC অ্যাপ ব্যাকএন্ড পরিষেবা তৈরি করা

Sam Dutton

প্রকাশিত: ৪ নভেম্বর, ২০১৩

WebRTC পিয়ার-টু-পিয়ার কমিউনিকেশন চালু করে। এটির জন্য সার্ভার প্রয়োজন যাতে ক্লায়েন্টরা মেটাডেটা আদান-প্রদান করতে পারে এবং সিগন্যালিং নামক একটি প্রসেসের মাধ্যমে কমিউনিকেশন সমন্বয় করতে পারে। এছাড়াও, সার্ভার ক্লায়েন্টদের নেটওয়ার্ক অ্যাড্রেস ট্রান্সলেটর (NAT) এবং ফায়ারওয়াল ম্যানেজ করতে সাহায্য করে।

এখানে, আপনি শিখবেন কীভাবে একটি সিগন্যালিং পরিষেবা তৈরি করতে হয় এবং STUN এবং TURN সার্ভারের সাথে বাস্তব-বিশ্বের সংযোগের অদ্ভুততা মোকাবেলা করতে হয়। এছাড়াও, আপনি বুঝতে পারবেন যে কীভাবে WebRTC অ্যাপ মাল্টি-পার্টি কল ম্যানেজ করতে পারে এবং VoIP ও PSTN (টেলিফোন নামেও পরিচিত) পরিষেবার সাথে ইন্টার‍্যাক্ট করতে পারে।

সিগন্যালিং কী?

সিগন্যালিং হল যোগাযোগের সমন্বয় সাধনের প্রক্রিয়া। WebRTC অ্যাপের মাধ্যমে কল সেট-আপ করতে, এর ক্লায়েন্টদের নিম্নলিখিত তথ্য এক্সচেঞ্জ করতে হবে:

  • যোগাযোগ শুরু বা বন্ধ করার জন্য সেশন-কন্ট্রোল মেসেজ ব্যবহার করা হয়
  • সমস্যার মেসেজ
  • মিডিয়া মেটাডেটা, যেমন কোডেক, কোডেক সেটিংস, ব্যান্ডউইথ ও মিডিয়ার ধরন
  • নিরাপদ কানেকশন তৈরি করতে ব্যবহৃত মূল ডেটা
  • নেটওয়ার্ক ডেটা, যেমন হোস্টের IP অ্যাড্রেস এবং পোর্ট যা বাইরের দুনিয়া দেখতে পায়

এই সিগন্যালিং প্রসেসের জন্য ক্লায়েন্টদের মেসেজ আদান-প্রদান করার একটি উপায় প্রয়োজন। WebRTC API-এর মাধ্যমে সেই মেকানিজম প্রয়োগ করা হয়নি। পরিবর্তে, আপনাকে এটি নিজে তৈরি করতে হবে।

WebRTC-এর মাধ্যমে সিগন্যালিং কেন সংজ্ঞায়িত করা হয় না?

অপ্রয়োজনীয়তা এড়াতে এবং প্রতিষ্ঠিত প্রযুক্তির সাথে সামঞ্জস্যতা সর্বাধিক করতে, সিগন্যালিং পদ্ধতি এবং প্রোটোকল WebRTC স্ট্যান্ডার্ড দ্বারা নির্দিষ্ট করা হয় না। এই পদ্ধতিটি জাভাস্ক্রিপ্ট সেশন এস্টাব্লিশমেন্ট প্রোটোকল (JSEP) দ্বারা ব্যাখ্যা করা হয়েছে:

JSEP-এর আর্কিটেকচার ব্রাউজারকে স্টেট সেভ করা থেকে বিরত রাখে, অর্থাৎ, সিগন্যালিং স্টেট মেশিন হিসেবে কাজ করে। এটি সমস্যাজনক হতে পারে, যেমন, প্রতিবার পৃষ্ঠা রিলোড করার সময় সিগন্যালিং ডেটা হারিয়ে যায়। পরিবর্তে, সিগন্যালিং স্টেট সার্ভারে সেভ করা যেতে পারে।

JSEP আর্কিটেকচার ডায়াগ্রাম

JSEP-এর জন্য পিয়ারের মধ্যে অফার ও উত্তর, মিডিয়া মেটাডেটা আদান-প্রদান করতে হয়। অফার ও উত্তর সেশন ডেসক্রিপশন প্রোটোকল (SDP) ফর্ম্যাটে পাঠানো হয়, যা দেখতে এইরকম হয়:

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-এর জটিল পরিভাষার আসল অর্থ কী তা জানতে চান? ইন্টারনেট ইঞ্জিনিয়ারিং টাস্ক ফোর্স (IETF) উদাহরণ দেখুন।

মনে রাখবেন যে WebRTC এমনভাবে ডিজাইন করা হয়েছে যাতে SDP টেক্সটে ভ্যালু এডিট করে লোকাল বা রিমোট বিবরণ হিসেবে সেট করার আগে অফার বা উত্তর টুইক করা যায়। যেমন, appr.tc-তে preferAudioCodec() ফাংশনটি ডিফল্ট কোডেক ও বিটরেট সেট করতে ব্যবহার করা যেতে পারে। JavaScript-এর মাধ্যমে SDP ম্যানিপুলেট করা কিছুটা কষ্টকর এবং WebRTC-এর পরবর্তী ভার্সনে এর পরিবর্তে JSON ব্যবহার করা উচিত কিনা তা নিয়ে আলোচনা চলছে, তবে SDP-এর সাথে লেগে থাকার কিছু সুবিধা রয়েছে।

RTCPeerConnection API এবং সিগন্যালিং: অফার, উত্তর এবং প্রার্থী

RTCPeerConnection হল API যা WebRTC অ্যাপ ব্যবহার করে পিয়ারের মধ্যে কানেকশন তৈরি করে এবং অডিও ও ভিডিও কমিউনিকেট করে।

এই প্রসেস শুরু করতে, RTCPeerConnection-এর দুটি টাস্ক আছে:

  • রেজোলিউশন ও কোডেক ক্ষমতার মতো স্থানীয় মিডিয়ার অবস্থা নিশ্চিত করা। এটি হল অফার-ও-উত্তর মেকানিজমের জন্য ব্যবহৃত মেটাডেটা।
  • অ্যাপের হোস্টের জন্য সম্ভাব্য নেটওয়ার্ক অ্যাড্রেস পান, যা ক্যান্ডিডেট নামে পরিচিত।

এই লোকাল ডেটা নিশ্চিত করা হয়ে গেলে, এটি অবশ্যই রিমোট পিয়ারের সাথে সিগন্যালিং মেকানিজমের মাধ্যমে এক্সচেঞ্জ করতে হবে।

ধরুন, অ্যালিস ইভকে কল করার চেষ্টা করছে। এখানে সম্পূর্ণ উত্তর দেওয়ার মেকানিজম বিস্তারিতভাবে দেওয়া হল:

  1. অ্যালিস একটি RTCPeerConnection অবজেক্ট তৈরি করে।
  2. অমিতা RTCPeerConnection createOffer() পদ্ধতি ব্যবহার করে একটি অফার (একটি SDP সেশন বিবরণ) তৈরি করেন।
  3. অ্যালিস তার অফার নিয়ে setLocalDescription()-কে কল করে।
  4. অ্যালিস অফারটি স্ট্রিংয়ে পরিণত করে এবং সিগন্যালিং মেকানিজম ব্যবহার করে ইভকে পাঠায়।
  5. ইভ, অ্যালিসের অফার নিয়ে setRemoteDescription()-কে কল করে, যাতে তার RTCPeerConnection, অ্যালিসের সেট-আপ সম্পর্কে জানতে পারে।
  6. ইভ createAnswer()-কে কল করে এবং এর জন্য সফল কলব্যাক একটি লোকাল সেশন বিবরণ পাস করে - ইভের উত্তর।
  7. ইভ setLocalDescription()-এ কল করে তার উত্তর স্থানীয় বিবরণ হিসেবে সেট করে।
  8. তারপর, ইভ সিগন্যালিং মেকানিজম ব্যবহার করে অ্যালিসকে তার স্ট্রিং করা উত্তর পাঠায়।
  9. setRemoteDescription() ব্যবহার করে, রিমোট সেশনের বিবরণ হিসেবে ইভের উত্তর অ্যালিস সেট করে।

এছাড়াও, Alice ও Eve-কে নেটওয়ার্ক সংক্রান্ত তথ্য এক্সচেঞ্জ করতে হবে। "প্রার্থী খোঁজা" বাক্যাংশটি 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-এ যান এবং সিঙ্গেল-পেজ ভিডিও চ্যাটের উদাহরণের জন্য কনসোল লগ দেখুন। আপনি Google Chrome-এর about://webrtc-internals পৃষ্ঠা বা Opera-এর opera://webrtc-internals পৃষ্ঠা থেকে WebRTC সিগন্যালিং ও পরিসংখ্যানের সম্পূর্ণ ডাম্প ডাউনলোড করতে পারবেন।

পিয়ার ডিসকভারি

এটি হল, "আমি কথা বলার জন্য কাউকে কীভাবে খুঁজে পাব?" প্রশ্নটি জিজ্ঞাসা করার একটি অভিনব উপায়।

টেলিফোন কলের জন্য আপনার কাছে টেলিফোন নম্বর ও ডিরেক্টরি আছে। অনলাইন ভিডিও চ্যাট ও মেসেজিংয়ের জন্য, আপনার পরিচয় ও উপস্থিতি ম্যানেজমেন্ট সিস্টেম এবং ব্যবহারকারীদের সেশন শুরু করার উপায় প্রয়োজন। WebRTC অ্যাপের ক্ষেত্রে ক্লায়েন্টদের একে অপরকে সিগন্যাল দেওয়ার প্রয়োজন হয় যে তারা কল শুরু করতে বা কলে যোগ দিতে চায়।

WebRTC-এর মাধ্যমে পিয়ার ডিসকভারি মেকানিজম সংজ্ঞায়িত করা হয় না এবং আপনি এখানে বিকল্পে যান না। এই প্রসেসটি ইমেল বা মেসেজের মাধ্যমে URL পাঠানোর মতো ছোট হতে পারে। Talky, tawk.to এবং Browser Meeting-এর মতো ভিডিও চ্যাট অ্যাপের ক্ষেত্রে, আপনি কাস্টম লিঙ্ক শেয়ার করে লোকজনকে কলে আমন্ত্রণ জানান। ডেভেলপার ক্রিস বল একটি আকর্ষণীয় serverless-webrtc এক্সপেরিমেন্ট তৈরি করেছেন যা WebRTC কল অংশগ্রহণকারীদের IM, ইমেল বা হোমিং পিজিয়নের মতো যেকোনও মেসেজিং পরিষেবার মাধ্যমে মেটাডেটা এক্সচেঞ্জ করতে দেয়।

আপনি কীভাবে সিগন্যালিং পরিষেবা তৈরি করতে পারেন?

আবার বলছি, সিগন্যালিং প্রোটোকল ও মেকানিজম WebRTC স্ট্যান্ডার্ডের মাধ্যমে সংজ্ঞায়িত করা হয় না। আপনি যে বিকল্পই বেছে নিন না কেন, ক্লায়েন্টদের মধ্যে সিগন্যালিং মেসেজ ও অ্যাপ ডেটা আদান-প্রদান করার জন্য আপনার একটি ইন্টারমিডিয়ারি সার্ভার প্রয়োজন হবে। দুঃখের বিষয়, কোনও ওয়েব অ্যাপ ইন্টারনেটে চিৎকার করে বলতে পারে না, "আমার বন্ধুর সাথে আমাকে কানেক্ট করো!"

তবে, সিগন্যালিং মেসেজ ছোট হয় এবং বেশিরভাগ ক্ষেত্রে কলের শুরুতে আদানপ্রদান করা হয়। ভিডিও চ্যাট সেশনের জন্য appr.tc-এর সাথে পরীক্ষা করার সময়, সিগন্যালিং পরিষেবা মোট প্রায় ৩০-৪৫টি মেসেজ ম্যানেজ করেছে এবং সব মেসেজের মোট সাইজ ছিল প্রায় ১০ কেবি।

ব্যান্ডউইথের ক্ষেত্রে তুলনামূলকভাবে কম চাহিদা থাকার পাশাপাশি, WebRTC সিগন্যালিং পরিষেবাগুলি বেশি প্রসেসিং বা মেমরি ব্যবহার করে না কারণ তাদের শুধুমাত্র মেসেজ রিলে করতে হয় এবং সেশন স্টেট ডেটার একটি ছোট পরিমাণ ধরে রাখতে হয়, যেমন কোন ক্লায়েন্ট কানেক্ট করা আছে।

সার্ভার থেকে ক্লায়েন্টে মেসেজ পুশ করুন

Browser Support

  • Chrome: 6.
  • Edge: 79.
  • Firefox: 6.
  • Safari: 5.

Source

সিগন্যালিংয়ের জন্য মেসেজ পরিষেবা দ্বিমুখী হতে হবে: ক্লায়েন্ট-টু-সার্ভার এবং সার্ভার-টু-ক্লায়েন্ট। দ্বিমুখী যোগাযোগ HTTP ক্লায়েন্ট/সার্ভার অনুরোধ/উত্তর মডেলের বিরুদ্ধে যায়, তবে লং পোলিং-এর মতো বিভিন্ন হ্যাক অনেক বছর ধরে ডেভেলপ করা হয়েছে যাতে ওয়েব সার্ভারে চলা কোনও পরিষেবা থেকে ব্রাউজারে চলা কোনও ওয়েব অ্যাপে ডেটা পুশ করা যায়।

EventSource API সার্ভার-প্রেরিত ইভেন্ট, HTTP-এর মাধ্যমে ওয়েব সার্ভার থেকে ব্রাউজার ক্লায়েন্টে পাঠানো ডেটা চালু করে। EventSource ওয়ান-ওয়ে মেসেজিংয়ের জন্য ডিজাইন করা হয়েছে, তবে এটি XHR-এর সাথে ব্যবহার করে সিগন্যালিং মেসেজ আদান-প্রদান করার জন্য পরিষেবা তৈরি করা যেতে পারে। একটি সিগন্যালিং পরিষেবা কলারের থেকে একটি মেসেজ পাস করে, যা XHR অনুরোধের মাধ্যমে ডেলিভার করা হয়, এটি EventSource-এর মাধ্যমে কলি-তে পুশ করে।

Browser Support

  • Chrome: 5.
  • Edge: 12.
  • Firefox: 11.
  • Safari: 5.

Source

WebSocket সম্পূর্ণ ডুপ্লেক্স ক্লায়েন্ট-সার্ভার কমিউনিকেশনের জন্য ডিজাইন করা হয়েছে, যার অর্থ হল একই সময়ে মেসেজ দুই দিকেই যেতে পারে। শুধুমাত্র WebSocket বা সার্ভার-প্রেরিত ইভেন্ট (EventSource) দিয়ে তৈরি সিগন্যালিং পরিষেবার একটি সুবিধা হল, এইসব API-এর ব্যাকএন্ড PHP, Python ও Ruby-র মতো ভাষার জন্য বেশিরভাগ ওয়েব-হোস্টিং প্যাকেজে সাধারণ বিভিন্ন ওয়েব ফ্রেমওয়ার্কে প্রয়োগ করা যেতে পারে।

WebRTC কাজ করে এমন সব ব্রাউজারে WebSocket-ও কাজ করে। মেসেজ যাতে এনক্রিপ্ট না করে ইন্টারসেপ্ট করা না যায় এবং প্রক্সি ট্রাভার্সাল সংক্রান্ত সমস্যা কমানো যায়, তার জন্য সব কানেকশনে TLS ব্যবহার করা উচিত। WebSocket এবং প্রক্সি ট্রাভার্সাল সম্পর্কে আরও তথ্যের জন্য, Ilya Grigorik-এর হাই পারফরম্যান্স ব্রাউজার নেটওয়ার্কিং-এ WebRTC অধ্যায় পড়ুন।

আপনি Ajax-এর মাধ্যমে বারবার মেসেজিং সার্ভার পোল করার জন্য WebRTC ক্লায়েন্টদের ব্যবহার করে সিগন্যালিং ম্যানেজ করতে পারেন, তবে এর ফলে অনেক অপ্রয়োজনীয় নেটওয়ার্ক রিকোয়েস্ট তৈরি হয়, যা বিশেষ করে মোবাইল ডিভাইসের ক্ষেত্রে সমস্যা সৃষ্টি করে। সেশন শুরু হয়ে যাওয়ার পরেও, অন্যান্য পিয়ারের মাধ্যমে সেশন বন্ধ করা বা পরিবর্তন করার ক্ষেত্রে সিগন্যালিং মেসেজের জন্য পিয়ারদের পোল করতে হবে। WebRTC Book অ্যাপের উদাহরণে পোলিং ফ্রিকোয়েন্সির জন্য কিছু অপ্টিমাইজেশন সহ এই বিকল্পটি ব্যবহার করা হয়।

স্কেল সিগন্যালিং

যদিও সিগন্যালিং পরিষেবা ক্লায়েন্ট প্রতি তুলনামূলকভাবে কম ব্যান্ডউইথ ও সিপিইউ ব্যবহার করে, জনপ্রিয় অ্যাপের সিগন্যালিং সার্ভারকে বিভিন্ন লোকেশন থেকে আসা অনেক মেসেজ একই সাথে ম্যানেজ করতে হতে পারে। যেসব WebRTC অ্যাপে প্রচুর ট্রাফিক আসে, সেগুলির সিগন্যালিং সার্ভারকে যথেষ্ট লোড সামলানোর ক্ষমতা থাকতে হবে। এখানে বিস্তারিতভাবে বলা হয়নি, তবে হাই-ভলিউম, হাই-পারফর্ম্যান্স মেসেজিংয়ের জন্য অনেক বিকল্প আছে, যার মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত:

  • এক্সটেনসিবল মেসেজিং অ্যান্ড প্রেজেন্স প্রোটোকল (XMPP) হল ইনস্ট্যান্ট মেসেজিংয়ের জন্য তৈরি করা একটি প্রোটোকল যা সিগন্যালিংয়ের জন্য ব্যবহার করা যেতে পারে। সার্ভার ইমপ্লিমেন্টেশনের মধ্যে ejabberd এবং Openfire অন্তর্ভুক্ত। Strophe.js-এর মতো জাভাস্ক্রিপ্ট ক্লায়েন্ট, দ্বিমুখী স্ট্রিমিং এমুলেট করতে BOSH ব্যবহার করে, কিন্তু WebSocket-এর তুলনায় BOSH অদক্ষ হতে পারে এবং স্কেল করার ক্ষেত্রে খারাপ পারফর্ম করতে পারে।

  • ওপেন সোর্স লাইব্রেরি, যেমন ZeroMQ (TokBox তাদের Rumour পরিষেবার জন্য ব্যবহার করে) এবং OpenMQ (NullMQ WebSocket-এর মাধ্যমে STOMP প্রোটোকল ব্যবহার করে ওয়েব প্ল্যাটফর্মে ZeroMQ কনসেপ্ট প্রয়োগ করে।)

  • WebSocket ব্যবহার করে এমন বাণিজ্যিক ক্লাউড-মেসেজিং প্ল্যাটফর্ম (যদিও তারা লং পোলিংয়ে ফিরে যেতে পারে), যেমন Pusher এবং Kaazing।

  • কমার্শিয়াল WebRTC প্ল্যাটফর্ম, যেমন vLine

Node-এ Socket.io-এর সাহায্যে সিগন্যালিং পরিষেবা তৈরি করা

নিচে একটি ওয়েব অ্যাপের কোড দেওয়া হল যা Node-এ Socket.io দিয়ে তৈরি সিগন্যালিং পরিষেবা ব্যবহার করে। Socket.io-এর ডিজাইন মেসেজ এক্সচেঞ্জ করার জন্য পরিষেবা তৈরি করা সহজ করে তোলে এবং Socket.io বিশেষ করে WebRTC সিগন্যালিংয়ের জন্য উপযুক্ত কারণ এতে রুমের বিল্ট-ইন কনসেপ্ট রয়েছে। এই উদাহরণটি প্রোডাকশন ব্যবহারের পরিবর্তে তুলনামূলকভাবে কম সংখ্যক ব্যবহারকারীর জন্য ডিজাইন করা হয়েছে।

Socket.io, ফলব্যাক সহ WebSocket ব্যবহার করে: AJAX লং পোলিং, AJAX মাল্টিপার্ট স্ট্রিমিং, Forever Iframe এবং 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>

ক্লায়েন্টে রেফারেন্স করা জাভাস্ক্রিপ্ট ফাইল 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.js, Socket.IO এবং node-static থাকতে হবে। Socket.IO এবং node-static ইনস্টল করতে, আপনার অ্যাপ ডিরেক্টরিতে একটি টার্মিনাল থেকে npm রান করুন:

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 ড্রাফ্ট-এ বাধ্যতামূলক করা হয়েছে।
  • ট্রিকল ICE-এর সুবিধা নিন। প্রার্থীরা পৌঁছানোর সাথে সাথেই addIceCandidate()-এ কল করুন।

রেডি-মেড সিগন্যাল সার্ভার

আপনি যদি নিজেরটা রোল করতে না চান, তাহলে বেশ কয়েকটি WebRTC সিগন্যালিং সার্ভার উপলভ্য, যা আগের উদাহরণের মতো Socket.IO ব্যবহার করে এবং এর সাথে একত্রিত হয় WebRTC ক্লায়েন্ট জাভাস্ক্রিপ্ট লাইব্রেরি:

  • WebRTC-এর জন্য প্রথম অ্যাবস্ট্রাকশন লাইব্রেরিগুলির মধ্যে একটি হল webRTC.io।
  • Signalmaster হল একটি সিগন্যালিং সার্ভার যা SimpleWebRTC জাভাস্ক্রিপ্ট ক্লায়েন্ট লাইব্রেরির সাথে ব্যবহার করার জন্য তৈরি করা হয়েছে।

আপনি যদি কোনও কোড লিখতে না চান, তাহলে vLine, OpenTok এবং Asterisk-এর মতো কোম্পানি থেকে সম্পূর্ণ বাণিজ্যিক WebRTC প্ল্যাটফর্ম উপলভ্য।

রেকর্ডের জন্য, Ericsson WebRTC-এর প্রথম দিকে Apache-তে PHP ব্যবহার করে একটি সিগন্যালিং সার্ভার তৈরি করেছিল। এটি এখন কিছুটা অপ্রচলিত, তবে আপনি যদি একই রকম কিছু বিবেচনা করেন তবে কোডটি দেখার মতো।

সিগন্যাল নিরাপত্তা

সব WebRTC কম্পোনেন্টের জন্য এনক্রিপশন বাধ্যতামূলক।

তবে, সিগন্যালিং মেকানিজম WebRTC স্ট্যান্ডার্ড দ্বারা সংজ্ঞায়িত নয়, তাই সিগন্যালিং সুরক্ষিত করার দায়িত্ব আপনার। কোনও আক্রমণকারী সিগন্যালিং হাইজ্যাক করতে পারলে, সে সেশন বন্ধ করতে, কানেকশন রিডাইরেক্ট করতে এবং কন্টেন্ট রেকর্ড, পরিবর্তন বা ইনজেক্ট করতে পারে।

সিগন্যালিং সুরক্ষিত করার সবচেয়ে গুরুত্বপূর্ণ বিষয় হল সুরক্ষিত প্রোটোকল ব্যবহার করা: HTTPS এবং WSS, যেমন TLS। এটি নিশ্চিত করে যে মেসেজগুলি আনএনক্রিপ্ট করা অবস্থায় ইন্টারসেপ্ট করা যাবে না। এছাড়াও, সিগন্যালিং মেসেজ ব্রডকাস্ট করার সময় সতর্ক থাকুন যাতে একই সিগন্যালিং সার্ভার ব্যবহার করে অন্য কলাররা সেগুলি অ্যাক্সেস করতে না পারেন।

NAT ও ফায়ারওয়াল সংক্রান্ত সমস্যা সমাধান করা

মেটাডেটা সিগন্যালিংয়ের জন্য, WebRTC অ্যাপ একটি মধ্যবর্তী সার্ভার ব্যবহার করে, কিন্তু সেশন একবার প্রতিষ্ঠিত হলে প্রকৃত মিডিয়া এবং ডেটা স্ট্রিমিংয়ের জন্য, RTCPeerConnection ক্লায়েন্টদের সরাসরি বা পিয়ার-টু-পিয়ার কানেক্ট করার চেষ্টা করে।

সহজ কথায়, প্রতিটি WebRTC এন্ডপয়েন্টের একটি অনন্য ঠিকানা থাকবে যা এটি সরাসরি যোগাযোগ করার জন্য অন্যান্য পিয়ারের সাথে এক্সচেঞ্জ করতে পারে।

সহজ পিয়ার-টু-পিয়ার কানেকশন
NAT ও ফায়ারওয়াল ছাড়া পৃথিবী

বাস্তবে, বেশিরভাগ ডিভাইস এক বা একাধিক NAT লেয়ারের পিছনে থাকে, কিছু ডিভাইসে অ্যান্টিভাইরাস সফ্টওয়্যার থাকে যা নির্দিষ্ট পোর্ট এবং প্রোটোকল ব্লক করে এবং অনেকগুলি প্রক্সি এবং কর্পোরেট ফায়ারওয়ালের পিছনে থাকে। আসলে, একই ডিভাইস, যেমন, বাড়ির ওয়াই-ফাই রাউটার, ফায়ারওয়াল ও NAT প্রয়োগ করতে পারে।

NAT এবং ফায়ারওয়ালের পিছনে থাকা পিয়ার
বাস্তব জগৎ

WebRTC অ্যাপ ICE ফ্রেমওয়ার্ক ব্যবহার করে বাস্তব জগতের নেটওয়ার্কিংয়ের জটিলতা কাটিয়ে উঠতে পারে। এটি চালু করতে, আপনার অ্যাপকে অবশ্যই ICE সার্ভার URL RTCPeerConnection-এ পাস করতে হবে।

ICE পিয়ার কানেক্ট করার জন্য সবচেয়ে ভালো পাথ খোঁজার চেষ্টা করে। এটি সমান্তরালভাবে সব সম্ভাবনা চেষ্টা করে এবং সবচেয়ে কার্যকর বিকল্পটি বেছে নেয় যা কাজ করে। ICE প্রথমে ডিভাইসের অপারেটিং সিস্টেম ও নেটওয়ার্ক কার্ড থেকে পাওয়া হোস্ট অ্যাড্রেস ব্যবহার করে কানেকশন তৈরি করার চেষ্টা করে। এটি কাজ না করলে (NAT-এর পিছনে থাকা ডিভাইসের ক্ষেত্রে এটি কাজ করবে), ICE, STUN সার্ভার ব্যবহার করে একটি এক্সটার্নাল অ্যাড্রেস পায় এবং এটি কাজ না করলে, ট্রাফিক TURN রিলে সার্ভারের মাধ্যমে রুট করা হয়।

অন্যভাবে বলতে গেলে, STUN সার্ভার ব্যবহার করা হয় এক্সটার্নাল নেটওয়ার্ক অ্যাড্রেস পাওয়ার জন্য এবং TURN সার্ভার ব্যবহার করা হয় ট্রাফিক রিলে করার জন্য, যদি সরাসরি (পিয়ার-টু-পিয়ার) কানেকশন ব্যর্থ হয়।

প্রতিটি TURN সার্ভার STUN-কে সাপোর্ট করে। TURN সার্ভার হল অতিরিক্ত বিল্ট-ইন রিলেয়িং কার্যকারিতা সহ STUN সার্ভার। এছাড়াও, ICE, NAT সেট-আপের জটিলতা সামলায়। বাস্তবে, NAT হোল-পাঞ্চিংয়ের জন্য শুধু পাবলিক IP:পোর্ট অ্যাড্রেসের চেয়ে বেশি কিছু প্রয়োজন হতে পারে।

STUN এবং TURN সার্ভারের URL (ঐচ্ছিক) 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 সার্ভারের সাথে কাজ করে।

STUN

NATs কোনও ডিভাইসকে একটি IP অ্যাড্রেস প্রদান করে যা একটি ব্যক্তিগত লোকাল নেটওয়ার্কের মধ্যে ব্যবহার করা যায়, তবে এই অ্যাড্রেসটি বাইরে ব্যবহার করা যায় না। পাবলিক অ্যাড্রেস ছাড়া, WebRTC পিয়ারের পক্ষে যোগাযোগ করার কোনও উপায় নেই। এই সমস্যা এড়াতে, WebRTC STUN ব্যবহার করে।

STUN সার্ভার পাবলিক ইন্টারনেটে থাকে এবং এর একটিই কাজ: ইনকামিং অনুরোধের (NAT-এর পিছনে চলা অ্যাপ থেকে) IP:পোর্ট অ্যাড্রেস চেক করা এবং সেই অ্যাড্রেস উত্তর হিসেবে ফেরত পাঠানো। অন্যভাবে বলতে গেলে, অ্যাপটি একটি STUN সার্ভার ব্যবহার করে পাবলিক দৃষ্টিকোণ থেকে এর IP:পোর্ট আবিষ্কার করে। এই প্রসেস WebRTC পিয়ারকে নিজের জন্য সর্বজনীনভাবে অ্যাক্সেসযোগ্য অ্যাড্রেস পেতে এবং তারপর সরাসরি লিঙ্ক সেট-আপ করার জন্য সিগন্যালিং মেকানিজমের মাধ্যমে অন্য পিয়ারে পাস করতে সাহায্য করে।

STUN সার্ভারকে খুব বেশি কাজ করতে বা মনে রাখতে হয় না, তাই তুলনামূলকভাবে কম স্পেসিফিকেশন থাকা STUN সার্ভারও অনেক বেশি সংখ্যক অনুরোধ ম্যানেজ করতে পারে।

বেশিরভাগ WebRTC কল STUN ব্যবহার করে কানেকশন তৈরি করে, তবে ফায়ারওয়াল ও জটিল NAT কনফিগারেশনের পিছনে থাকা পিয়ারের মধ্যে কলের ক্ষেত্রে এটি কম হতে পারে।

STUN সার্ভার ব্যবহার করে পিয়ার-টু-পিয়ার কানেকশন
পাবলিক IP:পোর্ট অ্যাড্রেস পেতে STUN সার্ভার ব্যবহার করা

টার্ন

RTCPeerConnection UDP-এর মাধ্যমে পিয়ারের মধ্যে সরাসরি যোগাযোগ স্থাপন করার চেষ্টা করে। সেটি কাজ না করলে, RTCPeerConnection TCP ব্যবহার করে। এটি কাজ না করলে, TURN সার্ভার এন্ডপয়েন্টের মধ্যে ডেটা রিলে করে ফলব্যাক হিসেবে ব্যবহার করা যেতে পারে।

আবার মনে করিয়ে দিই, TURN ব্যবহার করা হয় পিয়ারের মধ্যে অডিও, ভিডিও ও ডেটা স্ট্রিমিং রিলে করার জন্য, সিগন্যালিং ডেটা নয়!

TURN সার্ভারের সর্বজনীন ঠিকানা থাকে, তাই পিয়াররা ফায়ারওয়াল বা প্রক্সির পিছনে থাকলেও তাদের সাথে যোগাযোগ করা যেতে পারে। TURN সার্ভারের একটিই কাজ: স্ট্রিম রিলে করা। STUN সার্ভারের মতো নয়, এগুলি সহজাতভাবে অনেক ব্যান্ডউইথ ব্যবহার করে।

STUN সার্ভার ব্যবহার করে পিয়ার-টু-পিয়ার কানেকশন
The full Monty: STUN, TURN এবং সিগন্যালিং

এই ডায়াগ্রাম TURN-এর অ্যাকশন দেখায়। Pure 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 ইমেজ উপলভ্য।

বিকল্প TURN সার্ভার হল restund, যা সোর্স কোড হিসেবে এবং AWS-এর জন্যও উপলভ্য। আপনি Compute-এ restund সেট-আপ করতে পারবেন :

  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 থেকে restund ফেচ করে আনপ্যাক করুন।
  7. wget hancke.name/restund-auth.patch এবং patch -p1 < restund-auth.patch-এর সাথে প্রয়োগ করুন।
  8. libre ও restund-এর জন্য make, sudo make install রান করুন।
  9. আপনার প্রয়োজন অনুযায়ী restund.conf অ্যাডাপ্ট করুন (IP অ্যাড্রেস পরিবর্তন করুন এবং এটিতে একই শেয়ার্ড সিক্রেট আছে কিনা তা নিশ্চিত করুন) এবং /etc-এ কপি করুন।
  10. restund/etc/restund, /etc/init.d/-এ কপি করুন।
  11. restund কনফিগার করুন:
    1. LD_LIBRARY_PATH সেট করা হয়েছে।
    2. restund.conf, /etc/restund.conf-এ কপি করুন।
    3. ডানদিকের ১০টি ব্যবহার করতে restund.conf সেট করুন। IP অ্যাড্রেস।
  12. restund রান করুন
  13. রিমোট মেশিন থেকে stund ক্লায়েন্ট ব্যবহার করে পরীক্ষা করুন: ./client IP:port

মাল্টি-পার্টি WebRTC

এছাড়াও, আপনি জাস্টিন উবার্টির প্রস্তাবিত IETF স্ট্যান্ডার্ড দেখতে চাইতে পারেন, যা TURN পরিষেবা অ্যাক্সেস করার জন্য REST API-এর জন্য তৈরি।

মিডিয়া স্ট্রিমিংয়ের ক্ষেত্রে এমন অনেক উদাহরণ আছে যা ওয়ান-টু-ওয়ান কলের বাইরে। যেমন, সহকর্মীদের একটি গ্রুপের মধ্যে ভিডিও কনফারেন্সিং বা একজন বক্তা এবং শত শত বা লক্ষ লক্ষ দর্শকের সাথে একটি সর্বজনীন ইভেন্ট।

একটি WebRTC অ্যাপ একাধিক RTCPeerConnections ব্যবহার করতে পারে যাতে প্রতিটি এন্ডপয়েন্ট একটি মেশ কনফিগারেশনে অন্য প্রতিটি এন্ডপয়েন্টের সাথে কানেক্ট করে। এই পদ্ধতিটি talky.io-এর মতো অ্যাপে ব্যবহার করা হয় এবং অল্প সংখ্যক পিয়ারের ক্ষেত্রে এটি খুব ভালো কাজ করে। এর থেকে বেশি হলে, প্রসেসিং ও ব্যান্ডউইথ খরচ অতিরিক্ত হয়ে যায়, বিশেষত মোবাইল ক্লায়েন্টের ক্ষেত্রে।

মেশ: ছোট N-ওয়ে কল
ফুল মেশ টোপোলজি: প্রত্যেকে প্রত্যেকের সাথে কানেক্টেড

বিকল্প হিসেবে, WebRTC অ্যাপ স্টার কনফিগারেশনে অন্য সব এন্ডপয়েন্টে স্ট্রিম ডিস্ট্রিবিউট করার জন্য একটি এন্ডপয়েন্ট বেছে নিতে পারে। এছাড়াও, সার্ভারে WebRTC এন্ডপয়েন্ট রান করা এবং আপনার নিজস্ব রিডিস্ট্রিবিউশন মেকানিজম তৈরি করা সম্ভব (webrtc.org-এর মাধ্যমে একটি স্যাম্পেল ক্লায়েন্ট অ্যাপ প্রদান করা হয়)।

একটি RTCPeerConnection থেকে পাওয়া MediaStream অন্যটির ইনপুট হিসেবে ব্যবহার করা যেতে পারে। এটি আরও নমনীয় আর্কিটেকচার সক্ষম করতে পারে কারণ এটি একটি ওয়েবকে সক্ষম করে কোন অন্য পিয়ারের সাথে সংযোগ করতে হবে তা বেছে নিয়ে কল-রাউটিং পরিচালনা করার জন্য অ্যাপ। এটি কীভাবে কাজ করে তা দেখতে, WebRTC স্যাম্পেল পিয়ার কানেকশন রিলে এবং WebRTC স্যাম্পেল একাধিক পিয়ার কানেকশন দেখুন।

মাল্টিপয়েন্ট কন্ট্রোল ইউনিট

অনেকগুলি এন্ডপয়েন্টের জন্য আরও ভালো বিকল্প হল মাল্টিপয়েন্ট কন্ট্রোল ইউনিট (MCU) ব্যবহার করা। এটি এমন একটি সার্ভার যা বিপুল সংখ্যক অংশগ্রহণকারীর মধ্যে মিডিয়া বিতরণ করার জন্য একটি ব্রিজ হিসেবে কাজ করে। MCU ভিডিও কনফারেন্সে বিভিন্ন রেজোলিউশন, কোডেক এবং ফ্রেম রেট সামলাতে পারে; ট্রান্সকোডিং ম্যানেজ করতে পারে; বেছে নেওয়া স্ট্রিম ফরওয়ার্ড করতে পারে; এবং অডিও ও ভিডিও মিক্স বা রেকর্ড করতে পারে। মাল্টিপার্টি কলের ক্ষেত্রে, বেশ কিছু বিষয় বিবেচনা করতে হয়, বিশেষ করে কীভাবে একাধিক ভিডিও ইনপুট দেখানো হবে এবং একাধিক সোর্স থেকে অডিও মিক্স করা হবে। vLine-এর মতো ক্লাউড প্ল্যাটফর্মও ট্রাফিক রাউটিং অপ্টিমাইজ করার চেষ্টা করে।

সম্পূর্ণ MCU হার্ডওয়্যার প্যাকেজ কেনা অথবা আপনার নিজের প্যাকেজ তৈরি করা সম্ভব।

Cisco MCU5300-এর পিছনের দিকের ভিউ
Cisco MCU-এর পিছনের দিক

বেশ কয়েকটি ওপেন সোর্স MCU সফ্টওয়্যার বিকল্প উপলভ্য। যেমন, Licode (আগে Lynckia নামে পরিচিত ছিল) WebRTC-এর জন্য ওপেন সোর্স MCU তৈরি করে। OpenTok-এ Mantis আছে।

ব্রাউজার ছাড়াও: VoIP, টেলিফোন এবং মেসেজিং

WebRTC-এর স্ট্যান্ডার্ডাইজড প্রকৃতির কারণে, ব্রাউজারে চলা WebRTC অ্যাপ এবং অন্য কোনও কমিউনিকেশন প্ল্যাটফর্মে চলা ডিভাইস বা প্ল্যাটফর্মের মধ্যে কমিউনিকেশন স্থাপন করা সম্ভব হয়, যেমন টেলিফোন বা ভিডিও-কনফারেন্সিং সিস্টেম।

SIP হল একটি সিগন্যালিং প্রোটোকল যা VoIP এবং ভিডিও-কনফারেন্সিং সিস্টেম দ্বারা ব্যবহৃত হয়। WebRTC ওয়েব অ্যাপ ও SIP ক্লায়েন্টের (যেমন, ভিডিও কনফারেন্সিং সিস্টেম) মধ্যে কমিউনিকেশন চালু করতে, সিগন্যালিংয়ের মধ্যস্থতা করার জন্য WebRTC-এর একটি প্রক্সি সার্ভার প্রয়োজন। সিগন্যাল অবশ্যই গেটওয়ের মাধ্যমে প্রবাহিত হতে হবে, তবে একবার যোগাযোগ স্থাপিত হয়ে গেলে, SRTP ট্রাফিক (ভিডিও এবং অডিও) পিয়ার-টু-পিয়ার প্রবাহিত হতে পারে।

পাবলিক সুইচড টেলিফোন নেটওয়ার্ক (PSTN) হল সব "পুরনো দিনের" অ্যানালগ টেলিফোনের সার্কিট-সুইচড নেটওয়ার্ক। WebRTC ওয়েব অ্যাপ ও টেলিফোনের মধ্যে কলের জন্য, ট্রাফিককে অবশ্যই PSTN গেটওয়ের মাধ্যমে যেতে হবে। একইভাবে, WebRTC ওয়েব অ্যাপের Jingle এন্ডপয়েন্ট যেমন IM ক্লায়েন্টের সাথে কমিউনিকেট করার জন্য একটি মধ্যবর্তী XMPP সার্ভার প্রয়োজন। মেসেজিং পরিষেবার জন্য ভয়েস ও ভিডিও চালু করতে, XMPP-এর এক্সটেনশন হিসেবে Google, Jingle ডেভেলপ করেছে। বর্তমান WebRTC ইমপ্লিমেন্টেশন C++ libjingle লাইব্রেরির উপর ভিত্তি করে তৈরি, যা Talk-এর জন্য প্রাথমিকভাবে ডেভেলপ করা Jingle-এর ইমপ্লিমেন্টেশন।

বহু অ্যাপ, লাইব্রেরি ও প্ল্যাটফর্ম WebRTC-এর ক্ষমতা ব্যবহার করে বাইরের জগতের সাথে যোগাযোগ করে। যেমন:

  • jsSIP: JavaScript SIP লাইব্রেরি
  • Phono: প্লাগ-ইন হিসেবে তৈরি করা ওপেন সোর্স JavaScript ফোন API
  • Twilio: ভয়েস ও মেসেজিং

আরও খুঁজুন

৩৫০ পৃষ্ঠার বই WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web ডেটা এবং সিগন্যালিং পাথওয়ে সম্পর্কে অনেক বিস্তারিত তথ্য প্রদান করে এবং এতে অনেকগুলি বিস্তারিত নেটওয়ার্ক টপোলজি ডায়াগ্রাম অন্তর্ভুক্ত রয়েছে।