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-এর প্রধান প্রযুক্তিগত চ্যালেঞ্জ হল 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। এই 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-র বিকেন্দ্রীভূত আর্কিটেকচার-এর মূল সুবিধা।