आप में से कई लोगों ने रियलटाइम वेब संचार, उर्फ वेबआरटीसी के लिए नए मानक के बारे में सुना है। हम वेबसाइटों और मोबाइल एप्लिकेशन के उपयोगकर्ताओं के साथ
ध्वनि संचार (क्लिक-टू-कॉल / टैप-टू-कॉल) के
लिए सेवाएं विकसित कर रहे हैं। और यही कारण है कि ब्राउज़र से सीधे वॉयस और वीडियो कॉल का विचार अतिरिक्त प्लग-इन स्थापित किए बिना हमारे बहुत करीब है। सामान्य तौर पर, कोई भी अतिरिक्त सॉफ्टवेयर। हमारी कंपनी Google, मोज़िला, सिस्को, एरिक्सन, स्काइप और कई अन्य लोगों के साथ इस मानक को विकसित करने के लिए W3C कामकाजी समूह का हिस्सा है (हाँ, हमने एक महान कंपनी में समाप्त किया)। Cullen Jennings (Cisco), जस्टिन Uberti (Google), Daniel Burnett (Voxeo), Cary FitzGerald जैसे गंभीर पेशेवरों की एक टीम मानक पर काम कर रही है। उनमें से कई ने आईपी-टेलीफोनी के निर्माण में भाग लिया, जैसा कि हम पिछले 10-15 वर्षों में जानते हैं।
Google ने GIPS के अधिग्रहण के बाद पूरे WebRTC आंदोलन की शुरुआत की, और वे अपने ब्राउज़र में मानक के नवीनतम ड्राफ्ट संस्करण के लिए समर्थन जोड़ने वाले थे। WebRTC पहले से ही Google Chrome 23 में शानदार काम करता है। लेकिन हां, आपकी ऑनलाइन सेवा के WebRTC संस्करण के लिए "टेक ऑफ" करने के लिए, आपको समय बिताने और यह पता लगाने की आवश्यकता है कि अब सब कुछ कैसे काम करता है। और आपकी वेबआरटीसी सेवा के लिए काम करना जारी रखने के लिए, आपको यह भी निगरानी करने की आवश्यकता है कि कार्य समूह में क्या हो रहा है और मानक में सभी परिवर्तन हो रहे हैं, जो उतना तुच्छ नहीं है जितना लगता है।
थोड़ा इतिहास। WebRTC के लिए कम से कम कुछ समर्थन को लागू करने वाला पहला ब्राउज़र एरिक्सन का एक प्रयोगात्मक ब्राउज़र था। हम कार्रवाई में WebRTC की कोशिश करने के लिए उत्सुक थे, और हमने इस तरह से समर्थन को "देखा" कि हमारे सर्वर इस ब्राउज़र के साथ काम करेंगे। जैसा कि बाद में पता चला, यह एक बेवकूफी भरा उपक्रम था। जैसे ही Google ने सक्रिय रूप से इस मामले को उठाया, सभी एरिक्सन की उपलब्धियों को नरक में भेज दिया गया, और मानक में निरंतर परिवर्तन, साथ ही साथ क्रोम कैनरी के विकास विधानसभा में इसी कार्यान्वयन को शुरू किया।
काफी अजीब क्षण भी थे जब ब्राउज़र डेवलपर्स ने कुछ अजीब RFC वेरिएंट का उपयोग किया (या उन्हें बिल्कुल भी उपयोग नहीं किया) और यह पता चला कि STUN या ICE को फिर से लिखना होगा ताकि यह कम से कम किसी तरह काम करे। नतीजतन, सामान्य ज्ञान की जीत हुई, और सभी ने आरएफसी किया, लेकिन काफी समय एक तंबू के साथ नाचते हुए बिताया गया और यह बताते हुए कि ऐसा करना अच्छा नहीं है।
कई बिंदु हैं जो अब WebRTC के साथ काम करते समय कठिनाइयों का कारण बनते हैं:
- मानक पर काम पूरे जोरों पर है, और एक निश्चित तैयार संस्करण अभी भी दूर है। सब कुछ बदल जाता है - उदाहरण के लिए, ब्राउज़रों के नए संस्करण जारी किए जाते हैं जिनके लिए संपूर्ण कार्यान्वयन की दोहरी जांच और अक्सर प्रसंस्करण की आवश्यकता होती है। यह एक तथ्य नहीं है कि पिछड़ी संगतता है। अक्सर वह चला जाता है।
- मानक प्रोटोकॉल (जैसे एसडीपी) को लागू करना अभी भी आदर्श से दूर है। कहते हैं, अब PeerConnection केवल एक पोर्ट पर वीडियो और ऑडियो भेज सकता है, भले ही विपरीत किसी अन्य प्रतिभागी के एसडीपी में इंगित किया गया हो। सच है, निष्पक्षता में यह ध्यान देने योग्य है कि स्थिति धीरे-धीरे सुधार रही है। उदाहरण के लिए, क्रोम के हाल के संस्करणों में ICE RFC के अनुसार काम करता है।
- मीडिया नियंत्रण XML विधियों को लागू करने में असमर्थता द्वारा SIP के साथ एकीकरण में कठिनाई को जोड़ा जाता है। इसलिए, जब पैकेट गेटवे से एसआईपी उपकरण तक खो जाते हैं, तो छवि पुनर्प्राप्ति के साथ समस्याएं होंगी। Google के सहकर्मियों ने कहा कि उन्होंने इसे RTP प्रोटोकॉल के स्तर पर लागू किया है, इसलिए इस मुद्दे से अभी भी निपटने की आवश्यकता है।
- आम वीडियो कोडेक्स के लिए कोई समर्थन नहीं है (पढ़ें - H.264)। बेशक, कुछ सॉफ्टफ़ोन में पहले से ही VP8 कार्यान्वयन है, लेकिन कोई भी औद्योगिक समाधान इस कोडेक का समर्थन नहीं करता है। इस मुद्दे के साथ अभी भी कोई स्पष्टता नहीं है, H.264 समर्थन का समर्थन करने वाली कई कंपनियां हैं, लेकिन चूंकि कोडेक MPEG-LA द्वारा पेटेंट किया गया है, और इसमें केवल रॉयल्टी मुक्त कोडेक्स का उपयोग करने की योजना है, अब तक केवल VP8 उपलब्ध है।
यूएक्स / यूआई के दृष्टिकोण से, वेबआरटीसी फ्लैश (स्क्रीनशॉट देखें) की तुलना में स्पष्ट रूप से बेहतर है, लेकिन ऐसी कई कमियां हैं जो हमें उम्मीद है कि भविष्य में तय हो जाएंगी। उदाहरण के लिए, यदि आप रिकॉर्डिंग डिवाइस के चयन को सहेजते हैं (केवल HTTPS का उपयोग करते समय उपलब्ध है), तो इस सेटिंग को रीसेट करने के लिए आपको सेटिंग्स -> उन्नत सेटिंग्स ... -> गोपनीयता -> सामग्री सेटिंग्स ... -> मीडिया -> अपवादों पर जाने की आवश्यकता है ... एक नियमित उपयोगकर्ता वहाँ कभी नहीं मिलेगा?
यह (फ्लैश) था
अब (वेबआरटीसी)
मुझे कहना होगा कि वेबआरटीसी का उपयोग करते समय ध्वनि की गुणवत्ता फ्लैश की तुलना में वास्तव में बेहतर है। उदाहरण के लिए, WebRTC में माइक्रोफ़ोन के लिए एक पूर्ण-स्वचालित स्वचालित नियंत्रण (AGC, स्वचालित लाभ नियंत्रण) है, और कुछ स्पष्ट रूप से धार्मिक कारणों से एडोब ने इस तरह की उपयोगी सुविधा को शामिल करना शुरू नहीं किया है। खैर, बाकी GIPS ऑडियो इंजन बहुत अच्छा काम करता है। वेबआरटीसी में निकट भविष्य में ओपस ऑडियो कोडेक का उपयोग करना संभव होगा, जो स्काइप एसआईएलके और सीईएलटी का हाइब्रिड है और इसे पहले ही जीआर 11 के साथ वेबआरटीसी के लिए अनिवार्य माना गया है। Google Android के लिए Chrome के मोबाइल संस्करण के लिए WebRTC का समर्थन करने के लिए पहले से ही कड़ी मेहनत कर रहा है, जिसका अर्थ है कि मोबाइल प्लेटफ़ॉर्म के लिए एक गंभीर भविष्य है (एडोब ने मोबाइल के लिए फ्लैश को बढ़ावा देने और विकसित करने के प्रयासों को छोड़ दिया)।
और अंत में: WebRTC कॉन्फ एंड एक्सपो में यह घोषणा की गई कि फ़ायरफ़ॉक्स 18 के रिलीज़ संस्करण में WebRTC समर्थन को जोड़ा जाएगा, और यह अद्भुत घटना लगभग अप्रैल 2013 में होगी। हम ओपेरा, IE और सफारी की प्रतीक्षा कर रहे हैं। वैसे, हम सम्मेलन में प्रत्यक्ष प्रतिभागी थे और यहां तक कि पुरस्कार जीतने में भी कामयाब रहे, हम इस बारे में एक अलग पोस्ट लिखने का प्रयास करेंगे।