একটি WebRTC অ্যাপের জন্য প্রয়োজনীয় ব্যাকএন্ড পরিষেবাগুলি তৈরি করুন৷

সংকেত কি?

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

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

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

কেন WebRTC দ্বারা সংকেত সংজ্ঞায়িত করা হয় না?

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

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

মনে রাখবেন যে WebRTC ডিজাইন করা হয়েছে যাতে SDP পাঠ্যের মানগুলি সম্পাদনা করে স্থানীয় বা দূরবর্তী বিবরণ হিসাবে সেট করার আগে অফার বা উত্তরটি টুইক করা যায়। উদাহরণস্বরূপ, appr.tc-preferAudioCodec() ফাংশনটি ডিফল্ট কোডেক এবং বিটরেট সেট করতে ব্যবহার করা যেতে পারে। 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() ব্যবহার করে দূরবর্তী সেশনের বিবরণ হিসাবে ইভের উত্তর সেট করে।

অ্যালিস এবং ইভকেও নেটওয়ার্ক তথ্য বিনিময় করতে হবে। "প্রার্থী খোঁজার" অভিব্যক্তিটি আইসিই ফ্রেমওয়ার্ক ব্যবহার করে নেটওয়ার্ক ইন্টারফেস এবং পোর্টগুলি খোঁজার প্রক্রিয়াকে বোঝায়।

  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 এবং ব্রাউজার মিটিং , আপনি একটি কাস্টম লিঙ্ক শেয়ার করে লোকেদের একটি কলে আমন্ত্রণ জানান৷ বিকাশকারী ক্রিস বল একটি আকর্ষণীয় সার্ভারহীন-ওয়েব্রটিসি পরীক্ষা তৈরি করেছেন যা WebRTC কল অংশগ্রহণকারীদের তাদের পছন্দের মেসেজিং পরিষেবা যেমন IM, ইমেল বা হোমিং কবুতর দ্বারা মেটাডেটা বিনিময় করতে সক্ষম করে৷

আপনি কিভাবে একটি সংকেত পরিষেবা তৈরি করতে পারেন?

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

সৌভাগ্যক্রমে সংকেত বার্তাগুলি ছোট এবং বেশিরভাগই একটি কলের শুরুতে বিনিময় হয়। একটি ভিডিও চ্যাট সেশনের জন্য appr.tc-এর সাথে পরীক্ষা করার সময়, প্রায় 10KB এর সমস্ত বার্তাগুলির জন্য মোট আকার সহ সিগন্যালিং পরিষেবা দ্বারা মোট 30-45টি বার্তা পরিচালনা করা হয়েছিল৷

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

সার্ভার থেকে ক্লায়েন্টের কাছে বার্তা পাঠান

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

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

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

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

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

স্কেল সংকেত

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

  • এক্সটেনসিবল মেসেজিং অ্যান্ড প্রেজেন্স প্রোটোকল (এক্সএমপিপি), যা মূলত জব্বার নামে পরিচিত- তাৎক্ষণিক বার্তাপ্রেরণের জন্য তৈরি একটি প্রোটোকল যা সিগন্যালিংয়ের জন্য ব্যবহার করা যেতে পারে (সার্ভার বাস্তবায়নে ইজাবার্ড এবং ওপেনফায়ার অন্তর্ভুক্ত রয়েছে। জাভাস্ক্রিপ্ট ক্লায়েন্ট, যেমন Strophe.js , অনুকরণ করতে BOSH ব্যবহার করে, বিভিন্ন eBOSH কারণের জন্য দ্বিমুখী হতে পারে না। WebSocket হিসাবে এবং, একই কারণে, ভালভাবে স্কেল নাও হতে পারে।) (একটি স্পর্শক-এ, জিঙ্গল হল ভয়েস এবং ভিডিও সক্ষম করার জন্য একটি XMPP এক্সটেনশন। WebRTC প্রকল্পটি libjingle লাইব্রেরি থেকে নেটওয়ার্ক এবং পরিবহন উপাদান ব্যবহার করে - Jingle-এর একটি C++ বাস্তবায়ন।)

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

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

  • বাণিজ্যিক WebRTC প্ল্যাটফর্ম, যেমন vLine

(ডেভেলপার ফিল লেগেটারের রিয়েল-টাইম ওয়েব টেকনোলজিস গাইড মেসেজিং পরিষেবা এবং লাইব্রেরির একটি বিস্তৃত তালিকা প্রদান করে।)

নোডে Socket.io দিয়ে একটি সিগন্যালিং পরিষেবা তৈরি করুন

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

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

  });

});

(এর জন্য আপনাকে নোড-স্ট্যাটিক সম্পর্কে শিখতে হবে না। এটি এই উদাহরণে ব্যবহার করা হবে।)

লোকালহোস্টে এই অ্যাপটি চালানোর জন্য আপনার Node, Socket.IO এবং নোড-স্ট্যাটিক ইনস্টল থাকতে হবে। Node.js থেকে নোড ডাউনলোড করা যেতে পারে (ইনস্টলেশন সহজবোধ্য এবং দ্রুত)। Socket.IO এবং নোড-স্ট্যাটিক ইনস্টল করতে, আপনার অ্যাপ ডিরেক্টরির একটি টার্মিনাল থেকে নোড প্যাকেজ ম্যানেজার চালান:

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 ক্লায়েন্ট জাভাস্ক্রিপ্ট লাইব্রেরির সাথে একত্রিত হয়:

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

আপনি যদি একেবারেই কোনো কোড লিখতে না চান, সম্পূর্ণ বাণিজ্যিক WebRTC প্ল্যাটফর্মগুলি কোম্পানি থেকে পাওয়া যায়, যেমন vLine , OpenTok , এবং Asterisk

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

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

"নিরাপত্তা হল কিছু না ঘটানোর শিল্প।"

সালমান রুশদি

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

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

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

সংকেত দেওয়ার পরে: NATs এবং ফায়ারওয়ালগুলির সাথে মানিয়ে নিতে ICE ব্যবহার করুন

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

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

সহজ পিয়ার থেকে পিয়ার সংযোগ
NATs এবং ফায়ারওয়াল ছাড়া একটি পৃথিবী

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

NATs এবং ফায়ারওয়ালের পিছনে সহকর্মীরা
বাস্তব জগত

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

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

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

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

STUN এবং/অথবা টার্ন সার্ভারের URLগুলি (ঐচ্ছিকভাবে) 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 ICE ফ্রেমওয়ার্ক ব্যবহার করে সমবয়সীদের মধ্যে সর্বোত্তম পথ তৈরি করতে, STUN এবং TURN সার্ভারের সাথে প্রয়োজনে কাজ করে।

STUN

NATs একটি ব্যক্তিগত স্থানীয় নেটওয়ার্কের মধ্যে ব্যবহারের জন্য একটি IP ঠিকানা সহ একটি ডিভাইস সরবরাহ করে, কিন্তু এই ঠিকানাটি বাহ্যিকভাবে ব্যবহার করা যাবে না। একটি সর্বজনীন ঠিকানা ছাড়া, WebRTC সহকর্মীদের যোগাযোগ করার কোন উপায় নেই৷ এই সমস্যাটি পেতে, WebRTC STUN ব্যবহার করে।

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

STUN সার্ভারগুলিকে অনেক কিছু করতে বা মনে রাখতে হবে না, তাই অপেক্ষাকৃত কম-স্পেকের STUN সার্ভারগুলি প্রচুর সংখ্যক অনুরোধ পরিচালনা করতে পারে।

বেশিরভাগ WebRTC কল সফলভাবে STUN - 86% ব্যবহার করে একটি সংযোগ তৈরি করে Webrtcstats.com অনুসারে, যদিও ফায়ারওয়াল এবং জটিল NAT কনফিগারেশনের পিছনে থাকা সহকর্মীদের মধ্যে কলের জন্য এটি কম হতে পারে।

একটি STUN সার্ভার ব্যবহার করে পিয়ার টু পিয়ার সংযোগ
পাবলিক আইপি:পোর্ট ঠিকানা পেতে STUN সার্ভার ব্যবহার করে

টার্ন

RTCPeerConnection UDP-এর মাধ্যমে সহকর্মীদের মধ্যে সরাসরি যোগাযোগ স্থাপন করার চেষ্টা করে। যদি এটি ব্যর্থ হয়, RTCPeerConnection টিসিপি-তে অবলম্বন করে। যদি এটি ব্যর্থ হয়, টার্ন সার্ভারগুলিকে ফলব্যাক হিসাবে ব্যবহার করা যেতে পারে, শেষ পয়েন্টগুলির মধ্যে ডেটা রিলে করে৷

শুধু পুনরাবৃত্ত করার জন্য, টার্ন ব্যবহার করা হয় অডিও, ভিডিও এবং ডেটা স্ট্রিমিং সহ সমবয়সীদের মধ্যে রিলে করতে, ডেটা সিগন্যাল করার জন্য নয়!

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

একটি STUN সার্ভার ব্যবহার করে পিয়ার টু পিয়ার সংযোগ
সম্পূর্ণ মন্টি: STUN, টার্ন, এবং সিগন্যালিং

এই চিত্রটি টার্নকে কর্মে দেখায়। বিশুদ্ধ STUN সফল হয়নি, তাই প্রতিটি পিয়ার একটি টার্ন সার্ভার ব্যবহার করে।

STUN এবং TURN সার্ভার স্থাপন করা হচ্ছে

পরীক্ষার জন্য, Google একটি সর্বজনীন STUN সার্ভার চালায়, stun.l.google.com:19302, যেমনটি appr.tc দ্বারা ব্যবহৃত হয়। একটি উত্পাদন STUN/টার্ন পরিষেবার জন্য, rfc5766-টার্ন-সার্ভার ব্যবহার করুন৷ STUN এবং টার্ন সার্ভারের জন্য সোর্স কোড GitHub- এ উপলব্ধ, যেখানে আপনি সার্ভার ইনস্টলেশন সম্পর্কে তথ্যের বিভিন্ন উত্সের লিঙ্কও খুঁজে পেতে পারেন। অ্যামাজন ওয়েব পরিষেবাগুলির জন্য একটি ভিএম চিত্রও উপলব্ধ।

একটি বিকল্প টার্ন সার্ভার হল রেস্টন্ড, সোর্স কোড হিসাবে উপলব্ধ এবং AWS-এর জন্যও। কম্পিউট ইঞ্জিনে রেস্টন্ড সেট আপ করার জন্য এখানে নির্দেশাবলী রয়েছে৷

  1. tcp=443, udp/tcp=3478 এর জন্য প্রয়োজনীয় ফায়ারওয়াল খুলুন।
  2. চারটি উদাহরণ তৈরি করুন, প্রতিটি পাবলিক আইপির জন্য একটি, স্ট্যান্ডার্ড উবুন্টু 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. চালান make , sudo make install for libre এবং restund.
  9. আপনার প্রয়োজন অনুযায়ী restund.conf মানিয়ে নিন (আইপি ঠিকানাগুলি প্রতিস্থাপন করুন এবং নিশ্চিত করুন যে এটিতে একই ভাগ করা গোপনীয়তা রয়েছে) এবং /etc এ অনুলিপি করুন।
  10. restund/etc/restund /etc/init.d/ এ কপি করুন।
  11. বিশ্রাম কনফিগার করুন:
    1. LD_LIBRARY_PATH সেট করুন।
    2. restund.conf কপি করুন /etc/restund.conf এ।
    3. ডান 10. ​​IP ঠিকানা ব্যবহার করতে restund.conf সেট করুন।
  12. বিশ্রাম চালান
  13. রিমোট মেশিন থেকে স্টান্ড ক্লায়েন্ট ব্যবহার করে পরীক্ষা করুন: ./client IP:port

একের পর এক: মাল্টিপার্টি WebRTC

আপনি টার্ন পরিষেবাগুলিতে অ্যাক্সেসের জন্য একটি REST API-এর জন্য জাস্টিন উবার্তির প্রস্তাবিত IETF স্ট্যান্ডার্ডটিও দেখতে চাইতে পারেন৷

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

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

মেশ: ছোট এন-ওয়ে কল
সম্পূর্ণ জাল টপোলজি: প্রত্যেকে প্রত্যেকের সাথে সংযুক্ত

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

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

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

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

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

Cisco MCU5300 এর পিছনের দৃশ্য
একটি সিসকো MCU পিছনে

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

ব্রাউজারগুলির বাইরে: ভিওআইপি, টেলিফোন এবং মেসেজিং

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

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

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

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

  • sipML5 : একটি ওপেন সোর্স জাভাস্ক্রিপ্ট SIP ক্লায়েন্ট
  • jsSIP : জাভাস্ক্রিপ্ট এসআইপি লাইব্রেরি
  • ফোনো : ওপেন সোর্স জাভাস্ক্রিপ্ট ফোন এপিআই একটি প্লাগইন হিসেবে তৈরি
  • জিঙ্গায়া : একটি এমবেডযোগ্য ফোন উইজেট
  • Twilio : ভয়েস এবং মেসেজিং
  • উবার কনফারেন্স : কনফারেন্সিং

sipML5 বিকাশকারীরাও webrtc2sip গেটওয়ে তৈরি করেছে। Tethr এবং Tropo WebRTC এর মাধ্যমে ফিচার ফোন এবং কম্পিউটারের মধ্যে যোগাযোগ সক্ষম করতে OpenBTS সেল ব্যবহার করে "একটি ব্রিফকেসে" দুর্যোগ যোগাযোগের জন্য একটি কাঠামো প্রদর্শন করেছে। যে একটি ক্যারিয়ার ছাড়া টেলিফোন যোগাযোগ!

আরও জানুন

WebRTC কোডল্যাব নোডে চলমান একটি Socket.io সিগন্যালিং পরিষেবা ব্যবহার করে কীভাবে একটি ভিডিও এবং পাঠ্য চ্যাট অ্যাপ তৈরি করতে হয় তার জন্য ধাপে ধাপে নির্দেশনা প্রদান করে।

WebRTC টেক লিড, জাস্টিন উবার্তি সহ 2013 থেকে Google I/O WebRTC উপস্থাপনা

ক্রিস উইলসনের SFHTML5 উপস্থাপনা - WebRTC অ্যাপের ভূমিকা

350-পৃষ্ঠার বই WebRTC: APIs এবং HTML5 রিয়েল-টাইম ওয়েবের RTCWEB প্রোটোকল ডেটা এবং সিগন্যালিং পাথওয়ে সম্পর্কে অনেক বিশদ প্রদান করে এবং এতে বেশ কয়েকটি বিশদ নেটওয়ার্ক টপোলজি ডায়াগ্রাম রয়েছে।

ওয়েবআরটিসি এবং সিগন্যালিং: দুই বছর আমাদের কী শিখিয়েছে - টোকবক্স ব্লগ পোস্ট কেন সিগন্যালিংকে বিশেষত্বের বাইরে রেখে দেওয়া একটি ভাল ধারণা ছিল

WebRTC অ্যাপস তৈরির জন্য বেন স্ট্রং-এর একটি ব্যবহারিক গাইড WebRTC টপোলজি এবং অবকাঠামো সম্পর্কে অনেক তথ্য প্রদান করে।

ইলিয়া গ্রিগোরিকের হাই পারফরম্যান্স ব্রাউজার নেটওয়ার্কিং- এর WebRTC অধ্যায় WebRTC আর্কিটেকচার, কেস ব্যবহার এবং পারফরম্যান্সের গভীরে যায়।

,

সংকেত কি?

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

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

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

কেন WebRTC দ্বারা সংকেত সংজ্ঞায়িত করা হয় না?

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

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

মনে রাখবেন যে WebRTC ডিজাইন করা হয়েছে যাতে SDP পাঠ্যের মানগুলি সম্পাদনা করে স্থানীয় বা দূরবর্তী বিবরণ হিসাবে সেট করার আগে অফার বা উত্তরটি টুইক করা যায়। উদাহরণস্বরূপ, appr.tc-preferAudioCodec() ফাংশনটি ডিফল্ট কোডেক এবং বিটরেট সেট করতে ব্যবহার করা যেতে পারে। 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() ব্যবহার করে দূরবর্তী সেশনের বিবরণ হিসাবে ইভের উত্তর সেট করে।

অ্যালিস এবং ইভকেও নেটওয়ার্কের তথ্য বিনিময় করতে হবে। "সন্ধানকারী প্রার্থীদের" অভিব্যক্তিটি আইসিই কাঠামো ব্যবহার করে নেটওয়ার্ক ইন্টারফেস এবং পোর্টগুলি সন্ধানের প্রক্রিয়াটিকে বোঝায়।

  1. অ্যালিস onicecandidate হ্যান্ডলারের সাথে একটি RTCPeerConnection অবজেক্ট তৈরি করে।
  2. নেটওয়ার্ক প্রার্থীরা উপলব্ধ হয়ে গেলে হ্যান্ডলারটিকে বলা হয়।
  3. হ্যান্ডলারে, অ্যালিস তাদের সিগন্যালিং চ্যানেলের মাধ্যমে প্রাক্কালে স্ট্রিংফাইড প্রার্থীদের ডেটা প্রেরণ করে।
  4. ইভটি যখন অ্যালিসের কাছ থেকে প্রার্থী বার্তা পায়, তখন তিনি রিমোট পিয়ারের বিবরণে প্রার্থী যুক্ত করতে addIceCandidate() কল করেন।

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

সিগন্যালিংয়ের জন্য কোড ওয়েবআরটিসি

নিম্নলিখিত কোড স্নিপেট একটি ডাব্লু 3 সি কোড উদাহরণ যা সম্পূর্ণ সংকেত প্রক্রিয়াটির সংক্ষিপ্তসার করে। কোডটি কিছু সিগন্যালিং মেকানিজমের অস্তিত্ব ধরে নিয়েছে, 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);
  }
};

অফার/উত্তর এবং প্রার্থী-এক্সচেঞ্জ প্রক্রিয়াগুলি ক্রিয়াকলাপ দেখতে, সিম্পল.ইনফো আরটিসিপিয়ার সংযোগ দেখুন এবং একক পৃষ্ঠার ভিডিও চ্যাট উদাহরণের জন্য কনসোল লগটি দেখুন। আপনি যদি আরও চান তবে গুগল ক্রোমে // ওয়েবআরটিসি-ইন্টারনালস পৃষ্ঠা বা অপেরা: // অপেরাতে ওয়েবআরটিসি-ইন্টারনালস পৃষ্ঠা থেকে ওয়েবআরটিসি সিগন্যালিং এবং পরিসংখ্যানগুলির একটি সম্পূর্ণ ডাম্প ডাউনলোড করুন।

পিয়ার আবিষ্কার

এটি জিজ্ঞাসা করার অভিনব উপায়, "আমি কীভাবে কারও সাথে কথা বলতে পারি?"

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

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

আপনি কীভাবে একটি সংকেত পরিষেবা তৈরি করতে পারেন?

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

ধন্যবাদ সিগন্যালিং বার্তাগুলি ছোট এবং বেশিরভাগ কলের শুরুতে বিনিময় হয়। একটি ভিডিও চ্যাট সেশনের জন্য এডিআর.টি.সি.র সাথে পরীক্ষার ক্ষেত্রে, প্রায় 10 কেবি-র সমস্ত বার্তার জন্য মোট আকারের সাথে সিগন্যালিং পরিষেবা দ্বারা মোট 30-45 বার্তাগুলি পরিচালনা করা হয়েছিল।

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

সার্ভার থেকে ক্লায়েন্টের কাছে বার্তাগুলি চাপুন

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

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

ওয়েবসকেট হ'ল একটি আরও প্রাকৃতিক সমাধান, সম্পূর্ণ দ্বৈত ক্লায়েন্ট - সিরারভার যোগাযোগের জন্য ডিজাইন করা - এমন বার্তা যা একই সাথে উভয় দিকেই প্রবাহিত হতে পারে। খাঁটি ওয়েবসকেট বা সার্ভার-সেন্ট ইভেন্টস ( EventSource ) দিয়ে নির্মিত একটি সিগন্যালিং পরিষেবার একটি সুবিধা হ'ল এই এপিআইগুলির ব্যাকএন্ডটি পিএইচপি, পাইথন এবং রুবির মতো ভাষার জন্য বেশিরভাগ ওয়েব-হোস্টিং প্যাকেজগুলিতে সাধারণ বিভিন্ন ওয়েব ফ্রেমওয়ার্কগুলিতে প্রয়োগ করা যেতে পারে।

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

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

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

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

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

  • ওপেন সোর্স লাইব্রেরিগুলি, যেমন জেরোমক (যেমন তাদের গুজব পরিষেবার জন্য টোকবক্স দ্বারা ব্যবহৃত) এবং ওপেনএমকিউ ( নালমকিউ ওয়েবসকেটের মাধ্যমে স্টম্প প্রোটোকল ব্যবহার করে ওয়েব প্ল্যাটফর্মগুলিতে জেরোমকিউ ধারণাগুলি প্রয়োগ করে))

  • বাণিজ্যিক ক্লাউড-মেসেজিং প্ল্যাটফর্মগুলি যা ওয়েবকেট ব্যবহার করে (যদিও তারা দীর্ঘ পোলিংয়ে ফিরে যেতে পারে), যেমন পুশার , কাজিং এবং পাবনব (পাবনবও ওয়েবআরটিসি-র জন্য একটি এপিআই রয়েছে))

  • বাণিজ্যিক ওয়েবআরটিসি প্ল্যাটফর্মগুলি যেমন ভিনলাইন

(বিকাশকারী ফিল লেগেটারের রিয়েল-টাইম ওয়েব টেকনোলজিস গাইড মেসেজিং পরিষেবা এবং গ্রন্থাগারগুলির একটি বিস্তৃত তালিকা সরবরাহ করে))

নোডে সকেট.আইও দিয়ে একটি সিগন্যালিং পরিষেবা তৈরি করুন

নিম্নলিখিতটি একটি সাধারণ ওয়েব অ্যাপের জন্য কোড যা নোডে সকেট.আইও দিয়ে নির্মিত একটি সিগন্যালিং পরিষেবা ব্যবহার করে। সকেট.আইওর নকশাটি বার্তা এবং সকেট বিনিময় করার জন্য একটি পরিষেবা তৈরি করা সহজ করে তোলে yo এই উদাহরণটি উত্পাদন-গ্রেড সিগন্যালিং পরিষেবা হিসাবে স্কেল করার জন্য ডিজাইন করা হয়নি, তবে তুলনামূলকভাবে অল্প সংখ্যক ব্যবহারকারীর জন্য বোঝা সহজ।

সকেট.আইও ফ্যালব্যাকস সহ ওয়েবকেট ব্যবহার করে: অ্যাজাক্স লং পোলিং, অ্যাজাক্স মাল্টিপার্ট স্ট্রিমিং, চিরকাল আইফ্রেম এবং জেএসএনপি পোলিং। এটি বিভিন্ন ব্যাকেন্ডে পোর্ট করা হয়েছে, তবে সম্ভবত এই উদাহরণে ব্যবহৃত নোড সংস্করণের জন্য এটি সবচেয়ে বেশি পরিচিত।

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

এখানে ক্লায়েন্ট 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);

  });

});

(এর জন্য আপনার নোড-স্ট্যাটিক সম্পর্কে শেখার দরকার নেই It এটি কেবল এই উদাহরণে ব্যবহার করা হবে))

লোকালহোস্টে এই অ্যাপ্লিকেশনটি চালানোর জন্য আপনার নোড, সকেট.আইও এবং নোড-স্ট্যাটিক ইনস্টল থাকা দরকার। নোড নোড.জেএস থেকে ডাউনলোড করা যায় (ইনস্টলেশনটি সোজা এবং দ্রুত)। সকেট.আইও এবং নোড-স্ট্যাটিক ইনস্টল করতে, আপনার অ্যাপ্লিকেশন ডিরেক্টরিতে একটি টার্মিনাল থেকে নোড প্যাকেজ ম্যানেজার চালান:

npm install socket.io
npm install node-static

সার্ভারটি শুরু করতে, আপনার অ্যাপ্লিকেশন ডিরেক্টরিতে একটি টার্মিনাল থেকে নিম্নলিখিত কমান্ডটি চালান:

node server.js

আপনার ব্রাউজার থেকে, localhost:2013 । যে কোনও ব্রাউজারে একটি নতুন ট্যাব বা উইন্ডো খুলুন এবং localhost:2013 আবার খুলুন। কী ঘটছে তা দেখতে, কনসোলটি পরীক্ষা করুন। ক্রোম এবং অপেরাতে, আপনি Ctrl+Shift+J (বা ম্যাকের উপর Command+Option+J ) দিয়ে গুগল ক্রোম বিকাশকারী সরঞ্জামগুলির মাধ্যমে কনসোলটি অ্যাক্সেস করতে পারেন।

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

সিগন্যালিং গটচাস

  • RTCPeerConnection setLocalDescription() বলা না হওয়া পর্যন্ত প্রার্থীদের সংগ্রহ করা শুরু করবে না। এটি জেএসইপি আইইটিএফ খসড়াতে বাধ্যতামূলক।
  • ট্রিকল বরফের সুবিধা নিন। প্রার্থীরা আসার সাথে সাথেই addIceCandidate() কল করুন।

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

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

আপনি যদি কোনও কোড লিখতে না চান তবে সম্পূর্ণ বাণিজ্যিক ওয়েবআরটিটিসি প্ল্যাটফর্মগুলি ভিনলাইন , ওপেনটোক এবং অ্যাসটারিস্কের মতো সংস্থাগুলি থেকে পাওয়া যায়।

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

সিগন্যালিং সুরক্ষা

"সুরক্ষা হ'ল কিছুই না করার শিল্প।"

সালমান রুশদি

সমস্ত ওয়েবআরটিটিসি উপাদানগুলির জন্য এনক্রিপশন বাধ্যতামূলক

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

সিগন্যালিং সুরক্ষার সর্বাধিক গুরুত্বপূর্ণ বিষয় হ'ল সুরক্ষিত প্রোটোকলগুলি ব্যবহার করা - এইচটিটিপিএস এবং ডাব্লুএসএস (উদাহরণস্বরূপ, টিএলএস) - যা নিশ্চিত করে যে বার্তাগুলি অনিচ্ছাকৃতভাবে বাধা দেওয়া যায় না। এছাড়াও, সিগন্যালিং বার্তাগুলি এমনভাবে সম্প্রচার না করার বিষয়ে সতর্কতা অবলম্বন করুন যাতে তারা একই সংকেত সার্ভার ব্যবহার করে অন্য কলারদের দ্বারা অ্যাক্সেস করা যায়।

সিগন্যালিংয়ের পরে: নাট এবং ফায়ারওয়ালগুলি মোকাবেলায় বরফ ব্যবহার করুন

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

একটি সহজ বিশ্বে, প্রতিটি ওয়েবআরটিসি এন্ডপয়েন্টে একটি অনন্য ঠিকানা থাকবে যা এটি সরাসরি যোগাযোগের জন্য অন্যান্য সমবয়সীদের সাথে বিনিময় করতে পারে।

পিয়ার সংযোগ সহজ পিয়ার
নাট এবং ফায়ারওয়াল ছাড়া একটি বিশ্ব

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

নাট এবং ফায়ারওয়ালের পিছনে সহকর্মীরা
বাস্তব জগত

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

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

অন্য কথায়, একটি স্টান সার্ভার একটি বাহ্যিক নেটওয়ার্ক ঠিকানা পেতে ব্যবহৃত হয় এবং টার্ন সার্ভারগুলি ট্র্যাফিক রিলে করতে ব্যবহৃত হয় যদি সরাসরি (পিয়ার-টু-পিয়ার) সংযোগ ব্যর্থ হয়।

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

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

{
  '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 এই তথ্যটি পেয়ে গেলে আইস ম্যাজিকটি স্বয়ংক্রিয়ভাবে ঘটে। RTCPeerConnection সহকর্মীদের মধ্যে সেরা পথটি কাজ করতে, স্টান এবং টার্ন সার্ভারগুলি প্রয়োজনীয় হিসাবে কাজ করার জন্য বরফের কাঠামোটি ব্যবহার করে।

STUN

NATS একটি ব্যক্তিগত স্থানীয় নেটওয়ার্কের মধ্যে ব্যবহারের জন্য একটি আইপি ঠিকানা সহ একটি ডিভাইস সরবরাহ করে তবে এই ঠিকানাটি বাহ্যিকভাবে ব্যবহার করা যায় না। জনসাধারণের ঠিকানা ব্যতীত ওয়েবআরটিসি সহকর্মীদের যোগাযোগের কোনও উপায় নেই। এই সমস্যাটি পেতে, ওয়েবআরটিসি স্টান ব্যবহার করে।

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

স্টান সার্ভারগুলিকে বেশি কিছু করতে হবে না বা খুব বেশি মনে রাখতে হবে না, তাই তুলনামূলকভাবে কম-স্পেক স্টান সার্ভারগুলি প্রচুর পরিমাণে অনুরোধগুলি পরিচালনা করতে পারে।

বেশিরভাগ ডাব্লুআরবিআরটিসি কল সফলভাবে স্টান ব্যবহার করে একটি সংযোগ তৈরি করে - ওয়েবআরটিসিএসটিএসটিএস.কম অনুসারে 86%, যদিও এটি ফায়ারওয়াল এবং জটিল NAT কনফিগারেশনের পিছনে সহকর্মীদের মধ্যে কলগুলির জন্য কম হতে পারে।

স্টান সার্ভার ব্যবহার করে পিয়ার টু পিয়ার সংযোগ
পাবলিক আইপি পেতে স্টান সার্ভারগুলি ব্যবহার করে: পোর্টের ঠিকানাগুলি

ঘুরিয়ে

RTCPeerConnection ইউডিপির উপর সহকর্মীদের মধ্যে সরাসরি যোগাযোগ স্থাপনের চেষ্টা করে। যদি এটি ব্যর্থ হয় তবে RTCPeerConnection টিসিপিতে রিসর্ট করে। যদি এটি ব্যর্থ হয় তবে টার্ন সার্ভারগুলি ফ্যালব্যাক হিসাবে ব্যবহার করা যেতে পারে, শেষ পয়েন্টগুলির মধ্যে ডেটা রিলে করে।

কেবল পুনরাবৃত্তি করার জন্য, টার্নটি অডিও, ভিডিও এবং ডেটা স্ট্রিমিং রিলে করতে ব্যবহৃত হয়, ডেটা সংকেত না করে!

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

স্টান সার্ভার ব্যবহার করে পিয়ার টু পিয়ার সংযোগ
পুরো মন্টি: স্তম্ভিত, টার্ন এবং সিগন্যালিং

এই চিত্রটি কর্মে ঘুরে দেখায়। খাঁটি স্টান সফল হয়নি, সুতরাং প্রতিটি পিয়ার একটি টার্ন সার্ভার ব্যবহার করে রিসর্ট করে।

স্টান এবং টার্ন সার্ভার স্থাপন করা

পরীক্ষার জন্য, গুগল একটি পাবলিক স্টান সার্ভার চালায়, stun.l.google.com:19302, যেমন APREA.TC দ্বারা ব্যবহৃত হয়। একটি উত্পাদন স্টান/টার্ন পরিষেবার জন্য, আরএফসি 5766-টার্ন-সার্ভারটি ব্যবহার করুন। স্টান এবং টার্ন সার্ভারগুলির জন্য উত্স কোডটি গিটহাবে উপলভ্য, যেখানে আপনি সার্ভার ইনস্টলেশন সম্পর্কিত তথ্যের বেশ কয়েকটি উত্সের লিঙ্কগুলিও খুঁজে পেতে পারেন। অ্যামাজন ওয়েব পরিষেবাদির জন্য একটি ভিএম চিত্রও উপলব্ধ।

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

  1. টিসিপি = 443, ইউডিপি/টিসিপি = 3478 এর জন্য প্রয়োজনীয় হিসাবে ফায়ারওয়াল খুলুন।
  2. চারটি উদাহরণ তৈরি করুন, প্রতিটি পাবলিক আইপি, স্ট্যান্ডার্ড উবুন্টু 12.06 চিত্রের জন্য একটি করুন।
  3. স্থানীয় ফায়ারওয়াল কনফিগারেশন সেট আপ করুন (যে কোনও থেকে অনুমতি দিন)।
  4. সরঞ্জামগুলি ইনস্টল করুন: shell sudo apt-get install make sudo apt-get install gcc
  5. ক্রেইটিভ.কম/রে.এইচটিএমএল থেকে লিব্রে ইনস্টল করুন।
  6. ক্রেইটিভ.কম/রেস্টুন্ড.এইচটিএমএল এবং আনপ্যাক./ থেকে রেস্টুন্ড আনুন
  7. wget hancke.name/restund-auth.patch এবং patch -p1 < restund-auth.patch এর সাথে আবেদন করুন।
  8. রান make , sudo make install
  9. আপনার প্রয়োজনের সাথে restund.conf মানিয়ে নিন (আইপি ঠিকানাগুলি প্রতিস্থাপন করুন এবং এটিতে একই ভাগ করা গোপনীয়তা রয়েছে তা নিশ্চিত করুন) এবং /etc অনুলিপি করুন।
  10. /etc/init.d/restund/etc/restund অনুলিপি করুন।
  11. রেস্টুন্ড কনফিগার করুন:
    1. LD_LIBRARY_PATH সেট করুন।
    2. restund.conf অনুলিপি করুন /etc/restund.conf
    3. ডান 10 আইপি ঠিকানা ব্যবহার করতে restund.conf সেট করুন।
  12. রেস্টুন্ড চালান
  13. রিমোট মেশিন থেকে স্টান্ড ক্লায়েন্ট ব্যবহার করে পরীক্ষা করুন: ./client IP:port

এক-একের বাইরে: মাল্টিপ্লার্টি ওয়েবআরটিসি

আপনি টার্ন সার্ভিসেস অ্যাক্সেসের জন্য একটি REST এপিআইয়ের জন্য জাস্টিন উবার্তির প্রস্তাবিত আইইটিএফ স্ট্যান্ডার্ডটিও একবার দেখে নিতে পারেন।

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

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

জাল: ছোট এন-ওয়ে কল
পূর্ণ জাল টপোলজি: প্রত্যেকের সাথে প্রত্যেকে সংযুক্ত

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

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

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

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

একটি সম্পূর্ণ এমসিইউ হার্ডওয়্যার প্যাকেজ কেনা বা নিজের তৈরি করা সম্ভব।

সিসকো এমসিইউ 5300 এর রিয়ার ভিউ
একটি সিসকো এমসিইউ এর পিছনে

বেশ কয়েকটি ওপেন সোর্স এমসিইউ সফ্টওয়্যার বিকল্পগুলি উপলব্ধ। উদাহরণস্বরূপ, লিকোড (পূর্বে লিনকিয়া নামে পরিচিত) ওয়েবআরটিসির জন্য একটি ওপেন সোর্স এমসিইউ তৈরি করে। ওপেনটকের ম্যান্টিস রয়েছে।

ব্রাউজারগুলির বাইরে: ভিওআইপি, টেলিফোন এবং মেসেজিং

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

এসআইপি হ'ল ভিওআইপি এবং ভিডিও কনফারেন্সিং সিস্টেম দ্বারা ব্যবহৃত একটি সিগন্যালিং প্রোটোকল। একটি ওয়েবআরটিটিসি ওয়েব অ্যাপ্লিকেশন এবং একটি এসআইপি ক্লায়েন্টের মধ্যে যেমন ভিডিও কনফারেন্সিং সিস্টেমের মধ্যে যোগাযোগ সক্ষম করতে, ওয়েবআরটিটিসির সিগন্যালিংয়ের মধ্যস্থতা করার জন্য একটি প্রক্সি সার্ভার প্রয়োজন। সিগন্যালিং অবশ্যই গেটওয়ে দিয়ে প্রবাহিত হতে হবে তবে একবার যোগাযোগ প্রতিষ্ঠিত হয়ে গেলে, এসআরটিপি ট্র্যাফিক (ভিডিও এবং অডিও) সরাসরি পিয়ারকে পিয়ারে প্রবাহিত করতে পারে।

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

বেশ কয়েকটি অ্যাপ্লিকেশন, গ্রন্থাগার এবং প্ল্যাটফর্মগুলি বাইরের বিশ্বের সাথে যোগাযোগের জন্য ওয়েবআরটিসি'র দক্ষতা ব্যবহার করে:

এসআইপিএমএল 5 বিকাশকারীরা ওয়েবআরটিসি 2 এসআইপি গেটওয়েও তৈরি করেছে। টেটিআর এবং ট্রোপো ওয়েবআরটিসির মাধ্যমে বৈশিষ্ট্য ফোন এবং কম্পিউটারের মধ্যে যোগাযোগ সক্ষম করতে একটি ওপেনবিটিএস সেল ব্যবহার করে "একটি ব্রিফকেসে" দুর্যোগ যোগাযোগের জন্য একটি কাঠামো প্রদর্শন করেছে। এটি ক্যারিয়ার ছাড়া টেলিফোন যোগাযোগ!

আরও জানুন

ওয়েবআরটিসি কোডল্যাব নোডে চলমান সকেট.আইও সিগন্যালিং পরিষেবা ব্যবহার করে কীভাবে একটি ভিডিও এবং পাঠ্য চ্যাট অ্যাপ্লিকেশন তৈরি করতে পারে তার জন্য ধাপে ধাপে নির্দেশাবলী সরবরাহ করে।

ওয়েবআরটিসি টেক লিড, জাস্টিন উবার্তির সাথে 2013 থেকে গুগল আই/ও ওয়েবআরটিসি উপস্থাপনা

ক্রিস উইলসনের এসএফএইচটিএমএল 5 উপস্থাপনা - ওয়েবআরটিটিসি অ্যাপ্লিকেশনগুলির পরিচিতি

350-পৃষ্ঠার বইয়ের ওয়েবটিটিসি: এইচটিএমএল 5 রিয়েল-টাইম ওয়েবের এপিআই এবং আরটিসিডব্লিউইবি প্রোটোকলগুলি ডেটা এবং সিগন্যালিং পথগুলি সম্পর্কে প্রচুর বিশদ সরবরাহ করে এবং এতে বেশ কয়েকটি বিশদ নেটওয়ার্ক টপোলজি ডায়াগ্রাম অন্তর্ভুক্ত রয়েছে।

ওয়েবআরটিসি এবং সিগন্যালিং: দু'বছর আমাদের শিখিয়েছে - কেন স্পেসের বাইরে সিগন্যাল ছেড়ে দেওয়া ভাল ধারণা ছিল সে সম্পর্কে টোকবক্স ব্লগ পোস্ট

বেন স্ট্রংয়ের ওয়েবআরটিসি অ্যাপ্লিকেশন তৈরির জন্য একটি ব্যবহারিক গাইড ওয়েবআরটিসি টপোলজিস এবং অবকাঠামো সম্পর্কে প্রচুর তথ্য সরবরাহ করে।

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

,

সংকেত কি?

সংকেত হ'ল যোগাযোগের সমন্বয় প্রক্রিয়া। একটি ওয়েবআরটিসি অ্যাপ্লিকেশন কল সেট আপ করার জন্য, এর ক্লায়েন্টদের নিম্নলিখিত তথ্য বিনিময় করতে হবে:

  • যোগাযোগ খোলার বা ঘনিষ্ঠ করতে ব্যবহৃত সেশন-নিয়ন্ত্রণ বার্তা
  • ত্রুটি বার্তা
  • মিডিয়া মেটাডেটা, যেমন কোডেকস, কোডেক সেটিংস, ব্যান্ডউইথ এবং মিডিয়া প্রকার
  • সুরক্ষিত সংযোগ স্থাপন করতে ব্যবহৃত মূল ডেটা
  • নেটওয়ার্ক ডেটা, যেমন একটি হোস্টের আইপি ঠিকানা এবং পোর্ট হিসাবে বাইরের বিশ্ব দ্বারা দেখা

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

সিগন্যালিং কেন ওয়েবআরটিসি দ্বারা সংজ্ঞায়িত করা হয় না?

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

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

জেএসইপি আর্কিটেকচার ডায়াগ্রাম
জেএসইপি আর্কিটেকচার

জেএসইপি -র অফার এবং উত্তরের সহকর্মীদের মধ্যে বিনিময় প্রয়োজন, উপরে উল্লিখিত মিডিয়া মেটাডেটা। অফার এবং উত্তরগুলি সেশন বিবরণ প্রোটোকল (এসডিপি) ফর্ম্যাটে যোগাযোগ করা হয়, যা এর মতো দেখায়:

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

এই সমস্ত এসডিপি গাব্বলডিগুক আসলে কী বোঝায় তা জানতে চান? ইন্টারনেট ইঞ্জিনিয়ারিং টাস্ক ফোর্স (আইইটিএফ) উদাহরণগুলি একবার দেখুন।

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

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

RTCPeerConnection হ'ল সমবয়সীদের মধ্যে সংযোগ তৈরি করতে এবং অডিও এবং ভিডিও যোগাযোগের জন্য ওয়েবআরটিসি অ্যাপ্লিকেশন দ্বারা ব্যবহৃত এপিআই।

এই প্রক্রিয়াটি শুরু করার জন্য, RTCPeerConnection দুটি কাজ রয়েছে:

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

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

কল্পনা করুন অ্যালিস ইভকে কল করার চেষ্টা করছে । এখানে তার সমস্ত গৌরব বিশদটিতে সম্পূর্ণ অফার/উত্তর প্রক্রিয়া রয়েছে:

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

অ্যালিস এবং ইভকেও নেটওয়ার্কের তথ্য বিনিময় করতে হবে। "সন্ধানকারী প্রার্থীদের" অভিব্যক্তিটি আইসিই কাঠামো ব্যবহার করে নেটওয়ার্ক ইন্টারফেস এবং পোর্টগুলি সন্ধানের প্রক্রিয়াটিকে বোঝায়।

  1. অ্যালিস onicecandidate হ্যান্ডলারের সাথে একটি RTCPeerConnection অবজেক্ট তৈরি করে।
  2. নেটওয়ার্ক প্রার্থীরা উপলব্ধ হয়ে গেলে হ্যান্ডলারটিকে বলা হয়।
  3. হ্যান্ডলারে, অ্যালিস তাদের সিগন্যালিং চ্যানেলের মাধ্যমে প্রাক্কালে স্ট্রিংফাইড প্রার্থীদের ডেটা প্রেরণ করে।
  4. ইভটি যখন অ্যালিসের কাছ থেকে প্রার্থী বার্তা পায়, তখন তিনি রিমোট পিয়ারের বিবরণে প্রার্থী যুক্ত করতে addIceCandidate() কল করেন।

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

সিগন্যালিংয়ের জন্য কোড ওয়েবআরটিসি

নিম্নলিখিত কোড স্নিপেট একটি ডাব্লু 3 সি কোড উদাহরণ যা সম্পূর্ণ সংকেত প্রক্রিয়াটির সংক্ষিপ্তসার করে। কোডটি কিছু সিগন্যালিং মেকানিজমের অস্তিত্ব ধরে নিয়েছে, 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);
  }
};

অফার/উত্তর এবং প্রার্থী-এক্সচেঞ্জ প্রক্রিয়াগুলি ক্রিয়াকলাপ দেখতে, সিম্পল.ইনফো আরটিসিপিয়ার সংযোগ দেখুন এবং একক পৃষ্ঠার ভিডিও চ্যাট উদাহরণের জন্য কনসোল লগটি দেখুন। আপনি যদি আরও চান তবে গুগল ক্রোমে // ওয়েবআরটিসি-ইন্টারনালস পৃষ্ঠা বা অপেরা: // অপেরাতে ওয়েবআরটিসি-ইন্টারনালস পৃষ্ঠা থেকে ওয়েবআরটিসি সিগন্যালিং এবং পরিসংখ্যানগুলির একটি সম্পূর্ণ ডাম্প ডাউনলোড করুন।

পিয়ার আবিষ্কার

এটি জিজ্ঞাসা করার অভিনব উপায়, "আমি কীভাবে কারও সাথে কথা বলতে পারি?"

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

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

আপনি কীভাবে একটি সংকেত পরিষেবা তৈরি করতে পারেন?

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

ধন্যবাদ সিগন্যালিং বার্তাগুলি ছোট এবং বেশিরভাগ কলের শুরুতে বিনিময় হয়। একটি ভিডিও চ্যাট সেশনের জন্য এডিআর.টি.সি.র সাথে পরীক্ষার ক্ষেত্রে, প্রায় 10 কেবি-র সমস্ত বার্তার জন্য মোট আকারের সাথে সিগন্যালিং পরিষেবা দ্বারা মোট 30-45 বার্তাগুলি পরিচালনা করা হয়েছিল।

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

সার্ভার থেকে ক্লায়েন্টের কাছে বার্তাগুলি চাপুন

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

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

WebSocket is a more-natural solution, designed for full duplex client–server communication - messages that can flow in both directions at the same time. One advantage of a signaling service built with pure WebSocket or server-sent events ( EventSource ) is that the backend for these APIs can be implemented on a variety of web frameworks common to most web-hosting packages for languages such as PHP, Python, and Ruby.

All modern browsers except Opera Mini support WebSocket and, more importantly, all browsers that support WebRTC also support WebSocket, both on desktop and mobile. TLS should be used for all connections to ensure messages cannot be intercepted unencrypted and also to reduce problems with proxy traversal . (For more information about WebSocket and proxy traversal see the WebRTC chapter in Ilya Grigorik's High Performance Browser Networking .)

It is also possible to handle signaling by getting WebRTC clients to poll a messaging server repeatedly through Ajax, but that leads to a lot of redundant network requests, which is especially problematic for mobile devices. Even after a session has been established, peers need to poll for signaling messages in case of changes or session termination by other peers. The WebRTC Book app example takes this option with some optimizations for polling frequency.

Scale signaling

Although a signaling service consumes relatively little bandwidth and CPU per client, signaling servers for a popular app may have to handle a lot of messages from different locations with high levels of concurrency. WebRTC apps that get a lot of traffic need signaling servers able to handle considerable load. You don't go into detail here, but there are a number of options for high-volume, high-performance messaging, including the following:

  • eXtensible Messaging and Presence Protocol (XMPP), originally known as Jabber-a protocol developed for instant messaging that can be used for signaling (Server implementations include ejabberd and Openfire . JavaScript clients, such as Strophe.js , use BOSH to emulate bidirectional streaming, but for various reasons , BOSH may not be as efficient as WebSocket and, for the same reasons, may not scale well.) (On a tangent, Jingle is an XMPP extension to enable voice and video. The WebRTC project uses network and transport components from the libjingle library - a C++ implementation of Jingle.)

  • Open source libraries, such as ZeroMQ (as used by TokBox for their Rumour service) and OpenMQ ( NullMQ applies ZeroMQ concepts to web platforms using the STOMP protocol over WebSocket.)

  • Commercial cloud-messaging platforms that use WebSocket (though they may fall back to long polling), such as Pusher , Kaazing , and PubNub (PubNub also has an API for WebRTC .)

  • Commercial WebRTC platforms, such as vLine

(Developer Phil Leggetter's Real-Time Web Technologies Guide provides a comprehensive list of messaging services and libraries.)

Build a signaling service with Socket.io on Node

The following is code for a simple web app that uses a signaling service built with Socket.io on Node . The design of Socket.io makes it simple to build a service to exchange messages and Socket.io is particularly suited to WebRTC signaling because of its built-in concept of rooms. This example is not designed to scale as a production-grade signaling service, but is simple to understand for a relatively small number of users.

Socket.io uses WebSocket with fallbacks: AJAX long polling, AJAX multipart streaming, Forever Iframe, and JSONP polling. It has been ported to various backends, but is perhaps best known for its Node version used in this example.

There's no WebRTC in this example. It's designed only to show how to build signaling into a web app. View the console log to see what's happening as clients join a room and exchange messages. This WebRTC codelab gives step-by-step instructions for how to integrate this into a complete WebRTC video chat app.

Here is the client 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>

Here's the JavaScript file main.js referenced in the client:

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

Here's the complete server app:

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

  });

});

(You don't need to learn about node-static for this. It just happens to be used in this example.)

To run this app on localhost, you need to have Node, Socket.IO, and node-static installed. Node can be downloaded from Node.js (installation is straightforward and quick). To install Socket.IO and node-static, run Node Package Manager from a terminal in your app directory:

npm install socket.io
npm install node-static

To start the server, run the following command from a terminal in your app directory:

node server.js

From your browser, open localhost:2013 . Open a new tab or window in any browser and open localhost:2013 again. To see what's happening, check the console. In Chrome and Opera, you can access the console through Google Chrome Developer Tools with Ctrl+Shift+J (or Command+Option+J on Mac).

Whatever approach you choose for signaling, your backend and client app - at the very least - need to provide services similar to this example.

Signaling gotchas

  • RTCPeerConnection won't start gathering candidates until setLocalDescription() is called. This is mandated in the JSEP IETF draft .
  • Take advantage of Trickle ICE. Call addIceCandidate() as soon as candidates arrive.

Readymade signaling servers

If you don't want to roll your own, there are several WebRTC signaling servers available, which use Socket.IO like the previous example and are integrated with WebRTC client JavaScript libraries:

If you don't want to write any code at all, complete commercial WebRTC platforms are available from companies, such as vLine , OpenTok , and Asterisk .

For the record, Ericsson built a signaling server using PHP on Apache in the early days of WebRTC. This is now somewhat obsolete, but it's worth looking at the code if you're considering something similar.

Signaling security

"Security is the art of making nothing happen."

সালমান রুশদি

Encryption is mandatory for all WebRTC components.

However, signaling mechanisms aren't defined by WebRTC standards, so it's up to you to make signaling secure. If an attacker manages to hijack signaling, they can stop sessions, redirect connections, and record, alter, or inject content.

The most important factor in securing signaling is to use secure protocols - HTTPS and WSS (for example, TLS) - which ensure that messages cannot be intercepted unencrypted. Also, be careful not to broadcast signaling messages in a way that they can be accessed by other callers using the same signaling server.

After signaling: Use ICE to cope with NATs and firewalls

For metadata signaling, WebRTC apps use an intermediary server, but for actual media and data streaming once a session is established, RTCPeerConnection attempts to connect clients directly or peer-to-peer.

In a simpler world, every WebRTC endpoint would have a unique address that it could exchange with other peers in order to communicate directly.

Simple peer to peer connection
A world without NATs and firewalls

In reality, most devices live behind one or more layers of NAT , some have antivirus software that blocks certain ports and protocols, and many are behind proxies and corporate firewalls. A firewall and NAT may in fact be implemented by the same device, such as a home WIFI router.

Peers behind NATs and firewalls
বাস্তব জগত

WebRTC apps can use the ICE framework to overcome the complexities of real-world networking. To enable this to happen, your app must pass ICE server URLs to RTCPeerConnection , as described in this article.

ICE tries to find the best path to connect peers. It tries all possibilities in parallel and chooses the most efficient option that works. ICE first tries to make a connection using the host address obtained from a device's operating system and network card. If that fails (which it will for devices behind NATs), ICE obtains an external address using a STUN server and, if that fails, traffic is routed through a TURN relay server.

In other words, a STUN server is used to get an external network address and TURN servers are used to relay traffic if direct (peer-to-peer) connection fails.

Every TURN server supports STUN. A TURN server is a STUN server with additional built-in relaying functionality. ICE also copes with the complexities of NAT setups. In reality, NAT hole-punching may require more than just a public IP:port address.

URLs for STUN and/or TURN servers are (optionally) specified by a WebRTC app in the iceServers configuration object that is the first argument to the RTCPeerConnection constructor. For appr.tc , that value looks like this:

{
  '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'
    }
  ]
}

Once RTCPeerConnection has that information, the ICE magic happens automatically. RTCPeerConnection uses the ICE framework to work out the best path between peers, working with STUN and TURN servers as necessary.

STUN

NATs provide a device with an IP address for use within a private local network, but this address can't be used externally. Without a public address, there's no way for WebRTC peers to communicate. To get around this problem, WebRTC uses STUN .

STUN servers live on the public internet and have one simple task - check the IP:port address of an incoming request (from an app running behind a NAT) and send that address back as a response. In other words, the app uses a STUN server to discover its IP:port from a public perspective. This process enables a WebRTC peer to get a publicly accessible address for itself and then pass it to another peer through a signaling mechanism in order to set up a direct link. (In practice, different NATs work in different ways and there may be multiple NAT layers, but the principle is still the same.)

STUN servers don't have to do much or remember much, so relatively low-spec STUN servers can handle a large number of requests.

Most WebRTC calls successfully make a connection using STUN - 86% according to Webrtcstats.com , though this can be less for calls between peers behind firewalls and complex NAT configurations.

Peer to peer connection using a STUN server
Using STUN servers to get public IP:port addresses

ঘুরিয়ে

RTCPeerConnection tries to set up direct communication between peers over UDP. If that fails, RTCPeerConnection resorts to TCP. If that fails, TURN servers can be used as a fallback, relaying data between endpoints.

Just to reiterate, TURN is used to relay audio, video, and data streaming between peers, not signaling data!

TURN servers have public addresses, so they can be contacted by peers even if the peers are behind firewalls or proxies. TURN servers have a conceptually simple task - to relay a stream. However, unlike STUN servers, they inherently consume a lot of bandwidth. In other words, TURN servers need to be beefier.

Peer to peer connection using a STUN server
The full Monty: STUN, TURN, and signaling

This diagram shows TURN in action. Pure STUN didn't succeed, so each peer resorts to using a TURN server.

Deploying STUN and TURN servers

For testing, Google runs a public STUN server, stun.l.google.com:19302, as used by appr.tc . For a production STUN/TURN service, use the rfc5766-turn-server. Source code for STUN and TURN servers is available on GitHub , where you can also find links to several sources of information about server installation. A VM image for Amazon Web Services is also available.

An alternative TURN server is restund, available as source code and also for AWS. Here are instructions for how to set up restund on Compute Engine.

  1. Open firewall as necessary for tcp=443, udp/tcp=3478.
  2. Create four instances, one for each public IP, Standard Ubuntu 12.06 image.
  3. Set up local firewall config (allow ANY from ANY).
  4. Install tools: shell sudo apt-get install make sudo apt-get install gcc
  5. Install libre from creytiv.com/re.html .
  6. Fetch restund from creytiv.com/restund.html and unpack./
  7. wget hancke.name/restund-auth.patch and apply with patch -p1 < restund-auth.patch .
  8. Run make , sudo make install for libre and restund.
  9. Adapt restund.conf to your needs (replace IP addresses and make sure it contains the same shared secret) and copy to /etc .
  10. Copy restund/etc/restund to /etc/init.d/ .
  11. Configure restund:
    1. Set LD_LIBRARY_PATH .
    2. Copy restund.conf to /etc/restund.conf .
    3. Set restund.conf to use the right 10. IP address.
  12. Run restund
  13. Test using stund client from remote machine: ./client IP:port

Beyond one-to-one: Multiparty WebRTC

You may also want to take a look at Justin Uberti's proposed IETF standard for a REST API for access to TURN Services .

It's easy to imagine use cases for media streaming that go beyond a simple one-to-one call. For example, video conferencing between a group of colleagues or a public event with one speaker and hundreds or millions of viewers.

A WebRTC app can use multiple RTCPeerConnections so that every endpoint connects to every other endpoint in a mesh configuration. This is the approach taken by apps, such as talky.io , and works remarkably well for a small handful of peers. Beyond that, processing and bandwidth consumption becomes excessive, especially for mobile clients.

Mesh: small N-way call
Full mesh topology: Everyone connected to everyone

Alternatively, a WebRTC app could choose one endpoint to distribute streams to all others in a star configuration. It would also be possible to run a WebRTC endpoint on a server and construct your own redistribution mechanism (a sample client app is provided by webrtc.org).

Since Chrome 31 and Opera 18, a MediaStream from one RTCPeerConnection can be used as the input for another. This can enable more flexible architectures because it enables a web app to handle call-routing by choosing which other peer to connect to. To see this in action, see WebRTC samples Peer connection relay and WebRTC samples Multiple peer connections .

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

A better option for a large number of endpoints is to use a Multipoint Control Unit (MCU). This is a server that works as a bridge to distribute media between a large number of participants. MCUs can cope with different resolutions, codecs, and frame rates in a video conference; handle transcoding; do selective stream forwarding; and mix or record audio and video. For multiparty calls, there are a number of issues to consider, particularly how to display multiple video inputs and mix audio from multiple sources. Cloud platforms, such as vLine , also attempt to optimize traffic routing.

It's possible to buy a complete MCU hardware package or build your own.

Rear view of Cisco MCU5300
The back of a Cisco MCU

Several open source MCU software options are available. For example, Licode (previously known as Lynckia) produces an open source MCU for WebRTC. OpenTok has Mantis .

Beyond browsers: VoIP, telephones, and messaging

The standardized nature of WebRTC makes it possible to establish communication between a WebRTC app running in a browser and a device or platform running on another communication platform, such as a telephone or a video-conferencing system.

SIP is a signaling protocol used by VoIP and video-conferencing systems. To enable communication between a WebRTC web app and a SIP client, such as a video-conferencing system, WebRTC needs a proxy server to mediate signaling. Signaling must flow through the gateway but, once communication has been established, SRTP traffic (video and audio) can flow directly peer to peer.

The Public Switched Telephone Network (PSTN) is the circuit-switched network of all "plain old" analog telephones. For calls between WebRTC web apps and telephones, traffic must go through a PSTN gateway. Likewise, WebRTC web apps need an intermediary XMPP server to communicate with Jingle endpoints such as IM clients. Jingle was developed by Google as an extension to XMPP to enable voice and video for messaging services. Current WebRTC implementations are based on the C++ libjingle library, an implementation of Jingle initially developed for Talk.

A number of apps, libraries, and platforms make use of WebRTC's ability to communicate with the outside world:

  • sipML5 : an open source JavaScript SIP client
  • jsSIP : JavaScript SIP library
  • Phono : open source JavaScript phone API built as a plugin
  • Zingaya : an embeddable phone widget
  • Twilio : voice and messaging
  • Uberconference : conferencing

The sipML5 developers have also built the webrtc2sip gateway. Tethr and Tropo have demonstrated a framework for disaster communications "in a briefcase" using an OpenBTS cell to enable communications between feature phones and computers through WebRTC. That's telephone communication without a carrier!

আরও জানুন

The WebRTC codelab provides step-by-step instructions for how to build a video and text chat app using a Socket.io signaling service running on Node.

Google I/O WebRTC presentation from 2013 with WebRTC tech lead, Justin Uberti

Chris Wilson's SFHTML5 presentation - Introduction to WebRTC Apps

The 350-page book WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web provides a lot of detail about data and signaling pathways, and includes a number of detailed network topology diagrams.

WebRTC and Signaling: What Two Years Has Taught Us - TokBox blog post about why leaving signaling out of the spec was a good idea

Ben Strong's A Practical Guide to Building WebRTC Apps provides a lot of information about WebRTC topologies and infrastructure.

The WebRTC chapter in Ilya Grigorik's High Performance Browser Networking goes deep into WebRTC architecture, use cases, and performance.

,

What is signaling?

Signaling is the process of coordinating communication. In order for a WebRTC app to set up a call, its clients need to exchange the following information:

  • Session-control messages used to open or close communication
  • ত্রুটি বার্তা
  • Media metadata, such as codecs, codec settings, bandwidth, and media types
  • Key data used to establish secure connections
  • Network data, such as a host's IP address and port as seen by the outside world

This signaling process needs a way for clients to pass messages back and forth. That mechanism is not implemented by the WebRTC APIs. আপনি নিজেই এটি নির্মাণ করতে হবে. Later in this article, you learn ways to build a signaling service. First, however, you need a little context.

Why is signaling not defined by WebRTC?

To avoid redundancy and to maximize compatibility with established technologies, signaling methods and protocols are not specified by WebRTC standards. This approach is outlined by the JavaScript Session Establishment Protocol (JSEP) :

JSEP's architecture also avoids a browser having to save state, that is, to function as a signaling state machine. This would be problematic if, for example, signaling data was lost each time a page was reloaded. Instead, signaling state can be saved on a server.

JSEP architecture diagram
JSEP architecture

JSEP requires the exchange between peers of offer and answer , the media metadata mentioned above. Offers and answers are communicated in Session Description Protocol (SDP) format, which look like this:

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

Want to know what all this SDP gobbledygook actually means? Take a look at the Internet Engineering Task Force (IETF) examples .

Bear in mind that WebRTC is designed so that the offer or answer can be tweaked before being set as the local or remote description by editing the values in the SDP text. For example, the preferAudioCodec() function in appr.tc can be used to set the default codec and bitrate. SDP is somewhat painful to manipulate with JavaScript and there is discussion about whether future versions of WebRTC should use JSON instead, but there are some advantages to sticking with SDP.

RTCPeerConnection API and signaling: Offer, answer, and candidate

RTCPeerConnection is the API used by WebRTC apps to create a connection between peers, and communicate audio and video.

To initialize this process, RTCPeerConnection has two tasks:

  • Ascertain local media conditions, such as resolution and codec capabilities. This is the metadata used for the offer-and-answer mechanism.
  • Get potential network addresses for the app's host, known as candidates .

Once this local data has been ascertained, it must be exchanged through a signaling mechanism with the remote peer.

Imagine Alice is trying to call Eve . Here's the full offer/answer mechanism in all its gory detail:

  1. Alice creates an RTCPeerConnection object.
  2. Alice creates an offer (an SDP session description) with the RTCPeerConnection createOffer() method.
  3. Alice calls setLocalDescription() with her offer.
  4. Alice stringifies the offer and uses a signaling mechanism to send it to Eve.
  5. Eve calls setRemoteDescription() with Alice's offer, so that her RTCPeerConnection knows about Alice's setup.
  6. Eve calls createAnswer() and the success callback for this is passed a local session description - Eve's answer.
  7. Eve sets her answer as the local description by calling setLocalDescription() .
  8. Eve then uses the signaling mechanism to send her stringified answer to Alice.
  9. Alice sets Eve's answer as the remote session description using setRemoteDescription() .

Alice and Eve also need to exchange network information. The expression "finding candidates" refers to the process of finding network interfaces and ports using the ICE framework .

  1. Alice creates an RTCPeerConnection object with an onicecandidate handler.
  2. The handler is called when network candidates become available.
  3. In the handler, Alice sends stringified candidate data to Eve through their signaling channel.
  4. When Eve gets a candidate message from Alice, she calls addIceCandidate() to add the candidate to the remote peer description.

JSEP supports ICE Candidate Trickling , which allows the caller to incrementally provide candidates to the callee after the initial offer, and for the callee to begin acting on the call and set up a connection without waiting for all candidates to arrive.

Code WebRTC for signaling

The following code snippet is a W3C code example that summarizes the complete signaling process. The code assumes the existence of some signaling mechanism, SignalingChannel . Signaling is discussed in greater detail later.

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

To see the offer/answer and candidate-exchange processes in action, see simpl.info RTCPeerConnection and look at the console log for a single-page video chat example. If you want more, download a complete dump of WebRTC signaling and stats from the about://webrtc-internals page in Google Chrome or the opera://webrtc-internals page in Opera.

পিয়ার আবিষ্কার

This is a fancy way of asking, "How do I find someone to talk to?"

For telephone calls, you have telephone numbers and directories. For online video chat and messaging, you need identity and presence management systems, and a means for users to initiate sessions. WebRTC apps need a way for clients to signal to each other that they want to start or join a call.

Peer discovery mechanisms are not defined by WebRTC and you don't go into the options here. The process can be as simple as emailing or messaging a URL. For video chat apps, such as Talky , tawk.to and Browser Meeting , you invite people to a call by sharing a custom link. Developer Chris Ball built an intriguing serverless-webrtc experiment that enables WebRTC call participants to exchange metadata by any messaging service they like, such as IM, email, or homing pigeon.

How can you build a signaling service?

To reiterate, signaling protocols and mechanisms are not defined by WebRTC standards. Whatever you choose, you need an intermediary server to exchange signaling messages and app data between clients. Sadly, a web app cannot simply shout into the internet, "Connect me to my friend!"

Thankfully signaling messages are small and mostly exchanged at the start of a call. In testing with appr.tc for a video chat session, a total of around 30-45 messages were handled by the signaling service with a total size for all messages of around 10KB.

As well as being relatively undemanding in terms of bandwidth, WebRTC signaling services don't consume much processing or memory because they only need to relay messages and retain a small amount of session state data, such as which clients are connected.

Push messages from the server to the client

A message service for signaling needs to be bidirectional: client to server and server to client. Bidirectional communication goes against the HTTP client/server request/response model, but various hacks such as long polling have been developed over many years in order to push data from a service running on a web server to a web app running in a browser.

More recently, the EventSource API has been widely implemented . This enables server-sent events - data sent from a web server to a browser client through HTTP. EventSource is designed for one-way messaging, but it can be used in combination with XHR to build a service for exchanging signaling messages. A signaling service passes a message from a caller, delivered by XHR request, by pushing it through EventSource to the callee.

WebSocket is a more-natural solution, designed for full duplex client–server communication - messages that can flow in both directions at the same time. One advantage of a signaling service built with pure WebSocket or server-sent events ( EventSource ) is that the backend for these APIs can be implemented on a variety of web frameworks common to most web-hosting packages for languages such as PHP, Python, and Ruby.

All modern browsers except Opera Mini support WebSocket and, more importantly, all browsers that support WebRTC also support WebSocket, both on desktop and mobile. TLS should be used for all connections to ensure messages cannot be intercepted unencrypted and also to reduce problems with proxy traversal . (For more information about WebSocket and proxy traversal see the WebRTC chapter in Ilya Grigorik's High Performance Browser Networking .)

It is also possible to handle signaling by getting WebRTC clients to poll a messaging server repeatedly through Ajax, but that leads to a lot of redundant network requests, which is especially problematic for mobile devices. Even after a session has been established, peers need to poll for signaling messages in case of changes or session termination by other peers. The WebRTC Book app example takes this option with some optimizations for polling frequency.

Scale signaling

Although a signaling service consumes relatively little bandwidth and CPU per client, signaling servers for a popular app may have to handle a lot of messages from different locations with high levels of concurrency. WebRTC apps that get a lot of traffic need signaling servers able to handle considerable load. You don't go into detail here, but there are a number of options for high-volume, high-performance messaging, including the following:

  • eXtensible Messaging and Presence Protocol (XMPP), originally known as Jabber-a protocol developed for instant messaging that can be used for signaling (Server implementations include ejabberd and Openfire . JavaScript clients, such as Strophe.js , use BOSH to emulate bidirectional streaming, but for various reasons , BOSH may not be as efficient as WebSocket and, for the same reasons, may not scale well.) (On a tangent, Jingle is an XMPP extension to enable voice and video. The WebRTC project uses network and transport components from the libjingle library - a C++ implementation of Jingle.)

  • Open source libraries, such as ZeroMQ (as used by TokBox for their Rumour service) and OpenMQ ( NullMQ applies ZeroMQ concepts to web platforms using the STOMP protocol over WebSocket.)

  • Commercial cloud-messaging platforms that use WebSocket (though they may fall back to long polling), such as Pusher , Kaazing , and PubNub (PubNub also has an API for WebRTC .)

  • Commercial WebRTC platforms, such as vLine

(Developer Phil Leggetter's Real-Time Web Technologies Guide provides a comprehensive list of messaging services and libraries.)

Build a signaling service with Socket.io on Node

The following is code for a simple web app that uses a signaling service built with Socket.io on Node . The design of Socket.io makes it simple to build a service to exchange messages and Socket.io is particularly suited to WebRTC signaling because of its built-in concept of rooms. This example is not designed to scale as a production-grade signaling service, but is simple to understand for a relatively small number of users.

Socket.io uses WebSocket with fallbacks: AJAX long polling, AJAX multipart streaming, Forever Iframe, and JSONP polling. It has been ported to various backends, but is perhaps best known for its Node version used in this example.

There's no WebRTC in this example. It's designed only to show how to build signaling into a web app. View the console log to see what's happening as clients join a room and exchange messages. This WebRTC codelab gives step-by-step instructions for how to integrate this into a complete WebRTC video chat app.

Here is the client 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>

Here's the JavaScript file main.js referenced in the client:

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

Here's the complete server app:

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

  });

});

(You don't need to learn about node-static for this. It just happens to be used in this example.)

To run this app on localhost, you need to have Node, Socket.IO, and node-static installed. Node can be downloaded from Node.js (installation is straightforward and quick). To install Socket.IO and node-static, run Node Package Manager from a terminal in your app directory:

npm install socket.io
npm install node-static

To start the server, run the following command from a terminal in your app directory:

node server.js

From your browser, open localhost:2013 . Open a new tab or window in any browser and open localhost:2013 again. To see what's happening, check the console. In Chrome and Opera, you can access the console through Google Chrome Developer Tools with Ctrl+Shift+J (or Command+Option+J on Mac).

Whatever approach you choose for signaling, your backend and client app - at the very least - need to provide services similar to this example.

Signaling gotchas

  • RTCPeerConnection won't start gathering candidates until setLocalDescription() is called. This is mandated in the JSEP IETF draft .
  • Take advantage of Trickle ICE. Call addIceCandidate() as soon as candidates arrive.

Readymade signaling servers

If you don't want to roll your own, there are several WebRTC signaling servers available, which use Socket.IO like the previous example and are integrated with WebRTC client JavaScript libraries:

If you don't want to write any code at all, complete commercial WebRTC platforms are available from companies, such as vLine , OpenTok , and Asterisk .

For the record, Ericsson built a signaling server using PHP on Apache in the early days of WebRTC. This is now somewhat obsolete, but it's worth looking at the code if you're considering something similar.

Signaling security

"Security is the art of making nothing happen."

সালমান রুশদি

Encryption is mandatory for all WebRTC components.

However, signaling mechanisms aren't defined by WebRTC standards, so it's up to you to make signaling secure. If an attacker manages to hijack signaling, they can stop sessions, redirect connections, and record, alter, or inject content.

The most important factor in securing signaling is to use secure protocols - HTTPS and WSS (for example, TLS) - which ensure that messages cannot be intercepted unencrypted. Also, be careful not to broadcast signaling messages in a way that they can be accessed by other callers using the same signaling server.

After signaling: Use ICE to cope with NATs and firewalls

For metadata signaling, WebRTC apps use an intermediary server, but for actual media and data streaming once a session is established, RTCPeerConnection attempts to connect clients directly or peer-to-peer.

In a simpler world, every WebRTC endpoint would have a unique address that it could exchange with other peers in order to communicate directly.

Simple peer to peer connection
A world without NATs and firewalls

In reality, most devices live behind one or more layers of NAT , some have antivirus software that blocks certain ports and protocols, and many are behind proxies and corporate firewalls. A firewall and NAT may in fact be implemented by the same device, such as a home WIFI router.

Peers behind NATs and firewalls
বাস্তব জগত

WebRTC apps can use the ICE framework to overcome the complexities of real-world networking. To enable this to happen, your app must pass ICE server URLs to RTCPeerConnection , as described in this article.

ICE tries to find the best path to connect peers. It tries all possibilities in parallel and chooses the most efficient option that works. ICE first tries to make a connection using the host address obtained from a device's operating system and network card. If that fails (which it will for devices behind NATs), ICE obtains an external address using a STUN server and, if that fails, traffic is routed through a TURN relay server.

In other words, a STUN server is used to get an external network address and TURN servers are used to relay traffic if direct (peer-to-peer) connection fails.

Every TURN server supports STUN. A TURN server is a STUN server with additional built-in relaying functionality. ICE also copes with the complexities of NAT setups. In reality, NAT hole-punching may require more than just a public IP:port address.

URLs for STUN and/or TURN servers are (optionally) specified by a WebRTC app in the iceServers configuration object that is the first argument to the RTCPeerConnection constructor. For appr.tc , that value looks like this:

{
  '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'
    }
  ]
}

Once RTCPeerConnection has that information, the ICE magic happens automatically. RTCPeerConnection uses the ICE framework to work out the best path between peers, working with STUN and TURN servers as necessary.

STUN

NATs provide a device with an IP address for use within a private local network, but this address can't be used externally. Without a public address, there's no way for WebRTC peers to communicate. To get around this problem, WebRTC uses STUN .

STUN servers live on the public internet and have one simple task - check the IP:port address of an incoming request (from an app running behind a NAT) and send that address back as a response. In other words, the app uses a STUN server to discover its IP:port from a public perspective. This process enables a WebRTC peer to get a publicly accessible address for itself and then pass it to another peer through a signaling mechanism in order to set up a direct link. (In practice, different NATs work in different ways and there may be multiple NAT layers, but the principle is still the same.)

STUN servers don't have to do much or remember much, so relatively low-spec STUN servers can handle a large number of requests.

Most WebRTC calls successfully make a connection using STUN - 86% according to Webrtcstats.com , though this can be less for calls between peers behind firewalls and complex NAT configurations.

Peer to peer connection using a STUN server
Using STUN servers to get public IP:port addresses

ঘুরিয়ে

RTCPeerConnection tries to set up direct communication between peers over UDP. If that fails, RTCPeerConnection resorts to TCP. If that fails, TURN servers can be used as a fallback, relaying data between endpoints.

Just to reiterate, TURN is used to relay audio, video, and data streaming between peers, not signaling data!

TURN servers have public addresses, so they can be contacted by peers even if the peers are behind firewalls or proxies. TURN servers have a conceptually simple task - to relay a stream. However, unlike STUN servers, they inherently consume a lot of bandwidth. In other words, TURN servers need to be beefier.

Peer to peer connection using a STUN server
The full Monty: STUN, TURN, and signaling

This diagram shows TURN in action. Pure STUN didn't succeed, so each peer resorts to using a TURN server.

Deploying STUN and TURN servers

For testing, Google runs a public STUN server, stun.l.google.com:19302, as used by appr.tc . For a production STUN/TURN service, use the rfc5766-turn-server. Source code for STUN and TURN servers is available on GitHub , where you can also find links to several sources of information about server installation. A VM image for Amazon Web Services is also available.

An alternative TURN server is restund, available as source code and also for AWS. Here are instructions for how to set up restund on Compute Engine.

  1. Open firewall as necessary for tcp=443, udp/tcp=3478.
  2. Create four instances, one for each public IP, Standard Ubuntu 12.06 image.
  3. Set up local firewall config (allow ANY from ANY).
  4. Install tools: shell sudo apt-get install make sudo apt-get install gcc
  5. Install libre from creytiv.com/re.html .
  6. Fetch restund from creytiv.com/restund.html and unpack./
  7. wget hancke.name/restund-auth.patch and apply with patch -p1 < restund-auth.patch .
  8. Run make , sudo make install for libre and restund.
  9. Adapt restund.conf to your needs (replace IP addresses and make sure it contains the same shared secret) and copy to /etc .
  10. Copy restund/etc/restund to /etc/init.d/ .
  11. Configure restund:
    1. Set LD_LIBRARY_PATH .
    2. Copy restund.conf to /etc/restund.conf .
    3. Set restund.conf to use the right 10. IP address.
  12. Run restund
  13. Test using stund client from remote machine: ./client IP:port

Beyond one-to-one: Multiparty WebRTC

You may also want to take a look at Justin Uberti's proposed IETF standard for a REST API for access to TURN Services .

It's easy to imagine use cases for media streaming that go beyond a simple one-to-one call. For example, video conferencing between a group of colleagues or a public event with one speaker and hundreds or millions of viewers.

A WebRTC app can use multiple RTCPeerConnections so that every endpoint connects to every other endpoint in a mesh configuration. This is the approach taken by apps, such as talky.io , and works remarkably well for a small handful of peers. Beyond that, processing and bandwidth consumption becomes excessive, especially for mobile clients.

Mesh: small N-way call
Full mesh topology: Everyone connected to everyone

Alternatively, a WebRTC app could choose one endpoint to distribute streams to all others in a star configuration. It would also be possible to run a WebRTC endpoint on a server and construct your own redistribution mechanism (a sample client app is provided by webrtc.org).

Since Chrome 31 and Opera 18, a MediaStream from one RTCPeerConnection can be used as the input for another. This can enable more flexible architectures because it enables a web app to handle call-routing by choosing which other peer to connect to. To see this in action, see WebRTC samples Peer connection relay and WebRTC samples Multiple peer connections .

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

A better option for a large number of endpoints is to use a Multipoint Control Unit (MCU). This is a server that works as a bridge to distribute media between a large number of participants. MCUs can cope with different resolutions, codecs, and frame rates in a video conference; handle transcoding; do selective stream forwarding; and mix or record audio and video. For multiparty calls, there are a number of issues to consider, particularly how to display multiple video inputs and mix audio from multiple sources. Cloud platforms, such as vLine , also attempt to optimize traffic routing.

It's possible to buy a complete MCU hardware package or build your own.

Rear view of Cisco MCU5300
The back of a Cisco MCU

Several open source MCU software options are available. For example, Licode (previously known as Lynckia) produces an open source MCU for WebRTC. OpenTok has Mantis .

Beyond browsers: VoIP, telephones, and messaging

The standardized nature of WebRTC makes it possible to establish communication between a WebRTC app running in a browser and a device or platform running on another communication platform, such as a telephone or a video-conferencing system.

SIP is a signaling protocol used by VoIP and video-conferencing systems. To enable communication between a WebRTC web app and a SIP client, such as a video-conferencing system, WebRTC needs a proxy server to mediate signaling. Signaling must flow through the gateway but, once communication has been established, SRTP traffic (video and audio) can flow directly peer to peer.

The Public Switched Telephone Network (PSTN) is the circuit-switched network of all "plain old" analog telephones. For calls between WebRTC web apps and telephones, traffic must go through a PSTN gateway. Likewise, WebRTC web apps need an intermediary XMPP server to communicate with Jingle endpoints such as IM clients. Jingle was developed by Google as an extension to XMPP to enable voice and video for messaging services. Current WebRTC implementations are based on the C++ libjingle library, an implementation of Jingle initially developed for Talk.

A number of apps, libraries, and platforms make use of WebRTC's ability to communicate with the outside world:

  • sipML5 : an open source JavaScript SIP client
  • jsSIP : JavaScript SIP library
  • Phono : open source JavaScript phone API built as a plugin
  • Zingaya : an embeddable phone widget
  • Twilio : voice and messaging
  • Uberconference : conferencing

The sipML5 developers have also built the webrtc2sip gateway. Tethr and Tropo have demonstrated a framework for disaster communications "in a briefcase" using an OpenBTS cell to enable communications between feature phones and computers through WebRTC. That's telephone communication without a carrier!

আরও জানুন

The WebRTC codelab provides step-by-step instructions for how to build a video and text chat app using a Socket.io signaling service running on Node.

Google I/O WebRTC presentation from 2013 with WebRTC tech lead, Justin Uberti

Chris Wilson's SFHTML5 presentation - Introduction to WebRTC Apps

The 350-page book WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web provides a lot of detail about data and signaling pathways, and includes a number of detailed network topology diagrams.

WebRTC and Signaling: What Two Years Has Taught Us - TokBox blog post about why leaving signaling out of the spec was a good idea

Ben Strong's A Practical Guide to Building WebRTC Apps provides a lot of information about WebRTC topologies and infrastructure.

The WebRTC chapter in Ilya Grigorik's High Performance Browser Networking goes deep into WebRTC architecture, use cases, and performance.