Voice के लिए अपना नेटवर्क ऑप्टिमाइज़ करना

क्लाउड-फ़्रेंडली नेटवर्क इन्फ़्रास्ट्रक्चर की मदद से, वॉइस ट्रैफ़िक को Google के इन्फ़्रास्ट्रक्चर के साथ बेहतर तरीके से कम्यूनिकेट करने में मदद मिलती है. इसे बनाने के लिए:

• पक्का करें कि वॉइस ट्रैफ़िक के लिए इंटरनेट का शॉर्ट पाथ उपलब्ध हो. इनसे बचें:
  • प्रॉक्सी
  • पैकेट की जांच या प्रोटोकॉल ऐनालाइज़र
• मेज़रमेंट और ऑप्टिमाइज़ेशन:
  • विलंबता: एक तरफ़ से दूसरी तरफ़ डेटा पहुंचने में ज़्यादा से ज़्यादा 150 मि॰से॰ का समय लगना चाहिए (ITU G114)
  • बैंडविड्थ: 50 केबीपीएस का सुझाव दिया गया है
  • वाई-फ़ाई नेटवर्क: वाई-फ़ाई इस्तेमाल करने के सबसे सही तरीके देखें

हमारा सुझाव है कि आपका नेटवर्क, वॉइस ट्रैफ़िक के लिए प्रॉक्सी सर्वर का इस्तेमाल न करे:

• प्रॉक्सी कॉन्फ़िगरेशन में, Voice के ट्रैफ़िक को अनुमति वाली सूची में रखें.
• Google Meet की तरह, Voice टीसीपी पर फ़ॉलबैक नहीं करता है. Voice, सिर्फ़ वॉइस ट्रैफ़िक के लिए यूडीपी का इस्तेमाल करता है.
• ट्रैफ़िक को प्रॉक्सी करने से इंतज़ार का समय बढ़ जाता है. इससे Voice, ऑडियो की क्वालिटी को अपने-आप कम कर सकता है. आवाज़ की परफ़ॉर्मेंस तब सबसे अच्छी होती है, जब क्लाइंट और Google के बैकएंड के बीच इंतज़ार का समय 100 मि॰से॰ से कम हो.
• सॉकेट सिक्योर (SOCKS5) इंटरनेट प्रोटोकॉल काम नहीं करता.

अगर हो सके, तो Voice के लिए पैकेट की जांच करने या प्रोटोकॉल ऐनालाइज़र का इस्तेमाल न करें. इनसे ऑडियो ट्रांसफ़र होने में देरी होती है. इस वजह से, वॉइस इंफ़्रास्ट्रक्चर ऑडियो की क्वालिटी को अपने-आप कम कर सकता है.

ऑडियो ट्रैफ़िक की पैकेट जांच से भी ज़्यादा फ़ायदा नहीं मिलता, क्योंकि ऑटोमेटेड स्कैनिंग टूल, ऑडियो स्ट्रीम डेटा को फिर से नहीं बना सकते.

अगर इन टूल का इस्तेमाल किया जाता है, तो Voice के सभी पोर्ट नंबर को अनुमति वाली सूची में शामिल करें, ताकि टूल को बायपास किया जा सके.

यहां दिए गए सुझाव, सामान्य ऑफ़िस के माहौल पर लागू होते हैं. वायरलेस इंजीनियर को, हर मामले के हिसाब से ज़्यादा जटिल एनवायरमेंट का आकलन करना चाहिए. जैसे, मैन्युफ़ैक्चरिंग फ़्लोर, रेडियो फ़्रीक्वेंसी (आरएफ़) नॉइज़ वाली जगहें या कम कवरेज वाली जगहें.

वायरलेस नेटवर्क पर रीयल-टाइम ऐप्लिकेशन चलाना मुश्किल हो सकता है. ऐसा इसलिए, क्योंकि आरएफ स्पेक्ट्रम और बैंडविड्थ को इस्तेमाल करने वाले सभी डिवाइसों के साथ शेयर किया जाता है.

Voice के साथ इस्तेमाल किए जाने वाले वायरलेस नेटवर्क को डिज़ाइन, डिप्लॉय, और ऑपरेट करते समय, इन बातों का ध्यान रखें.

2.4 गीगाहर्ट्ज़ बनाम 5 गीगाहर्ट्ज़ आरएफ़ बैंड

हम आम तौर पर यह सुझाव देते हैं कि रीयल-टाइम ऐप्लिकेशन को वायरलेस नेटवर्क के 2.4 GHz बैंड पर डिप्लॉय और ऑपरेट न किया जाए. आम तौर पर, इस बैंड का इस्तेमाल ज़्यादा किया जाता है. इस सुझाव में ऐसे ऐप्लिकेशन शामिल हैं जो सामान्य ऑफ़िस के माहौल में कनेक्टिविटी देते हैं.

2.4 Ghz बैंड में समस्या आती है, क्योंकि इसमें सिर्फ़ तीन नॉन-ओवरलैपिंग चैनल होते हैं. साथ ही, आस-पास के नेटवर्क से ज़्यादा नॉइज़ लेवल होता है और अन्य डिवाइसों (जैसे, माइक्रोवेव) से ज़्यादा इंटरफ़ेरेंस होता है. इससे आरएफ़ का माहौल शोरगुल वाला और जटिल हो जाता है.

Voice जैसे रीयल-टाइम ऐप्लिकेशन के भरोसेमंद तरीके से काम करने के लिए, ज़रूरी है कि नेटवर्क में बैंडविड्थ की क्षमता, डेटा ट्रांसफ़र में लगने वाला समय, जिटर, और पैकेट लॉस का लेवल सही हो. 2.4 GHz बैंड पर इन सभी ज़रूरी शर्तों को पूरा करना लगभग नामुमकिन है.

डिज़ाइन/डिप्लॉयमेंट से जुड़ी ज़रूरी बातें

अगर आपको रीयल-टाइम ऐप्लिकेशन के लिए वायरलेस नेटवर्क डिज़ाइन करना है, तो कवरेज के बजाय क्षमता के बारे में सोचें.

• सेल के साइज़ को मैनेज करें. इसे ऐक्सेस पॉइंट (एपी) की ट्रांसमिट पावर से कंट्रोल किया जाता है. ज़्यादा डिवाइसों के लिए, छोटी सेल डिप्लॉय करें. जैसे, मीटिंग रूम और ऑडिटोरियम. इससे क्षमता बढ़ाई जा सकती है. बड़ी सेल, ऑफ़िस के फ़्लोर पर सामान्य कवरेज दे सकती हैं.
• आरएफ़ के इस्तेमाल की क्षमता को बेहतर बनाने के लिए, कम दरों को बंद करें. इससे, एक ऐक्सेस पॉइंट से दूसरे ऐक्सेस पॉइंट पर रोमिंग करते समय, क्लाइंट को सबसे नज़दीकी ऐक्सेस पॉइंट पर ट्रांसफ़र किया जाता है.

अगर किसी वायरलेस नेटवर्क का एसएसआईडी, दोनों बैंड (2.4 गीगाहर्ट्ज़ और 5 गीगाहर्ट्ज़) पर उपलब्ध है, तो नेटवर्क को एग्रेसिव बैंड स्टीयरिंग लागू करनी चाहिए, ताकि क्लाइंट को 5 गीगाहर्ट्ज़ बैंड पर स्विच करने के लिए मजबूर किया जा सके.

• एक ही ऐक्सेस पॉइंट (एपी) से कनेक्ट किए गए डेस्क फ़ोन की संख्या 10 से ज़्यादा नहीं होनी चाहिए. ज़्यादा संख्या में बदलाव करने से, उपयोगकर्ता अनुभव पर बुरा असर पड़ सकता है.
• वायरलेस तरीके से कनेक्ट किए गए डेस्क फ़ोन का इस्तेमाल, ज़्यादा घनत्व/ज़्यादा वॉइस कॉल वाली टीमों को नहीं करना चाहिए. जैसे, एजेंट या सहायता टीमें. उदाहरण के लिए, GOVO की साइटें या 24/7 कॉल सेंटर.
• वायरलेस तरीके से कनेक्ट किए गए डेस्क फ़ोन में, 10 सेकंड से कम समय के लिए आवाज़ में रुकावट आ सकती है. इसे नेटवर्क लेवल पर ठीक नहीं किया जा सकता. हमारा सुझाव है कि कॉन्फ़्रेंस, प्रेस मीटिंग या एक्ज़ीक्यूटिव कॉल जैसे ज़रूरी फ़ोन कॉल करने के लिए, वायरलेस नेटवर्क का इस्तेमाल न करें.
• हालांकि, देशों/इलाकों के हिसाब से नियम अलग-अलग होते हैं. हालांकि, एक सामान्य शर्त यह है कि वाई-फ़ाई डिवाइसों में, DFS चैनलों का इस्तेमाल किया जाना चाहिए. इससे यह पक्का किया जा सकेगा कि यह आपके स्थानीय मौसम रडार सिस्टम में रुकावट न डाले. इस वजह से, रडार के सिग्नल में रुकावट डालने वाला एपी चैनल बंद हो जाएगा. सभी क्लाइंट को, किसी दूसरे चैनल पर काम करने वाले किसी दूसरे एपी से फिर से कनेक्ट करना होगा.

ऐडवांस सुविधाओं का इस्तेमाल करने के लिए, वायरलेस नेटवर्क को केंद्रीय तौर पर मैनेज और ऑपरेट किया जाना चाहिए. जैसे, एपी के बीच बिना किसी रुकावट के रोमिंग करना और आरएफ़ को सही तरीके से मैनेज करना. यह अलग-अलग, स्टैंडअलोन एपी का कलेक्शन नहीं होना चाहिए.

आखिर में, डिप्लॉयमेंट के बाद वॉयरलेस सर्वे करें. इससे यह पुष्टि की जा सकेगी कि उन सभी जगहों पर वॉयरलेस कवरेज है जहां आम तौर पर Voice का इस्तेमाल किया जाता है.

वॉइस ट्रैफ़िक सुरक्षित होता है और इसे एन्क्रिप्ट (सुरक्षित) किया जाता है. इसलिए, Google के आईपी पतों पर ट्रैफ़िक को सीमित करने की कोई ज़रूरत नहीं है.

हालांकि, अगर आपके नेटवर्क में कुछ पाबंदियां हैं और आपको ट्रैफ़िक को सीमित करना है, तो वॉइस मीडिया सर्वर को अनुमति देने के लिए, आईपी पतों की इस सूची को अनुमति वाली सूची में जोड़ें. आईपी पतों का इस्तेमाल सिर्फ़ Voice for Google Workspace के लिए किया जाता है. इससे आपको Google Workspace में इस्तेमाल किए गए वॉइस ट्रैफ़िक की पहचान करने में मदद मिलती है. साथ ही, उपभोक्ता खातों से मिले वॉइस ट्रैफ़िक को कम प्राथमिकता दी जा सकती है. इससे आपको नेटवर्क और फ़ायरवॉल ऐक्सेस को बेहतर तरीके से सेट अप और ऑप्टिमाइज़ करने में मदद मिल सकती है.

• IPv4: 74.125.39.0/24
• IPv6: 2001:4860:4864:2::0/64

अपने नेटवर्क को इस तरह से सेट अप करें कि नीचे दिए गए पोर्ट, आपके संगठन में वॉइस ट्रैफ़िक को आने और जाने की अनुमति दें:

• आउटबाउंड यूडीपी पोर्ट 19302 से 19309
• आउटबाउंड टीसीपी पोर्ट 443

ध्यान दें: Voice की पोर्ट रेंज 19302 से 19309, Chrome WebRTC UDP पोर्ट सेटिंग का इस्तेमाल करती है. ज़्यादा जानने के लिए, उपयोगकर्ताओं या ब्राउज़र के लिए Chrome की नीतियां सेट करना लेख पढ़ें.