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 की नीतियां सेट करना लेख पढ़ें.