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 کی ہارڈویئر انکوڈنگ، کیمرہ، مائیکروفون اور ڈیوائس اسپیکرز کے سپورٹ کے ساتھ مستحکم SDKs ہیں۔

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 traversal: ICE، STUN اور TURN

WebRTC کا بنیادی تکنیکی چیلنج NAT (Network Address Translation) کے پیچھے موجود آلات کے درمیان P2P کنکشن قائم کرنا ہے۔ خصوصی میکانزم کے بغیر، آلات ایک دوسرے تک براہ راست نہیں پہنچ سکتے کیونکہ ان کے مقامی 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۔ یہ SDKs سگنلنگ، روم مینجمنٹ کو آسان بناتے ہیں اور شرکاء کا ویڈیو گرڈ دکھانے کے لیے تیار 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 کے وکندریقرت فن تعمیر کا اہم فائدہ ہے۔