ভয়েসের জন্য আপনার নেটওয়ার্ক অপ্টিমাইজ করুন

একটি ক্লাউড-বান্ধব নেটওয়ার্ক পরিকাঠামো ভয়েস ট্র্যাফিককে গুগল পরিকাঠামোর সাথে দক্ষতার সাথে যোগাযোগ করতে সক্ষম করে। এটি তৈরি করতে:

• নিশ্চিত করুন যেন ভয়েস ট্র্যাফিকের ইন্টারনেট সংযোগ পথটি সংক্ষিপ্ত হয়। এড়িয়ে চলুন:
  • প্রক্সি
  • প্যাকেট পরিদর্শন বা প্রোটোকল বিশ্লেষক
• পরিমাপ করুন এবং সর্বোত্তম করুন:
  • লেটেন্সি: সর্বোচ্চ ১৫০ মিলিসেকেন্ড একমুখী বিলম্ব ( আইটিইউ জি১১৪ )
  • ব্যান্ডউইথ: ৫০ কেবিপিএস (প্রস্তাবিত)
  • ওয়াই-ফাই নেটওয়ার্ক: ওয়াই- ফাই ব্যবহারের সর্বোত্তম পদ্ধতি দেখুন

আমরা দৃঢ়ভাবে সুপারিশ করছি যে আপনার নেটওয়ার্ক যেন ভয়েস ট্র্যাফিকের জন্য প্রক্সি সার্ভার ব্যবহার না করে:

• প্রক্সি কনফিগারেশনে, ভয়েস ট্র্যাফিককে একটি অনুমোদিত তালিকায় রাখুন।
• গুগল মিটের মতো ভয়েস টিসিপি-তে ফলব্যাক করে না। ভয়েস শুধুমাত্র ভয়েস ট্র্যাফিকের জন্য ইউডিপি ব্যবহার করে।
• ট্র্যাফিক প্রক্সি করার ফলে ল্যাটেন্সি বাড়ে এবং এর কারণে ভয়েস স্বয়ংক্রিয়ভাবে অডিওর মান কমিয়ে দিতে পারে। ক্লায়েন্ট এবং গুগল ব্যাকএন্ডের মধ্যে ল্যাটেন্সি ১০০ মিলিসেকেন্ডের কম হলে ভয়েসের পারফরম্যান্স সর্বোত্তম থাকে।
• সকেট সিকিওর (SOCKS5) ইন্টারনেট প্রোটোকল সমর্থিত নয়।

সম্ভব হলে, ভয়েসের জন্য প্যাকেট ইন্সপেকশন বা প্রোটোকল অ্যানালাইজার ব্যবহার করবেন না। এগুলো এমন ল্যাটেন্সি তৈরি করে, যার ফলে ভয়েস ইনফ্রাস্ট্রাকচার স্বয়ংক্রিয়ভাবে অডিওর মান কমিয়ে দিতে পারে।

অডিও ট্র্যাফিকের প্যাকেট পরিদর্শন করেও খুব একটা লাভ হয় না, কারণ স্বয়ংক্রিয় স্ক্যানিং টুলগুলো অডিও স্ট্রিম ডেটা পুনর্গঠন করতে পারে না।

এই টুলগুলো ব্যবহার করা হলে, টুলগুলোকে বাইপাস করার জন্য সমস্ত ভয়েস ট্র্যাফিক পোর্ট নম্বর একটি অ্যালাওলিস্টে রাখুন।

নিম্নলিখিত সুপারিশগুলি সাধারণ অফিস পরিবেশের জন্য প্রযোজ্য। একজন ওয়্যারলেস ইঞ্জিনিয়ারের উচিত উৎপাদন কেন্দ্র, উচ্চ মাত্রার রেডিও ফ্রিকোয়েন্সি (RF) নয়েজযুক্ত এলাকা বা স্বল্প আচ্ছাদিত স্থানের মতো আরও জটিল পরিবেশগুলি ক্ষেত্রবিশেষে মূল্যায়ন করা।

একটি ওয়্যারলেস নেটওয়ার্কে রিয়েল-টাইম অ্যাপ্লিকেশন চালানো বেশ কঠিন হতে পারে, কারণ এর আরএফ স্পেকট্রাম এবং ব্যান্ডউইথ ব্যবহারকারী সমস্ত ডিভাইসের মধ্যে ভাগ হয়ে যায়।

ভয়েসের সাথে ব্যবহৃত ওয়্যারলেস নেটওয়ার্কের ডিজাইন, স্থাপন এবং পরিচালনার সময় নিম্নলিখিত বিষয়গুলো যত্নসহকারে পর্যালোচনা করুন।

২.৪ গিগাহার্টজ বনাম ৫ গিগাহার্টজ আরএফ ব্যান্ড

আমরা সাধারণত সুপারিশ করি যে, রিয়েল-টাইম অ্যাপ্লিকেশনগুলো কোনো ওয়্যারলেস নেটওয়ার্কের (সাধারণত ব্যাপকভাবে ব্যবহৃত) ২.৪ গিগাহার্টজ ব্যান্ডে স্থাপন ও পরিচালনা করা উচিত নয়। এই সুপারিশের মধ্যে সেইসব অ্যাপ্লিকেশনও অন্তর্ভুক্ত, যেগুলো একটি সাধারণ অফিস পরিবেশে সংযোগ প্রদান করে।

২.৪ গিগাহার্টজ ব্যান্ডটি সমস্যাযুক্ত, কারণ এতে মাত্র ৩টি পরস্পর-অসংলগ্ন চ্যানেল রয়েছে, সাধারণত কাছাকাছি থাকা হস্তক্ষেপকারী নেটওয়ার্কগুলো থেকে উচ্চ মাত্রার নয়েজ আসে এবং অন্যান্য ডিভাইস (যেমন মাইক্রোওয়েভ) থেকে অতিরিক্ত হস্তক্ষেপ একটি কোলাহলপূর্ণ ও জটিল আরএফ পরিবেশ তৈরি করে।

ভয়েসের মতো রিয়েল-টাইম অ্যাপ্লিকেশনগুলির নির্ভরযোগ্য কার্যক্রম পর্যাপ্ত ধারণক্ষমতা, ডিলে, জিটার এবং প্যাকেট-লস লেভেলের উপর নির্ভর করে, যা ২.৪ গিগাহার্টজ ব্যান্ডে অর্জন করা প্রায় অসম্ভব।

নকশা/মোতায়েন বিবেচনা

রিয়েল-টাইম অ্যাপ্লিকেশন সমর্থন করার জন্য যদি আপনি একটি ওয়্যারলেস নেটওয়ার্ক ডিজাইন করেন, তবে কভারেজের পরিবর্তে ধারণক্ষমতা নিয়ে ভাবুন।

• সেল সাইজ পরিচালনা করুন, যা অ্যাক্সেস পয়েন্টের (AP) ট্রান্সমিট পাওয়ার দ্বারা নিয়ন্ত্রিত হয়। ধারণক্ষমতা বাড়ানোর জন্য মিটিং রুম এবং অডিটোরিয়ামের মতো যেখানে বেশি ডিভাইস আসার সম্ভাবনা থাকে, সেখানে ছোট সেল স্থাপন করুন। বড় সেল অফিসের ফ্লোরে সাধারণ কভারেজ প্রদান করতে পারে।
• আরএফ ব্যবহারের দক্ষতা বাড়াতে লো রেট নিষ্ক্রিয় করুন। এটি এপি-গুলোর মধ্যে রোমিং করার সময় ক্লায়েন্টকে নিকটতম এপি-তে হ্যান্ডওভার করতে বাধ্য করে।

যদি কোনো ওয়্যারলেস নেটওয়ার্কের SSID উভয় ব্যান্ডেই (২.৪ গিগাহার্টজ এবং ৫ গিগাহার্টজ) উপলব্ধ থাকে, তবে ক্লায়েন্টদের ৫ গিগাহার্টজ ব্যান্ডে যেতে বাধ্য করার জন্য নেটওয়ার্কটির অ্যাগ্রেসিভ ব্যান্ড স্টিয়ারিং প্রয়োগ করা উচিত।

• একটি বাস্তবসম্মত প্রত্যাশা হলো একই AP-তে ১০টির বেশি ডেস্ক ফোন সংযুক্ত না থাকা। এর চেয়ে বেশি সংখ্যক ফোন সংযুক্ত থাকলে ব্যবহারকারীর অভিজ্ঞতা অপ্রত্যাশিত হতে পারে।
• এজেন্ট বা সাপোর্ট টিমের মতো উচ্চ ঘনত্বের বা উচ্চ ভয়েস কল টিমের ওয়্যারলেস-সংযুক্ত ডেস্ক ফোন ব্যবহার করা উচিত নয়। উদাহরণস্বরূপ, GOVO সাইট বা ২৪/৭ কল সেন্টার।
• ওয়্যারলেস-সংযুক্ত ডেস্ক ফোনের ক্ষেত্রে ১০ সেকেন্ডের কম সময়ের সংক্ষিপ্ত কথোপকথন বিঘ্ন ঘটা স্বাভাবিক এবং নেটওয়ার্ক পর্যায়ে তা দূর করা সম্ভব নয়। আমরা সম্মেলন, সংবাদ সম্মেলন বা নির্বাহী পর্যায়ের কলের মতো গুরুত্বপূর্ণ ফোন কলের জন্য ওয়্যারলেস নেটওয়ার্ক ব্যবহারের সুপারিশ করি না।
• যদিও দেশ/অঞ্চলভেদে নিয়মকানুন ভিন্ন হয়, একটি সাধারণ শর্ত হলো ডিএফএস চ্যানেল ব্যবহারকারী ওয়াই-ফাই ডিভাইসগুলো যেন আপনার স্থানীয় আবহাওয়া রাডার সিস্টেমে হস্তক্ষেপ না করে, তা নিশ্চিত করা। এর ফলে, রাডার হস্তক্ষেপের শিকার হওয়া একটি এপি (AP) চ্যানেলটি ছেড়ে দেবে। সমস্ত ক্লায়েন্টকে ভিন্ন চ্যানেলে পরিচালিত একটি ভিন্ন এপি-তে পুনরায় সংযোগ করতে হবে।

AP-গুলোর মধ্যে নির্বিঘ্ন রোমিং এবং সঠিক RF ব্যবস্থাপনার মতো উন্নত বৈশিষ্ট্যগুলো কার্যকর করার জন্য, একটি ওয়্যারলেস নেটওয়ার্ককে কেন্দ্রীয়ভাবে পরিচালনা ও নিয়ন্ত্রণ করা উচিত—এটি বিচ্ছিন্ন ও স্বতন্ত্র AP-গুলোর একটি সংগ্রহ হওয়া উচিত নয়।

অবশেষে, ভয়েস সাধারণত ব্যবহৃত হয় এমন স্থানগুলোতে ওয়্যারলেস কভারেজ নিশ্চিত করার জন্য ডেপ্লয়মেন্ট-পরবর্তী একটি সমীক্ষা চালান।

ভয়েস ট্র্যাফিক সুরক্ষিত এবং এনক্রিপ্টেড, তাই গুগল আইপি-তে ট্র্যাফিক সীমাবদ্ধ করার কোনো প্রয়োজন নেই।

তবে, যদি আপনার নেটওয়ার্কের সীমাবদ্ধতার কারণে ট্র্যাফিক সীমিত করার প্রয়োজন হয়, তাহলে ভয়েস মিডিয়া সার্ভারগুলোকে অনুমতি দেওয়ার জন্য নিম্নলিখিত আইপি রেঞ্জগুলোকে একটি অ্যালাওলিস্টে রাখুন। এই আইপিগুলো শুধুমাত্র গুগল ওয়ার্কস্পেসের ভয়েস পরিষেবার জন্য ব্যবহৃত হয়, যার ফলে আপনি গুগল ওয়ার্কস্পেসে ব্যবহৃত ভয়েস ট্র্যাফিক শনাক্ত করতে এবং গ্রাহক অ্যাকাউন্টগুলো থেকে আসা ভয়েস ট্র্যাফিকের অগ্রাধিকার কমাতে পারবেন। এটি আপনাকে নেটওয়ার্ক এবং ফায়ারওয়াল অ্যাক্সেস আরও ভালোভাবে সেট আপ ও অপ্টিমাইজ করতে সাহায্য করতে পারে।

• আইপিভি৪: ৭৪.১২৫.৩৯.০/২৪
• IPv6: 2001:4860:4864:2::0/64

আপনার নেটওয়ার্কটি এমনভাবে সেট আপ করুন যাতে নিম্নলিখিত পোর্টগুলির মাধ্যমে আপনার প্রতিষ্ঠানে ভয়েস ট্র্যাফিক আসা-যাওয়া করতে পারে:

• বহির্গামী ইউডিপি পোর্ট ১৯৩০২ থেকে ১৯৩০৯
• বহির্গামী TCP পোর্ট 443

দ্রষ্টব্য: ভয়েস পোর্ট রেঞ্জ ১৯৩০২ থেকে ১৯৩০৯ পর্যন্ত Chrome WebRTC UDP পোর্ট সেটিং ব্যবহার করে। আরও জানতে, ব্যবহারকারী বা ব্রাউজারের জন্য Chrome নীতি নির্ধারণ পড়ুন।