স্কাইপ থেকে WebRTC: কিভাবে আমরা ওয়েবের মাধ্যমে ভিডিও যোগাযোগ সংগঠিত করেছি

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

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

ইতিহাস একটি বিট

2017 সালের গ্রীষ্মে, স্কাইং ডেভেলপমেন্টের প্রধান, সের্গেই সাফোনভ, ব্যাকএন্ড কনফ-এ কীভাবে আমরা "স্কাইপ পরিত্যাগ করেছি এবং WebRTC প্রয়োগ করেছি" সে সম্পর্কে একটি গল্প দিয়েছিলেন। আগ্রহীরা ভাষণের রেকর্ডিং এখানে দেখতে পারেন লিংক (~45 মিনিট), এবং এখানে আমি সংক্ষেপে এর সারাংশ তুলে ধরব।

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

প্রকৃতপক্ষে, ভিডিও যোগাযোগের জন্য আমাদের প্রয়োজনীয়তাগুলি প্রায় নিম্নরূপ ছিল:
- স্থিতিশীলতা;
- পাঠ প্রতি কম দাম;
- রেকর্ডিং পাঠ;
— কে কতটা কথা বলে তা ট্র্যাক করা (আমাদের জন্য এটা গুরুত্বপূর্ণ যে ছাত্ররা পাঠের সময় শিক্ষকের চেয়ে বেশি কথা বলে);
- লিনিয়ার স্কেলিং;
- UDP এবং TCP উভয় ব্যবহার করার ক্ষমতা।

2013 সালে টোকবক্স বাস্তবায়নের প্রথম চেষ্টা করা হয়েছিল। সবকিছুই ভাল ছিল, তবে এটি খুব ব্যয়বহুল হয়ে উঠল - প্রতি পাঠে 113 রুবেল - এবং লাভটি খেয়েছিল।

তারপর 2015 সালে, Voximplant একত্রিত করা হয়েছিল। কে কতটা কথা বলেছিল তা ট্র্যাক করার জন্য এখানে আমাদের ফাংশনটি ছিল এবং একই সময়ে সমাধানটি অনেক সস্তা ছিল: যদি কেবল অডিও রেকর্ড করা হয় তবে প্রতি পাঠে 20 রুবেল খরচ হয়। যাইহোক, এটি শুধুমাত্র UDP এর মাধ্যমে কাজ করে এবং TCP-এ স্যুইচ করতে পারেনি। যাইহোক, প্রায় 40% শিক্ষার্থী এটি ব্যবহার করে শেষ করেছে।

এক বছর পরে, আমরা তাদের নিজস্ব নির্দিষ্ট প্রয়োজনীয়তা সহ কর্পোরেট ক্লায়েন্ট পেতে শুরু করি। উদাহরণস্বরূপ, সবকিছু একটি ব্রাউজারের মাধ্যমে কাজ করা উচিত; কোম্পানি শুধুমাত্র http এবং https খোলে; যেমন কোন স্কাইপ বা UDP নেই। কর্পোরেট ক্লায়েন্ট = টাকা, তাই তারা টোকবক্সে ফিরে এসেছে, কিন্তু দামের সমস্যা দূর হয়নি।

সমাধান - WebRTC এবং Janus

ব্যবহার করার সিদ্ধান্ত নিয়েছে পিয়ার-টু-পিয়ার ভিডিও যোগাযোগের জন্য ব্রাউজার প্ল্যাটফর্ম WebRTC. এটি একটি সংযোগ স্থাপন, এনকোডিং এবং ডিকোডিং স্ট্রীম, ট্র্যাক সিঙ্ক্রোনাইজ করা এবং নেটওয়ার্ক গ্লিচগুলি পরিচালনার সাথে মান নিয়ন্ত্রণের জন্য দায়ী। আমাদের অংশের জন্য, আমাদের অবশ্যই ক্যামেরা এবং মাইক্রোফোন থেকে স্ট্রীম পড়া, ভিডিও আঁকা, সংযোগ পরিচালনা, একটি WebRTC সংযোগ স্থাপন এবং এতে স্ট্রীম প্রেরণ নিশ্চিত করতে হবে, সেইসাথে সংযোগ স্থাপনের জন্য ক্লায়েন্টদের মধ্যে সংকেত বার্তা প্রেরণ নিশ্চিত করতে হবে (WebRTC নিজেই বর্ণনা করে শুধুমাত্র তথ্য বিন্যাস, কিন্তু এর প্রক্রিয়া স্থানান্তর নয়)। যদি ক্লায়েন্টরা NAT-এর পিছনে থাকে, WebRTC STUN সার্ভারগুলিকে সংযুক্ত করে; যদি এটি সাহায্য না করে, সার্ভারগুলিকে টার্ন করুন৷

একটি নিয়মিত p2p সংযোগ আমাদের জন্য যথেষ্ট নয়, কারণ আমরা অভিযোগের ক্ষেত্রে আরও বিশ্লেষণের জন্য পাঠ রেকর্ড করতে চাই। তাই আমরা একটি রিলে মাধ্যমে WebRTC স্ট্রীম পাঠাই মিটেকো দ্বারা জানুস গেটওয়ে. ফলস্বরূপ, ক্লায়েন্টরা একে অপরের ঠিকানা জানেন না, শুধুমাত্র জানুস সার্ভারের ঠিকানা দেখে; এটি একটি সংকেত সার্ভারের কার্য সম্পাদন করে। জানুসের আমাদের প্রয়োজনীয় অনেক বৈশিষ্ট্য রয়েছে: ক্লায়েন্টের UDP ব্লক থাকলে স্বয়ংক্রিয়ভাবে TCP-তে সুইচ করে; UDP এবং TCP উভয় স্ট্রিম রেকর্ড করতে পারে; মাপযোগ্য; এমনকি ইকো পরীক্ষার জন্য একটি বিল্ট-ইন প্লাগইন রয়েছে। প্রয়োজনে, Twilio থেকে STUN এবং TURN সার্ভার স্বয়ংক্রিয়ভাবে সংযুক্ত হয়।

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

ভিডিও যোগাযোগের বিষয়ে ফিরে আসছি

আমরা ক্রমাগত ছাত্র এবং শিক্ষকদের কাছ থেকে প্রতিক্রিয়া নিরীক্ষণ করি যাতে সময়মত সমস্যাগুলি সনাক্ত এবং সংশোধন করা যায়। 2018 সালের গ্রীষ্মে, অভিযোগগুলির মধ্যে কলের মান দৃঢ়ভাবে প্রথম স্থানে ছিল। একদিকে, এর অর্থ হল আমরা সফলভাবে অন্যান্য ত্রুটিগুলি কাটিয়ে উঠতে পেরেছি। অন্যদিকে, জরুরিভাবে কিছু করা দরকার ছিল: পাঠটি ব্যাহত হলে, আমরা এর মূল্য হারানোর ঝুঁকি নিয়ে থাকি, কখনও কখনও পরবর্তী প্যাকেজ কেনার খরচ সহ, এবং যদি প্রাথমিক পাঠ ব্যাহত হয়, আমরা একজন সম্ভাব্য ক্লায়েন্টকে হারানোর ঝুঁকি নিয়ে থাকি। সব মিলিয়ে

সেই সময়ে, আমাদের ভিডিও যোগাযোগ এখনও MVP মোডে ছিল। সহজ কথায়, তারা এটি চালু করেছে, এটি কাজ করেছে, তারা এটিকে একবার স্কেল করেছে, তারা বুঝতে পেরেছে কিভাবে এটি করতে হবে - ভাল, দুর্দান্ত। যদি এটি কাজ করে তবে এটি ঠিক করবেন না। কেউই ইচ্ছাকৃতভাবে যোগাযোগের মানের সমস্যাটি সমাধান করেনি। আগস্টের মধ্যে, এটা স্পষ্ট হয়ে গেল যে এটি চলতে পারে না, এবং WebRTC এবং Janus-এর সাথে কী ভুল ছিল তা বের করার জন্য আমরা একটি পৃথক দিকনির্দেশ চালু করেছি।

ইনপুটে, এই দিকটি প্রাপ্ত হয়েছে: একটি MVP সমাধান, কোনও মেট্রিক্স নেই, কোনও লক্ষ্য নেই, উন্নতির জন্য কোনও প্রক্রিয়া নেই, যখন 7% শিক্ষক যোগাযোগের গুণমান সম্পর্কে অভিযোগ করেন (ছাত্রদেরও কোনও ডেটা ছিল না)৷

একটি নতুন দিকনির্দেশনা চলছে

কমান্ড এই মত কিছু দেখায়:

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

শুরু করার জন্য, আমরা একটি অপেক্ষাকৃত নির্ভরযোগ্য মেট্রিক সেট আপ করেছি যা যোগাযোগের গুণমান মূল্যায়নের পরিবর্তনগুলি ট্র্যাক করে (দিন, সপ্তাহ, মাসের গড়)। সেই সময়ে, এগুলি ছিল শিক্ষকদের কাছ থেকে গ্রেড; পরে ছাত্রদের গ্রেডগুলি তাদের সাথে যুক্ত করা হয়েছিল। তারপরে তারা কী ভুল কাজ করছে সে সম্পর্কে অনুমান তৈরি করতে শুরু করে, এটি সংশোধন করে এবং গতিবিদ্যার পরিবর্তনগুলি দেখে। আমরা কম ঝুলন্ত ফলের জন্য গিয়েছিলাম: উদাহরণস্বরূপ, আমরা vp8 দিয়ে vp9 কোডেক প্রতিস্থাপন করেছি, কর্মক্ষমতা উন্নত হয়েছে। আমরা জানুস সেটিংসের সাথে খেলতে এবং অন্যান্য পরীক্ষা-নিরীক্ষা করার চেষ্টা করেছি - বেশিরভাগ ক্ষেত্রেই তারা কিছুতে নেতৃত্ব দেয়নি।

দ্বিতীয় পর্যায়ে, একটি হাইপোথিসিস আবির্ভূত হয়: WebRTC হল একটি পিয়ার-টু-পিয়ার সমাধান, এবং আমরা মাঝখানে একটি সার্ভার ব্যবহার করি। সম্ভবত সমস্যা এখানে মিথ্যা? আমরা খনন শুরু করেছি এবং এখন পর্যন্ত সবচেয়ে উল্লেখযোগ্য উন্নতি পেয়েছি।

সেই মুহুর্তে, পুল থেকে একটি সার্ভার একটি বরং বোকা অ্যালগরিদম ব্যবহার করে নির্বাচন করা হয়েছিল: চ্যানেল এবং শক্তির উপর নির্ভর করে প্রত্যেকটির নিজস্ব "ওজন" ছিল এবং আমরা ব্যবহারকারীকে সবচেয়ে বড় "ওজন" ছাড়াই পাঠাতে চেষ্টা করেছি। ব্যবহারকারী ভৌগলিকভাবে কোথায় অবস্থিত ছিল সেদিকে মনোযোগ দেওয়া। ফলস্বরূপ, সেন্ট পিটার্সবার্গের একজন শিক্ষক সাইবেরিয়া থেকে মস্কোর মাধ্যমে একজন শিক্ষার্থীর সাথে যোগাযোগ করতে পারেন, সেন্ট পিটার্সবার্গে আমাদের জানুস সার্ভারের মাধ্যমে নয়।

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

আমরা সম্প্রতি আরেকটি অ-স্পষ্ট, কিন্তু দৃশ্যত গুরুত্বপূর্ণ জিনিস আবিষ্কার করেছি: একটি মোটা চ্যানেলে একটি শক্তিশালী জানুস সার্ভারের পরিবর্তে, পাতলা ব্যান্ডউইথ সহ দুটি সহজ সার্ভার থাকা ভাল। আমরা একই সময়ে অনেকগুলি কক্ষ (যোগাযোগ সেশন) ক্র্যাম করার আশায় শক্তিশালী মেশিন কেনার পরে এটি পরিষ্কার হয়ে গেল। সার্ভারগুলির একটি ব্যান্ডউইথের সীমা থাকে, যা আমরা সঠিকভাবে রুমের সংখ্যায় অনুবাদ করতে পারি - আমরা জানি কতগুলি খোলা যেতে পারে, উদাহরণস্বরূপ, 300 Mbit/s এ। যত তাড়াতাড়ি একটি সার্ভারে অনেকগুলি রুম খোলা থাকে, আমরা লোড কম না হওয়া পর্যন্ত এটিকে নতুন কার্যকলাপের জন্য বেছে নেওয়া বন্ধ করি৷ ধারণাটি ছিল যে, একটি শক্তিশালী মেশিন কেনার পরে, আমরা এটিতে চ্যানেলটিকে সর্বাধিক লোড করব, যাতে শেষ পর্যন্ত এটি ব্যান্ডউইথের দ্বারা নয়, প্রসেসর এবং মেমরি দ্বারা সীমাবদ্ধ থাকবে। তবে দেখা গেল যে নির্দিষ্ট সংখ্যক খোলা কক্ষের পরে (420), প্রসেসর, মেমরি এবং ডিস্কের লোড এখনও সীমা থেকে অনেক দূরে থাকা সত্ত্বেও, প্রযুক্তিগত সহায়তায় নেতিবাচকতা আসতে শুরু করে। স্পষ্টতই, জানুসের ভিতরে কিছু খারাপ হচ্ছে, সম্ভবত সেখানেও কিছু বিধিনিষেধ রয়েছে। আমরা পরীক্ষা-নিরীক্ষা শুরু করেছি, ব্যান্ডউইথের সীমা 300 থেকে 200 Mbit/s-এ নামিয়েছি এবং সমস্যাগুলি চলে গেছে। এখন আমরা কম সীমা এবং বৈশিষ্ট্য সহ একসাথে তিনটি নতুন সার্ভার কিনেছি, আমরা মনে করি এটি যোগাযোগের মানের একটি স্থিতিশীল উন্নতির দিকে নিয়ে যাবে। অবশ্যই, আমরা সেখানে কী ঘটছে তা বোঝার চেষ্টা করিনি; আমাদের ক্রাচই সবকিছু। আমাদের প্রতিরক্ষায়, আসুন বলি যে সেই মুহুর্তে চাপের সমস্যাটি যত তাড়াতাড়ি সম্ভব সমাধান করা প্রয়োজন ছিল এবং এটি সুন্দরভাবে করা উচিত নয়; এছাড়াও, আমাদের জন্য Janus হল C তে লেখা একটি কালো বক্স, এটির সাথে টিঙ্কার করা খুব ব্যয়বহুল।

আচ্ছা, প্রক্রিয়ায় আমরা:

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

পরীক্ষাগুলি এবং পরবর্তী পরিবর্তনগুলি জানুয়ারী 7,1 এর 2018% থেকে 2,5 সালের জানুয়ারীতে 2019% থেকে শিক্ষকদের মধ্যে যোগাযোগের সাথে অসন্তোষ কমিয়ে আনা সম্ভব করেছে।

পরবর্তী কি

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

প্রধান অসুবিধা হ'ল আমরা জানি না যে গুণমান উন্নত করা আসলে কোন স্তরে সম্ভব। এই সিলিং খুঁজে বের করা প্রধান কাজ। অতএব, দুটি পরীক্ষার পরিকল্পনা করা হয়েছিল:

1. যুদ্ধের পরিস্থিতিতে নিয়মিত p2p এর সাথে Janus এর মাধ্যমে ভিডিও তুলনা করুন। এই পরীক্ষাটি ইতিমধ্যেই করা হয়েছে, আমাদের সমাধান এবং p2p এর মধ্যে কোন পরিসংখ্যানগতভাবে উল্লেখযোগ্য পার্থক্য পাওয়া যায়নি;
2. ভিডিও কমিউনিকেশন সলিউশনের মাধ্যমে একচেটিয়াভাবে অর্থ উপার্জনকারী সংস্থাগুলি থেকে (ব্যয়বহুল) পরিষেবা সরবরাহ করা যাক এবং বিদ্যমান একটির সাথে তাদের থেকে নেতিবাচকতার পরিমাণ তুলনা করি।

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

এছাড়াও, বেশ কয়েকটি কাজ রয়েছে যা নিয়মিতভাবে সমাধান করা যেতে পারে:

• আমরা বিষয়ভিত্তিক পর্যালোচনার পরিবর্তে যোগাযোগের মানের একটি প্রযুক্তিগত মেট্রিক তৈরি করি;
• আমরা আরও বিস্তারিত সেশন লগগুলি তৈরি করি যাতে ঘটে যাওয়া ব্যর্থতাগুলি আরও সঠিকভাবে বিশ্লেষণ করা যায়, কখন এবং ঠিক কোথায় ঘটেছিল এবং সেই মুহূর্তে কী আপাতদৃষ্টিতে সম্পর্কহীন ঘটনা ঘটেছিল তা বোঝার জন্য;
• আমরা পাঠের আগে একটি স্বয়ংক্রিয় সংযোগের গুণমান পরীক্ষা প্রস্তুত করি, এবং ক্লায়েন্টকে তার হার্ডওয়্যার এবং চ্যানেল দ্বারা সৃষ্ট নেতিবাচকতার পরিমাণ হ্রাস করার জন্য ম্যানুয়ালি সংযোগ পরীক্ষা করার সুযোগও দিই;
• আমরা পরিবর্তনশীল প্যাকেট লস ইত্যাদি সহ খারাপ পরিস্থিতিতে আরও ভিডিও যোগাযোগ লোড পরীক্ষা তৈরি করব এবং পরিচালনা করব;
• আমরা ত্রুটি সহনশীলতা বাড়ানোর জন্য সমস্যার ক্ষেত্রে সার্ভারের আচরণ পরিবর্তন করি;
• আমরা ব্যবহারকারীকে সতর্ক করব যদি তার সংযোগে কিছু ভুল থাকে, যেমন স্কাইপ করে, যাতে সে বুঝতে পারে যে সমস্যাটি তার পক্ষে।

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

এবং, অবশ্যই, আমরা ভিডিও যোগাযোগের সাথে কাজ করা ব্যক্তি এবং কোম্পানিগুলির সাথে সক্রিয়ভাবে যোগাযোগ চালিয়ে যাচ্ছি। আপনি যদি আমাদের সাথে অভিজ্ঞতা বিনিময় করতে চান, আমরা খুশি হব! মন্তব্য করুন, যোগাযোগ করুন - আমরা সবাইকে উত্তর দেব।

উত্স: www.habr.com