ब्राउज़र और डेस्क फ़ोन मीडिया को अलग-अलग तरीके से संभालते हैं, फिर भी वे एक ही कॉल के दो छोर हो सकते हैं।
इनमें से एक चुनने का मतलब है कि जो सुविधाएँ जानबूझकर एक परत को सौंपी गई हैं, उन्हें दूसरी परत का हिस्सा मान लेना।
क्या ये एक-दूसरे के विकल्प हैं?
नहीं। ये अलग-अलग परतों पर काम करते हैं, और दोनों में से कोई भी दूसरे का काम नहीं करता।
SIP सिग्नलिंग है। यह दूसरे छोर को ढूँढता है, तय करता है कि कौन-सा मीडिया आदान-प्रदान होगा, घंटी बजाता है, कॉल जोड़ता है और समाप्त करता है। यह ऑडियो नहीं ले जाता। RFC 3261 यह सीमा तय करता है: "SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture."
WebRTC ब्राउज़र का मीडिया स्टैक है। यह दो एंडपॉइंट के बीच ऑडियो और वीडियो ले जाता है। यह नेटवर्क एड्रेस ट्रांसलेशन को पार करता है, जिसकी वजह से ब्राउज़र से ब्राउज़र तक सीधा रास्ता बनाना कठिन होता है। यह मीडिया को एन्क्रिप्ट भी करता है। इसका अपना विनिर्देश, RFC 8825, जनवरी 2021 का एक IETF Standards Track दस्तावेज़ है, और यह बताता है कि मीडिया का प्रारूप RTP है। यह SRTP को अनिवार्य करता है: "Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations"।
SIP मीडिया ले जाए बिना कॉल की व्यवस्था करता है। WebRTC कॉल की व्यवस्था किए बिना मीडिया ले जाता है।
WebRTC किस चीज़ को शामिल नहीं करता, और क्यों?
WebRTC सिग्नलिंग को शामिल नहीं करता, और ऐसा जानबूझकर करता है: विनिर्देश सिग्नलिंग प्रोटोकॉल के चुनाव को अपने दायरे से बाहर रखता है।
RFC 8825 इस व्यवस्था को एक ट्रेपेज़ॉइड के रूप में बताता है। मीडिया सीधे दोनों ब्राउज़रों के बीच जाता है। सिग्नलिंग सर्वरों से होकर जाती है, जो "can modify, translate, or manipulate the signals as needed"। विनिर्देश कोई सिग्नलिंग प्रोटोकॉल तय नहीं करता:
The choice of protocols for client-server and inter-server signaling, and the definition of the translation between them, are outside the scope of the WebRTC protocol suite described in this document.
यह कोई कमी नहीं है जिसे ठीक किया जाना बाकी हो। इसी वजह से एक चैट एप्लिकेशन अपने WebSocket संदेशों से सिग्नलिंग कर सकता है, जबकि एक टेलीफ़ोनी प्लेटफ़ॉर्म SIP से सिग्नलिंग करता है, और दोनों के नीचे एक ही मीडिया स्टैक होता है। यही दस्तावेज़ टेलीफ़ोनी विकल्प का सीधे नाम लेता है और एक ऐसी व्यवस्था का वर्णन करता है जिसमें ब्राउज़र और सर्वर के बीच "a standardized signaling mechanism (e.g., SIP over WebSockets)" का उपयोग होता है।
WebSocket पर SIP को जनवरी 2014 के RFC 7118 में निर्दिष्ट किया गया है, जो "a WebSocket subprotocol as a reliable transport mechanism between SIP entities to enable use of SIP in web-oriented deployments" को परिभाषित करता है। यह बदलता है कि SIP संदेश कैसे पहुँचते हैं, यह नहीं कि उनमें क्या लिखा है। इसी वजह से एक ब्राउज़र और एक डेस्क फ़ोन एक सामान्य कॉल के दो छोर बन सकते हैं।
Bird पर यह कैसा दिखता है?
Bird के माध्यम से ब्राउज़र को जोड़ने के लिए WebSocket पर SIP का उपयोग करें।
डैशबोर्ड का अपना फ़ोन इसका व्यावहारिक उदाहरण है। ब्राउज़र SIP क्लाइंट की भूमिका निभाता है। डैशबोर्ड किसी पेज में लंबे समय तक चलने वाला सीक्रेट भेजने के बजाय उसके लिए कम अवधि वाला सेशन क्रेडेंशियल बनाता है। API क्रेडेंशियल के handshake_token को "Short-lived token required when upgrading the WebSocket connection" के रूप में बताता है। यह "केवल कनेक्शन को अधिकृत करता है; हर कॉल फिर भी password से प्रमाणित होती है"। हैंडशेक टोकन कनेक्शन को अधिकृत करता है, जबकि पासवर्ड हर कॉल को प्रमाणित करता है।
ब्राउज़र के साथ संगतता ट्रंक के digest एल्गोरिदम पर निर्भर करती है। ब्राउज़र SIP digest चुनौती का जवाब केवल MD5 से देते हैं। ट्रंक केवल वही एल्गोरिदम स्वीकार करता है जो वह ऑफ़र करता है। इसलिए जो ट्रंक केवल SHA-256 ऑफ़र करने के लिए कॉन्फ़िगर है, वह डैशबोर्ड के फ़ोन सहित हर ब्राउज़र कॉल को अस्वीकार कर देता है। ऑफ़र में MD5 बनाए रखने से ही ट्रंक पर ब्राउज़र से कॉल की जा सकती है, और SIP ट्रंक में यह सेटिंग बताई गई है।
इसके अलावा कॉल उसी ट्रंक पर पहुँचती है, उसी सत्यापित कॉलर ID की जाँच करती है, उन्हीं सक्षम गंतव्यों का पालन करती है और वैसा ही रिकॉर्ड बनाती है जैसा PBX से आई कॉल बनाती है। PBX वह व्यावसायिक फ़ोन सिस्टम है जो किसी कंपनी की कॉल रूट करता है।
तो मैं किसका उपयोग करूँ?
अपना एंडपॉइंट कहाँ चलता है, उसके आधार पर चुनें, और दोनों ही स्थितियों में SIP का उपयोग होगा।
WebRTC के लिए मीडिया का एन्क्रिप्टेड होना ज़रूरी है। SIP ट्रंक का TLS ट्रांसपोर्ट ऑडियो के बजाय ट्रांज़िट में सिग्नलिंग को एन्क्रिप्ट करता है। इसलिए एन्क्रिप्शन की समीक्षा में दोनों रास्तों को शामिल करना ज़रूरी है।
- ब्राउज़र। वेब पेज मीडिया के लिए ब्राउज़र के WebRTC स्टैक का उपयोग करता है, इसलिए वह हिस्सा तय है। सिग्नलिंग कैसे हो, यह आप चुनते हैं। SIP इसे केवल दूसरे ब्राउज़रों से नहीं, बल्कि टेलीफ़ोन नेटवर्क से जोड़ता है।
- डेस्क फ़ोन, PBX या सेशन बॉर्डर कंट्रोलर (SBC), जो नेटवर्क की सीमा पर कॉल नियंत्रित करता है। UDP, TCP या TLS पर सामान्य SIP। जो उपकरण पहले से RTP का उपयोग करते हैं, उन्हें WebRTC से कुछ नहीं मिलता।
- वॉइस AI एजेंट। जिसे आपका रनटाइम पहले से लागू करता है। ब्राउज़र में या ब्राउज़र मीडिया API पर बने रनटाइम में चलने वाला एजेंट WebRTC का उपयोग करेगा और उसे सिग्नलिंग जोड़नी होगी। टेलीफ़ोनी स्टैक पर बना एजेंट सीधे SIP और RTP का उपयोग करता है। वॉइस AI एजेंट क्या है में इस रास्ते का बाकी हिस्सा बताया गया है, जिसमें वह हिस्सा भी शामिल है जहाँ एजेंट को केवल सिग्नलिंग ही नहीं, ऑडियो को भी टर्मिनेट करना होता है।
संक्षेप में
यह सवाल दो अलग-अलग परतों की तुलना करता है।
WebRTC ब्राउज़र के लिए एक मीडिया स्टैक है, जिसमें कोई सिग्नलिंग प्रोटोकॉल नहीं है। SIP एक सिग्नलिंग प्रोटोकॉल है, जो मीडिया नहीं ले जाता। कोई भी दूसरे की जगह नहीं ले सकता।
WebRTC सिग्नलिंग को जानबूझकर छोड़ता है।
इसका अपना ओवरव्यू सिग्नलिंग प्रोटोकॉल के चुनाव को स्पेसिफ़िकेशन के दायरे से बाहर रखता है, और इस कमी को भरने के एक मानक तरीके के रूप में WebSockets पर SIP का नाम लेता है।
Bird पर ब्राउज़र कॉल एक SIP कॉल होती है।
ब्राउज़र SIP क्लाइंट की तरह काम करता है, कनेक्शन को कम समय तक मान्य टोकन के साथ WebSocket में अपग्रेड किया जाता है, और हर कॉल फिर भी digest पासवर्ड से प्रमाणित होती है।
दोनों में एन्क्रिप्शन अलग-अलग जगह होता है।
WebRTC मीडिया के लिए SRTP अनिवार्य करता है। SIP ट्रंक का TLS ट्रांसपोर्ट सिग्नलिंग को एन्क्रिप्ट करता है, जो ऑडियो से अलग चीज़ है।