Skype થી WebRTC સુધી: અમે વેબ દ્વારા વિડિયો સંચાર કેવી રીતે ગોઠવ્યો

વિમબોક્સ પ્લેટફોર્મ પર શિક્ષક અને વિદ્યાર્થી વચ્ચે વાતચીતનો મુખ્ય માર્ગ વિડિયો કમ્યુનિકેશન છે. અમે લાંબા સમય પહેલા Skype છોડી દીધી હતી, ઘણા તૃતીય-પક્ષ ઉકેલો અજમાવ્યા હતા અને આખરે WebRTC - Janus-gateway સંયોજન પર સ્થાયી થયા હતા. થોડા સમય માટે અમે દરેક વસ્તુથી ખુશ હતા, પરંતુ તેમ છતાં કેટલાક નકારાત્મક પાસાઓ બહાર આવતા રહ્યા. પરિણામે, એક અલગ વિડિઓ દિશા બનાવવામાં આવી હતી.

મેં નવી દિશાના વડા કિરીલ રોગોવોયને સ્કાયેંગ ખાતે વિડિયો કમ્યુનિકેશનની ઉત્ક્રાંતિ, શોધાયેલ સમસ્યાઓ, ઉકેલો અને ક્રેચ વિશે વાત કરવા કહ્યું જેનો અમે આખરે ઉપયોગ કર્યો. અમે આશા રાખીએ છીએ કે લેખ એવી કંપનીઓ માટે ઉપયોગી થશે કે જેઓ વેબ એપ્લિકેશન દ્વારા પોતાની જાતે વિડિયો પણ બનાવે છે.

ઇતિહાસ એક બીટ

2017 ના ઉનાળામાં, Skyeng ડેવલપમેન્ટના વડા, Sergey Safonov, Backend Conf ખાતે અમે કેવી રીતે "Skype છોડી દીધું અને WebRTC અમલમાં મૂક્યું" તેની વાર્તા સાથે વાત કરી. રસ ધરાવતા લોકો ભાષણનું રેકોર્ડિંગ અહીં જોઈ શકે છે કડી (~45 મિનિટ), અને અહીં હું તેના સારને ટૂંકમાં રૂપરેખા આપીશ.

સ્કાયેંગ સ્કૂલ માટે, શિક્ષક-વિદ્યાર્થી સંચાર માટે વિડિયો કમ્યુનિકેશન હંમેશા પ્રાથમિકતાનો માર્ગ રહ્યો છે. શરૂઆતમાં, સ્કાયપેનો ઉપયોગ કરવામાં આવ્યો હતો, પરંતુ તે ઘણા કારણોસર સ્પષ્ટ રીતે સંતોષકારક ન હતો, મુખ્યત્વે લોગની અછત અને વેબ એપ્લિકેશનમાં સીધા જ એકીકરણની અશક્યતાને કારણે. તેથી, અમે તમામ પ્રકારના પ્રયોગો કર્યા.

વાસ્તવમાં, વિડિઓ સંચાર માટેની અમારી આવશ્યકતાઓ લગભગ નીચે મુજબ હતી:
- સ્થિરતા;
- પાઠ દીઠ ઓછી કિંમત;
- રેકોર્ડિંગ પાઠ;
- કોણ કેટલું બોલે છે તે ટ્રેકિંગ (અમારા માટે તે મહત્વનું છે કે વિદ્યાર્થીઓ પાઠ દરમિયાન શિક્ષક કરતાં વધુ બોલે);
- રેખીય સ્કેલિંગ;
- UDP અને TCP બંનેનો ઉપયોગ કરવાની ક્ષમતા.

2013 માં ટોકબોક્સને અમલમાં મૂકવાનો પ્રથમ પ્રયાસ કર્યો હતો. બધું સારું હતું, પરંતુ તે ખૂબ ખર્ચાળ બન્યું - પાઠ દીઠ 113 રુબેલ્સ - અને નફો ઉઠાવ્યો.

પછી 2015 માં, વોક્સીમ્પ્લાન્ટને એકીકૃત કરવામાં આવ્યું. કોણ કેટલું બોલે છે તે ટ્રૅક કરવા માટે અમારે જે ફંક્શનની જરૂર હતી તે અહીં હતું, અને તે જ સમયે સોલ્યુશન ઘણું સસ્તું હતું: જો માત્ર ઑડિયો રેકોર્ડ કરવામાં આવે, તો તેની કિંમત પ્રતિ પાઠ 20 રુબેલ્સ હતી. જો કે, તે માત્ર UDP દ્વારા જ કામ કરતું હતું અને TCP પર સ્વિચ કરી શકતું નથી. જો કે, લગભગ 40% વિદ્યાર્થીઓએ તેનો ઉપયોગ કરવાનું સમાપ્ત કર્યું.

એક વર્ષ પછી, અમે કોર્પોરેટ ક્લાયન્ટ્સને તેમની પોતાની ચોક્કસ જરૂરિયાતો સાથે રાખવાનું શરૂ કર્યું. ઉદાહરણ તરીકે, બધું બ્રાઉઝર દ્વારા કામ કરવું જોઈએ, કંપની ફક્ત http અને https ખોલે છે; એટલે કે Skype અથવા 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 કરી, અને સમસ્યાઓ દૂર થઈ ગઈ. હવે અમે નીચી મર્યાદાઓ અને લાક્ષણિકતાઓ સાથે એક સાથે ત્રણ નવા સર્વર ખરીદ્યા છે, અમને લાગે છે કે આનાથી સંચારની ગુણવત્તામાં સ્થિર સુધારો થશે. અલબત્ત, અમે ત્યાં શું ચાલી રહ્યું છે તે શોધવાનો પ્રયાસ કર્યો નથી; અમારી ક્રૉચ બધું જ છે. અમારા બચાવમાં, ચાલો કહીએ કે તે ક્ષણે દબાણયુક્ત સમસ્યાને શક્ય તેટલી ઝડપથી હલ કરવી જરૂરી હતી, અને તેને સુંદર રીતે ન કરવી; આ ઉપરાંત, અમારા માટે જાનુસ એ C માં લખેલું બ્લેક બોક્સ છે, તેની સાથે ટિંકર કરવું ખૂબ ખર્ચાળ છે.

સારું, પ્રક્રિયામાં અમે:

• સર્વર અને ક્લાયંટ બંને પર અપડેટ કરી શકાય તેવી તમામ નિર્ભરતાઓને અપડેટ કરી (આ પણ પ્રયોગો હતા, અમે પરિણામોનું નિરીક્ષણ કર્યું હતું);
• ચોક્કસ કેસોને લગતી તમામ ઓળખાયેલ ભૂલોને ઠીક કરી, ઉદાહરણ તરીકે, જ્યારે કનેક્શન ઘટી ગયું અને આપમેળે પુનઃસ્થાપિત થયું ન હતું;
• અમે વિડિયો કમ્યુનિકેશનના ક્ષેત્રમાં કામ કરતી કંપનીઓ સાથે ઘણી બધી મીટિંગો યોજી અને અમારી સમસ્યાઓથી પરિચિત છીએ: સ્ટ્રીમિંગ ગેમ્સ, વેબિનર્સનું આયોજન; અમે તે બધું અજમાવ્યું જે અમને ઉપયોગી લાગ્યું;
• શિક્ષકોના હાર્ડવેર અને કોમ્યુનિકેશન ગુણવત્તાની તકનીકી સમીક્ષા હાથ ધરી, જેમની પાસેથી સૌથી વધુ ફરિયાદો આવી હતી.

પ્રયોગો અને ત્યારપછીના ફેરફારોને કારણે શિક્ષકો વચ્ચેના સંચાર અંગેના અસંતોષને જાન્યુઆરી 7,1માં 2018%થી ઘટાડીને જાન્યુઆરી 2,5માં 2019% કરવામાં આવ્યો.

આગળ શું છે

અમારા Vimbox પ્લેટફોર્મને સ્થિર કરવું એ 2019 માટે કંપનીના મુખ્ય પ્રોજેક્ટ્સમાંનું એક છે. અમને ઘણી આશા છે કે અમે ગતિ જાળવી રાખી શકીશું અને ટોચની ફરિયાદોમાં હવે વિડિયો સંચાર જોવા મળશે નહીં. અમે સમજીએ છીએ કે આ ફરિયાદોનો નોંધપાત્ર ભાગ વપરાશકર્તાઓના કમ્પ્યુટર્સ અને ઈન્ટરનેટમાં ક્ષતિઓ સાથે સંબંધિત છે, પરંતુ આપણે આ ભાગ નક્કી કરવો જોઈએ અને બાકીનાને ઉકેલવા જોઈએ. બાકીનું બધું તકનીકી સમસ્યા છે, એવું લાગે છે કે આપણે તેનો સામનો કરવા સક્ષમ હોવા જોઈએ.

મુખ્ય મુશ્કેલી એ છે કે ગુણવત્તા સુધારવા માટે ખરેખર કયા સ્તર સુધી શક્ય છે તે આપણે જાણતા નથી. આ ટોચમર્યાદા શોધવાનું મુખ્ય કાર્ય છે. તેથી, બે પ્રયોગોનું આયોજન કરવામાં આવ્યું હતું:

1. લડાયક પરિસ્થિતિઓમાં નિયમિત p2p સાથે જાનુસ દ્વારા વિડિઓની તુલના કરો. આ પ્રયોગ પહેલેથી જ હાથ ધરવામાં આવ્યો છે, અમારા સોલ્યુશન અને p2p વચ્ચે કોઈ આંકડાકીય રીતે નોંધપાત્ર તફાવત જોવા મળ્યો નથી;
2. ચાલો ફક્ત વિડિયો કમ્યુનિકેશન સોલ્યુશન્સ પર પૈસા કમાતી કંપનીઓ પાસેથી (મોંઘી) સેવાઓ સપ્લાય કરીએ, અને તેમની પાસેથી નકારાત્મકતાની રકમની હાલની સાથે સરખામણી કરીએ.

આ બે પ્રયોગો આપણને પ્રાપ્ત કરી શકાય તેવા ધ્યેયને ઓળખવા અને તેના પર ધ્યાન કેન્દ્રિત કરવાની મંજૂરી આપશે.

આ ઉપરાંત, ત્યાં સંખ્યાબંધ કાર્યો છે જે નિયમિત રીતે ઉકેલી શકાય છે:

• અમે વ્યક્તિલક્ષી સમીક્ષાઓને બદલે સંચાર ગુણવત્તાનું ટેકનિકલ મેટ્રિક બનાવીએ છીએ;
• નિષ્ફળતાઓનું વધુ સચોટપણે પૃથ્થકરણ કરવા માટે અમે વધુ વિગતવાર સત્ર લૉગ્સ બનાવીએ છીએ, તે ક્યારે અને ક્યાં આવી હતી તે સમજવા અને તે ક્ષણે કઈ અસંબંધિત ઘટનાઓ બની હતી;
• અમે પાઠ પહેલાં સ્વચાલિત કનેક્શન ગુણવત્તા પરીક્ષણ તૈયાર કરીએ છીએ, અને ક્લાયન્ટને તેના હાર્ડવેર અને ચેનલ દ્વારા થતી નકારાત્મકતાની માત્રા ઘટાડવા માટે કનેક્શનને મેન્યુઅલી પરીક્ષણ કરવાની તક પણ આપીએ છીએ;
• અમે વેરિયેબલ પેકેટ લોસ વગેરે સાથે નબળી સ્થિતિમાં વધુ વિડિયો કોમ્યુનિકેશન લોડ ટેસ્ટ વિકસાવીશું અને ચલાવીશું;
• અમે ખામી સહિષ્ણુતા વધારવા માટે સમસ્યાઓના કિસ્સામાં સર્વરની વર્તણૂક બદલીએ છીએ;
• અમે વપરાશકર્તાને ચેતવણી આપીશું કે જો તેના કનેક્શનમાં કંઇક ખોટું હશે તો, Skypeની જેમ, જેથી તે સમજી શકે કે સમસ્યા તેની બાજુમાં છે.

એપ્રિલથી, વિડિયો કમ્યુનિકેશન ડિરેક્શન સ્કાયેંગની અંદર એક સંપૂર્ણ સુવિધાયુક્ત અલગ પ્રોજેક્ટ બની ગયું છે, જે તેના પોતાના ઉત્પાદન સાથે કામ કરે છે, માત્ર Vimboxનો એક ભાગ નથી. આનો અર્થ એ છે કે અમે લોકોને શોધવાનું શરૂ કરી રહ્યા છીએ પૂર્ણ સમય મોડમાં વિડિઓ સાથે કામ કરવું. સારું, હંમેશની જેમ અમે ઘણા સારા લોકોની શોધમાં છીએ.

અને, અલબત્ત, અમે વિડિઓ સંચાર સાથે કામ કરતા લોકો અને કંપનીઓ સાથે સક્રિયપણે વાતચીત કરવાનું ચાલુ રાખીએ છીએ. જો તમે અમારી સાથે અનુભવની આપ-લે કરવા માંગો છો, તો અમને આનંદ થશે! ટિપ્પણી કરો, સંપર્કમાં રહો - અમે દરેકને જવાબ આપીશું.

સોર્સ: www.habr.com