WebRTC کی پیمائش کیسے کریں: سگنلنگ، NAT ٹراورسل، اور میش/SFU/MCU ٹریڈ آف

ویب ریئل ٹائم کمیونیکیشنز (یا WebRTC) ایک کھلا معیاری براؤزر ہے جو آڈیو، ویڈیو اور ڈیٹا کو براہ راست ایک دوسرے کو منتقل کرنے کے لیے استعمال ہوتا ہے۔ کوئی پلگ ان نہیں ہے، کوئی مقامی ایپس نہیں ہیں، APIs سے آگے کچھ نہیں ہے جو تمام براؤزر پہلے سے فراہم کرتے ہیں۔

WebRTC میڈیا کے راستوں سے متعلق ہے۔ ایک بار جب دونوں ساتھی ایک دوسرے کو ڈھونڈ لیتے ہیں، کوڈیک مذاکرات سے لے کر انکوڈنگ سے لے کر ٹرانسمیشن تک سب کچھ سنبھال لیا جاتا ہے۔ جس چیز کا ہم کبھی احاطہ نہیں کرتے وہ دریافت کا حصہ ہے۔

یہ مضمون تین APIs پر بحث کرتا ہے جو تفصیلات بناتے ہیں، کیوں سگنلنگ اور NAT ٹراورسل تصریح سے باہر موجود ہیں، بڑے پیمانے پر سگنلنگ سرورز کو لاگو کرنا، اور میش/SFU/MCU ٹریڈ آف جو یہ طے کرتے ہیں کہ میڈیا کو کیسے پیمانہ کیا جائے۔

انڈیکس

بلڈنگ بلاکس: تین APIs، ایک گیپ

WebRTC ایسا کرنے کے لیے تین JavaScript API کو ظاہر کرتا ہے:

• RTCPeerConnection یہ دو ساتھیوں کے درمیان کوڈیکس پر بات چیت کرتا ہے اور جب کوئی کنکشن موجود ہوتا ہے تو میڈیا اسٹریمز کی انکوڈنگ، ڈی کوڈنگ اور ٹرانسمیشن کو ہینڈل کرتا ہے۔

• MediaStream یہ آپ جو بھیج رہے ہیں اسے لیتا ہے اور آپ کے ویب کیم یا مائکروفون تک رسائی کو لپیٹ دیتا ہے۔

• RTCDataChannel یہ کسی بھی ایسی چیز کے لیے میڈیا کنکشن کے ساتھ چلتا ہے جو آڈیو یا ویڈیو نہیں ہے، چیٹ میسجز، فائل چنکس، گیم اسٹیٹ، یا ایپلیکیشن ڈیٹا جس کے لیے کوڈیک کی ضرورت نہیں ہے۔

ان میں سے کوئی بھی نہیں جانتا کہ اپنے طور پر دور دراز کے ساتھیوں کو کیسے تلاش کرنا ہے۔ یہ وہی ہے جسے WebRTC مکمل طور پر چھوڑ دیتا ہے۔

سگنل بھیجنا اور تجاویز/جوابات کا تبادلہ کرنا

اس سے پہلے کہ دو ساتھی میڈیا کا تبادلہ کر سکیں، انہیں کوڈیک، نیٹ ورک کی معلومات، میڈیا کی قسم، اور سیشن ڈسکرپشن پروٹوکول (SDP) میں انکوڈ کردہ خصوصیات کی تفصیل کا تبادلہ کرنا چاہیے۔

WebRTC اس تفصیل کو ساتھیوں کے درمیان منتقل کرنے کے لیے کوئی طریقہ کار فراہم نہیں کرتا ہے۔ یہ سگنلنگ ہے، اور قیاس آرائی جان بوجھ کر اس کو چھوڑ دیتا ہے جو اس کے اوپر بناتا ہے، عام طور پر WebSockets یا HTTP طویل پولنگ کے ذریعے۔

تبادلہ بذات خود ایک مقررہ شکل کی پیروی کرتا ہے: کال شروع کرنے والے ہم مرتبہ کی طرف سے تجویز اور اسے موصول کرنے والے ہم مرتبہ کی طرف سے جواب۔

// Peer A: create and send the offer
const pc = new RTCPeerConnection({ iceServers });
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
signalingChannel.send({ type: 'offer', sdp: pc.localDescription });

// Peer B: accept the offer, respond with an answer
await pc.setRemoteDescription(offerFromA);
const answer = await pc.createAnswer();
await pc.setLocalDescription(answer);
signalingChannel.send({ type: 'answer', sdp: pc.localDescription });

// Peer A: complete the handshake
await pc.setRemoteDescription(answerFromB);

setLocalDescription اور setRemoteDescription یہاں صرف دو کالیں ہیں جو کوئی حقیقی کام کرتی ہیں: باقی سب کچھ صرف ایک ہم مرتبہ کے سگنلنگ کنکشن سے دوسرے کے ساتھ SDP بلاب لا رہا ہے۔

NAT ٹراورسل: ICE، STUN، اور ٹرن

ایک SDP ایکسچینج ہر ایک کو بتاتا ہے کہ دوسرا کیا سپورٹ کرتا ہے۔ زیادہ تر ڈیوائسز آپ کو یہ نہیں بتاتی ہیں کہ ایک دوسرے سے کیسے جڑیں کیونکہ وہ NAT یا فائر وال کے پیچھے ہوتے ہیں جن کا براہ راست روٹیبل ایڈریس نہیں ہوتا ہے۔

ICE (انٹرایکٹو کنکشن اسٹیبلشمنٹ) وہ حصہ ہے جو ان تمام پتوں کو اکٹھا کرکے حل کرتا ہے جن سے کوئی ہم مرتبہ رابطہ کرسکتا ہے اور جب تک یہ کام کرتا ہے ان کی جانچ کرتا ہے۔ امیدوار کہلانے والے یہ پتے دو طرح کے سرورز سے آتے ہیں: سیشن ٹراورسل یوٹیلیٹیز برائے NAT (STUN) اور ٹراورسل یوزنگ ریلے NAT (ٹرن) کے ارد گرد۔

خاکہ ایک واحد ہم مرتبہ کو متوازی طور پر تین امیدواروں کی اقسام کو جمع کرتا ہے۔ اپنے نیٹ ورک انٹرفیس کے لیے میزبان امیدوار، STUN سرور سے واپس آنے والے سرور کی عکاسی کرنے والے امیدوار (Public IP اور NAT کے ذریعے میپ کیے گئے پورٹ)، اور ٹرن سرور کو تفویض کردہ ریلے امیدوار۔ تینوں کو ریموٹ پیئر کو ICE امیدواروں کے طور پر بھیجا جاتا ہے، اور جو جوڑا کامیابی سے جڑتا ہے اسے کال کے لیے استعمال کیا جاتا ہے۔

STUN عام کیس کو ہینڈل کرتا ہے۔ ہم مرتبہ STUN سرور سے عوامی IP اور NAT کے ذریعے میپ کردہ پورٹ کے لیے پوچھتا ہے اور اسے امیدوار کے پتے کے طور پر استعمال کرتا ہے۔

جب STUN کافی نہ ہو تو ٹرن ایک متبادل ہے۔ Symmetric NAT اور کچھ فائر وال کنفیگریشنز براہ راست رابطوں کو مکمل طور پر مسدود کر دیتے ہیں، اس لیے ٹرن سرور اس کی بجائے دو ہم عمروں کے درمیان ٹریفک کو ریلے کرتا ہے۔ کسی بھی نیٹ ورک کنفیگریشن پر کام کرتا ہے۔ ساتھیوں کے درمیان براہ راست کنکشن کے بجائے تمام پیکٹوں کو تھرڈ پارٹی سرور کے ذریعے روٹ کرنے کے بجائے، STUN لیٹنسی میں اضافہ کرتا ہے اور کال کے دورانیے کے لیے سرور بینڈوڈتھ استعمال کرتا ہے، جو کچھ STUN نہیں کر سکتا۔

امیدواروں کا تبادلہ دو طریقوں سے کیا جا سکتا ہے۔ سب سے پہلے، ایک باقاعدہ ICE انتظار کر سکتا ہے جب تک کہ تمام امیدواروں کو باہر بھیجنے سے پہلے جمع نہیں کر لیا جاتا۔ یہ آسان ہے، لیکن سامنے میں تاخیر کا اضافہ کرتا ہے۔ کنکشن کی گفت و شنید اس وقت تک شروع نہیں ہو سکتی جب تک کہ سست ترین امیدوار جمع کرنا مکمل نہ کر لے۔

دوسرا، چھوٹا ICE جیسے ہی ہر امیدوار کو دریافت کرتا ہے اسے منتقل کرتا ہے، لہذا تمام امیدواروں کا انتظار کرنے کے بجائے، پہلے آنے والے امیدوار کے ساتھ گفت و شنید شروع ہوتی ہے۔ تاہم، یہ اُن امیدواروں کو ہینڈل کرنے کے لیے ساتھیوں سے سگنلنگ اور ICE دونوں عمل درآمد کی ضرورت کی قیمت پر آتا ہے جو ایک ساتھ آنے کی بجائے بتدریج پہنچتے ہیں۔

وقت کے لحاظ سے حساس ایپلی کیشنز کے لیے، یہ تجویز کی جاتی ہے کہ ان کو چھوٹے اضافے میں شامل کیا جائے کیونکہ نفاذ کی پیچیدگی بڑھ جاتی ہے۔ زیادہ تر جدید WebRTC اسٹیک مقامی طور پر اس کی حمایت کرتے ہیں۔

// Sending side: forward each candidate the moment ICE finds it
pc.onicecandidate = (event) => {
  if (event.candidate) {
    signalingChannel.send({ type: 'ice-candidate', candidate: event.candidate });
  }
};

// Receiving side: add each candidate as it arrives, don't wait for the rest
signalingChannel.on('ice-candidate', ({ candidate }) => {
  pc.addIceCandidate(candidate);
});

نفاذ کی مثال

ہم نے یہ دیکھنے کے لیے ایک سگنلنگ سرور MVP بنایا ہے کہ ان کی اصل میں پیمانے پر کیا قیمت ہے۔

• سرورز کے لیے Node.js کیونکہ اس کا سنگل تھریڈڈ ایونٹ لوپ فی کنکشن تھریڈ اوور ہیڈ کے بغیر بہت سے کنکرنٹ WebSocket کنکشن کو ہینڈل کرتا ہے۔

• روٹنگ کے لیے ایکسپریس اور کلائنٹ کنیکٹیویٹی کے لیے Socket.IO کے اوپر پرتوں والا، Socket.IO خود بخود HTTP لانگ پولنگ میں واپس آجاتا ہے جب کلائنٹ کا نیٹ ورک WebSockets کو مکمل طور پر بلاک کر دیتا ہے۔

خاکہ ایک براؤزر کلائنٹ کو دکھاتا ہے جو WebSockets پر ایپلیکیشن لوڈ بیلنسر سے منسلک ہوتا ہے (HTTP لانگ پولنگ سے بدل دیا جاتا ہے)۔ یہ EKS پر Docker کنٹینرز میں چلنے والے متعدد Socket.IO سرور پوڈز میں سے ہر ایک کنکشن کو روٹ کرتا ہے۔ تمام پوڈز کمرے کی حالت کے لیے ایک ہی Redis کلسٹر کا اشتراک کرتے ہیں، اس لیے اس سے کوئی فرق نہیں پڑتا کہ کوئی خاص کلائنٹ کس پوڈ میں ہے۔

روم ٹو پیئر میپنگز Redis (Amazon ElastiCache) میں رہتی ہیں اور صرف "اس کمرے میں اور کون ہے” کا فوری جواب دینے کی ضرورت ہے اور کال سے آگے کچھ بھی برقرار نہیں رہتا ہے۔

یہی وجہ ہے کہ ALB کے چپچپا سیشن ایسا کرتے ہیں۔ WebSocket کنکشن کو اپنی پوری زندگی کے لیے ایک ہی سگنلنگ سرور مثال کے ساتھ بند رہنا چاہیے، اس لیے ایک کلائنٹ کی تمام درخواستوں کو ہر بار ایک ہی بیک اینڈ پوڈ تک پہنچنا چاہیے۔

اہم واقعات کے علاوہ سرور خود ایک پتلی ریلے ہے۔ یہ Redis میں کمرے کی رکنیت کو ٹریک کرتا ہے اور SDP بلاب یا ICE امیدوار کے اندر دیکھے بغیر پیغامات کو درست ساکٹ پر بھیجتا ہے۔

io.on('connection', (socket) => {
  socket.on('join', async (roomId) => {
    socket.join(roomId);
    await redis.sadd(`room:${roomId}`, socket.id);
    socket.to(roomId).emit('peer-joined', socket.id);
  });

  socket.on('offer', ({ target, sdp }) => {
    io.to(target).emit('offer', {
      from: socket.id,
      sdp,
    });
  });

  socket.on('answer', ({ target, sdp }) => {
    io.to(target).emit('answer', {
      from: socket.id,
      sdp,
    });
  });

  socket.on('ice-candidate', ({ target, candidate }) => {
    io.to(target).emit('ice-candidate', {
      from: socket.id,
      candidate,
    });
  });

  socket.on('disconnecting', async () => {
    // Copy the rooms before Socket.IO removes the socket from them.
    // socket.rooms also contains a private room named after socket.id.
    const rooms = [...socket.rooms].filter(
      (roomId) => roomId !== socket.id
    );

    for (const roomId of rooms) {
      socket.to(roomId).emit('peer-left', socket.id);
      await redis.srem(`room:${roomId}`, socket.id);
    }
  });
});

join ایک کمرے میں ایک ساکٹ شامل کریں اور اسے Redis میں لاگ ان کریں تاکہ دوسرے سرور کی مثالیں اسے دیکھ سکیں۔ offer، answerاور ice-candidate وہ سب بنیادی طور پر ایک ہی کام کرتے ہیں۔ یعنی، یہ ٹارگٹ ساکٹ ID لیتا ہے اور SDP یا ICE ڈیٹا کی تشریح کیے بغیر پے لوڈ فراہم کرتا ہے۔

کہ disconnecting Socket.IO ساکٹ کو اپنی جگہ سے ہٹانے سے پہلے ہینڈلر صفائی کرتا ہے۔ یہ پہلے موجودہ اسپیس آئی ڈی کو کاپی کرتا ہے، ساکٹ کی پرائیویٹ اسپیس کو چھوڑ کر، پھر باقی ساتھیوں کو مطلع کرتا ہے کہ کنکشن ختم ہو گیا ہے اور پیئر کو اس کے متعلقہ Redis سیٹ سے ہٹا دیتا ہے۔

کمرے کی ID کو پہلے سے کاپی کرنا ضروری ہے کیونکہ ہینڈلر غیر مطابقت پذیر Redis آپریشن کرتا ہے اور جب رابطہ منقطع ہو جاتا ہے تو ساکٹ کی کمرے کی رکنیت صاف ہو جاتی ہے۔

اس صفائی کے بغیر، Redis ساتھیوں کی فہرست بنا سکتا ہے جو ساکٹ کے غائب ہونے کے بعد بھی موجود رہتا ہے، جو کمرے کی باسی حالت کو پیچھے چھوڑ دیتا ہے اور باقی ساتھیوں کو سگنلنگ پیغامات یا ICE امیدواروں کا انتظار کرنا پڑتا ہے جو کبھی نہیں پہنچتے ہیں۔

معیاری

10 نقلیں، ہر ایک 1 CPU اور 512 MB میموری کے ساتھ، 60 سیکنڈ کے لیے فی سیکنڈ 100,000 درخواستوں پر چل رہا ہے:

واقعہ	مکمل	ناکام	تاثیر
چیٹ روم میں شامل ہوں۔	99991	9	99.991%
ایس ڈی پی کی تجویز	99968	32	99.968%
SDP جواب	99982	18	99.982%
پانی کے قطرے برف	99977	23	99.977%

تمام ایونٹ کی اقسام میں 99.96% سے زیادہ لوڈز کی دستیابی تھی، چار اوسط 99.98% کے ساتھ۔ سگنل ڈیزائن کے لحاظ سے ہلکے ہوتے ہیں۔ چونکہ آپ چھوٹے JSON پے لوڈز کو میڈیا کے بجائے پہلے سے ہی کھلے کنکشنز پر منتقل کر رہے ہیں، اس لیے اس قسم کے سرورز کے لیے اصل رکاوٹ تقریباً ہمیشہ کنکشنز اور میموری فی کنکشن کی تعداد ہوتی ہے، CPU نہیں۔

ٹوپولوجی کی توسیع

ایک سگنل صرف ایک کنکشن قائم کرتا ہے۔ اصل میڈیا ٹریفک کا کیا ہوتا ہے جب دو یا دو سے زیادہ ساتھی بات کرتے ہیں ایک الگ اور مشکل مسئلہ ہے اور تین میں سے کسی ایک کو منتخب کرنے پر آتا ہے۔

پیئر ٹو پیئر (P2P)

براہ راست نقطہ نظر ہر ہم مرتبہ کو ہر دوسرے ہم مرتبہ سے جوڑتا ہے، یعنی مکمل میش۔ یہ سستا ہے کیونکہ اسے کسی بھی میڈیا سرور کی ضرورت نہیں ہے، اور تمام اسٹریمز کو آخر سے آخر تک رکھتا ہے، لیکن کنکشنز کی تعداد کو چاروں طرف سے بڑھاتا ہے۔ n(n-1)/2 کے لیے n ساتھی 6 پیئرز کا مطلب ہے 15 کنکشن، جہاں ہر ہم مرتبہ اپنا سلسلہ دوسرے 5 پر اپ لوڈ کرتا ہے اور بدلے میں 5 اسٹریمز ڈاؤن لوڈ کرتا ہے۔

1 ایم بی پی ایس فی اسٹریم پر، 6 افراد کی میش کال میں ہر ہم مرتبہ 5 ایم بی پی ایس کو بڑھاتا ہے اور اپنی شرکت کو برقرار رکھنے کے لیے 5 ایم بی پی ایس کو کم کرتا ہے۔ یہی قیمت ہے جو شرکاء کی ایک چھوٹی سی تعداد سے آگے میشنگ کو ناقابل عمل بناتی ہے۔ یہ سرور کی کوئی حد نہیں ہے، بس یہ ہے کہ ہر ایک کلائنٹ پہلے اپنی اپ لوڈ بینڈوتھ اور CPU کو ختم کرتا ہے۔

سلیکٹیو ڈیلیوری یونٹ (SFU)

SFU اس میش کو ستارے کی شکل میں کم کر دیتا ہے۔ ہر ہم مرتبہ مرکزی سرور کو ایک بار ایک سلسلہ بھیجتا ہے، اور مرکزی سرور ہر سلسلہ کو دوسرے ساتھیوں کے پاس بھیجتا ہے جنہیں اس کی ضرورت ہوتی ہے۔ سے اپ لوڈ چھوڑ دیں۔ (n-1) آپ کی کال کے سائز سے قطع نظر، آپ کے پاس اب بھی 1 کنکشن اور 1 ڈاؤن لوڈ ہوگا۔ (n-1) اس کی وجہ یہ ہے کہ SFU اب بھی ہر ایک ساتھی کو انفرادی طور پر ہر کسی کے سلسلے کو ڈیلیور کرنے کا تقاضا کرتا ہے۔

کل کنکشن چوکور سے لکیری تک کم ہو جاتے ہیں۔ n اس کے بجائے n(n-1)/2ہم مرتبہ کے اپ لوڈ کے اخراجات کال کے سائز کے ساتھ اسکیلنگ کو مکمل طور پر روک دیتے ہیں۔ اس کے بجائے، SFU کو خود ہی بڑھایا جانا چاہیے، لیکن فارورڈنگ پیکٹس کو ڈی کوڈنگ اور دوبارہ انکوڈنگ کرنے سے کہیں زیادہ سستا ہے۔ یہ وہ تجارت ہے جو MCU کرتا ہے۔

ملٹی پوائنٹ کانفرنس یونٹ (MCU)

MCU ایک قدم آگے بڑھتا ہے۔ تمام ہم عمروں کے سلسلے کو ڈی کوڈ کیا جاتا ہے اور سرور سائیڈ پر ایک جامع سٹریم میں ملایا جاتا ہے، پھر دوبارہ انکوڈ کیا جاتا ہے اور ایک ہی سلسلے کے طور پر واپس بھیجا جاتا ہے۔ اپ لوڈز اور ڈاؤن لوڈز دونوں فی پیئر 1 کنکشن تک گر جاتے ہیں۔ یہ تین طریقوں میں سب سے کم بینڈوڈتھ لاگت ہے۔

بینڈوڈتھ کی یہ کمی ہر کال، ڈی کوڈنگ، مکسنگ، اور انکوڈنگ میں تمام شرکاء کے لیے ریئل ٹائم ٹرانس کوڈنگ کے ذریعے مسلسل حاصل کی جاتی ہے۔ یہ ایک CPU ہے اور اکثر SFU سے مختلف طریقے سے ہارڈویئر انکوڈرز کا پابند ہوتا ہے۔ یہ سرور سائیڈ آؤٹ پٹ لے آؤٹ میں بھی ترمیم کرتا ہے۔ کلائنٹ دوبارہ ترتیب نہیں دے سکتے ہیں کہ وہ SFU سے علیحدہ سلسلے وصول کرتے وقت کہاں ظاہر ہوتے ہیں۔

نقطہ نظر	اپ لوڈ/ڈاؤن لوڈ کریں۔	بینڈوتھ	کے درمیان
P2P	5Mbps / 5Mbps	30Mbps	15
ایس ایف یو	1 ایم بی پی ایس / 5 ایم بی پی ایس	12Mbps	6
ایم سی یو	1 ایم بی پی ایس / 1 ایم بی پی ایس	12Mbps	6

زیادہ تر گروپ کالنگ پروڈکٹس کے لیے، SFU کو فوقیت حاصل ہے۔ میش کے لیے بینڈوڈتھ کی بچت اب بھی برقرار ہے اور کلائنٹ اب بھی اپنے لے آؤٹ کو کنٹرول کر سکتے ہیں۔ MCU تنگ صورتوں میں اپنے لیے ادائیگی کرتا ہے، اور اس کی تاریخ ایک صاف ستھری مثال ہے۔ اگر تمام اسٹریمز پہلے سے ہی سرور سائیڈ پر اکٹھے ہیں، S3 پر نتائج لکھنا کلائنٹ سائڈ کمپوزٹ کے بجائے ایک بار فائل رائٹ ہے۔ n الگ نہریں۔

سائز کے بارے میں دیگر اہم معاملات

ٹوپولوجی واحد چیز نہیں ہے جو حقیقی ٹریفک میں ٹوٹ جاتی ہے۔ کنیکٹیویٹی، سگنل لوڈنگ، براؤزر سپورٹ، سیکورٹی، اور قابل اعتماد ہر ایک کے اپنے ناکام طریقے ہوتے ہیں جب پروڈکشن ٹریفک سسٹم تک پہنچ جاتی ہے۔

کنیکٹوٹی

کچھ نیٹ ورک مکمل طور پر STUN کو روکتے ہیں اور ٹریفک کو موڑ دیتے ہیں جب تک کہ یہ سادہ HTTPS کی طرح نظر نہ آئے۔ معیاری بندرگاہوں پر STUN اور ٹرن کو TLS پر چلانے اور STUN سرور کو جغرافیائی طور پر کلائنٹس کے قریب رکھنا اس فریکوئنسی کو بہتر بناتا ہے جس کے ساتھ ٹرن پر واپس آنے سے پہلے براہ راست رابطہ کامیاب ہو جاتا ہے۔

بوجھ کے تحت سگنل

چونکہ سگنلنگ سرورز میں میڈیا نہیں ہوتا ہے، اس لیے ان کی پیمائش کرنا ویب سروسز کا ایک عام مسئلہ ہے۔ CPU- اور میموری کے لیے ذمہ دار افقی پوڈ آٹو اسکیلنگ چپچپا سیشنوں کو ہینڈل کرتی ہے جیسے وہ چلتے ہیں، بالکل کسی بھی دوسری بے وطن سروس کی طرح۔

براؤزر سپورٹ

پرانے براؤزرز میں مکمل WebRTC سپورٹ کی کمی ہو سکتی ہے۔ Adapter.js جیسے پولی فلز ہر براؤزر کے لیے آپ کے ایپلیکیشن کوڈ کو برانچ کرنے کے بجائے براؤزر ورژن کے درمیان API کے فرق کو دستاویز کرتا ہے۔

سیکورٹی

WebRTC میڈیا کو بطور ڈیفالٹ خفیہ کرتا ہے۔ DTLS کلیدی تبادلے کو ہینڈل کرتا ہے اور SRTP آڈیو اور ویڈیو پیکٹ کو خفیہ کرتا ہے۔ تاہم، یہ ساتھیوں اور ریلے کے درمیان ٹرانسپورٹ انکرپشن ہے، صارفین کے درمیان اینڈ ٹو اینڈ انکرپشن نہیں۔

سگنلنگ چینل پر HTTPS اور WSS کو نافذ کرنا، ٹرن سرور سے تصدیق کی ضرورت، سگنلنگ API کی شرح کو محدود کرنا، اور پرفیکٹ فارورڈ سیکریسی کو فعال کرنا اس خلا کو ختم کرتا ہے جسے DTLS/SRTP خود ہینڈل نہیں کر سکتا۔

قابل اعتماد

WebRTC UDP پر چلتا ہے، دوبارہ منتقلی کے بغیر پیکٹوں کو چھوڑنا اور دوبارہ ترتیب دینا۔ فارورڈ خرابی کی اصلاح اصل اسٹریم کے ساتھ بے کار ڈیٹا کو منتقل کرتی ہے، جس سے وصول کنندہ کو پہلے سے موجود فالتو پن سے کھوئے ہوئے پیکٹوں کو دوبارہ تشکیل دینے کی اجازت ملتی ہے، بجائے اس کے کہ ری ٹرانسمیشنز کا انتظار کریں جو بہت دیر سے پہنچتی ہیں اور ریئل ٹائم میڈیا کے لیے ایک مسئلہ بن جاتی ہیں۔

اگلے اقدامات

اس آرٹیکل میں، آپ نے ان تین APIs کے بارے میں سیکھا جن کو WebRTC ظاہر کرتا ہے، سگنلنگ اور NAT ٹراورسل کیوں مخصوص نہیں ہیں، بوجھ کے نیچے سگنلنگ سرور کو بینچ مارک کیسے کیا جائے، اور میش، SFU، اور MCU ٹوپولاجیز کے درمیان بینڈ وڈتھ کو متوازن کیا جائے۔

اس میں سے کوئی بھی ویڈیو کالز تک محدود نہیں ہے۔ WebRTC پر بنائے گئے تمام پروڈکٹس، جیسے اسکرین شیئرنگ، ریئل ٹائم تعاون، یا کلاؤڈ گیمنگ، ایک ہی سگنلنگ، NAT ٹراورسل، اور ٹاپولوجی کے فیصلوں کی پیروی کرتے ہیں۔

آپ ذیل کے وسائل کا جائزہ لے کر بھی سیکھنا جاری رکھ سکتے ہیں۔