WebRTC: यह क्या है, आर्किटेक्चर और कार्य सिद्धांत

WebRTC क्या है

WebRTC (Web Real-Time Communication) एक ओपन सोर्स प्रोजेक्ट है जिसे Google ने 2011 में शुरू किया और W3C (JavaScript API) और IETF (प्रोटोकॉल) द्वारा मानकीकृत किया गया। इसका मुख्य उद्देश्य प्लगइन या तृतीय-पक्ष सॉफ़्टवेयर स्थापित किए बिना ब्राउज़रों और एप्लिकेशन के बीच कम विलंबता संचार प्रदान करना है।

पारंपरिक समाधानों (RTMP, HLS) के विपरीत जहां वीडियो सर्वर से होकर गुज़रता है, WebRTC पीयर-टू-पीयर आर्किटेक्चर का उपयोग करता है: डेटा सीधे प्रतिभागियों के बीच ट्रांसमिट होता है। यह HLS के 3-10 सेकंड की तुलना में 200-500 ms विलंबता प्रदान करता है — वॉइस और वीडियो कॉल, गेम स्ट्रीमिंग और रिमोट सर्जरी के लिए एक महत्वपूर्ण अंतर।

Google WebRTC टीम (2025) के अनुसार, इस तकनीक का उपयोग 5 बिलियन से अधिक इंस्टॉलेशन वाले एप्लिकेशन में किया जाता है: Google Meet, WhatsApp, Discord, Telegram, Zoom (आंशिक रूप से)। telehealth और edtech क्षेत्र के 85% से अधिक वेंचर स्टार्टअप WebRTC को अपने बेस रियल-टाइम ट्रांसपोर्ट के रूप में चुनते हैं।

मोबाइल डेवलपमेंट को 2013 में libjingle_peerconnection के रिलीज़ के साथ पूर्ण WebRTC समर्थन मिला — Android और iOS के लिए एक नेटिव इम्प्लीमेंटेशन। आज दोनों प्लेटफ़ॉर्म के पास H.264 और VP8 के हार्डवेयर एन्कोडिंग, कैमरा, माइक्रोफ़ोन और डिवाइस स्पीकर के समर्थन के साथ स्थिर SDK हैं।

WebRTC आर्किटेक्चर और प्रोटोकॉल

WebRTC आर्किटेक्चर तीन परतों से बना है। शीर्ष परत JavaScript API (या मोबाइल प्लेटफ़ॉर्म के लिए नेटिव API), मध्य परत ट्रांसपोर्ट प्रोटोकॉल, निचली परत कोडेक और सुरक्षा है। प्रत्येक परत अपना कार्य हल करती है, लेकिन कनेक्शन स्थापना के लिए सभी आवश्यक हैं।

मुख्य WebRTC API

MediaStream (getUserMedia) — डिवाइस के माइक्रोफ़ोन और कैमरे से ऑडियो और वीडियो कैप्चर करता है। RTCPeerConnection — P2P कनेक्शन प्रबंधित करता है: एन्कोडिंग, ट्रांसपोर्ट, बिटरेट अनुकूलन। RTCDataChannel — उसी चैनल पर मनमाना डेटा (टेक्स्ट, फ़ाइलें, बाइनरी संदेश) ट्रांसमिट करता है।

// WebRTC JavaScript API (ब्राउज़र उदाहरण)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

रियल-टाइम प्रोटोकॉल

WebRTC ऑडियो और वीडियो के लिए SRTP (Secure Real-Time Transport Protocol) का उपयोग करता है — AES-128 एन्क्रिप्शन के साथ RTP का एक सुरक्षित संस्करण। सत्र प्रबंधन DTLS के ऊपर SCTP (Stream Control Transmission Protocol) के माध्यम से होता है। प्रत्येक डेटा स्ट्रीम अनिवार्य रूप से एन्क्रिप्ट की जाती है: WebRTC में कोई असुरक्षित मोड नहीं है।

• SRTP/SRTCP — रिप्ले अटैक सुरक्षा के साथ मीडिया स्ट्रीम का एन्क्रिप्टेड ट्रांसमिशन
• DTLS-SRTP — UDP पर Datagram TLS के माध्यम से एन्क्रिप्शन कुंजी स्थापना
• SCTP — DataChannel के लिए विश्वसनीय या आंशिक रूप से विश्वसनीय डेटा डिलीवरी
• ICE (Interactive Connectivity Establishment) — पीयर्स के बीच नेटवर्क पथ खोजने के लिए फ्रेमवर्क
• Trickle ICE — ICE का वृद्धिशील संस्करण जहां उम्मीदवार खोजे जाने पर भेजे जाते हैं, कनेक्शन स्थापना को गति देता है

NAT ट्रैवर्सल: ICE, STUN और TURN

WebRTC की मुख्य तकनीकी चुनौती उन उपकरणों के बीच P2P कनेक्शन स्थापित करना है जो NAT (Network Address Translation) के पीछे हैं। विशेष तंत्र के बिना, उपकरण सीधे एक-दूसरे तक नहीं पहुंच सकते क्योंकि उनके स्थानीय IP पते इंटरनेट से दिखाई नहीं देते।

STUN — सार्वजनिक पता निर्धारण

STUN (Session Traversal Utilities for NAT) — एक सर्वर जो इस प्रश्न का उत्तर देता है “मेरा सार्वजनिक IP और पोर्ट क्या है?”। क्लाइंट STUN सर्वर को एक अनुरोध भेजता है, सर्वर उसका सार्वजनिक पता देखता है और क्लाइंट को वापस भेजता है। Google सार्वजनिक रूप से STUN सर्वर stun:stun.l.google.com:19302 का रखरखाव करता है।

// iOS पर WebRTC — ICE सर्वर कॉन्फ़िगरेशन
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — रिले कनेक्शन

TURN (Traversal Using Relays around NAT) — उन मामलों के लिए एक रिले सर्वर जब STUN मदद नहीं करता (सममित NAT या कॉर्पोरेट फ़ायरवॉल)। इस मोड में सभी डेटा TURN सर्वर से होकर गुज़रता है — इससे गति कम होती है और विलंबता बढ़ती है, लेकिन 99% मामलों में कनेक्शन की गारंटी देता है।

TURN WebRTC बुनियादी ढांचे का सबसे महंगा घटक है, क्योंकि सर्वर सभी मीडिया ट्रैफ़िक को अपने माध्यम से पास करता है। Coturn Project (2025) के अनुसार, 8 vCPU और 16 GB RAM वाला एक विशिष्ट TURN सर्वर लगभग 200 समवर्ती ऑडियो कॉल या 40 HD वीडियो कॉल को संभालता है।

ICE प्रक्रिया

ICE सभी संभावित उम्मीदवारों (स्थानीय IP, STUN के माध्यम से सार्वजनिक IP, TURN के माध्यम से रिले) को इकट्ठा करता है और प्राथमिकता क्रम में कनेक्शन स्थापित करने का प्रयास करता है। जैसे ही उम्मीदवारों की कम से कम एक जोड़ी (स्थानीय-दूरस्थ) कनेक्टिविटी जांच पास करती है, कनेक्शन स्थापित माना जाता है।

• Host candidates — सबनेट में डिवाइस का स्थानीय IP पता (सबसे तेज़, लेकिन NAT के पीछे काम नहीं करता)
• Server Reflexive candidates — STUN सर्वर के माध्यम से प्राप्त सार्वजनिक IP
• Relay candidates — TURN सर्वर पता जिसके माध्यम से रिले होता है (सबसे धीमा, सबसे विश्वसनीय)

मोबाइल ऐप्स में WebRTC

मोबाइल डेवलपमेंट के लिए, Google libWebRTC बनाए रखता है — Android (AAR) और iOS (XCFramework) के लिए एक नेटिव लाइब्रेरी। लाइब्रेरी में पूरा प्रोटोकॉल स्टैक, कोडेक (VP8, VP9, H.264, AV1) और एन्कोडिंग/डिकोडिंग के लिए हार्डवेयर त्वरण शामिल है।

Android पर WebRTC

Android SDK PeerConnectionFactory, PeerConnection, MediaStream क्लास प्रदान करता है। ऐप एक फ़ैक्टरी बनाता है, वीडियो कोडेक कॉन्फ़िगर करता है, VideoCapturer के माध्यम से कैमरा स्ट्रीम कैप्चर करता है और SDP offer/answer के माध्यम से पीयर कनेक्शन स्थापित करता है।

// Android WebRTC — प्रारंभिकरण
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

iOS पर WebRTC

iOS SDK RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack रैपर के साथ Objective-C API का उपयोग करता है। हार्डवेयर H.264 एन्कोडिंग VideoToolbox के माध्यम से उपलब्ध है। वीडियो प्रदर्शन के लिए RTCMTLVideoView (Metal) या RTCVideoRenderer का उपयोग किया जाता है।

// iOS WebRTC — कैमरे से वीडियो कैप्चर
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// कैमरा चयन (सामने/पीछे)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// अधिकतम FPS के साथ कैप्चर प्रारंभ करें
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

प्रोडक्शन वीडियो कॉल के लिए, मोबाइल ऐप्स आमतौर पर libWebRTC के ऊपर SDK रैपर का उपयोग करते हैं: Twilio Video, Agora, Daily.co। ये SDK सिग्नलिंग, रूम प्रबंधन को सरल बनाते हैं और प्रतिभागियों की वीडियो ग्रिड प्रदर्शित करने के लिए तैयार UI घटक प्रदान करते हैं।

सिग्नलिंग और कनेक्शन स्थापना

WebRTC सिग्नलिंग प्रोटोकॉल निर्दिष्ट नहीं करता — पीयर्स के बीच SDP (Session Description Protocol) संदेशों का आदान-प्रदान। डेवलपर सिग्नलिंग के लिए ट्रांसपोर्ट चुनता है: WebSocket, MQTT, SIP, XMPP या REST API। सिग्नलिंग एक पीयर से दूसरे तक offer, answer और ICE उम्मीदवार पहुंचाती है।

SDP Offer/Answer आदान-प्रदान

प्रक्रिया offer बनाने से शुरू होती है (आरंभकर्ता अपनी मीडिया क्षमताओं का वर्णन करता है), सिग्नलिंग के माध्यम से दूसरे पीयर को प्रेषित किया जाता है, जो answer के साथ जवाब देता है। SDP आदान-प्रदान के बाद प्रत्येक पीयर ICE शुरू करता है और स्ट्रीम एन्क्रिप्शन के लिए DTLS-SRTP लॉन्च करता है।

// Android — offer बनाना और भेजना
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // सिग्नलिंग सर्वर को sdp.description भेजें
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

सिग्नलिंग प्रोटोकॉल

मोबाइल ऐप्स के लिए, सबसे लोकप्रिय सिग्नलिंग WebSocket के माध्यम से है — TCP पर एक द्विदिश चैनल जो सर्वर के साथ स्थायी कनेक्शन बनाए रखता है। सिग्नलिंग सर्वर अक्सर एक अलग माइक्रोसर्विस (Node.js, Golang, Elixir) होता है जो रूम प्रतिभागियों के बीच संदेशों को रूट करता है।

• WebSocket — स्थायी द्विदिश कनेक्शन, न्यूनतम ओवरहेड, सिग्नलिंग के लिए मानक विकल्प
• WebSocket पर SIP — मानक VoIP प्रोटोकॉल, मौजूदा टेलीफोनी बुनियादी ढांचे के साथ एकीकृत होता है
• MQTT — IoT और कमजोर नेटवर्क के लिए हल्का pub/sub प्रोटोकॉल, लेकिन अधिक विलंबता के साथ
• Matrix / XMPP — गोपनीयता-केंद्रित एप्लिकेशन के लिए विकेंद्रीकृत प्रोटोकॉल

ICE और DTLS-SRTP पूरा होने के बाद, सिग्नलिंग डेटा ट्रांसमिशन में भाग नहीं लेती — सभी मीडिया ट्रैफ़िक सीधे P2P (या TURN रिले के माध्यम से) प्रवाहित होता है। सिग्नलिंग सर्वर को सक्रिय कॉल को बाधित किए बिना बंद किया जा सकता है। यह WebRTC के विकेंद्रीकृत आर्किटेक्चर का मुख्य लाभ है।