OpenAI తక్కువ లేటెన్సీ వాయిస్ AIని విస్తృత స్థాయిలో ఎలా అందిస్తుంది

సంభాషణ మాటల వేగంతో ముందుకు సాగితేనే వాయిస్ AI సహజంగా అనిపిస్తుంది. నెట్‌వర్క్ అడ్డుపడినప్పుడు, అది అసహజమైన విరామాలు, మధ్యలో తెగిపోయే అంతరాయాలు లేదా ఆలస్యంగా జరిగే బార్జ్-ఇన్‌లా ప్రజలకు వెంటనే వినిపిస్తుంది. ఇది ChatGPT వాయిస్‌కు, Realtime APIతో నిర్మిస్తున్న డెవలపర్‌లకు, ఇంటరాక్టివ్ వర్క్‌ఫ్లోల్లో పని చేసే ఏజెంట్లకు, అలాగే వినియోగదారు ఇంకా మాట్లాడుతూనే ఉన్నప్పుడు ఆడియోను ప్రాసెస్ చేయాల్సిన మోడల్‌కు ముఖ్యమైనది.

OpenAI స్థాయిలో, అది మూడు నిర్దిష్ట అవసరాలుగా మారుతుంది:

• 900 మిలియన్‌కు పైగా వీక్లీ యాక్టివ్ యూజర్లతో గ్లోబల్ రీచ్
• సెషన్ ప్రారంభమైన వెంటనే యూజర్ మాట్లాడటం ప్రారంభించగలిగేలా వేగవంతమైన కనెక్షన్ సెటప్
• తక్కువ మరియు స్థిరమైన మీడియా రౌండ్-ట్రిప్ సమయం, తక్కువ జిట్టర్ మరియు ప్యాకెట్ నష్టంతో, టర్న్-టేకింగ్ చురుకుగా అనిపిస్తుంది

రియల్-టైమ్ AI పరస్పర చర్యలకు బాధ్యత వహించే OpenAI బృందం, స్కేల్‌లో ఒకదానితో ఒకటి ఢీకొనడం ప్రారంభించిన మూడు పరిమితులను పరిష్కరించడానికి ఇటీవల మా WebRTC స్టాక్‌ను మళ్లీ ఆర్కిటెక్ట్ చేసింది: ప్రతి సెషన్‌కు ఒక పోర్ట్ అనే మీడియా టర్మినేషన్ OpenAI ఇన్‌ఫ్రాస్ట్రక్చర్‌కు బాగా సరిపోదు, స్టేట్‌ఫుల్ ICE (ఇంటరాక్టివ్ కనెక్టివిటీ ఎస్టాబ్లిష్‌మెంట్) మరియు DTLS (డేటాగ్రామ్ ట్రాన్స్‌పోర్ట్ లేయర్ సెక్యూరిటీ) సెషన్‌లకు స్థిరమైన ఓనర్‌షిప్ అవసరం, అలాగే గ్లోబల్ రూటింగ్ ఫస్ట్-హాప్ లేటెన్సీని తక్కువగా ఉంచాలి. ఈ పోస్ట్‌లో, OpenAI ఇన్‌ఫ్రాస్ట్రక్చర్‌లో ప్యాకెట్‌లు ఎలా రూట్ చేయబడతాయో మార్చుతూనే, క్లయింట్‌ల కోసం ప్రామాణిక WebRTC ప్రవర్తనను కాపాడేందుకు మేం నిర్మించిన విభజిత రిలే ప్లస్ ట్రాన్స్‌సీవర్ ఆర్కిటెక్చర్‌ను వివరిస్తాం.

WebRTC అనేది బ్రౌజర్లు, మొబైల్ యాప్స్, మరియు సర్వర్ల మధ్య తక్కువ లేటెన్సీ ఆడియో, వీడియో, మరియు డేటాను పంపడానికి ఓపెన్ స్టాండర్డ్. ఇది తరచుగా పీర్-టు-పీర్ కాలింగ్‌తో అనుబంధించబడుతుంది, కానీ క్లయింట్-టు-సర్వర్ రియల్-టైమ్ సిస్టమ్‌లకు కూడా ఇది ఒక ప్రాక్టికల్ పునాదిగా ఉంటుంది, ఎందుకంటే ఇది ఇంటరాక్టివ్ మీడియా యొక్క కఠినమైన భాగాలను ప్రమాణీకరిస్తుంది: కనెక్టివిటీ స్థాపన మరియు NAT (నెట్‌వర్క్ అడ్రస్ ట్రాన్స్‌లేషన్) ట్రావర్సల్ కోసం ICE, ఎన్‌క్రిప్టెడ్ ట్రాన్స్‌పోర్ట్ కోసం DTLS మరియు SRTP (సురక్షిత రియల్-టైమ్ ట్రాన్స్‌పోర్ట్ ప్రోటోకాల్), ఆడియోను కంప్రెస్ చేసి డీకోడ్ చేయడానికి కోడెక్ నెగోషియేషన్, క్వాలిటీ కంట్రోల్ కోసం RTCP (రియల్-టైమ్ ట్రాన్స్‌పోర్ట్ కంట్రోల్ ప్రోటోకాల్), మరియు ఎకో క్యాన్సిలేషన్, జిట్టర్ బఫరింగ్ వంటి క్లయింట్-సైడ్ ఫీచర్స్.

ఆ ప్రామాణీకరణ AI ప్రోడక్ట్‌లకు ముఖ్యమైనది. WebRTC లేకుండా, ప్రతి క్లయింట్‌కు NATs అంతటా కనెక్టివిటీని ఎలా ఏర్పాటు చేయాలి, మీడియాను ఎలా ఎన్క్రిప్ట్ చేయాలి, ప్రసారం మరియు డీకంప్రెషన్ కోసం ఎంపిక చేసిన కోడెక్‌లను ఎలా నెగోషియేట్ చేయాలి మరియు మారుతున్న నెట్‌వర్క్ పరిస్థితులకు ఎలా అనుకూలించాలి అనే విషయాల్లో వేరే పరిష్కారం అవసరం అవుతుంది. WebRTCతో, బ్రౌజర్‌లు మరియు మొబైల్ ప్లాట్‌ఫారమ్‌ల వ్యాప్తంగా ఇప్పటికే అమలు చేయబడిన ప్రోటోకాల్ స్టాక్‌ను ఆధారంగా చేసుకుని, రియల్‌టైమ్ మీడియాను మోడల్‌లకు కనెక్ట్ చేసే మౌలిక సదుపాయంపై మా స్వంత పనిని కేంద్రీకరించగలము.

బ్రౌజర్‌లు, మొబైల్ యాప్‌లు మరియు సర్వర్‌లు పరస్పరం పనిచేసేలా ఉంచే పరిపక్వమైన ఓపెన్-సోర్స్ అమలీకరణలు మరియు ప్రమాణాల సంబంధిత పనితో సహా, మేము WebRTC ఎకోసిస్టమ్‌పైనే కూడా ఆధారపడి నిర్మిస్తాము. WebRTC యొక్క అసలు ఆర్కిటెక్ట్‌లలో ఒకరైన Justin Uberti మరియు Pion సృష్టికర్త, మెయింటైనర్ అయిన Sean DuBois చేసిన పునాది స్థాయి కృషి వల్ల, మా వంటి టీమ్స్ లో-లెవల్ ట్రాన్స్‌పోర్ట్, ఎన్‌క్రిప్షన్, మరియు కంజెషన్-కంట్రోల్ ప్రవర్తనను మళ్లీ ఆవిష్కరించాల్సిన అవసరం లేకుండా, వాస్తవ పరిస్థితుల్లో నిరూపితమైన మీడియా ఇన్‌ఫ్రాస్ట్రక్చర్‌పై నిర్మించగలిగాయి. Justin మరియు Sean ఇద్దరూ ఇప్పుడు ఇక్కడ OpenAIలో మా సహోద్యోగులుగా ఉండటం మా అదృష్టం; WebRTC మరియు రియల్-టైమ్ AIని మరింత దగ్గరగా తీసుకురావడంలో ఎలా ముందుకు సాగాలో మార్గనిర్దేశం చేయడంలో వారు సహాయపడుతున్నారు.

AI కోసం, ఆడియో నిరంతర స్ట్రీమ్‌గా అందడం అత్యంత ముఖ్యమైన లక్షణం. పూర్తి అప్‌లోడ్ కోసం వేచి ఉండకుండా, యూజర్ ఇంకా మాట్లాడుతుండగానే స్పోకెన్ ఏజెంట్ ట్రాన్స్‌క్రిప్ట్ చేయడం, రిజనింగ్, టూల్స్‌ను పిలవడం లేదా స్పీచ్‌ను ఉత్పత్తి చేయడం ప్రారంభించగలదు. ఇది సంభాషణాత్మకంగా అనిపించే సిస్టమ్ మరియు పుష్-టు-టాక్‌లా అనిపించే సిస్టమ్ మధ్య తేడా.

మేము WebRTCని ఎంచుకున్న తర్వాత, తదుపరి ప్రశ్న దాన్ని ఎక్కడ టెర్మినేట్ చేయాలి — అంటే WebRTC కనెక్షన్‌ను మేము ఎక్కడ స్వీకరించి నిర్వహించాలి, ఉదాహరణకు ఎడ్జ్ వద్ద — మరియు ఆ సెషన్‌లను ఇన్‌ఫరెన్స్ బ్యాక్‌ఎండ్‌కు ఎలా కనెక్ట్ చేయాలి అనేది. టర్మినేషన్ ముఖ్యం, ఎందుకంటే ఇది రియల్-టైమ్ సెషన్ స్థితి, మీడియా ట్రాన్స్‌పోర్ట్, రూటింగ్, లేటెన్సీ, మరియు వైఫల్య ఐసోలేషన్‌ను మనం ఎలా నిర్వహిస్తామో నిర్ణయిస్తుంది.

SFU, లేదా సెలెక్టివ్ ఫార్వర్డింగ్ యూనిట్, ప్రతి పాల్గొనేవారి నుండి ఒక WebRTC స్ట్రీమ్‌ను స్వీకరించి, ఇతరులకు స్ట్రీమ్‌లను ఎంపిక చేసి ఫార్వర్డ్ చేసే మీడియా సర్వర్. ఈ మోడల్‌లో, SFU ప్రతి పాల్గొనేవారి కోసం ఒక ప్రత్యేక WebRTC కనెక్షన్‌ను టర్మినేట్ చేస్తుంది, మరియు AI సెషన్‌లో మరో పాల్గొనేవారిగా చేరుతుంది. అది గ్రూప్ కాల్స్, తరగతి గదులు లేదా సహకార సమావేశాలు వంటి స్వభావతహా బహుళ పక్షాల ప్రోడక్ట్‌లకు బాగా సరిపోతుంది. ఇది ఆడియో కోడెక్‌లు, RTCP సందేశాలు, డేటా ఛానెల్స్, రికార్డింగ్, మరియు ప్రతి స్ట్రీమ్ పాలసీని ఒకే చోట ఉంచుతుంది.¹

క్లయింట్-టు-AI ప్రోడక్ట్‌లలో కూడా, SFU తరచుగా డిఫాల్ట్ ప్రారంభ బిందువుగా ఉంటుంది, ఎందుకంటే ఇది సిగ్నలింగ్, మీడియా రూటింగ్, రికార్డింగ్, పరిశీలన సామర్థ్యం, మరియు మానవునికి హ్యాండ్‌ఆఫ్ చేయడం లేదా మరిన్ని పాల్గొనేవారిని చేర్చడం వంటి భవిష్యత్ విస్తరణల కోసం ఒకే నిరూపితమైన సిస్టమ్‌ను టీమ్‌లు తిరిగి ఉపయోగించుకునేలా చేస్తుంది.

మా పనిభారం వేరుగా ఉంది. చాలా సెషన్స్ 1:1—ఒక యూజర్ ఒక మోడల్‌తో మాట్లాడటం లేదా ఒక అప్లికేషన్ ఒక రియల్-టైమ్ ఏజెంట్‌తో మాట్లాడటం—ప్రతి టర్న్‌లో లేటెన్సీ పట్ల సున్నితంగా ఉంటుంది. ఆ ట్రాఫిక్ స్వభావానికి అనుగుణంగా, మేము ట్రాన్స్‌సీవర్ మోడల్‌ను ఎంచుకున్నాము: WebRTC ఎడ్జ్ సర్వీస్ క్లయింట్ కనెక్షన్‌ను టెర్మినేట్ చేసి, ఆపై మీడియా మరియు ఈవెంట్‌లను మోడల్ ఇన్‌ఫరెన్స్, ట్రాన్స్‌క్రిప్షన్, స్పీచ్ జనరేషన్, టూల్ వినియోగం మరియు ఆర్కెస్ట్రేషన్ కోసం సరళమైన అంతర్గత ప్రోటోకాల్స్‌గా మార్చుతుంది.

ఈ డిజైన్‌లో, ట్రాన్స్‌సీవర్ మాత్రమే ICE కనెక్టివిటీ తనిఖీలు, DTLS హ్యాండ్‌షేక్, SRTP ఎన్‌క్రిప్షన్ కీలు మరియు సెషన్ జీవితచక్రంతో సహా WebRTC సెషన్ స్థితిని కలిగి ఉంటుంది. ఇక్కడ “Termination” అంటే, ట్రాన్స్‌సీవర్ అనేది ఆ హ్యాండ్‌షేక్‌లను పూర్తి చేసి, మీడియాను ఎన్‌క్రిప్ట్ లేదా డీక్రిప్ట్ చేసే ఎండ్‌పాయింట్ అని అర్థం. ఆ స్థితిని ఒకే చోట ఉంచడం వల్ల సెషన్ యాజమాన్యం గురించి అర్థం చేసుకోవడం సులభమైంది, అలాగే బ్యాక్‌ఎండ్ సర్వీసులు స్వయంగా WebRTC పీర్‌లుగా వ్యవహరించకుండా సాధారణ సర్వీసుల్లా స్కేల్ అవ్వడానికి వీలు కలిగింది.

ట్రాన్స్‌సీవర్ మోడల్‌ను ఎంచుకున్న తర్వాత, మా మొదటి అమలు Pion పై నిర్మించిన ఒకే Go సర్వీస్‌గా ఉంది, ఇది సిగ్నలింగ్ మరియు మీడియా టెర్మినేషన్ రెండింటినీ నిర్వహించింది. ఇది ChatGPT వాయిస్, రియల్‌టైమ్ API యొక్క WebRTC ఎండ్‌పాయింట్, అలాగే అనేక పరిశోధన ప్రాజెక్ట్‌లకు ఆధారంగా పనిచేస్తుంది.

ఆపరేషనల్‌గా, ట్రాన్స్‌సీవర్ సేవ రెండు పనులు చేస్తుంది:

• సిగ్నలింగ్: SDP నెగోషియేషన్, కోడెక్ ఎంపిక, ICE క్రెడెన్షియల్స్, మరియు సెషన్ సెటప్
• మీడియా: డౌన్‌స్ట్రీమ్ WebRTC కనెక్షన్‌లను ముగించడం మరియు ఇన్‌ఫరెన్స్, ఆర్కెస్ట్రేషన్ కోసం బ్యాకెండ్ సర్వీస్‌లకు అప్‌స్ట్రీమ్ కనెక్షన్‌లను కొనసాగించడం

మేము ఈ సర్వీస్‌ను మా మిగతా ఇన్‌ఫ్రాస్ట్రక్చర్‌లా నడపాలని కోరుకున్నాము: Kubernetes‌పై, అక్కడ వర్క్‌లోడ్స్ పెరగడం మరియు తగ్గడం, అలాగే డిమాండ్ మార్పులకు అనుగుణంగా హోస్ట్స్ మధ్య మారడం సాధ్యమవుతుంది. కానీ సాంప్రదాయ సెషన్‌కు-ఒక-పోర్ట్ WebRTC మోడల్ ఆ వాతావరణానికి సరిపోదు, ఎందుకంటే ఇది పెద్ద పబ్లిక్ UDP పోర్ట్ రేంజ్‌లపై ఆధారపడుతుంది, ఇవి పాడ్‌లు జోడించబడినప్పుడు, తీసివేయబడినప్పుడు లేదా రీషెడ్యూల్ చేయబడినప్పుడు ఎక్స్‌పోజ్ చేయడం, సురక్షితం చేయడం మరియు కొనసాగించడం కష్టంగా ఉంటుంది.²

మొదటి సమస్య ఒక్కో సెషన్‌కు ఒక పోర్ట్ అనే మోడల్‌దే. అధిక కన్కరెన్సీ వద్ద, అంటే చాలా పెద్ద UDP పోర్ట్ పరిధులను బహిర్గతం చేసి నిర్వహించాల్సి ఉంటుంది.

• క్లౌడ్ లోడ్ బ్యాలెన్సర్లు మరియు కుబెర్నెటీస్ సర్వీసులు ప్రతి సర్వీస్‌కు వేల సంఖ్యలో పబ్లిక్ UDP పోర్ట్‌లను నిర్వహించడానికి రూపొందించబడలేదు. ప్రతి అదనపు పరిధి లోడ్ బ్యాలెన్సర్ కాన్ఫిగరేషన్, హెల్త్ చెకింగ్, ఫైర్‌వాల్ పాలసీ మరియు రోల్‌అవుట్ భద్రతలో ఆపరేషనల్ సంక్లిష్టతను పెంచుతుంది.³
• పెద్ద UDP పోర్ట్ పరిధులను సురక్షితం చేయడం కష్టం, ఎందుకంటే అవి బయటినుంచి చేరుకోగల ఉపరితలాన్ని విస్తరించి, నెట్‌వర్క్ పాలసీని ఆడిట్ చేయడాన్ని మరింత కష్టతరం చేస్తాయి.
• అవి ఆటోస్కేలింగ్‌కు కూడా సరిపోవు. కుబెర్నెటీస్‌లో పాడ్స్ నిరంతరం జోడించబడతాయి, తొలగించబడతాయి మరియు మళ్లీ షెడ్యూల్ చేయబడతాయి. ప్రతి పాడ్ ఒక పెద్ద, స్థిరమైన పోర్ట్ పరిధిని రిజర్వ్ చేసి ప్రకటించాల్సి రావడం, ఆ ఎలాస్టిసిటీని పెళుసుగా చేస్తుంది.⁴

అందుకే అనేక 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 చిరునామా; పోర్ట్‌తో కలిపి, దాని వెనుక అనేక రీలే ఇన్‌స్టాన్స్‌లు ఉన్నప్పటికీ, ఇది క్లయింట్‌కు `203.0.113.10:3478` వంటి ఒకే స్థిరమైన గమ్యస్థానాన్ని అందిస్తుంది. క్లయింట్ యొక్క మొదటి మీడియా-పాత్ ప్యాకెట్ సాధారణంగా STUN (NAT కోసం సెషన్ ట్రావర్సల్ యుటిలిటీస్) బైండింగ్ అభ్యర్థనగా ఉంటుంది, దీన్ని ICE ప్యాకెట్‌లు ప్రకటించబడిన చిరునామాను చేరుకోగలవని ధృవీకరించడానికి ఉపయోగిస్తుంది.

రిలే ఆ మొదటి STUN ప్యాకెట్‌ను సర్వర్ ufrag ను చదవడానికి, రూటింగ్ హింట్‌ను డీకోడ్ చేయడానికి, మరియు ప్యాకెట్‌ను దాని ఓనింగ్ ట్రాన్స్‌సీవర్‌కు ఫార్వర్డ్ చేయడానికి అవసరమైనంత మేర మాత్రమే పార్స్ చేస్తుంది. ప్రతి ట్రాన్స్‌సీవర్ ఒక షేర్డ్ UDP సాకెట్‌పై లిసన్ చేస్తుంది, అంటే ఒక అంతర్గత IP:port కు బైండ్ చేయబడిన ఒక ఆపరేటింగ్ సిస్టమ్ ఎండ్‌పాయింట్, ప్రతి సెషన్‌కు ఒక సాకెట్ కాదు. రిలే క్లయింట్ యొక్క సోర్స్ IP:port నుండి ఆ ట్రాన్సీవర్ గమ్యానికి సెషన్‌ను సృష్టించిన తర్వాత, తదుపరి DTLS, RTP, మరియు RTCP ప్యాకెట్లు ufrag ను మళ్లీ డీకోడ్ చేయకుండానే సెషన్‌లో ప్రవహిస్తాయి.

రిలే యొక్క సెషన్ ఉద్దేశపూర్వకంగా కనిష్టంగా ఉంటుంది, ప్యాకెట్ ఫార్వార్డింగ్‌కు సమాచారం అందించేందుకు ఇన్-మెమరీ సెషన్ మాత్రమే ఉంటుంది, అలాగే మానిటరింగ్ కోసం అవసరమైన కౌంటర్లు మరియు సెషన్ గడువు ముగింపు, క్లీనప్ కోసం టైమర్లు ఉంటాయి. ఈ డిజైన్ ఎంపిక ప్యాకెట్ రూటింగ్‌ను నేరుగా ప్యాకెట్ మార్గంలోనే కొనసాగిస్తుంది. ఒక రిలే రీస్టార్ట్ అయి సెషన్‌ను కోల్పోతే, తదుపరి STUN ప్యాకెట్ ufrag రూటింగ్ సూచన నుండి సెషన్‌ను పునర్నిర్మిస్తుంది. దీన్ని మరింత నమ్మదగినదిగా చేయడానికి, రూట్ స్థాపించబడిన తర్వాత <client IP + Port, transceiver IP + Port> యొక్క మ్యాపింగ్‌ను నిల్వ ఉంచడానికి Redis క్యాష్ ఉపయోగించబడుతుంది, తద్వారా తదుపరి STUN ప్యాకెట్ రాకముందే అది చాలా ముందుగానే తిరిగి పొందబడుతుంది.

మేము పబ్లిక్ UDP సర్ఫేస్‌ను తక్కువ సంఖ్యలో ఉన్న స్థిరమైన అడ్రస్‌లు మరియు పోర్ట్‌లకు తగ్గించిన తర్వాత, అదే రిలే ప్యాటర్న్‌ను ప్రపంచవ్యాప్తంగా డిప్లాయ్ చేయగలిగాం. Global Relay అనేది భౌగోళికంగా పంపిణీ చేయబడిన రిలే ప్రవేశ బిందువుల మా సముదాయం, ఇవన్నీ ఒకే ప్యాకెట్-ఫార్వార్డింగ్ ప్రవర్తనను అమలు చేస్తాయి.

విస్తృత భౌగోళిక ఇన్‌గ్రెస్ వల్ల, ఒక ప్యాకెట్ ముందుగా దూర ప్రాంతానికి పబ్లిక్ ఇంటర్నెట్‌ను దాటకుండా, భౌగోళికంగా మరియు నెట్‌వర్క్ టోపాలజీ పరంగా వినియోగదారుడికి దగ్గరలో ఉన్న రిలే ద్వారా మా నెట్‌వర్క్‌లోకి ప్రవేశించగలదు. దీంతో క్లయింట్ నుంచి OpenAIకి జరిగే తొలి హాప్ సమయం తగ్గుతుంది. ప్రాక్టికల్‌గా చూస్తే, ట్రాఫిక్ మా బ్యాక్‌బోన్‌కు చేరుకునేలోపే తక్కువ లేటెన్సీ, తక్కువ జిట్టర్, మరియు నివారించగలిగే లాస్ బర్స్ట్‌లు తక్కువగా ఉండడం అని అర్థం.⁶

సిగ్నలింగ్ కోసం మేము Cloudflare జియో మరియు ప్రాక్సిమిటీ స్టీరింగ్‌ను ఉపయోగిస్తాము, తద్వారా ప్రారంభ HTTP లేదా WebSocket అభ్యర్థన సమీపంలోని ట్రాన్స్‌సీవర్ క్లస్టర్‌కు చేరుతుంది. అభ్యర్థన కాంటెక్స్ట్ సెషన్ యొక్క స్థానాన్ని మరియు క్లయింట్‌కు ఏ Global Relay ఇంగ్రెస్ పాయింట్ ప్రకటించబడాలో నిర్దేశిస్తుంది. SDP సమాధానం Global Relay అడ్రస్‌ను అందిస్తుంది, కాగా ufrag లో మీడియాను నిర్దిష్ట క్లస్టర్‌కు రూట్ చేయడానికి మరియు రిలేను గమ్య ట్రాన్స్‌సీవర్‌కు రూట్ చేయడానికి Global Relay‌కు సరిపడ సమాచారం ఉంటుంది.

జియో-స్టీర్డ్ సిగ్నలింగ్ మరియు Global Relay కలిపి సెటప్ మరియు మీడియాను సమీప ప్రవేశ మార్గంలో ఉంచుతాయి, సెషన్‌ను ఒకే ట్రాన్స్‌సీవర్‌కు స్థిరంగా ఉంచుతూ. దాంతో సిగ్నలింగ్ మరియు మొదటి ICE కనెక్టివిటీ చెక్ కోసం అవసరమైన రౌండ్-ట్రిప్ సమయం తగ్గుతుంది, దీనివల్ల వినియోగదారు స్పీచ్ ప్రారంభమయ్యే ముందు వేచి ఉండే సమయం తగ్గుతుంది.

మేము రిలే సర్వీస్‌ను Go లో రాశాము మరియు ఇంప్లిమెంటేషన్ పరిధిని ఉద్దేశపూర్వకంగా పరిమితంగా ఉంచాము. Linuxలో, కర్నల్ యొక్క నెట్‌వర్కింగ్ స్టాక్ మెషీన్ యొక్క నెట్‌వర్క్ ఇంటర్‌ఫేస్ నుండి UDP ప్యాకెట్లను స్వీకరించి, వాటిని సాకెట్‌కు—అంటే IP:Port‌ను బైండ్ చేసిన తర్వాత ప్రాసెస్ చదివే ఆపరేటింగ్ సిస్టమ్ ఎండ్‌పాయింట్‌కు—అందిస్తుంది. Relay యూజర్‌స్పేస్‌లో రన్ అవుతుంది, కాబట్టి సాధారణ Go ప్రాసెస్ ఆ సాకెట్ నుండి ప్యాకెట్ హెడర్‌లను చదివి, కొద్దిపాటి ఫ్లో స్టేట్‌ను అప్‌డేట్ చేసి, WebRTCని టర్మినేట్ చేయకుండా ప్యాకెట్‌లను ఫార్వర్డ్ చేస్తుంది. అధిక ప్యాకెట్ రేట్ల కోసం యూజర్‌స్పేస్ ప్రాసెస్ నెట్‌వర్క్ క్యూలను నేరుగా పోల్ చేయడానికి వీలు కల్పించే, కానీ ఆపరేషనల్ సంక్లిష్టతను కూడా పెంచే ఏ కర్నెల్-బైపాస్ ఫ్రేమ్‌వర్క్ మాకు అవసరం లేదు.

ముఖ్యమైన డిజైన్ ఎంపికలు:

• ప్రోటోకాల్ టర్మినేషన్ లేదు: Relay కేవలం STUN హెడర్‌లు/ufrag ను మాత్రమే పార్స్ చేస్తుంది; తదుపరి DTLS, RTP, మరియు RTCP కోసం క్యాష్ చేయబడిన స్థితిని ఉపయోగిస్తూ, ప్యాకెట్లను అపారదర్శకంగా ఉంచుతుంది.
• తాత్కాలిక స్థితి: ఇది ఫ్లో స్థితి మరియు పరిశీలనీయత కోసం, క్లయింట్ చిరునామా నుంచి ట్రాన్స్‌సీవర్ గమ్యస్థానానికి సంబంధించిన చిన్న, తక్కువ-టైమ్‌అవుట్ గల, ఇన్-మెమరీ మ్యాప్‌ను నిర్వహిస్తుంది.
• క్షితిజ సమాంతర స్కేలబిలిటీ: బహుళ రిలే ఇన్‌స్టాన్స్‌లు లోడ్ బాలెన్సర్ వెనుక సమాంతరంగా నడుస్తాయి. స్థితి హార్డ్ WebRTC స్థితి కాదు, కాబట్టి పునఃప్రారంభాల వల్ల ట్రాఫిక్ డ్రాప్‌లు కనిష్టంగా ఉంటాయి మరియు ఫ్లో త్వరగా రికవర్ అవుతుంది.

సమర్థత చర్యలు:

• SO_REUSEPORT అనేది Linux సాకెట్ ఆప్షన్, ఇది ఒకే మెషీన్‌లోని అనేక రిలే వర్కర్‌లు అదే UDP పోర్ట్‌ను బైండ్ చేయడానికి అనుమతిస్తుంది. ఆ తర్వాత కర్నెల్ లోపలికి వచ్చే ప్యాకెట్లను ఆ వర్కర్‌ల మధ్య పంపిణీ చేస్తుంది, దీనివల్ల ఒకే రీడ్-లూప్ అవరోధం నివారించబడుతుంది.
• runtime.LockOSThread UDPని చదివే ప్రతి గోరూటీన్‌ను నిర్దిష్ట OS థ్రెడ్‌కు కట్టిపడేస్తుంది. SO_REUSEPORTతో కలిపినప్పుడు, అది అదే ఫ్లోలోని ప్యాకెట్లను (సోర్స్ మరియు డెస్టినేషన్ IP:Port తో పాటు ప్రోటోకాల్) అదే CPU కోర్‌పై ఉంచేలా చేస్తుంది, తద్వారా క్యాష్ లోకాలిటీ మెరుగుపడి కాంటెక్స్ట్ స్విచింగ్ తగ్గుతుంది.
• ముందుగా కేటాయించిన బఫర్‌లు మరియు కనిష్ట కాపీయింగ్, Go లో గార్బేజ్ కలెక్షన్‌ను నివారించడానికి పార్సింగ్ మరియు కేటాయింపు ఓవర్‌హెడ్‌ను తక్కువగా ఉంచుతాయి.

ఈ అమలు, సాపేక్షంగా చిన్న రిలే ఫుట్‌ప్రింట్‌తో మా గ్లోబల్ రియల్-టైమ్ మీడియా ట్రాఫిక్‌ను నిర్వహించింది, కాబట్టి కెర్నల్ బైపాస్ రూట్‌ను తీసుకోకుండా మేము సరళమైన డిజైన్‌ను కొనసాగించాము.

ఈ ఆర్కిటెక్చర్, వేల సంఖ్యలో UDP పోర్ట్‌లను బహిర్గతం చేయకుండా, కుబెర్నెటీస్‌లో WebRTC మీడియాను నడపడానికి మాకు వీలు కల్పిస్తుంది. అది ముఖ్యం ఎందుకంటే చిన్నదిగా మరియు స్థిరంగా ఉండే UDP సర్ఫేస్‌ను భద్రపరచడం మరియు లోడ్ బ్యాలెన్స్ చేయడం సులభం, అలాగే పెద్ద పబ్లిక్ పోర్ట్ రేంజ్‌లను రిజర్వ్ చేయకుండా ఇన్‌ఫ్రాస్ట్రక్చర్ స్కేల్ కావడానికి ఇది అనుమతిస్తుంది. Kubernetes నుండి మెరుగైన ఇన్‌ఫ్రా మద్దతు మరియు చిన్న పరిధి కారణంగా మరింత సెక్యూరిటీతో, ఈ డిజైన్ క్లయింట్‌ల కోసం ప్రామాణిక WebRTC ప్రవర్తనను కూడా కాపాడుతుంది మరియు SFU-లెస్ డిజైన్ మా వర్క్‌లోడ్‌కు సరైన డిఫాల్ట్ అని నిర్ధారిస్తుంది. మా సెషన్‌లలో ఎక్కువ భాగం పాయింట్-టు-పాయింట్‌వి, లేటెన్సీ-సెన్సిటివ్‌వి, అలాగే ఇన్ఫరెన్స్ సేవలు WebRTC peers లా ప్రవర్తించాల్సిన అవసరం లేకపోతే వాటిని స్కేల్ చేయడం సులభం.

విస్తృతమైన పాఠం ఏమిటంటే, సంక్లిష్టతను జోడించడానికి ఉత్తమ స్థానం సన్నని రూటింగ్ లేయర్‌లోనే, ప్రతి బ్యాక్‌ఎండ్ సర్వీస్‌లో కాదు, కస్టమ్ క్లయింట్ ప్రవర్తనలో కూడా కాదు. రూటింగ్ మెటాడేటాను ప్రోటోకాల్-నేటివ్ ఫీల్డ్‌లో ఎన్‌కోడ్ చేయడం వల్ల మాకు నిర్ణీత మొదటి-ప్యాకెట్ రూటింగ్, చిన్న పబ్లిక్ UDP ఫుట్‌ప్రింట్, అలాగే ప్రపంచవ్యాప్తంగా ఉన్న యూజర్లకు దగ్గరగా ఇంగ్రెస్‌ను ఉంచేందుకు తగినంత ఫ్లెక్సిబిలిటీ లభించింది.

కొన్ని ఎంపికలు ప్రత్యేకంగా ముఖ్యమైనవి:

• ఎడ్జ్ వద్ద ప్రోటోకాల్ సెమాంటిక్స్‌ను కాపాడండి. క్లయింట్‌లు ఇప్పటికీ ప్రామాణిక WebRTCనే ఉపయోగిస్తాయి, దీనివల్ల బ్రౌజర్ మరియు మొబైల్ పరస్పర కార్యసాధ్యత సక్రమంగా ఉంటుంది.
• క్లిష్టమైన సెషన్ స్థితులను ఒకే చోట ఉంచండి. ట్రాన్స్‌సీవర్ ICE, DTLS, SRTP మరియు సెషన్ లైఫ్‌సైకిల్‌కు బాధ్యత వహిస్తుంది; రిలే ప్యాకెట్లను మాత్రమే ఫార్వర్డ్ చేస్తుంది.
• సెటప్‌లో ఇప్పటికే ఉన్న సమాచారం ఆధారంగా మార్గాన్ని నిర్ణయించండి. ICE ufrag హాట్-పాత్ లుకప్ డిపెండెన్సీని జోడించకుండా మాకు మొదటి ప్యాకెట్ రూటింగ్ హుక్‌ను అందించింది.
• కర్నెల్ బైపాస్‌ను ఆశ్రయించే ముందు సాధారణ సందర్భం కోసం ఆప్టిమైజ్ చేయండి. SO_REUSEPORT ను జాగ్రత్తగా ఉపయోగించడం, థ్రెడ్ పిన్నింగ్, మరియు తక్కువ-అలోకేషన్ పార్సింగ్‌తో కూడిన సంకుచిత Go అమలు మా వర్క్‌లోడ్‌కు సరిపోయింది.

రియల్-టైమ్ వాయిస్ AI, ఇన్‌ఫ్రాస్ట్రక్చర్ లేటెన్సీని గుర్తించలేనంతగా చేసినప్పుడే పనిచేస్తుంది. మా దృష్టిలో, WebRTC నుండే క్లయింట్లు ఆశించే విషయాలను మార్చకుండా, మా WebRTC డిప్లాయ్‌మెంట్ స్వరూపాన్ని మార్చడం అని దాని అర్థం.