OpenAI ਵੱਲੋਂ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਘੱਟ-ਲੇਟੈਂਸੀ ਵਾਲਾ ਵੌਇਸ AI ਕਿਵੇਂ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ

ਵੌਇਸ AI ਤਦੋਂ ਹੀ ਸੁਭਾਵਿਕ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਗੱਲਬਾਤ ਬੋਲਣ ਦੀ ਰਫ਼ਤਾਰ ਨਾਲ ਅੱਗੇ ਵਧਦੀ ਹੈ। ਜਦੋਂ ਨੈੱਟਵਰਕ ਵਿੱਚ ਰੁਕਾਵਟ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਲੋਕਾਂ ਨੂੰ ਇਹ ਤੁਰੰਤ ਅਜੀਬ ਖਾਮੋਸ਼ੀ, ਕੱਟਦੀ ਹੋਈ ਆਵਾਜ਼ ਜਾਂ ਦੇਰੀ ਨਾਲ ਹੋਣ ਵਾਲੀ ਟੋਕਾ-ਟਾਕੀ ਦੇ ਰੂਪ ਵਿੱਚ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਇਹ ChatGPT ਵੌਇਸ ਲਈ, ਰੀਅਲਟਾਈਮ API ਨਾਲ ਬਣਾਉਣ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਲਈ, ਇੰਟਰਐਕਟਿਵ ਵਰਕਫਲੋ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੇ ਏਜੰਟਾਂ ਲਈ, ਅਤੇ ਉਹਨਾਂ ਮਾਡਲ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਵਰਤੋਂਕਾਰ ਦੇ ਅਜੇ ਵੀ ਬੋਲਦੇ ਰਹਿਣ ਦੌਰਾਨ ਔਡੀਓ ਪ੍ਰੋਸੈਸ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

OpenAI ਦੇ ਪੱਧਰ 'ਤੇ, ਇਸਦਾ ਅਰਥ ਇਹ ਤਿੰਨ ਪੁਖ਼ਤਾ ਜ਼ਰੂਰਤਾਂ ਹਨ:

• ਹਫਤਾਵਾਰੀ 900 ਮਿਲੀਅਨ ਤੋਂ ਵੱਧ ਸਰਗਰਮ ਵਰਤੋਂਕਾਰਾਂ ਤੱਕ ਵਿਸ਼ਵਵਿਆਪੀ ਪਹੁੰਚ
• ਫੌਰੀ ਕਨੈਕਸ਼ਨ ਸੈਟਅੱਪ ਤਾਂ ਜੋ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹੀ ਵਰਤੋਂਕਾਰ ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਕਰ ਸਕੇ
• ਘੱਟ ਅਤੇ ਸਥਿਰ ਮੀਡੀਆ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਸਮਾਂ, ਘੱਟ ਜਿਟਰ ਅਤੇ ਪੈਕਟ ਲੌਸ ਨਾਲ, ਤਾਂ ਜੋ ਵਾਰੀ-ਵਾਰੀ ਗੱਲਬਾਤ ਕਰਨਾ ਤੁਰੰਤ ਅਤੇ ਸੁਚਾਰੂ ਮਹਿਸੂਸ ਹੋਵੇ

OpenAI ਦੀ ਰੀਅਲ-ਟਾਈਮ AI ਇੰਟਰੈਕਸ਼ਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਟੀਮ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਆਪਣੇ WebRTC ਸਟੈਕ ਨੂੰ ਮੁੜ-ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਹੈ ਤਾਂ ਜੋ ਉਨ੍ਹਾਂ ਤਿੰਨ ਚੁਣੌਤੀਆਂ ਦਾ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕੇ ਜੋ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਕੰਮ ਦੌਰਾਨ ਆਪਸ ਵਿੱਚ ਟਕਰਾ ਰਹੀਆਂ ਸਨ: ਵਨ-ਪੋਰਟ-ਪਰ-ਸੈਸ਼ਨ ਮੀਡੀਆ ਟਰਮੀਨੇਸ਼ਨ OpenAI ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਮੁਤਾਬਕ ਸਹੀ ਨਹੀਂ ਬੈਠਦੀ, ਸਟੇਟਫੁੱਲ ICE (ਇੰਟਰਐਕਟਿਵ ਕਨੈਕਟੀਵਿਟੀ ਐਸਟੈਬਲਿਸ਼ਮੈਂਟ) ਅਤੇ DTLS (ਡੇਟਾਗ੍ਰਾਮ ਟ੍ਰਾਂਸਪੋਰਟ ਲੇਅਰ ਸਕਿਓਰਿਟੀ) ਸੈਸ਼ਨਾਂ ਲਈ ਸਥਿਰ ਓਨਰਸ਼ਿਪ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਗਲੋਬਲ ਰਾਊਟਿੰਗ ਰਾਹੀਂ ਫਸਟ-ਹੌਪ ਲੇਟੈਂਸੀ ਨੂੰ ਘੱਟ ਰੱਖਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਇਸ ਪੋਸਟ ਵਿੱਚ, ਅਸੀਂ ਉਸ ਸਪਲਿਟ ਰਿਲੇਅ ਪਲੱਸ ਟ੍ਰਾਂਸੀਵਰ ਆਰਕੀਟੈਕਚਰ ਬਾਰੇ ਕਦਮ-ਦਰ-ਕਦਮ ਸਮਝਾਉਂਦੇ ਹਾਂ, ਜੋ ਅਸੀਂ ਕਲਾਇੰਟਾਂ ਲਈ ਮਿਆਰੀ WebRTC ਵਿਹਾਰ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਲਈ ਬਣਾਇਆ ਹੈ ਅਤੇ OpenAI ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਪੈਕਟਾਂ ਨੂੰ ਰਾਊਟ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲਦਾ ਹੈ।

WebRTC ਬ੍ਰਾਊਜ਼ਰਾਂ, ਮੋਬਾਈਲ ਐਪਾਂ ਅਤੇ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਘੱਟ-ਲੇਟੈਂਸੀ ਨਾਲ ਔਡੀਓ, ਵੀਡੀਓ ਅਤੇ ਡੇਟਾ ਭੇਜਣ ਲਈ ਇੱਕ ਮੁਕਤ ਮਿਆਰ ਹੈ। ਇਹ ਅਕਸਰ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਕਾਲਿੰਗ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਕਲਾਇੰਟ-ਟੂ-ਸਰਵਰ ਰੀਅਲ-ਟਾਈਮ ਸਿਸਟਮਾਂ ਲਈ ਵੀ ਇੱਕ ਵਿਹਾਰਕ ਬੁਨਿਆਦ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਇੰਟਰਐਕਟਿਵ ਮੀਡੀਆ ਦੇ ਔਖੇ ਹਿੱਸਿਆਂ ਦਾ ਮਿਆਰੀਕਰਨ ਕਰਦਾ ਹੈ: ਕਨੈਕਟੀਵਿਟੀ ਸਥਾਪਨਾ ਅਤੇ NAT (ਨੈੱਟਵਰਕ ਐਡਰੈੱਸ ਟ੍ਰਾਂਸਲੇਸ਼ਨ) ਟ੍ਰੈਵਰਸਲ ਲਈ ICE, ਇਨਕ੍ਰਿਪਟਡ ਟ੍ਰਾਂਸਪੋਰਟ ਲਈ DTLS ਅਤੇ SRTP (ਸਿਕਿਓਰ ਰੀਅਲ-ਟਾਈਮ ਟ੍ਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ ), ਔਡੀਓ ਨੂੰ ਕੰਪ੍ਰੈਸ ਅਤੇ ਡੀਕੋਡ ਕਰਨ ਲਈ ਕੋਡੈਕ ਨੇਗੋਸ਼ੀਏਸ਼ਨ, ਕੁਆਲਿਟੀ ਕੰਟਰੋਲ ਲਈ RTCP (ਰੀਅਲ-ਟਾਈਮ ਟ੍ਰਾਂਸਪੋਰਟ ਕੰਟਰੋਲ ਪ੍ਰੋਟੋਕੋਲ), ਅਤੇ ਕਲਾਇੰਟ-ਸਾਈਡ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਿਵੇਂ ਕਿ ਈਕੋ ਕੈਂਸਲੇਸ਼ਨ ਅਤੇ ਜਿੱਟਰ ਬਫਰਿੰਗ।

ਉਹ ਮਿਆਰੀਕਰਨ 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 ਪੀਅਰ ਵਜੋਂ ਕੰਮ ਕਰਨ ਦੀ ਬਜਾਏ ਆਮ ਸੇਵਾਵਾਂ ਵਾਂਗ ਸਕੇਲ ਕਰ ਸਕੀਆਂ।

ਟ੍ਰਾਂਸੀਵਰ ਮਾਡਲ ਚੁਣਨ ਤੋਂ ਬਾਅਦ, ਸਾਡੀ ਪਹਿਲੀ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ Pion 'ਤੇ ਬਣੀ ਇੱਕ ਇਕੱਲੀ Go ਸਰਵਿਸ ਸੀ, ਜੋ ਸਿਗਨਲਿੰਗ ਅਤੇ ਮੀਡੀਆ ਟਰਮੀਨੇਸ਼ਨ ਦੋਵਾਂ ਨੂੰ ਸੰਭਾਲਦੀ ਸੀ। ਇਹ ChatGPT ਵੌਇਸ, ਰੀਅਲਟਾਈਮ API ਦੇ WebRTC ਐਂਡਪੌਇੰਟ, ਅਤੇ ਕਈ ਖੋਜ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੀ ਹੈ।

ਸੰਚਾਲਨ ਪੱਧਰ 'ਤੇ, ਟ੍ਰਾਂਸੀਵਰ ਸੇਵਾ ਦੋ ਕੰਮ ਕਰਦੀ ਹੈ:

• ਸਿਗਨਲਿੰਗ: SDP ਨੇਗੋਸ਼ੀਏਸ਼ਨ, ਕੋਡੈਕ ਚੋਣ, ICE ਕ੍ਰੈਡੈਂਸ਼ਲ ਅਤੇ ਸੈਸ਼ਨ ਸੈਟਅੱਪ
• ਮੀਡੀਆ: ਡਾਊਨਸਟ੍ਰੀਮ WebRTC ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਟਰਮੀਨੇਟ ਕਰਨਾ ਅਤੇ ਇਨਫਰੈਂਸ ਅਤੇ ਓਰਕੇਸਟ੍ਰੇਸ਼ਨ ਲਈ ਬੈਕਐਂਡ ਸੇਵਾਵਾਂ ਨਾਲ ਅੱਪਸਟ੍ਰੀਮ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਜਾਰੀ ਰੱਖਣਾ

ਅਸੀਂ ਚਾਹੁੰਦੇ ਸੀ ਕਿ ਇਹ ਸਰਵਿਸ ਸਾਡੇ ਬਾਕੀ ਬੁਨਿਆਦੀ ਢਾਂਚਿਆਂ ਵਾਂਗ ਹੀ ਚੱਲੇ: ਮਤਲਬ 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) ਬਾਈਂਡਿੰਗ ਰਿਕੁਐਸਟ ਹੁੰਦੀ ਹੈ। ICE ਇਸ ਦੀ ਵਰਤੋਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਰਦਾ ਹੈ ਕਿ ਪੈਕੇਟ ਦਿੱਤੇ ਗਏ ਐਡਰੈੱਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ।

ਰਿਲੇਅ ਉਸ ਪਹਿਲੇ STUN ਪੈਕੇਟ ਨੂੰ ਸਿਰਫ਼ ਇੰਨਾ ਕੁ ਪਾਰਸ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਸਰਵਰ ufrag ਨੂੰ ਪੜ੍ਹ ਸਕੇ, ਰਾਊਟਿੰਗ ਹਿੰਟ ਨੂੰ ਡੀਕੋਡ ਕਰ ਸਕੇ, ਅਤੇ ਫਿਰ ਉਸ ਪੈਕੇਟ ਨੂੰ ਸਬੰਧਤ ਟ੍ਰਾਂਸੀਵਰ ਨੂੰ ਅੱਗੇ ਭੇਜ ਸਕੇ। ਹਰੇਕ ਟ੍ਰਾਂਸੀਵਰ ਇੱਕ ਸਾਂਝੇ UDP ਸੌਕੇਟ 'ਤੇ ਨਜ਼ਰ ਰੱਖਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਐਂਡਪੁਆਇੰਟ ਇੱਕ ਅੰਦਰੂਨੀ IP:port ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਹਰੇਕ ਸੈਸ਼ਨ ਲਈ ਇੱਕ ਵੱਖਰਾ ਸੌਕੇਟ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਰਿਲੇਅ ਕਲਾਇੰਟ ਦੇ ਸੋਰਸ IP:port ਤੋਂ ਉਸ ਟ੍ਰਾਂਸੀਵਰ ਮੰਜ਼ਿਲ ਤੱਕ ਸੈਸ਼ਨ ਬਣਾ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਉਸ ਤੋਂ ਬਾਅਦ ਦੇ ਸਾਰੇ DTLS, RTP, ਅਤੇ RTCP ਪੈਕੇਟ ufrag ਨੂੰ ਦੁਬਾਰਾ ਡੀਕੋਡ ਕੀਤੇ ਬਿਨ੍ਹਾਂ ਉਸੇ ਸੈਸ਼ਨ ਦੇ ਅੰਦਰ ਚੱਲਦੇ ਰਹਿੰਦੇ ਹਨ।

ਰਿਲੇਅ ਦਾ ਸੈਸ਼ਨ ਜਾਣਬੁੱਝ ਕੇ ਘੱਟੋ-ਘੱਟ ਰੱਖਿਆ ਗਿਆ ਹੈ। ਇਸ ਵਿੱਚ ਸਿਰਫ਼ ਪੈਕੇਟ ਫਾਰਵਰਡਿੰਗ ਲਈ ਜਾਣਕਾਰੀ ਦੇਣ ਵਾਸਤੇ ਇੱਕ ਇਨ-ਮੈਮੋਰੀ ਸੈਸ਼ਨ ਹੁੰਦਾ ਹੈ, ਨਾਲ ਹੀ ਨਿਗਰਾਨੀ ਲਈ ਲੋੜੀਂਦੇ ਕਾਊਂਟਰ ਅਤੇ ਸੈਸ਼ਨ ਦੀ ਮਿਆਦ ਖਤਮ ਹੋਣ ਅਤੇ ਕਲੀਨਅੱਪ ਲਈ ਟਾਈਮਰ ਹੁੰਦੇ ਹਨ। ਇਹ ਡਿਜ਼ਾਈਨ ਚੋਣ ਪੈਕਟ ਰੂਟਿੰਗ ਨੂੰ ਸਿੱਧੇ ਪੈਕਟ ਪਾਥ 'ਤੇ ਹੀ ਬਣਾਈ ਰੱਖਦੀ ਹੈ। ਜੇ ਕੋਈ ਰਿਲੇਅ ਮੁੜ ਚਾਲੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸੈਸ਼ਨ ਗੁਆ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਅਗਲਾ STUN ਪੈਕੇਟ ufrag ਰੂਟਿੰਗ ਹਿੰਟ ਤੋਂ ਸੈਸ਼ਨ ਨੂੰ ਮੁੜ ਬਣਾਉਂਦਾ ਹੈ। ਇਸਨੂੰ ਹੋਰ ਵੀ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਲਈ, ਰੂਟ ਸਥਾਪਤ ਹੋ ਜਾਣ ਤੋਂ ਬਾਅਦ <ਕਲਾਇੰਟ IP + ਪੋਰਟ, ਟ੍ਰਾਂਸੀਵਰ IP + ਪੋਰਟ> ਦੀ ਮੈਪਿੰਗ ਰੱਖਣ ਲਈ ਇੱਕ Redis ਕੈਸ਼ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਨਾਲ ਅਗਲਾ STUN ਪੈਕੇਟ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਇਸਨੂੰ ਰੀਕਵਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਜਿਵੇਂ ਹੀ ਅਸੀਂ ਪਬਲਿਕ UDP ਸਰਫ਼ੇਸ ਨੂੰ ਘਟਾ ਕੇ ਕੁਝ ਸਥਿਰ ਐਡਰੈੱਸਾਂ ਅਤੇ ਪੋਰਟਾਂ ਤੱਕ ਸੀਮਤ ਕਰ ਦਿੱਤਾ, ਅਸੀਂ ਉਸੇ ਰਿਲੇਅ ਪੈਟਰਨ ਨੂੰ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਲਾਗੂ ਕਰਨ ਦੇ ਯੋਗ ਹੋ ਗਏ। ਗਲੋਬਲ ਰਿਲੇਅ ਸਾਡੇ ਉਹ ਰਿਲੇਅ ਇੰਗ੍ਰੈੱਸ ਪੁਆਇੰਟ ਹਨ, ਜੋ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਵੰਡੇ ਹੋਏ ਹਨ ਅਤੇ ਸਾਰੇ ਇੱਕੋ ਜਿਹਾ ਪੈਕੇਟ-ਫਾਰਵਰਡਿੰਗ ਵਿਹਾਰ ਵਰਤਦੇ ਹਨ।

ਵਿਆਪਕ ਭੂਗੋਲਿਕ ਇੰਗ੍ਰੈਸ ਪਹਿਲੇ ਕਲਾਇੰਟ-ਤੋਂ- OpenAI ਹੌਪ ਨੂੰ ਛੋਟਾ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਪੈਕਟ ਸਾਡੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਵਰਤੋਂਕਾਰ ਦੇ ਨੇੜੇ ਕਿਸੇ ਰਿਲੇਅ 'ਤੇ ਦਾਖਲ ਹੋ ਸਕਦਾ ਹੈ, ਜੋ ਭੂਗੋਲ ਅਤੇ ਨੈੱਟਵਰਕ ਟੋਪੋਲੋਜੀ ਦੋਵਾਂ ਦੇ ਹਿਸਾਬ ਨਾਲ ਨੇੜੇ ਹੈ, ਬਜਾਏ ਇਸਦੇ ਕਿ ਉਹ ਪਹਿਲਾਂ ਦੂਰਲੇ ਖੇਤਰ ਤੱਕ ਪਬਲਿਕ ਇੰਟਰਨੈੱਟ ਪਾਰ ਕਰੇ। ਵਿਵਹਾਰਕ ਤੌਰ 'ਤੇ, ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਸਾਡੇ ਬੈਕਬੋਨ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਘੱਟ ਲੇਟੈਂਸੀ, ਘੱਟ ਜਿਟਰ, ਅਤੇ ਘੱਟ ਟਾਲਣਯੋਗ ਲਾਸ ਬਰਸਟਾਂ ਹੋਣਗੇ।⁶

ਅਸੀਂ ਸਿਗਨਲਿੰਗ ਲਈ Cloudflare ਦੀ ਜੀਓ ਅਤੇ ਪ੍ਰੌਕਸੀਮਿਟੀ ਸਟੀਅਰਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਜੋ ਸ਼ੁਰੂਆਤੀ HTTP ਜਾਂ WebSocket ਬੇਨਤੀ ਨੇੜਲੇ ਟ੍ਰਾਂਸੀਵਰ ਕਲੱਸਟਰ ਤੱਕ ਪਹੁੰਚੇ। ਬੇਨਤੀ ਸੰਦਰਭ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਸੈਸ਼ਨ ਦੀ ਲੋਕੇਸ਼ਨ ਕੀ ਹੋਵੇਗੀ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਕਿਹੜਾ ਗਲੋਬਲ ਰਿਲੇਅ ਇੰਗ੍ਰੈਸ ਪੁਆਇੰਟ ਦੱਸਿਆ ਜਾਵੇਗਾ। SDP ਜਵਾਬ ਗਲੋਬਲ ਰਿਲੇਅ ਪਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਦਕਿ ufrag ਵਿੱਚ ਗਲੋਬਲ ਰਿਲੇਅ ਵੱਲੋਂ ਮੀਡੀਆ ਨੂੰ ਨਿਰਧਾਰਤ ਕਲਸਟਰ ਤੱਕ ਰੂਟ ਕਰਨ ਅਤੇ ਰੀਲੇ ਵੱਲੋਂ ਮੰਜ਼ਿਲ ਟ੍ਰਾਂਸੀਵਰ ਤੱਕ ਰੂਟ ਕਰਨ ਲਈ ਕਾਫੀ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ।

ਜੀਓ-ਸਟੀਅਰਡ ਸਿਗਨਲਿੰਗ ਅਤੇ ਗਲੋਬਲ ਰਿਲੇਅ ਮਿਲ ਕੇ ਸੈੱਟਅੱਪ ਅਤੇ ਮੀਡੀਆ ਦੋਵਾਂ ਨੂੰ ਇੱਕ ਨਜ਼ਦੀਕੀ ਐਂਟਰੀ ਪਾਥ 'ਤੇ ਰੱਖਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਸੈਸ਼ਨ ਨੂੰ ਇੱਕੋ ਟ੍ਰਾਂਸੀਵਰ ਨਾਲ ਜੋੜ ਕੇ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਿਗਨਲਿੰਗ ਅਤੇ ਪਹਿਲੀ ICE ਕਨੈਕਟਿਵਿਟੀ ਜਾਂਚ ਲਈ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ, ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਉਹ ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ ਜਿਸ ਦੌਰਾਨ ਵਰਤੋਂਕਾਰ ਨੂੰ ਬੋਲਣਾ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਉਡੀਕ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।

ਅਸੀਂ ਰਿਲੇਅ ਸਰਵਿਸ ਨੂੰ Go ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਿਆ ਹੈ ਅਤੇ ਇਸਦੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਸੀਮਤ ਰੱਖਿਆ ਹੈ। Linux 'ਤੇ, kernel ਦਾ ਨੈੱਟਵਰਕਿੰਗ ਸਟੈਕ ਮਸ਼ੀਨ ਦੇ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਤੋਂ UDP ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸੌਕੇਟ ਤੱਕ ਪਹੁੰਚਾਉਂਦਾ ਹੈ, ਜੋ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦਾ ਐਂਡਪੌਇੰਟ ਹੈ ਜਿਸਨੂੰ ਇੱਕ ਪ੍ਰੋਸੈਸ IP:Port ਬਾਈਂਡ ਕਰਨ ਤੋਂ ਬਾਅਦ ਪੜ੍ਹਦਾ ਹੈ। ਰਿਲੇਅ ਯੂਜ਼ਰਸਪੇਸ ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਆਮ Go ਪ੍ਰੋਸੈਸ ਉਸ ਸੌਕੇਟ ਤੋਂ ਪੈਕਟ ਹੈਡਰ ਪੜ੍ਹਦਾ ਹੈ, ਫਲੋ ਸਟੇਟ ਦੀ ਥੋੜ੍ਹੀ ਜਿਹੀ ਮਾਤਰਾ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ, ਅਤੇ WebRTC ਨੂੰ ਟਰਮੀਨੇ ਕੀਤੇ ਬਿਨ੍ਹਾਂ ਪੈਕਟ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ। ਸਾਨੂੰ ਕਿਸੇ ਵੀ ਕਰਨਲ-ਬਾਈਪਾਸ ਫ੍ਰੇਮਵਰਕ ਦੀ ਲੋੜ ਨਹੀਂ ਪਈ, ਜੋ ਕਿ ਯੂਜ਼ਰਸਪੇਸ ਪ੍ਰੋਸੈਸ ਨੂੰ ਉੱਚ ਪੈਕੇਟ ਦਰਾਂ ਲਈ ਸਿੱਧੇ ਨੈੱਟਵਰਕ ਕਤਾਰਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਪਰ ਨਾਲ ਹੀ ਓਪਰੇਸ਼ਨਲ ਜਟਿਲਤਾ ਨੂੰ ਵੀ ਵਧਾਉਂਦਾ ਹੈ।

ਮੁੱਖ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ:

• ਕੋਈ ਪ੍ਰੋਟੋਕੋਲ ਟਰਮੀਨੇਸ਼ਨ ਨਹੀਂ: ਰਿਲੇਅ ਸਿਰਫ਼ STUN headers/ufrag ਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ; ਇਹ ਬਾਅਦ ਵਾਲੇ DTLS, RTP, ਅਤੇ RTCP ਲਈ ਕੈਸ਼ ਕੀਤੀ ਸਟੇਟ ਵਰਤਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਪੈਕੇਟ ਅਪਾਰਦਰਸ਼ੀ ਰਹਿੰਦੇ ਹਨ।
• ਅਸਥਾਈ ਸਟੇਟ: ਇਹ ਫਲੋ ਸਟੇਟ ਅਤੇ ਨਿਗਰਾਨੀ ਲਈ ਕਲਾਇੰਟ ਐਡਰੈੱਸ ਤੋਂ ਟ੍ਰਾਂਸੀਵਰ ਮੰਜ਼ਿਲ ਦਾ ਇੱਕ ਛੋਟਾ, ਘੱਟ-ਸਮੇਂ ਵਾਲਾ ਅਤੇ ਇਨ-ਮੈਮੋਰੀ ਮੈਪ ਬਣਾ ਕੇ ਰੱਖਦਾ ਹੈ।
• ਹੌਰੀਜੌਂਟਲ ਸਕੇਲੇਬਿਲਿਟੀ: ਕਈ ਰਿਲੇ ਇੰਸਟੈਂਸ ਲੋਡ ਬੈਲੈਂਸਰ ਦੇ ਪਿੱਛੇ ਸਮਾਂਤਰ ਤੌਰ ’ਤੇ ਚੱਲਦੇ ਹਨ। ਇਹ ਸਟੇਟ ਹਾਰਡ WebRTC ਸਟੇਟ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਰੀਸਟਾਰਟ ਕਰਨ ਨਾਲ ਟ੍ਰੈਫਿਕ ਬਹੁਤ ਘੱਟ ਡ੍ਰੌਪ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਲੋ ਜਲਦੀ ਬਹਾਲ ਹੋ ਜਾਂਦੀ ਹੈ।

ਕੁਸ਼ਲਤਾ ਦੇ ਉਪਾਅ:

• SO_REUSEPORT ਇੱਕ Linux ਸੌਕੇਟ ਵਿਕਲਪ ਹੈ ਜੋ ਇੱਕੋ ਮਸ਼ੀਨ 'ਤੇ ਕਈ ਰਿਲੇਅ ਵਰਕਰਾਂ ਨੂੰ ਉਸੇ UDP ਪੋਰਟ ਨਾਲ ਬਾਈਂਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਫਿਰ ਕਰਨਲ ਆਉਣ ਵਾਲੇ ਪੈਕੇਟਾਂ ਨੂੰ ਉਹਨਾਂ ਵਰਕਰਾਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇੱਕ ਹੀ ਰੀਡ-ਲੂਪ ਦੀ ਰੁਕਾਵਟ ਤੋਂ ਬਚਿਆ ਜਾਂਦਾ ਹੈ।
• runtime.LockOSThread ਹਰ UDP ਰੀਡਿੰਗ ਗੋਰੂਟੀਨ ਨੂੰ ਇੱਕ ਖਾਸ OS ਥ੍ਰੈਡ ਨਾਲ ਜੋੜਦਾ ਹੈ। SO_REUSEPORT ਨਾਲ ਮਿਲਾ ਕੇ, ਇਹ ਆਮ ਤੌਰ ‘ਤੇ ਉਸੇ ਫਲੋ (ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ IP:Port ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ) ਦੇ ਪੈਕੇਟਾਂ ਨੂੰ ਉਸੇ CPU ਕੋਰ ‘ਤੇ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕੈਸ਼ ਲੋਕੈਲਿਟੀ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ ਅਤੇ ਸੰਦਰਭ ਸਵਿਚਿੰਗ ਘਟਦੀ ਹੈ।
• ਪਹਿਲਾਂ ਤੋਂ ਐਲੋਕੇਟ ਕੀਤੇ ਬਫ਼ਰ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਕਾਪੀ ਕਰਨਾ ਪਾਰਸਿੰਗ ਅਤੇ ਐਲੋਕੇਸ਼ਨ ਓਵਰਹੈੱਡ ਨੂੰ ਘੱਟ ਰੱਖਦੇ ਹਨ, ਤਾਂ ਜੋ Go ਵਿੱਚ ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ।

ਇਸ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨੇ ਸਾਡੇ ਗਲੋਬਲ ਰੀਅਲ-ਟਾਈਮ ਮੀਡੀਆ ਟ੍ਰੈਫਿਕ ਨੂੰ ਤੁਲਨਾਤਮਕ ਤੌਰ 'ਤੇ ਛੋਟੇ ਰਿਲੇਅ ਫੁੱਟਪ੍ਰਿੰਟ ਨਾਲ ਸੰਭਾਲਿਆ, ਇਸ ਲਈ ਅਸੀਂ ਕਰਨਲ ਬਾਈਪਾਸ ਰੂਟ ਦੀ ਬਜਾਏ ਸਰਲ ਡਿਜ਼ਾਈਨ ਜਾਰੀ ਰੱਖਿਆ।

ਇਹ ਆਰਕੀਟੈਕਚਰ ਸਾਨੂੰ ਹਜ਼ਾਰਾਂ UDP ਪੋਰਟਾਂ ਨੂੰ ਐਕਸਪੋਜ਼ ਕੀਤੇ ਬਿਨ੍ਹਾਂ Kubernetes ਵਿੱਚ WebRTC ਮੀਡੀਆ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਛੋਟੀ ਅਤੇ ਨਿਸ਼ਚਿਤ UDP ਸਤਹ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਅਤੇ ਲੋਡ ਬੈਲੇਂਸ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਵੱਡੀਆਂ ਜਨਤਕ ਪੋਰਟ ਰੇਂਜਾਂ ਰਿਜ਼ਰਵ ਕੀਤੇ ਬਿਨ੍ਹਾਂ ਵਿਸਥਾਰ ਕਰਨ ਦਿੰਦਾ ਹੈ। Kubernetes ਵੱਲੋਂ ਬਿਹਤਰ ਇਨਫਰਾ ਸਮਰਥਨ ਅਤੇ ਛੋਟੀ ਸਰਫ਼ੇਸ ਏਰੀਆ ਕਾਰਨ ਵਧੀਕ ਸੁਰੱਖਿਆ ਦੇ ਨਾਲ, ਇਹ ਡਿਜ਼ਾਈਨ ਕਲਾਇੰਟਾਂ ਲਈ ਮਿਆਰੀ WebRTC ਵਿਵਹਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦਾ ਹੈ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਸਾਡੇ ਵਰਕਲੋਡ ਲਈ SFU-ਰਹਿਤ ਡਿਜ਼ਾਈਨ ਸਹੀ ਡਿਫੌਂਲਟ ਸੀ। ਸਾਡੇ ਜ਼ਿਆਦਾਤਰ ਸੈਸ਼ਨ ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ, ਲੇਟੈਂਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਜਦੋਂ ਇਨਫਰੈਂਸ ਸੇਵਾਵਾਂ ਨੂੰ WebRTC ਪੀਅਰਾਂ ਵਾਂਗ ਵਿਹਾਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ, ਤਾਂ ਇਹਨਾਂ ਨੂੰ ਸਕੇਲ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

ਵਿਆਪਕ ਸਬਕ ਇਹ ਹੈ ਕਿ ਜਟਿਲਤਾ ਜੋੜਣ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਥਾਂ ਇੱਕ ਪਤਲੀ ਰੂਟਿੰਗ ਲੇਅਰ ਹੈ, ਨਾ ਕਿ ਹਰ ਬੈਕਐਂਡ ਸਰਵਿਸ ਵਿੱਚ, ਅਤੇ ਨਾ ਹੀ ਕਸਟਮ ਕਲਾਇੰਟ ਵਿਵਹਾਰ ਵਿੱਚ। ਰੂਟਿੰਗ ਮੈਟਾਡਾਟਾ ਨੂੰ ਪ੍ਰੋਟੋਕੋਲ-ਨੇਟਿਵ ਫੀਲਡ ਵਿੱਚ ਐਨਕੋਡ ਕਰਨ ਨਾਲ ਸਾਨੂੰ ਨਿਰਧਾਰਿਤ ਫਰਸਟ-ਪੈਕਟ ਰੂਟਿੰਗ, ਇੱਕ ਛੋਟਾ ਪਬਲਿਕ UDP ਫੁੱਟਪ੍ਰਿੰਟ, ਅਤੇ ਦੁਨੀਆ ਭਰ ਦੇ ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਨੇੜੇ ਇੰਗ੍ਰੈੱਸ ਸਥਾਪਤ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਲਚਕਤਾ ਮਿਲੀ।

ਕੁਝ ਚੋਣਾਂ ਖਾਸ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਸਨ:

• ਐਜ ਉੱਤੇ ਪ੍ਰੋਟੋਕੋਲ ਸਿਮੈਂਟਿਕਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ। ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਮਿਆਰੀ WebRTC ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਮੋਬਾਈਲ ਇੰਟਰਓਪਰੇਬਿਲਟੀ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦੀ ਹੈ।
• ਸਖ਼ਤ ਸੈਸ਼ਨ ਸਟੇਟਾਂ ਨੂੰ ਇੱਕੋ ਜਗ੍ਹਾ 'ਤੇ ਰੱਖੋ। ਟ੍ਰਾਂਸੀਵਰ ICE, DTLS, SRTP ਅਤੇ ਸੈਸ਼ਨ ਦੇ ਜੀਵਨ ਚੱਕਰ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ; ਰਿਲੇਅ ਸਿਰਫ਼ ਪੈਕਟ ਅੱਗੇ ਭੇਜਦਾ ਹੈ।
• ਸੈਟਅੱਪ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਜਾਣਕਾਰੀ ਦੇ ਆਧਾਰ 'ਤੇ ਰੂਟ ਕਰੋ। ICE ufrag ਨੇ ਸਾਨੂੰ ਹੌਟ-ਪਾਥ ਲੁੱਕਅੱਪ ਡਿਪੈਂਡੈਂਸੀ ਜੋੜੇ ਬਿਨ੍ਹਾਂ ਫਸਟ-ਪੈਕੇਟ ਰੂਟਿੰਗ ਹੁੱਕ ਦਿੱਤਾ।
• ਕਰਨਲ ਬਾਈਪਾਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਮ ਮਾਮਲੇ ਲਈ ਸਿਸਟਮ ਨੂੰ ਔਪਟੀਮਾਈਜ਼ ਕਰੋ। SO_REUSEPORT ਦੀ ਸਾਵਧਾਨ ਵਰਤੋਂ, ਥ੍ਰੈਡ ਪਿਨਿੰਗ, ਅਤੇ ਘੱਟ-ਐਲੋਕੇਸ਼ਨ ਪਾਰਸਿੰਗ ਵਾਲੀ ਇੱਕ ਸੀਮਿਤ-ਦਾਇਰੇ ਵਾਲੀ Go ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਸਾਡੇ ਵਰਕਲੋਡ ਲਈ ਕਾਫ਼ੀ ਸੀ।

ਰੀਅਲ-ਟਾਈਮ ਵੌਇਸ ਉਦੋਂ ਹੀ ਕਾਰਗਰ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਲੇਟੈਂਸੀ ਨੂੰ ਅਦ੍ਰਿਸ਼ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਸਾਡੇ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਸੀ ਕਿ ਕਲਾਇੰਟਾਂ ਵੱਲੋਂ WebRTC ਤੋਂ ਕੀਤੀਆਂ ਉਮੀਦਾਂ ਨੂੰ ਬਦਲੇ ਬਿਨ੍ਹਾਂ , ਆਪਣੀ WebRTC ਡਿਪਲੌਏਮੈਂਟ ਦੀ ਰੂਪ-ਰੇਖਾ ਬਦਲਣੀ।