OpenAI нь бага сааталтай дуут хиймэл оюун ухааныг хэрхэн өргөн хүрээнд хүргэдэг вэ

Дуу хоолойн AI зөвхөн яриа ярианы хурдтай явагдах үед л байгалийн мэт санагддаг. Сүлжээ саад болоход хүмүүс үүнийг эвгүй түр зогсолт, тасалдал, эсвэл саатал гэж шууд мэдэрдэг. Энэ нь ChatGPT дуу хоолой, Realtime API ашиглан бүтээж буй хөгжүүлэгчид, интерактив ажлын урсгалд ажилладаг агентууд болон хэрэглэгч ярьж байх үед аудио боловсруулах шаардлагатай загваруудад чухал юм.

OpenAI-ийн хэмжээнд энэ нь гурван тодорхой шаардлагыг илэрхийлж байна:

• Дэлхий даяар долоо хоногт 900 сая гаруй идэвхтэй хэрэглэгчтэй болсон
• Хурдан холболтын тохиргоо хийснээр хэрэглэгч харилцан яриа эхэлмэгц ярьж эхлэх боломжтой болно
• Медиа дамжуулалтын хугацаа бага, тогтвортой, чичиргээ болон пакет алдагдал багатай тул ээлжлэн авах нь цэвэрхэн мэдрэмж төрүүлдэг

Бодит цагийн хиймэл оюун ухааны харилцан үйлчлэлийг хариуцдаг OpenAI-ийн баг саяхан WebRTC стекийг маань гурван хязгаарлалтыг шийдвэрлэхийн тулд дахин зохион бүтээсэн: нэг сесс тутамд нэг порттой медиа төгсгөл нь OpenAI дэд бүтцэд сайн тохирохгүй, төлөвтэй ICE (Интерактив холболтын байгууламж) болон DTLS (Өгөгдлийн дамжуулалтын давхаргын аюулгүй байдал) сессүүд тогтвортой эзэмшил шаарддаг бөгөөд дэлхийн чиглүүлэлт нь эхний хопын хоцрогдолыг бага байлгах ёстой. Энэ бичлэгт бид OpenAI-ийн дэд бүтэц дотор пакетуудыг хэрхэн чиглүүлдэгийг өөрчлөхийн зэрэгцээ үйлчлүүлэгчдэд зориулсан стандарт WebRTC зан төлөвийг хадгалахын тулд бүтээсэн split relay plus transceiver архитектурыг авч үзэх болно.

WebRTC нь хөтөч, гар утасны апп болон серверүүдийн хооронд бага сааталтай аудио, видео болон өгөгдөл илгээх нээлттэй стандарт юм. Энэ нь ихэвчлэн үе тэнгийн дуудлагатай холбоотой байдаг ч энэ нь интерактив медиагийн хатуу хэсгүүдийг стандартчилдаг тул үйлчлүүлэгчээс сервер хүртэлх бодит цагийн системийн практик үндэс суурь болдог: холболт тогтоох болон NAT (Сүлжээний хаягийн орчуулга)-ын дамжуулалтад зориулсан ICE, шифрлэгдсэн дамжуулалтад зориулсан DTLS болон SRTP (Аюулгүй бодит цагийн тээврийн протокол), аудиог шахах болон декодлоход зориулсан кодекийн тохиролцоо, чанарын хяналтад зориулсан RTCP (Бодит цагийн тээврийн хяналтын протокол), мөн цуурай цуцлах болон чичиргээ буферлэх зэрэг үйлчлүүлэгч талын функцууд.

Стандартчилал нь хиймэл оюун ухааны бүтээгдэхүүний хувьд чухал ач холбогдолтой. WebRTC байхгүй бол үйлчлүүлэгч бүр NAT-уудын хооронд холболт тогтоох, медиаг шифрлэх, кодек (дамжуулах болон задлахад сонгосон кодлогч-декодлогч)-ийг хэрхэн тохиролцох, өөрчлөгдөж буй сүлжээний нөхцөлд дасан зохицох талаар өөр өөр хариулт авах шаардлагатай болно. WebRTC-ийн тусламжтайгаар бид хөтөч болон гар утасны платформуудад аль хэдийн хэрэгжсэн протоколын стек дээр тулгуурлан, бодит цагийн медиаг загваруудтай холбодог дэд бүтцэд өөрсдийн ажлаа төвлөрүүлж чадна.

Бид мөн WebRTC экосистем дээр тулгуурлан хөгжүүлдэг бөгөөд үүнд дэвшилтэт нээлттэй эхийн хэрэгжилтүүд болон хөтөч, гар утасны аппликейшн болон серверүүдийг харилцан ажиллах боломжтой байлгах стандарт ажил багтдаг. Жастин Уберти (WebRTC-ийн анхны архитекторуудын нэг) болон Шон ДуБуа (Pion-ийг бүтээгч, засвар үйлчилгээ үзүүлэгч) нарын үндсэн ажил нь манайх шиг багуудад доод түвшний тээвэрлэлт, шифрлэлт, түгжрэлийг хянах зан үйлийг дахин зохион бүтээхийн оронд тулалдаанд туршигдсан медиа дэд бүтцийг бий болгох боломжийг олгосон. Жастин, Шон хоёр одоо OpenAI-ийн хамтрагчид болж, WebRTC болон бодит цагийн хиймэл оюун ухааныг хэрхэн ойртуулах талаар бидэнд зөвлөгөө өгч байгаад бид азтай байна.

Хиймэл оюун ухааны хувьд хамгийн чухал шинж чанар бол аудио тасралтгүй урсгал хэлбэрээр ирдэг явдал юм. Ярианы агент нь хэрэглэгч бүрэн байршуулахыг хүлээхийн оронд ярьж байх үед нь хуулбарлах, эргэцүүлэн бодох, хэрэгслүүдийг дуудах эсвэл яриа үүсгэж эхлэх боломжтой. Энэ бол яриа өрнөж байгаа мэт санагддаг систем болон ярихын тулд товч дарах шаардлагатай систем хоёрын ялгаа юм.

Бид WebRTC-г сонгосны дараа дараагийн асуулт нь үүнийг хаана дуусгах (жишээлбэл, захын хэсэгт WebRTC холболтыг хаана хүлээн авч, эзэмших) болон эдгээр сессүүдийг дүгнэлтийн арын хэсэгт хэрхэн холбох вэ гэдэг байв. Дуусгавар болгох нь чухал ач холбогдолтой, учир нь энэ нь бидний бодит цагийн сессийн төлөв, медиа дамжуулалт, чиглүүлэлт, хоцрогдол, алдаа тусгаарлалтыг хэрхэн зохицуулахыг тодорхойлдог.

SFU буюу сонгомол дамжуулах нэгж нь оролцогч бүрээс нэг WebRTC урсгалыг хүлээн авч, урсгалыг сонгон бусдад дамжуулдаг медиа сервер юм. Энэ загварт SFU нь оролцогч бүрийн хувьд тусдаа WebRTC холболтыг зогсоодог бөгөөд хиймэл оюун ухаан нь сессэд өөр оролцогчоор нэгддэг. Энэ нь төрөлхийн олон талын шинжтэй бүтээгдэхүүнүүдэд, жишээлбэл бүлгийн дуудлага, ангийн танхим эсвэл хамтын уулзалтуудад тохиромжтой байж болно. Энэ нь аудио кодек, RTCP мессеж, өгөгдлийн сувгууд, бичлэг болон урсгал тус бүрийн бодлогыг ^нэгдор хадгалдаг.

Үйлчлүүлэгчээс хиймэл оюун ухаан руу чиглэсэн бүтээгдэхүүнүүдэд ч гэсэн SFU нь ихэвчлэн анхдагч эхлэлийн цэг болдог, учир нь энэ нь багуудад дохиолол, медиа чиглүүлэлт, бичлэг, ажиглалт, хүний гарын авлага эсвэл оролцогчдыг нэмэх зэрэг ирээдүйн өргөтгөлүүдэд нэг батлагдсан системийг дахин ашиглах боломжийг олгодог.

Бидний ажлын ачаалал өөр. Ихэнх сессүүд нь 1:1 харьцаатай байдаг бөгөөд нэг хэрэглэгч нэг загвартай эсвэл нэг програм нэг бодит цагийн агенттай ярилцдаг бөгөөд ээлж бүрт хоцрогдол мэдрэг байдаг. Энэ хэлбэрийн урсгалын хувьд бид дамжуулагч загварыг сонгосон: WebRTC захын үйлчилгээ нь клиент холболтыг зогсоож, дараа нь медиа болон үйл явдлуудыг загварын дүгнэлт, транскрипц, яриа үүсгэх, багаж хэрэгсэл ашиглах, найрал хөгжимд зориулж илүү энгийн дотоод протокол болгон хөрвүүлдэг.

Энэ дизайнд транссивер нь ICE холболтын шалгалтууд, DTLS гар барилт, SRTP шифрлэлтийн түлхүүрүүд болон сешний амьдралын мөчлөгийг багтаасан WebRTC сешний төлөвийг эзэмшдэг цорын ганц үйлчилгээ юм. "Дуусгавар болгох" гэдэг нь дамжуулагч нь эдгээр гар барих үйлдлийг гүйцээж, медиаг шифрлэх эсвэл тайлах төгсгөлийн цэг гэсэн үг юм. Энэ төлөвийг нэг дор байлгах нь сессийн эзэмшлийн талаар бодоход хялбар болгосон бөгөөд энэ нь backend үйлчилгээнүүдийг WebRTC-ийн үе тэнгийнхэн шиг ажиллахын оронд ердийн үйлчилгээ шиг өргөжүүлэх боломжийг олгосон.

Трансивер загварыг сонгосны дараа бидний анхны хэрэгжүүлэлт бол дохиолол болон медиа төгсгөлийг хоёуланг нь зохицуулдаг Pion дээр бүтээгдсэн цорын ганц Go үйлчилгээ байсан. Энэ нь ChatGPT дуу хоолой, Realtime API-ийн WebRTC төгсгөлийн цэг болон хэд хэдэн судалгааны төслүүдийг дэмждэг.

Үйл ажиллагааны хувьд дамжуулагч үйлчилгээ нь хоёр ажлыг гүйцэтгэдэг:

• Дохио дамжуулах: SDP хэлэлцээр, кодек сонгох, ICE итгэмжлэлүүд болон сессийн тохиргоо
• Медиа: Доод урсгалын WebRTC холболтыг тасалдуулж, дүгнэлт болон найралчлалын зорилгоор backend үйлчилгээтэй дээд урсгалын холболтыг хадгалах

Бид үйлчилгээгээ бусад дэд бүтцийн адил ажиллуулахыг хүссэн: Kubernetes дээр, ажлын ачаалал нэмэгдэж, буурч, эрэлт өөрчлөгдөхийн хэрээр хостууд хооронд шилжих боломжтой байгаасай гэж хүссэн. Гэхдээ нэг сесс тутамд нэг порттой уламжлалт WebRTC загвар нь уг орчинд муу тохирдог, учир нь энэ нь под нэмэх, хасах эсвэл дахин хуваарь гаргах үед ил гаргах, аюулгүй болгох, хадгалахад хэцүү олон нийтийн UDP портын хүрээнээс хамаардаг.²

Эхний асуудал нь нэг сесс тутамд нэг порттой загвар өөрөө байсан юм. Өндөр зэрэгцээ үед энэ нь маш том UDP портын хүрээг ил гаргаж, удирдах гэсэн үг юм.

• Үүлэн ачааллын тэнцвэржүүлэгч болон Kubernetes үйлчилгээнүүдийг үйлчилгээ тус бүрт хэдэн арван мянган нийтийн UDP порттой холбож бүтээгээгүй. Нэмэлт хүрээ бүр нь ачааллын тэнцвэржүүлэгчийн тохиргоо, эрүүл мэндийн шалгалт, галт ханын бодлого болон нэвтрүүлэх аюулгүй байдлын үйл ажиллагааны нарийн төвөгтэй байдлыг нэмэгдүүлдэг.³
• Том хэмжээний UDP портын хүрээг аюулгүй болгоход хэцүү байдаг, учир нь тэдгээр нь гаднаас хүрч болох гадаргуугийн талбайг тэлж, сүлжээний бодлогыг аудит хийхэд хэцүү болгодог.
• Тэд мөн автомат масштаблахад тохиромжгүй. Kubernetes дээр подуудыг байнга нэмж, хасаж, дахин хуваарьлуулдаг. Под бүрийг том, тогтвортой портын хүрээг нөөцлөх, сурталчлахыг шаардах нь уян хатан чанарыг хэврэг болгодог.⁴

Тийм ч учраас олон WebRTC системүүд сервер бүрт ганц UDP порт руу шилждэг бөгөөд уг портын ард програмын түвшний демультиплекс хийгддэг.⁵

Сервер тус бүрт нэг порт ашиглах загвар нь портын тоог шийддэг боловч хоёр дахь асуудлыг бий болгодог: флот даяар сесс бүрийн эзэмшлийг хадгалах.

ICE болон DTLS нь төлөвт протоколууд юм. Сесс үүсгэсэн процесс нь холболтын шалгалтыг баталгаажуулах, DTLS гар барих ажиллагааг гүйцэтгэх, SRTP-г тайлах, ICE дахин эхлүүлэх гэх мэт дараагийн сессийн өөрчлөлтүүдийг боловсруулахын тулд тухайн сессийн пакетуудыг хүлээн авсаар байх шаардлагатай. Хэрэв нэгэн ижил сессийн пакетууд өөр процесс дээр ирэх юм бол тохиргоо бүтэлгүйтэж эсвэл медиа тасалдаж болно.

Энэ нь бидэнд тодорхой зорилт тавьсан: жижиг, тогтмол UDP гадаргууг олон нийтийн интернетэд гаргахын зэрэгцээ бүх пакетийг харгалзах WebRTC сессийг эзэмшдэг дамжуулагч руу чиглүүлэх.

Бид тийшээ хүрэх хэд хэдэн аргыг үнэлсэн бөгөөд үүнд захын реле нь үйлчлүүлэгчийн хуваарилалтыг зогсоож, тэдний өмнөөс урсгалыг дамжуулдаг TURN (NAT-ийн эргэн тойронд реле ашиглан транзит хийх) орно.²

Бидний илгээсэн архитектур нь пакет чиглүүлэлтийг протоколын төгсгөлөөс хуваадаг. Дохио нь сессийн тохиргоонд зориулж дамжуулагч руу хүрсээр байх бол медиа эхлээд релеээр дамждаг. Реле нь бага хэмжээний нийтийн эзэмшлийн талбайтай хөнгөн UDP дамжуулалтын давхарга бөгөөд дамжуулагч нь түүний ард байрлах төлөвт WebRTC төгсгөлийн цэг юм.

Реле нь медиаг тайлах, ICE төлөвийн машинуудыг ажиллуулах эсвэл кодекийн тохиролцоо хийхэд оролцохгүй. Энэ нь очих газрыг сонгоход хангалттай хэмжээний пакет мета өгөгдлийг уншиж, дараа нь пакетийг сессийг эзэмшдэг дамжуулагч руу дамжуулдаг. Трансивер нь хэвийн WebRTC урсгалыг харсаар байгаа бөгөөд бүх протоколын төлөвийг эзэмшсээр байна. Үйлчлүүлэгчийн үүднээс авч үзвэл WebRTC сессийн талаар юу ч өөрчлөгддөггүй.

Эхний пакет чиглүүлэлт нь энэ тохиргооны гол алхам юм. Реле нь гадаад хайлтын үйлчилгээ дээр түр зогсоохын оронд ямар нэгэн сесс пакетийн зам дээр байхаас өмнө клиентээс ирсэн эхний пакетийг чиглүүлэх ёстой.

WebRTC сесс бүр протоколын төрөлх чиглүүлэлтийн дэгээтэй байдаг: ICE хэрэглэгчийн нэрийн фрагмент буюу ufrag, энэ нь сессийн тохиргооны үеэр солилцдог бөгөөд STUN холболтын шалгалтанд давтагддаг богино танигч юм. Бид сервер талын ufrag-ийг үүсгэдэг бөгөөд ингэснээр энэ нь очих кластер болон эзэмшлийн дамжуулагчийг тодорхойлоход релейд хангалттай чиглүүлэлтийн мета өгөгдлийг агуулдаг.

Дохио дамжуулах үед дамжуулагч нь сессийн төлөвийг хуваарилж, SDP хариултад хуваалцсан реле VIP болон UDP портыг буцаана. VIP нь реле флотын урд байрлах виртуал IP хаяг юм; порттой хослуулан энэ нь үйлчлүүлэгчдэд `203.0.113.10:3478` гэх мэт ганц тогтвортой очих газрыг өгдөг боловч олон реле инстансууд үүний ард байрладаг. Үйлчлүүлэгчийн анхны медиа замын пакет нь ихэвчлэн STUN (NAT-д зориулсан Session Traversal Utilities) холболтын хүсэлт байдаг бөгөөд ICE нь пакетууд зарлагдсан хаягт хүрч чадах эсэхийг баталгаажуулахын тулд ашигладаг.

Релей нь серверийн Ufrag-г уншиж, чиглүүлэлтийн зөвлөмжийг тайлж, пакетийг эзэмшигч дамжуулагч руу дамжуулахын тулд эхний STUN пакетыг хангалттай хэмжээгээр задлан шинжилдэг. Трансивер бүр хуваалцсан UDP сокет дээр сонсдог бөгөөд энэ нь нэг үйлдлийн системийн төгсгөлийн цэг нь сесс бүрт нэг сокет биш, харин дотоод IP:порт руу холбогдсон гэсэн үг юм. Реле нь үйлчлүүлэгчийн эх үүсвэрийн IP:портоос тухайн дамжуулагчийн очих газар руу сесс үүсгэсний дараа дараагийн DTLS, RTP, болон RTCP пакетууд нь ufrag-ийг дахин декодлохгүйгээр сесс дотор урсдаг.

Релеийн сесси зориуд маш бага бөгөөд зөвхөн санах ойд багцыг дамжуулах сесс, хяналтын тоолуур, сессийн хугацаа дуусах, цэвэрлэгээний таймеруудаас бүрддэг. Энэхүү дизайны сонголт нь пакетийн чиглүүлэлтийг пакетийн зам дээр шууд хадгална. Хэрэв реле дахин эхлүүлж, сессийг алдвал дараагийн STUN пакет нь ufrag чиглүүлэлтийн зөвлөмжөөс сессийг дахин бүтээнэ. Үүнийг бүр ч найдвартай болгохын тулд маршрут тогтоогдсоны дараа <клиент IP + Порт, дамжуулагч IP + Порт> -ын зураглалыг хадгалахын тулд Redis кэшийг ашигладаг бөгөөд ингэснээр дараагийн STUN пакет ирэхээс өмнө хамаагүй эрт сэргээгдэх боломжтой болно.

Бид нийтийн UDP гадаргууг цөөн тооны тогтвортой хаяг болон порт болгон бууруулсны дараа дэлхий даяар ижил релений загварыг байршуулж чадна. Global Relay нь газарзүйн хувьд тархсан релений оролтын цэгүүдийн багц бөгөөд бүгд ижил пакет дамжуулах зан үйлийг хэрэгжүүлдэг.

Өргөн хүрээтэй газарзүйн оролт нь клиентээс OpenAI руу шилжих эхний үеийг богиносгодог, учир нь пакет нь нийтийн интернетийг алслагдсан бүс рүү түрүүлж нэвтрэхийн оронд газарзүй болон сүлжээний топологийн аль алинд нь хэрэглэгчтэй ойрхон реле ашиглан манай сүлжээнд орж болно. Практик утгаараа энэ нь урсгал бидний голомтод хүрэхээс өмнө бага хоцрогдол, бага чичиргээ, зайлсхийх боломжтой алдагдлын тэсрэлт бага гэсэн үг юм.⁶

Бид дохиололд Cloudflare газарзүйн болон ойрын зайн удирдлагыг ашигладаг тул анхны HTTP эсвэл WebSocket хүсэлт нь ойролцоох дамжуулагч кластерт хүрдэг. Хүсэлтийн контекст нь сессийн байршил болон үйлчлүүлэгчид аль Global Relay оролтын цэгийг сурталчлахыг тодорхойлдог. SDP хариулт нь Global Relay хаягийг өгдөг бол ufrag нь Global Relay-д медиаг тодорхойлсон кластер руу чиглүүлэх, релег очих дамжуулагч руу чиглүүлэхэд хангалттай мэдээллийг агуулдаг.

Газарзүйн удирдлагатай дохиолол болон Global Relay нь хамтдаа тохиргоо болон медиаг ойролцоох оролтын зам дээр байрлуулж, сессийг нэг дамжуулагчтай холбосон. Энэ нь дохиолол болон ICE холболтын анхны шалгалтын хоёр талын хугацааг багасгадаг бөгөөд энэ нь хэрэглэгч яриа эхлэхээс өмнө хэр удаан хүлээхийг шууд богиносгодог.

Бид релей үйлчилгээг Go дээр бичиж, хэрэгжүүлэлтийг зориудаар нарийсгасан. Линукс дээр цөмийн сүлжээний стек нь машины сүлжээний интерфэйсээс UDP пакетуудыг хүлээн авч, тэдгээрийг IP:Портыг холбосны дараа процесс уншдаг үйлдлийн системийн төгсгөлийн цэг болох сокет руу дамжуулдаг. Реле нь хэрэглэгчийн орон зайд ажилладаг тул ердийн Go процесс нь тухайн сокетоос пакетийн толгойнуудыг уншиж, бага хэмжээний урсгалын төлөвийг шинэчилж, WebRTC-г дуусгахгүйгээр пакетуудыг дамжуулдаг. Бидэнд хэрэглэгчийн орон зайд өндөр пакетийн хурд авахын тулд сүлжээний дарааллыг шууд боловсруулах боломжийг олгодог цөмийг тойрч гарах ямар ч систем хэрэггүй байсан бөгөөд энэ нь үйл ажиллагааны нарийн төвөгтэй байдлыг нэмэгдүүлдэг байв.

Гол дизайны сонголтууд:

• Протоколын төгсгөл байхгүй: Реле нь зөвхөн STUN толгой/ufrag-г задлан шинжилдэг; энэ нь дараагийн DTLS, RTP, болон RTCP-д кэшлэгдсэн төлөвийг ашигладаг бөгөөд пакетуудыг тунгалаг бус байлгадаг.
• Түр зуурын төлөв: Энэ нь урсгалын төлөв болон ажиглагдах байдлыг хангахын тулд дамжуулагчийн очих газар хүртэлх үйлчлүүлэгчийн хаягийн жижиг, богино хугацааны, санах ойн доторх газрын зургийг хадгалдаг.
• Хэвтээ өргөтгөх чадвар: Ачаалал тэнцвэржүүлэгчийн ард олон реле зэрэгцээ ажилладаг. Төлөв нь WebRTC-д хэцүү биш тул дахин ачаалах нь урсгалын уналтыг хамгийн бага байлгаж, урсгалыг хурдан сэргээхэд хүргэдэг.

Үр ашгийн хэмжүүрүүд:

• SO_REUSEPORT нь нэг машин дээрх олон реле ажилчдад нэг UDP портыг холбох боломжийг олгодог Linux сокет сонголт юм. Дараа нь цөм нь ирж буй пакетуудыг эдгээр ажилчдын дунд тараадаг бөгөөд энэ нь ганц унших давталтын саад тотгороос зайлсхийдэг.
• runtime.LockOSThread UDP унших горутин бүрийг тодорхой үйлдлийн системийн урсгалд холбодог. SO_REUSEPORT той хослуулсан нь пакетуудыг ижил CPU цөм дээр ижил урсгалаас (эх үүсвэр болон очих IP:Port plus протокол) хол байлгаж, кэшийн байршлыг сайжруулж, контекст шилжүүлэлтийг бууруулдаг.
• Урьдчилан хуваарилагдсан буферууд болон хамгийн бага хуулбарлалт нь Go дээр хог хаягдлын цуглуулгаас зайлсхийхийн тулд задлан шинжлэх болон хуваарилалтын ачааллыг бага байлгадаг.

Энэхүү хэрэгжилт нь бидний дэлхийн бодит цагийн медиа урсгалыг харьцангуй бага релений ул мөрөөр зохицуулсан тул бид цөмийн тойрч гарах замыг ашиглахын оронд илүү энгийн загварыг хадгалсан.

Энэхүү архитектур нь бидэнд мянга мянган UDP портуудыг ил гаргахгүйгээр WebRTC медиаг Kubernetes дээр ажиллуулах боломжийг олгодог. Энэ нь чухал юм, учир нь жижиг, тогтмол UDP гадаргуу нь бэхлэхэд болон ачааллыг тэнцвэржүүлэхэд илүү хялбар байдаг бөгөөд энэ нь олон нийтийн портын томоохон хүрээг хадгалахгүйгээр дэд бүтцийг өргөжүүлэх боломжийг олгодог. Kubernetes-ийн илүү сайн дэд бүтцийн дэмжлэг болон жижиг гадаргуугийн талбайгаас шалтгаалан илүү аюулгүй байдлын ачаар энэхүү загвар нь үйлчлүүлэгчдэд зориулсан WebRTC-ийн стандарт зан төлөвийг хадгалж, SFU-гүй загвар нь бидний ажлын ачааллын хувьд зөв анхдагч байсан гэдгийг баталж байна. Бидний ихэнх сессүүд нь цэгээс цэгт чиглэсэн, хоцрогдолд мэдрэмтгий бөгөөд дүгнэлтийн үйлчилгээ нь WebRTC-ийн үе тэнгийнхэн шиг ажиллах шаардлагагүй үед өргөжүүлэхэд хялбар байдаг.

Илүү өргөн хүрээтэй сургамж бол нарийн төвөгтэй байдлыг нэмэх хамгийн сайн газар бол бүх арын үйлчилгээнд биш, мөн үйлчлүүлэгчийн өөрчлөн тохируулсан зан төлөвт биш харин нимгэн чиглүүлэлтийн давхарга юм. Чиглүүлэлтийн мета өгөгдлийг протоколын уугуул талбарт кодлох нь бидэнд тодорхойлогдсон эхний пакет чиглүүлэлт, бага хэмжээний нийтийн UDP ул мөр, дэлхий даяарх хэрэглэгчдэд ойрхон байршуулах хангалттай уян хатан байдлыг өгсөн.

Хэд хэдэн сонголт онцгой чухал байсан:

• Протоколын семантикийг захын хэсэгт хадгал. Үйлчлүүлэгчид нь хөтөч болон гар утасны харилцан үйлчлэлийг бүрэн бүтэн байлгадаг стандарт WebRTC дээр ярьдаг хэвээр байна.
• Хатуу сессийн төлөвүүдийг нэг дор байлга. Transceiver нь ICE, DTLS, SRTP болон сессийн амьдралын мөчлөгийг эзэмшдэг; зөвхөн пакетуудыг дамжуулдаг.
• Тохиргоонд аль хэдийн байгаа мэдээллийг чиглүүлэх. ICE ufrag нь hot-path хайлтын хамаарал нэмэлгүйгээр эхний пакетийн чиглүүлэлтийн hook-ийг бидэнд олгосон.
• Kernel bypass ашиглахаас өмнө нийтлэг тохиолдолд оновчлол хий. SO_REUSEPORT болгоомжтой ашиглах, thread pinning болон бага хуваарилалтын задлан шинжлэх зэрэг нарийн Go хэрэгжүүлэлт нь бидний ажлын ачааллыг нөхөхөд хангалттай байсан.

Бодит цагийн дуут хиймэл оюун ухаан нь дэд бүтэц нь хоцрогдолыг үл үзэгдэх мэт мэдрүүлэх үед л ажилладаг. Бидний хувьд энэ нь үйлчлүүлэгчид WebRTC-ээс юу хүлээж байгааг өөрчлөхгүйгээр WebRTC байршуулалтын хэлбэрийг өөрчлөх гэсэн үг юм.