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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डिज़ाइन/डिप्लॉयमेंट के दौरान ध्यान देने वाली बातें

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

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

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

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

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

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

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

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

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

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

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

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