OpenAI بڑے پیمانے پر کم لیٹنسی والی وائس AI کیسے فراہم کرتا ہے

وائس AI اسی وقت فطری محسوس ہوتی ہے جب گفتگو بولنے کی رفتار کے مطابق آگے بڑھے۔ جب نیٹ ورک رکاوٹ بنتا ہے تو لوگ فوراً اسے غیر فطری وقفوں، کٹے ہوئے جملوں، یا تاخیر سے ہونے والی بارج اِن کی صورت میں محسوس کرتے ہیں۔ یہ بات ChatGPT وائس کے لیے، Realtime API کے ساتھ کام کرنے والے ڈویلپرز کے لیے، انٹرایکٹو ورک فلو میں کام کرنے والے ایجنٹس کے لیے، اور ان ماڈلز کے لیے اہم ہے جنہیں اس وقت بھی آڈیو پراسیس کرنا ہوتا ہے جب صارف بات کر ہی رہا ہو۔

OpenAI کے پیمانے پر، اس کا مطلب تین واضح تقاضے ہیں:

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

OpenAI میں ریئل ٹائم AI انٹرایکشنز کی ذمہ دار ٹیم نے حال ہی میں ہمارے WebRTC اسٹیک کو دوبارہ ڈیزائن کیا تاکہ ان تین تکنیکی پابندیوں کو حل کیا جا سکے جو بڑے پیمانے پر آ کر ایک دوسرے سے ٹکراؤ کا باعث بننے لگے تھے: فی سیشن ایک پورٹ پر میڈیا ٹرمینیشن OpenAI کے انفراسٹرکچر کے لیے موزوں نہیں ہے، stateful ICE (Interactive Connectivity Establishment) اور DTLS (Datagram Transport Layer Security) سیشنز کو مستحکم ملکیت کی ضرورت ہوتی ہے، اور گلوبل روٹنگ کو فرسٹ ہاپ لیٹنسی کم رکھنی ہوتی ہے۔ اس پوسٹ میں ہم اس split relay plus transceiver آرکیٹیکچر کی وضاحت کرتے ہیں جو ہم نے اس لیے بنایا کہ کلائنٹس کے لیے معیاری WebRTC رویہ برقرار رہے، جبکہ OpenAI کے انفراسٹرکچر کے اندر پیکٹس کی روٹنگ کا طریقہ بدل دیا جائے۔

WebRTC ایک اوپن اسٹینڈرڈ ہے جو براؤزرز، موبائل ایپس اور سرورز کے درمیان کم لیٹنسی کے ساتھ آڈیو، ویڈیو اور ڈیٹا منتقل کرنے کے لیے استعمال ہوتا ہے۔ اسے اکثر پیر-ٹو-پیر کالنگ سے جوڑا جاتا ہے، مگر یہ کلائنٹ-ٹو-سرور ریئل ٹائم سسٹمز کے لیے بھی ایک عملی بنیاد ہے کیونکہ یہ انٹرایکٹو میڈیا کے مشکل حصوں کو معیاری بناتا ہے: کنیکٹیویٹی اسٹیبلشمنٹ اور NAT (Network Address Translation) ٹریورسل کے لیے ICE، انکرپٹڈ ٹرانسپورٹ کے لیے DTLS اور SRTP (Secure Real-time Transport Protocol)، آڈیو کو کمپریس اور ڈیکوڈ کرنے کے کوڈیک نیگوشی ایشن، کوالٹی کنٹرول کے لیے RTCP (Real-time Transport Control Protocol)، اور کلائنٹ سائیڈ فیچرز جیسے echo cancellation اور jitter buffering۔

یہ اسٹینڈرڈائزیشن AI پروڈکٹس کے لیے اہم ہے۔ WebRTC کے بغیر ہر کلائنٹ کو NATs کے پار کنیکٹیویٹی قائم کرنے، میڈیا کو انکرپٹ کرنے، کوڈیکس (ٹرانسمیشن اور ڈی کمپریشن کے لیے منتخب کوڈر-ڈیکوڈر) کو نیگوشی ایٹ کرنے، اور بدلتے ہوئے نیٹ ورک حالات کے مطابق ڈھلنے کے لیے مختلف حل درکار ہوتے۔ WebRTC کے ساتھ ہم ایک ایسے پروٹوکول اسٹیک پر کام کر سکتے ہیں جو پہلے ہی براؤزرز اور موبائل پلیٹ فارمز میں موجود ہے، اور اپنی توجہ اس انفراسٹرکچر پر مرکوز کر سکتے ہیں جو ریئل ٹائم میڈیا کو ماڈلز سے جوڑتا ہے۔

ہم WebRTC ایکو سسٹم پر بھی کام کرتے ہیں، جس میں میچور اوپن سورس امپلیمنٹیشنز اور وہ اسٹینڈرڈ کام شامل ہے جو براؤزرز، موبائل ایپس اور سرورز کو ایک دوسرے کے ساتھ انٹرآپریبل رکھتا ہے۔ Justin Uberti (جو WebRTC کے اصل آرکیٹیکٹس میں سے ایک ہیں) اور Sean DuBois (Pion کے کریئیٹر اور مینٹینر) کا بنیادی کام اس بات کو ممکن بناتا ہے کہ ہماری جیسی ٹیمیں لو لیول ٹرانسپورٹ، انکرپشن اور کنجیسشن کنٹرول کے رویے کو دوبارہ بنانے کے بجائے پہلے سے آزمودہ میڈیا انفراسٹرکچر پر کام کر سکیں۔ ہم خوش قسمت ہیں کہ Justin اور Sean دونوں اب OpenAI میں ہمارے کولیگز ہیں، جو ہمیں یہ رہنمائی فراہم کر رہے ہیں کہ ہم WebRTC اور ریئل ٹائم AI کو مزید قریب کیسے لا سکتے ہیں۔

AI کے لیے سب سے اہم خصوصیت یہ ہے کہ آڈیو ایک مسلسل اسٹریم کی صورت میں پہنچے۔ ایک اسپوکن ایجنٹ صارف کے ابھی بولتے رہنے کے دوران ہی ٹرانسکرائب کرنا، ریزننگ پیش کرنا، ٹولز کو کال کرنا یا اسپيچ جنریٹ کرنا شروع کر سکتا ہے، بجائے اس کے کہ مکمل اپ لوڈ کا انتظار کرے۔ یہی وہ فرق ہے جو ایک ایسے سسٹم کے درمیان ہوتا ہے جو کنورزیشنل محسوس ہوتا ہے اور ایک ایسے سسٹم کے درمیان جو پُش-ٹو-ٹاک جیسا لگتا ہے۔

جب ہم نے WebRTC کو منتخب کر لیا، تو اگلا سوال یہ تھا کہ اسے کہاں ٹرمینیٹ کیا جائے (یعنی ہم WebRTC کنیکشن کو کہاں قبول اور اس کے مالک ہوں—مثال کے طور پر کنارے پر) اور ان سیشنز کو انفیرنس بیک اینڈ سے کیسے جوڑا جائے۔ ٹرمینیشن اہم ہے کیونکہ یہ طے کرتا ہے کہ ہم ریئل ٹائم سیشن اسٹیٹ، میڈیا ٹرانسپورٹ، روٹنگ، لیٹنسی اور فیلئر آئسولیشن کو کیسے ہینڈل کرتے ہیں۔

SFU، یا سیلیکٹو فارورڈنگ یونٹ، ایک میڈیا سرور ہوتا ہے جو ہر ایک پارٹیسپنٹ سے ایک WebRTC اسٹریم وصول کرتا ہے اور منتخب طور پر یہ اسٹریمز دوسرے پارٹیسپنٹس کو فارورڈ کرتا ہے۔ اس ماڈل میں SFU ہر پارٹیسپنٹ کے لیے الگ WebRTC کنیکشن ٹرمینیٹ کرتا ہے، اور AI سیشن میں ایک اور پارٹیسپنٹ کے طور پر شامل ہو جاتا ہے۔ یہ ان پروڈکٹس کے لیے ایک اچھا انتخاب ہو سکتا ہے جو فطری طور پر ملٹی پارٹی ہوں، جیسے گروپ کالز، کلاس رومز یا کولیبوریٹو میٹنگز۔ یہ آڈیو کوڈیکس، RTCP میسجز، ڈیٹا چینلز، ریکارڈنگ، اور فی-اسٹریم پالیسی کو ایک ہی جگہ پر رکھتا ہے۔¹

یہاں تک کہ کلائنٹ-ٹو-AI پروڈکٹس میں بھی SFU اکثر ڈیفالٹ اسٹارٹنگ پوائنٹ ہوتا ہے کیونکہ یہ ٹیموں کو ایک ہی آزمودہ سسٹم کو سگنلنگ، میڈیا روٹنگ، ریکارڈنگ، آبزرویبیلٹی، اور مستقبل کی ایکسٹینشنز جیسے ہیومن ہینڈآف یا مزید پارٹیسپنٹس شامل کرنے کے لیے دوبارہ استعمال کرنے کی سہولت دیتا ہے۔

ہمارا ورک لوڈ مختلف ہے۔ زیادہ تر سیشنز 1:1 ہوتے ہیں—ایک صارف ایک ماڈل سے بات کر رہا ہوتا ہے، یا ایک ایپلیکیشن ایک ریئل ٹائم ایجنٹ سے—جہاں ہر ٹرن پر لیٹنسی کے حوالے سے حساسیت ہوتی ہے۔ اس ٹریفک پیٹرن کے لیے ہم نے ایک ٹرانسیور ماڈل منتخب کیا: ایک WebRTC ایج سروس کلائنٹ کنیکشن کو ٹرمینیٹ کرتی ہے اور پھر میڈیا اور ایونٹس کو آسان اندرونی پروٹوکولز میں تبدیل کرتی ہے تاکہ ماڈل انفیرنس، ٹرانسکرپشن، اسپيچ جنریشن، ٹول یوز اور آرکیسٹریشن ممکن ہو سکے۔

اس ڈیزائن میں ٹرانسیور واحد سروس ہے جو WebRTC سیشن اسٹیٹ کی مالک ہوتی ہے، جس میں ICE کنیکٹیوٹی چیکس، DTLS ہینڈ شیک، SRTP انکرپشن کیز، اور سیشن لائف سائیکل شامل ہیں۔ یہاں "ٹرمینیشن" سے مراد یہ ہے کہ ٹرانسیور وہ اینڈپوائنٹ ہے جو ان ہینڈ شیکس کو مکمل کرتا ہے اور میڈیا کو انکرپٹ یا ڈیکرپٹ کرتا ہے۔ اس اسٹیٹ کو ایک ہی جگہ رکھنے سے سیشن اونرشپ کو سمجھنا آسان ہو گیا، اور اس نے بیک اینڈ سروسز کو اس قابل بنایا کہ وہ عام سروسز کی طرح اسکیل ہو سکیں بجائے اس کے کہ وہ خود WebRTC پیئرز کے طور پر کام کریں۔

ٹرانسیور ماڈل منتخب کرنے کے بعد ہماری پہلی امپلیمنٹیشن ایک سنگل Go سروس تھی جو Pion پر بنی ہوئی تھی اور جو سگنلنگ اور میڈیا ٹرمینیشن دونوں کو ہینڈل کرتی تھی۔ یہ ChatGPT وائس، Realtime API کے WebRTC اینڈپوائنٹ، اور متعدد ریسرچ پروجیکٹس کو پاور کرتی ہے۔

آپریشنل طور پر، ٹرانسیور سروس دو کام انجام دیتی ہے:

• سگنلنگ: SDP نیگوشی ایشن، کوڈیک سلیکشن، ICE کریڈنشلز، اور سیشن سیٹ اپ
• میڈیا: ڈاؤن اسٹریم WebRTC کنیکشنز کو ٹرمینیٹ کرنا اور انفیرنس اور آرکیسٹریشن کے لیے بیک اینڈ سروسز کے ساتھ اپ اسٹریم کنیکشنز کو برقرار رکھنا

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

پہلا مسئلہ خود ون-پورٹ-پر-سیشن ماڈل تھا۔ زیادہ کنکرنسی پر، اس کا مطلب بہت بڑے UDP پورٹ رینجز کو ایکسپوز اور مینیج کرنا ہوتا ہے۔

• کلاؤڈ لوڈ بیلنسرز اور Kubernetes سروسز اس طرح ڈیزائن نہیں کی گئی ہیں کہ ہر سروس کے لیے دسیوں ہزار پبلک UDP پورٹس کو ہینڈل کیا جا سکے۔ ہر اضافی رینج لوڈ بیلنسر کنفیگریشن، ہیلتھ چیکنگ، فائر وال پالیسی، اور رول آؤٹ سیفٹی میں آپریشنل کمپلیکسٹی بڑھا دیتی ہے۔³
• بڑے UDP پورٹ رینجز کو سیکیور کرنا مشکل ہوتا ہے کیونکہ یہ ایکسٹرنلی ریچیبل سرفیس ایریا کو بڑھا دیتے ہیں اور نیٹ ورک پالیسی کو آڈٹ کرنا مشکل بنا دیتے ہیں۔
• یہ آٹو اسکیلنگ کے لیے بھی موزوں نہیں ہیں۔ Kubernetes میں پوڈز مسلسل شامل کیے جاتے ہیں، ہٹائے جاتے ہیں اور ری شیڈول کیے جاتے ہیں۔ ہر پوڈ سے ایک بڑا اسٹیبل پورٹ رینج ریزرو اور ایڈورٹائز کروانے کی ضرورت اس لچک کو کمزور بنا دیتی ہے۔⁴

یہی وجہ ہے کہ بہت سے WebRTC سسٹمز ایک سرور کے لیے ایک ہی UDP پورٹ کی طرف منتقل ہو رہے ہیں، اور اس پورٹ کے پیچھے ایپلیکیشن لیول پر ڈی مَلٹی پلیکسنگ کرتے ہیں۔⁵

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

ICE اور DTLS اسٹیٹ فل پروٹوکولز ہیں۔ جس پروسس نے کوئی سیشن کریٹ کیا ہوتا ہے اسے اسی سیشن کے پیکٹس مسلسل موصول ہوتے رہنے چاہئیں تاکہ وہ کنیکٹیوٹی چیکس کو ویریفائی کر سکے، DTLS ہینڈ شیک مکمل کر سکے، SRTP کو ڈیکرپٹ کر سکے، اور سیشن کی بعد کی تبدیلیوں جیسے ICE ری اسٹارٹس کو پروسس کر سکے۔ اگر ایک ہی سیشن کے پیکٹس کسی دوسرے پروسس میں چلے جائیں تو سیٹ اپ فیل ہو سکتا ہے یا میڈیا خراب ہو سکتا ہے۔

اس نے ہمیں ایک واضح ہدف دیا: پبلک انٹرنیٹ پر ایک چھوٹی اور فکسڈ UDP سرفیس ایکسپوز کرنا، جبکہ ہر پیکٹ کو پھر بھی اس ٹرانسیور تک روٹ کرنا جو متعلقہ WebRTC سیشن کا مالک ہو۔

ہم نے اس مقصد تک پہنچنے کے لیے کئی طریقوں کا جائزہ لیا، جن میں TURN (Traversal Using Relays around NAT) بھی شامل تھا، جہاں ایک ایج ریلے کلائنٹ ایلوکیشنز کو ٹرمینیٹ کرتا ہے اور ان کی طرف سے ٹریفک فارورڈ کرتا ہے۔²

جو آرکیٹیکچر ہم نے شِپ کیا اس میں پیکٹ روٹنگ کو پروٹوکول ٹرمینیشن سے الگ کیا گیا ہے۔ سگنلنگ اب بھی سیشن سیٹ اپ کے لیے ٹرانسیور تک پہنچتی ہے، جبکہ میڈیا پہلے ریلے کے ذریعے داخل ہوتا ہے۔ ریلے ایک لائٹ ویٹ UDP فارورڈنگ لیئر ہے جس کا پبلک فٹ پرنٹ چھوٹا ہوتا ہے، اور اس کے پیچھے ٹرانسیور وہ اسٹیٹ فل WebRTC اینڈپوائنٹ ہے۔

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

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

ہر WebRTC سیشن پہلے سے ہی ایک پروٹوکول-نیٹو روٹنگ ہُک رکھتا ہے: ICE یوزرنیم فریگمنٹ، یا ufrag، جو سیشن سیٹ اپ کے دوران ایک مختصر شناخت کنندہ کے طور پر ایکسچینج ہوتا ہے اور STUN کنیکٹیوٹی چیکس میں ریپیٹ ہوتا ہے۔ ہم سرور سائیڈ ufrag اس طرح جنریٹ کرتے ہیں کہ اس میں اتنا روٹنگ میٹا ڈیٹا شامل ہو جو ریلے کو ڈیسٹینیشن کلسٹر اور سیشن کے مالک ٹرانسیور کا اندازہ لگانے کے قابل بنا دے۔

سگنلنگ کے دوران ٹرانسیور سیشن اسٹیٹ الاٹ کرتا ہے اور SDP آؤٹ میں ایک مشترکہ ریلے VIP اور UDP پورٹ واپس کرتا ہے۔ VIP (ورچوئل IP ایڈریس) ایک ورچوئل IP ایڈریس ہوتا ہے جو ریلے فلیٹ کو فرنٹ کرتا ہے؛ پورٹ کے ساتھ مل کر یہ کلائنٹ کو ایک سنگل اور اسٹےبل ڈیسٹینیشن دیتا ہے، جیسے `203.0.113.10:3478`، حالانکہ اس کے پیچھے متعدد ریلے انسٹینسز موجود ہوتے ہیں۔ کلائنٹ کا پہلا میڈیا پاتھ پیکٹ عموماً STUN (Session Traversal Utilities for NAT) بائنڈنگ ریکویسٹ ہوتا ہے، جسے ICE استعمال کرتا ہے تاکہ یہ ویریفائی کیا جا سکے کہ پیکٹس اعلان کردہ ایڈریس تک پہنچ سکتے ہیں۔

ریلے اس پہلے STUN پیکٹ کو اتنا ہی پارس کرتا ہے کہ سرور ufrag پڑھ سکے، روٹنگ ہنٹ کو ڈی کوڈ کر سکے، اور پیکٹ کو اس ٹرانسیور تک فارورڈ کر دے جو اس کا مالک ہے۔ ہر ٹرانسیور ایک شیئرڈ UDP ساکٹ پر سنتا ہے، یعنی ایک ہی آپریٹنگ سسٹم اینڈپوائنٹ جو انٹرنل IP:پورٹ پر باؤنڈ ہوتا ہے، نہ کہ ہر سیشن کے لیے الگ ساکٹ۔ جب ریلے کلائنٹ کے سورس IP:پورٹ سے ٹرانسیور ڈیسٹینیشن تک ایک سیشن بنا دیتا ہے، تو بعد کے DTLS، RTP، اور RTCP پیکٹس اسی سیشن کے اندر بہتے رہتے ہیں بغیر ufrag کو دوبارہ ڈی کوڈ کیے۔

ریلے کا سیشن جان بوجھ کر بہت کم رکھا گیا ہے، جس میں صرف ایک ان میموری سیشن شامل ہوتا ہے جو پیکٹ فارورڈنگ کو کنٹرول کرتا ہے، ساتھ ہی مانیٹرنگ کے لیے ضروری کاؤنٹرز اور سیشن ایکسپائریشن اور کلین اپ کے لیے ٹائمرز ہوتے ہیں۔ یہ ڈیزائن چوائس پیکٹ روٹنگ کو براہ راست پیکٹ پاتھ پر برقرار رکھتی ہے۔ اگر ریلے ری اسٹارٹ ہو جائے اور سیشن ختم ہو جائے تو اگلا STUN پیکٹ ufrag روٹنگ ہنٹ کی مدد سے سیشن دوبارہ بنا دیتا ہے۔ اسے مزید قابلِ اعتماد بنانے کے لیے Redis کیش استعمال کیا جاتا ہے جو <client IP + Port, transceiver IP + Port> کی میپنگ کو اس وقت تک محفوظ رکھتا ہے جب تک روٹ قائم ہو جائے، تاکہ اگلے STUN پیکٹ کے آنے سے پہلے ہی اسے ریکور کیا جا سکے۔

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

وسیع جغرافیائی انگریس پہلے کلائنٹ سے OpenAI تک ہاپ کو کم کر دیتا ہے کیونکہ پیکٹ پبلک انٹرنیٹ پر کسی دور دراز ریجن تک جانے کے بجائے صارف کے قریب موجود ریلے کے ذریعے ہماری نیٹ ورک میں داخل ہو سکتا ہے، چاہے جغرافیائی طور پر ہو یا نیٹ ورک ٹوپولوجی کے لحاظ سے۔ عملی طور پر، اس کا مطلب کم لیٹنسی، کم جِٹر، اور ہمارے بیک بون تک ٹریفک پہنچنے سے پہلے کم قابلِ اجتناب لاس برسٹس ہوتے ہیں۔⁶

ہم سگنلنگ کے لیے Cloudflare جیو اور پروکسیمیٹی اسٹیئرنگ استعمال کرتے ہیں تاکہ ابتدائی HTTP یا WebSocket ریکویسٹ قریبی ٹرانسیور کلسٹر تک پہنچ سکے۔ ریکویسٹ کا کانٹیکسٹ سیشن کی لوکیشن اور یہ طے کرتا ہے کہ کلائنٹ کو کون سا گلوبل ریلے انگریس پوائنٹ ایڈورٹائز کیا جائے۔ SDP آؤٹ گلوبل ریلے ایڈریس فراہم کرتا ہے، جبکہ ufrag میں اتنی معلومات شامل ہوتی ہے کہ گلوبل ریلے میڈیا کو مطلوبہ کلسٹر تک روٹ کر سکے اور ریلے اسے ڈیسٹینیشن ٹرانسیور تک فارورڈ کر سکے۔

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

ہم نے ریلے سروس Go میں لکھی اور امپلیمنٹیشن کو جان بوجھ کر محدود رکھا۔ Linux میں، کرنل کا نیٹ ورکنگ اسٹیک مشین کے نیٹ ورک انٹرفیس سے UDP پیکٹس موصول کرتا ہے اور انہیں ایک ساکٹ تک پہنچاتا ہے، جو وہ آپریٹنگ سسٹم اینڈپوائنٹ ہوتا ہے جسے کوئی پروسیس IP:Port بائنڈ کرنے کے بعد پڑھتا ہے۔ ریلے یوزر اسپیس میں چلتا ہے، اس لیے ایک عام Go پروسیس اس ساکٹ سے پیکٹ ہیڈرز پڑھتا ہے، فلو اسٹیٹ کی تھوڑی مقدار کو اپ ڈیٹ کرتا ہے، اور WebRTC کو ٹرمینیٹ کیے بغیر پیکٹس فارورڈ کرتا ہے۔ ہمیں کسی کرنل-بائی پاس فریم ورک کی ضرورت نہیں پڑی، جو یوزر اسپیس پروسس کو زیادہ پیکٹ ریٹس کے لیے نیٹ ورک کیوز کو براہ راست پول کرنے دیتا ہے، لیکن ساتھ ہی آپریشنل کمپلیکسٹی بھی بڑھا دیتا ہے۔

اہم ڈیزائن انتخابات:

• کوئی پروٹوکول ٹرمینیشن نہیں: ریلے صرف STUN ہیڈرز/ufrag پارس کرتا ہے؛ یہ بعد کے DTLS، RTP، اور RTCP کے لیے کیشڈ اسٹیٹ استعمال کرتا ہے، اور پیکٹس کو اوپیک رکھتا ہے۔
• عارضی اسٹیٹ: یہ کلائنٹ ایڈریس سے ٹرانسیور ڈیسٹینیشن تک فلو اسٹیٹ اور آبزرویبیلٹی کے لیے ایک چھوٹا، شارٹ ٹائم آؤٹ والا، ان میموری میپ برقرار رکھتا ہے۔
• ہوریزنٹل اسکیل ایبلیٹی: متعدد ریلے انسٹینسز ایک لوڈ بیلنسر کے پیچھے متوازی طور پر چلتے ہیں۔ اسٹیٹ کوئی ہارڈ WebRTC اسٹیٹ نہیں ہوتی، اس لیے ری اسٹارٹس کی صورت میں ٹریفک میں بہت کم کمی ہوتی ہے اور فلو تیزی سے ریکور ہو جاتا ہے۔

کارکردگی کے اقدامات:

• SO_REUSEPORT ایک Linux ساکٹ آپشن ہے جو ایک ہی مشین پر متعدد ریلے ورکرز کو ایک ہی UDP پورٹ پر بائنڈ کرنے کی اجازت دیتا ہے۔ اس کے بعد کرنل آنے والے پیکٹس کو ان ورکرز میں ڈسٹری بیوٹ کر دیتا ہے، جس سے ایک سنگل ریڈ-لوپ بٹلنیک سے بچا جا سکتا ہے۔
• runtime.LockOSThread ہر UDP-ریڈنگ گوروتین کو ایک مخصوص OS تھریڈ کے ساتھ پن (pin) کر دیتا ہے۔ SO_REUSEPORT کے ساتھ مل کر یہ عام طور پر ایک ہی فلو (یعنی سورس اور ڈیسٹینیشن IP:Port اور پروٹوکول) کے پیکٹس کو ایک ہی CPU کور پر رکھنے میں مدد دیتا ہے، جس سے کیش لوکلٹی بہتر ہوتی ہے اور کانٹیکسٹ سوئچنگ کم ہو جاتی ہے۔
• پری-ایلوکیٹڈ بفرز اور کم سے کم کاپینگ پارسنگ اور ایلوکیشن اوور ہیڈ کو کم رکھتے ہیں تاکہ Go میں گاربیج کلیکشن سے بچا جا سکے۔

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

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

بڑا سبق یہ ہے کہ پیچیدگی شامل کرنے کی بہترین جگہ ایک پتلی روٹنگ لیئر ہوتی ہے، نہ کہ ہر بیک اینڈ سروس میں اور نہ ہی کسٹم کلائنٹ رویہ میں۔ روٹنگ میٹا ڈیٹا کو پروٹوکول-نیٹو فیلڈ میں انکوڈ کرنے سے ہمیں ڈیٹرمنسٹک فرسٹ-پیکٹ روٹنگ، ایک چھوٹا پبلک UDP فٹ پرنٹ، اور اتنی فلیکسیبیلٹی ملی کہ ہم دنیا بھر میں یوزرز کے قریب انگریس پلیس کر سکیں۔

چند انتخاب خاص طور پر اہم تھے:

• ایج پر پروٹوکول سیمینٹکس کو برقرار رکھنا۔ کلائنٹس اب بھی اسٹینڈرڈ WebRTC استعمال کرتے ہیں، جس سے براؤزر اور موبائل انٹرآپریبلٹی برقرار رہتی ہے۔
• مشکل سیشن اسٹیٹس کو ایک ہی جگہ رکھنا۔ ٹرانسیور ICE، DTLS، SRTP، اور سیشن لائف سائیکل کا مالک ہوتا ہے؛ جبکہ ریلے صرف پیکٹس کو فارورڈ کرتا ہے۔
• سیٹ اپ میں پہلے سے موجود معلومات پر روٹ کرنا۔ ICE ufrag نے ہمیں فرسٹ-پیکٹ روٹنگ ہُک دیا بغیر اس کے کہ ہم کوئی ہاٹ-پاتھ لک اپ ڈیپنڈنسی شامل کریں۔
• عام کیس کے لیے پہلے آپٹمائز کرنا، اس سے پہلے کہ کرنل بائی پاس کی طرف جایا جائے۔ ایک محدود Go امپلیمنٹیشن جس میں SO_REUSEPORT کا محتاط استعمال، تھریڈ پننگ، اور کم ایلوکیشن پارسنگ شامل تھی، ہمارے ورک لوڈ کے لیے کافی ثابت ہوئی۔

ریئل ٹائم وائس AI صرف اس وقت مؤثر طریقے سے کام کرتا ہے جب انفراسٹرکچر لیٹنسی کو تقریباً غیر محسوس بنا دے۔ ہمارے لیے اس کا مطلب یہ تھا کہ ہم اپنے WebRTC ڈیپلائمنٹ کی ساخت کو تبدیل کریں، لیکن کلائنٹس WebRTC سے جس چیز کی توقع رکھتے ہیں اسے تبدیل نہ کریں۔