ICE Candidate: এটি কি, প্রার্থীদের ধরন এবং কিভাবে কাজ করে

ICE Candidate কী?

ICE Candidate (Interactive Connectivity Establishment Candidate) WebRTC প্রোটোকলের মাধ্যমে P2P সংযোগ স্থাপনের প্রক্রিয়ায় একটি মৌলিক একক। এটি একটি IP ঠিকানা + পোর্ট জোড়া উপস্থাপন করে যা দুই পিয়ারের মধ্যে ডেটা প্রেরণের জন্য ব্যবহার করা যেতে পারে। প্রতিটি প্রার্থীতে পরিবহন প্রোটোকল (UDP, TCP), সংযোগের ধরন এবং অগ্রাধিকার সম্পর্কে তথ্য থাকে।

ICE Candidate প্রতিটি ডিভাইসে আলাদাভাবে গঠিত হয়। ডিভাইসটি সমস্ত উপলব্ধ নেটওয়ার্ক ইন্টারফেস সংগ্রহ করে, একটি STUN সার্ভার এর মাধ্যমে বাহ্যিক ঠিকানা অনুরোধ করে এবং TURN সার্ভার থেকে একটি রিলে ঠিকানা যোগ করে। প্রার্থীদের ফলস্বরূপ তালিকা SDP (Session Description Protocol) বিন্যাসে সিগন্যালিং চ্যানেলের মাধ্যমে দূরবর্তী পিয়ারে পাঠানো হয়।

RFC 8445 (IETF, 2018) স্পেসিফিকেশন অনুযায়ী, ICE নমিনেটেড পেয়ার্স মেকানিজম ব্যবহার করে: সমস্ত প্রার্থী সংগ্রহের পরে, STUN অনুরোধের মাধ্যমে তাদের জোড়াভিত্তিক পরীক্ষা করা হয়। যে জোড়া প্রথমে পরীক্ষা পাস করে তাকে নমিনেটেড ঘোষণা করা হয় এবং মাল্টিমিডিয়া ট্রান্সমিশনের জন্য ব্যবহার করা হয়। বাকি জোড়াগুলো সংযোগ বিচ্ছিন্ন হওয়ার ক্ষেত্রে রিজার্ভে থাকে।

WebRTC স্ট্যাকে ICE এর ভূমিকা

WebRTC P2P যোগাযোগের জন্য একটি উন্মুক্ত মান, কিন্তু NAT (Network Address Translation) এবং ফায়ারওয়ালের কারণে ডিভাইসগুলির মধ্যে সরাসরি সংযোগ প্রায়ই সম্ভব হয় না। ICE Candidate একাধিক বিকল্প সংযোগ পথ প্রদান করে এই সমস্যার সমাধান করে। ICE (Interactive Connectivity Establishment) প্রোটোকল WebRTC এর একটি বাধ্যতামূলক উপাদান এবং W3C WebRTC স্পেসিফিকেশন (2025) এ বর্ণিত।

অনেক মোবাইল অ্যাপ্লিকেশন ডেভেলপার WebRTC লাইব্রেরি যেমন Google WebRTC (Android এর জন্য) এবং iOS এর জন্য নেটিভ র্যাপার ব্যবহার করেন। এগুলির প্রতিটিতে, ICE প্রক্রিয়া স্বয়ংক্রিয়ভাবে পরিচালিত হয়, কিন্তু প্রার্থীর ধরন বোঝা ডেভেলপারকে সার্ভার অবকাঠামো কনফিগার করতে এবং সংযোগের গুণমান অপ্টিমাইজ করতে দেয়।

ICE প্রার্থীদের সাথে SDP বিন্যাস

ICE Candidate SDP বার্তার ভিতরে a=candidate বৈশিষ্ট্য হিসাবে প্রেরিত হয়। প্রতিটি লাইনে foundation, component ID, পরিবহন প্রোটোকল, অগ্রাধিকার, IP ঠিকানা, পোর্ট এবং প্রার্থীর ধরন থাকে। নিচে বিভিন্ন ধরনের তিনটি প্রার্থীর সাথে SDP খণ্ডের একটি উদাহরণ দেওয়া হল:

// Sample SDP with ICE candidates
a=candidate:1 1 UDP 2130706431 192.168.1.10 54321 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 54322 typ srflx
a=candidate:3 1 TCP 1019212287 198.51.100.7 54323 typ relay raddr 203.0.113.5 rport 3478

priority ফিল্ড প্রার্থীদের পরীক্ষার ক্রম নির্ধারণ করে। অগ্রাধিকার যত বেশি, প্রার্থী তত তাড়াতাড়ি পরীক্ষা করা হবে। Host প্রার্থীদের সর্বদা সর্বোচ্চ অগ্রাধিকার থাকে, relay প্রার্থীদের সর্বনিম্ন।

ICE প্রার্থীদের প্রকার

RFC 8445 স্পেসিফিকেশন ICE প্রার্থীদের চার ধরন সংজ্ঞায়িত করে, প্রতিটি দূরবর্তী পিয়ারে পৌঁছানোর একটি নির্দিষ্ট উপায়ের সাথে মিলে যায়। প্রার্থীর ধরন তার অগ্রাধিকার, সংযোগ স্থাপনের সময় এবং সার্ভার অবকাঠামোর প্রয়োজনীয়তাকে প্রভাবিত করে।

Host প্রার্থী

Host প্রার্থী ডিভাইসের স্থানীয় নেটওয়ার্ক ইন্টারফেসের IP ঠিকানা থেকে গঠিত হয়। যদি ডিভাইসটি কোনো পিয়ারের সাথে একই স্থানীয় নেটওয়ার্কে থাকে, তাহলে host প্রার্থী ন্যূনতম বিলম্বের সাথে সরাসরি সংযোগ প্রদান করে। মোবাইল ডিভাইসের জন্য, host প্রার্থী WiFi ইন্টারফেস, সেলুলার LTE/5G সংযোগ এবং প্রয়োজন হলে VPN টানেলের জন্য উৎপন্ন হয়।

Host প্রার্থীদের সর্বোচ্চ অগ্রাধিকার (UDP এর জন্য 2130706431) থাকে এবং তাদের প্রথমে পরীক্ষা করা হয়। যদি উভয় পিয়ার NAT এর পিছনে থাকে, তাহলে তাদের host প্রার্থী ব্যক্তিগত ঠিকানা (192.168.x.x, 10.x.x.x) হবে এবং তাদের মাধ্যমে সরাসরি সংযোগ সম্ভব হবে না। ICE তখন srflx এবং relay প্রার্থীদের পরীক্ষায় এগিয়ে যায়।

SRFLX এবং PRFLX প্রার্থী

SRFLX (Server Reflexive) প্রার্থী একটি STUN সার্ভার থেকে প্রাপ্ত বাহ্যিক IP ঠিকানা এবং পোর্ট। যখন একটি ডিভাইস STUN অনুরোধ পাঠায়, সার্ভার NAT এর পরে তার পাবলিক ঠিকানা দেখে এবং তা ফেরত দেয়। এই প্রার্থী বিভিন্ন NAT এর পিছনে পিয়ারদের মধ্যে সরাসরি সংযোগ স্থাপনের অনুমতি দেয়, যদি তাদের NAT ডিভাইসগুলি Hairpinning সমর্থন করে।

PRFLX (Peer Reflexive) প্রার্থী গতিশীলভাবে আবিষ্কৃত হয় যখন একজন পিয়ার থেকে STUN অনুরোধ একটি অপ্রত্যাশিত ঠিকানায় আসে। এই ধরনটি ঘটে যখন উভয় পিয়ার একসাথে অনুরোধ পাঠায় এবং NAT একটি অস্থায়ী বন্ধন তৈরি করে। PRFLX প্রার্থীর srflx থেকে উচ্চ অগ্রাধিকার থাকে কিন্তু host থেকে কম।

মোবাইল অ্যাপ্লিকেশনে, WiFi এবং সেলুলার নেটওয়ার্কের মধ্যে স্যুইচ করার সময় srflx প্রার্থী বিশেষভাবে গুরুত্বপূর্ণ। যখন একটি ডিভাইস নেটওয়ার্ক পরিবর্তন করে, IP ঠিকানা পরিবর্তিত হয় এবং ICE কে প্রার্থীদের পুনরায় সংগ্রহ করতে হয়। এই প্রক্রিয়াটিকে ICE রিস্টার্ট বলা হয় এবং এর জন্য নতুন SDP পাঠানোর প্রয়োজন হয়।

TURN এর মাধ্যমে Relay প্রার্থী

Relay প্রার্থী TURN সার্ভারে একটি ঠিকানা যার মাধ্যমে ট্রাফিক এক পিয়ার থেকে অন্যটিতে রিলে করা হয়। এই ধরনটি ব্যাকআপ বিকল্প হিসাবে ব্যবহৃত হয় যখন সরাসরি P2P সংযোগ সম্ভব নয় (সমমিত NAT, কর্পোরেট ফায়ারওয়াল)। রিলে চ্যানেল বিলম্ব বাড়ায় এবং সার্ভার লোড বাড়ায়, তাই সর্বোত্তম কনফিগারেশনে, TURN সার্ভার শুধুমাত্র 10–15% সেশনের জন্য ব্যবহার করা হয়।

জনপ্রিয় TURN সার্ভার বাস্তবায়ন: coturn (ওপেন সোর্স), Twilio Network Traversal, Metered TURN। TURN প্রদানকারীর পছন্দ মোবাইল অ্যাপ্লিকেশনে মিডিয়া সংযোগের গুণমানকে প্রভাবিত করে — সার্ভারটি অতিরিক্ত বিলম্ব কমাতে ভৌগোলিকভাবে ব্যবহারকারীদের কাছে অবস্থিত হওয়া উচিত।

ICE প্রক্রিয়া কীভাবে কাজ করে

ICE প্রক্রিয়া একটি বহু-পদক্ষেপ প্রোটোকল যা নেটওয়ার্ক টোপোলজি অনিশ্চয়তার পরিস্থিতিতে একটি নির্ভরযোগ্য P2P সংযোগ স্থাপনের নিশ্চয়তা দেয়। অ্যালগরিদম RFC 8445 এ বর্ণিত এবং এতে চারটি বাধ্যতামূলক পর্যায় অন্তর্ভুক্ত রয়েছে: প্রার্থী সংগ্রহ, সাজানো, পরীক্ষা এবং নমিনেশন।

পর্যায় 1: প্রার্থী সংগ্রহ

প্রতিটি ডিভাইস সমস্ত উপলব্ধ নেটওয়ার্ক ঠিকানা সংগ্রহ করে। এটি করার জন্য, WebRTC ইঞ্জিন স্থানীয় ইন্টারফেস (host) গণনা করে, STUN সার্ভারে (srflx) একটি অনুরোধ পাঠায় এবং TURN সার্ভার থেকে একটি রিলে ঠিকানা অনুরোধ করে। একই সাথে, ডিভাইসটি একটি prflx প্রার্থী আবিষ্কার করতে পারে যদি এটি কোনো পিয়ার থেকে আগত STUN অনুরোধ পায়।

মোবাইল ডেভেলপমেন্টে, এই পর্যায়টি সংযোগ স্থাপনের সময়ের জন্য গুরুত্বপূর্ণ। iOS এবং Android এ, নেটওয়ার্ক গতি, STUN/TURN সার্ভারের প্রাপ্যতা এবং সক্রিয় নেটওয়ার্ক ইন্টারফেসের সংখ্যার উপর নির্ভর করে প্রার্থী সংগ্রহ 200 ms থেকে 2 সেকেন্ড পর্যন্ত সময় নিতে পারে।

পর্যায় 2: জোড়া গঠন এবং সাজানো

সিগন্যালিং চ্যানেলের মাধ্যমে দূরবর্তী পিয়ার থেকে প্রার্থীদের তালিকা পাওয়ার পর, স্থানীয় ICE ইঞ্জিন সমস্ত সম্ভাব্য প্রার্থী জোড়া (স্থানীয় + দূরবর্তী) গঠন করে। প্রতিটি জোড়া RFC 8445 এর সূত্র অনুসারে একটি অগ্রাধিকার পায়, যা উভয় প্রার্থীর অগ্রাধিকার এবং দিক (ইনকামিং/আউটগোয়িং) বিবেচনা করে।

জোড়াগুলি অগ্রাধিকারের অবরোহী ক্রমে সাজানো হয়। সেরা জোড়াগুলি প্রথমে পরীক্ষা করা হয়। অ্যালগরিদম নিশ্চিত করে যে একটি host-host জোড়া host-srflx, host-relay বা relay-relay এর আগে পরীক্ষা করা হবে, সরল নেটওয়ার্ক কনফিগারেশনে সংযোগ বিলম্ব কমিয়ে।

পর্যায় 3: পরীক্ষা এবং নমিনেশন

ICE প্রতিটি প্রার্থী জোড়ার জন্য STUN বাইন্ডিং অনুরোধ পাঠায়। যদি STUN প্রতিক্রিয়া পাওয়া যায় — জোড়াটি বৈধ। প্রথম বৈধ জোড়াটি প্রাথমিক হিসাবে নমিনেট করা হয়। WebRTC ইঞ্জিন এই জোড়ায় মিডিয়া প্রেরণ শুরু করে, যখন বাকি জোড়াগুলি প্রাথমিক ব্যর্থ হওয়ার ক্ষেত্রে পরীক্ষা করতে থাকে।

বিপুল সংখ্যক প্রার্থীর সাথে পরীক্ষা প্রক্রিয়া কয়েক সেকেন্ড পর্যন্ত সময় নিতে পারে। WebRTC টাইমার ব্যবহার করে: host জোড়ার জন্য টাইমার আক্রমণাত্মক (20 ms), relay জোড়ার জন্য — আরও রক্ষণশীল (200 ms)। মোবাইল অ্যাপ্লিকেশন ডেভেলপাররা ICE সার্ভারের সংখ্যা সীমিত করে বা iceTransportPolicy কনফিগার করে সংযোগ দ্রুত করতে পারেন।

ICE রিস্টার্ট

ICE রিস্টার্ট সম্পূর্ণ RTCPeerConnection পুনরায় তৈরি না করেই ICE প্রক্রিয়ার পুনরারম্ভ। এটি নেটওয়ার্ক পরিবর্তন, সংযোগ হারানো বা WiFi এবং মোবাইল নেটওয়ার্কের মধ্যে স্যুইচ করার সময় প্রয়োজনীয়। রিস্টার্টের সময়, সমস্ত বর্তমান প্রার্থী বাতিল করা হয় এবং প্রক্রিয়াটি নতুন ufrag এবং pwd জেনারেট করে পুনরায় শুরু হয়।

iOS ডেভেলপমেন্টে, ICE রিস্টার্ট RTCPeerConnection এ restartIce() পদ্ধতির মাধ্যমে আহ্বান করা হয়। Android এ, Google WebRTC থেকে PeerConnection ক্লাসে একটি অনুরূপ পদ্ধতি ব্যবহার করা হয়। সঠিক ICE রিস্টার্ট হ্যান্ডলিং অস্থির নেটওয়ার্ক সংযোগ সহ মোবাইল ডিভাইসে চলমান অ্যাপ্লিকেশনের জন্য একটি গুরুত্বপূর্ণ প্রয়োজনীয়তা।

ICE এ STUN এবং TURN সার্ভার

STUN (Session Traversal Utilities for NAT) এবং TURN (Traversal Using Relays around NAT) গুরুত্বপূর্ণ সার্ভার উপাদান যা ছাড়া ICE Candidate বাস্তব ইন্টারনেট পরিস্থিতিতে সফল সংযোগযোগ্যতার নিশ্চয়তা দিতে পারে না। তাদের সঠিক কনফিগারেশন সরাসরি মোবাইল অ্যাপ্লিকেশনে কলের গুণমানকে প্রভাবিত করে।

STUN: বাহ্যিক ঠিকানা আবিষ্কার

STUN সার্ভার একটি ডিভাইসকে তার পাবলিক IP ঠিকানা এবং পোর্ট আবিষ্কার করতে দেয় যা NAT আউটগোয়িং সংযোগের জন্য বরাদ্দ করেছে। STUN প্রোটোকল RFC 8489 এ সংজ্ঞায়িত এবং পোর্ট 3478 এ UDP এর উপর কাজ করে, পাশাপাশি TCP সমর্থন করে। Google পাবলিক STUN সার্ভার (stun.l.google.com:19302) প্রদান করে যা বিনামূল্যে ব্যবহার করা যেতে পারে।

মোবাইল ডেভেলপমেন্টে, STUN অনুরোধ একটি হালকা অপারেশন যা 50–200 ms সময় নেয়। তবে, কিছু কর্পোরেট এবং মোবাইল নেটওয়ার্ক UDP ট্রাফিক ব্লক করে, ICE কে STUN যোগাযোগের জন্য TCP ব্যবহার করতে বা সরাসরি TURN এ যেতে বাধ্য করে।

TURN: ট্রাফিক রিলে

TURN সার্ভার একটি মিডিয়া ট্রাফিক রিলে। যখন সরাসরি P2P সংযোগ সম্ভব নয় (সমমিত NAT, ফায়ারওয়াল), ডিভাইসটি TURN এ ডেটা পাঠায়, যা এটি অন্য পিয়ারে ফরোয়ার্ড করে। TURN একটি নির্ভরযোগ্য কিন্তু ব্যয়বহুল প্রক্রিয়া: এটি বিলম্ব (30–100 ms) যোগ করে এবং সমস্ত মিডিয়া সেশনের যোগফলের সমান সার্ভার ব্যান্ডউইথ প্রয়োজন।

WebRTC Stats Report (2025) অনুযায়ী, মোবাইল নেটওয়ার্কে প্রায় 8–15% WebRTC সেশনের TURN প্রয়োজন। TURN ট্রাফিক খরচ অপ্টিমাইজ করতে, ডেভেলপাররা প্রাথমিক সংযোগ পরীক্ষা ব্যবহার করে এবং P2P ব্যর্থ হলেই TURN চ্যানেল সক্রিয় করে।

মোবাইল অ্যাপ্লিকেশনের জন্য STUN/TURN নির্বাচন

মোবাইল প্রকল্পে ICE এর জন্য অবকাঠামো নির্বাচন করার সময়, নিম্নলিখিত বিষয়গুলি বিবেচনা করা হয়: বিলম্ব কমানোর জন্য সার্ভারের ভৌগোলিক অবস্থান, UDP এবং TCP সমর্থন, TURN ট্রাফিক খরচ এবং SLA। জনপ্রিয় সমাধানগুলির মধ্যে রয়েছে: স্ব-হোস্টিংয়ের জন্য coturn, ক্লাউড-ভিত্তিক ব্যবহারের জন্য Twilio, Agora এবং LiveKit।

মোবাইল ডেভেলপমেন্টে ICE Candidate

মোবাইল ডেভেলপারদের জন্য, ICE Candidate বোঝা তত্ত্বের বাইরে যায় — ভয়েস এবং ভিডিও কল সহ অ্যাপ্লিকেশন তৈরির সময় এটি একটি ব্যবহারিক প্রয়োজনীয়তা। iOS এবং Android প্ল্যাটফর্ম নেটিভ WebRTC API প্রদান করে যা ICE হ্যান্ডলিং স্বয়ংক্রিয় করে, কিন্তু ডেভেলপার ICE সার্ভার কনফিগার করা এবং নেটওয়ার্ক পরিবর্তন ইভেন্টগুলি পরিচালনার জন্য দায়ী।

iOS এ ICE কনফিগারেশন

iOS এ, WebRTC WebRTC.framework বা CocoaPods এর মাধ্যমে GoogleWebRTC লাইব্রেরির মাধ্যমে উপলব্ধ। ICE সার্ভার RTCConfiguration এ RTCIceServer এর অ্যারের মাধ্যমে কনফিগার করা হয়:

let config = RTCConfiguration()
let stunServer = RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"])
let turnServer = RTCIceServer(urlStrings: ["turn:turn.example.com:3478"],
                                    username: "user",
                                    credential: "pass")
config.iceServers = [stunServer, turnServer]
let pc = RTCPeerConnection(configuration: config)

RTCPeerConnection তৈরি এবং offer() বা answer() কল করার পর, ইঞ্জিন স্বয়ংক্রিয়ভাবে ICE প্রার্থী সংগ্রহ করে। iceGatheringStateChange ইভেন্ট সংগ্রহ অবস্থার পরিবর্তন সম্পর্কে জানায়, যখন iceConnectionState সংযোগের অবস্থা রিপোর্ট করে।

Android এ ICE কনফিগারেশন

Android একই Google WebRTC লাইব্রেরি ব্যবহার করে। ICE সার্ভার PeerConnection.RTCConfiguration এর মাধ্যমে সেট করা হয়। ডেভেলপার iceTransportsType এর মাধ্যমে ICE নীতি পরিচালনা করতে পারে — রিলে মোড জোরপূর্বক শুধুমাত্র TURN ব্যবহার করে, যা নির্ভরযোগ্যতা বাড়ায় কিন্তু বিলম্ব যোগ করে:

val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.l.google.com:19302").createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("pass")
        .createIceServer()
)
val config = PeerConnection.RTCConfiguration(iceServers)
config.iceTransportsType = PeerConnection.IceTransportsType.ALL
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE

bundlePolicy প্যারামিটার ICE প্রার্থীর সংখ্যা প্রভাবিত করে — MAXBUNDLE মোড সমস্ত মিডিয়া স্ট্রিম একটি পরিবহনে একত্রিত করে, প্রার্থীর মোট সংখ্যা হ্রাস করে এবং সংযোগ দ্রুত করে।

মোবাইল অ্যাপ্লিকেশনে ICE ইভেন্ট পরিচালনা

মূল ICE ইভেন্টগুলি যা একজন ডেভেলপারের পরিচালনা করা উচিত: ICE সংযোগ অবস্থা, ICE সংগ্রহ অবস্থা এবং নতুন প্রার্থী আবিষ্কার। ICE সংগ্রহ এবং পরীক্ষা সম্পূর্ণ করার পর, এর অবস্থা connected বা completed এ পরিবর্তিত হয়।

মোবাইল নেটওয়ার্কে, WiFi এবং সেলুলার সংযোগের মধ্যে স্যুইচ ঘন ঘন ঘটে। যখন নেটওয়ার্ক পরিবর্তিত হয়, ICE কে রিস্টার্ট করতে হয়, অন্যথায় মিডিয়া স্ট্রিম বাধাগ্রস্ত হয়। ডেভেলপাররা স্বয়ংক্রিয়ভাবে restartIce() কল করার জন্য NetworkManager (iOS) বা ConnectivityManager (Android) এর মনিটরিং বাস্তবায়ন করে।

মোবাইল অ্যাপ্লিকেশনে একটি সফল ICE বাস্তবায়ন অন্তর্ভুক্ত করে: নির্ভরযোগ্য STUN/TURN সার্ভার নির্বাচন, নেটওয়ার্ক পরিবর্তনে সঠিক ICE রিস্টার্ট হ্যান্ডলিং, UI অবস্থা প্রদর্শনের জন্য iceConnectionState কনফিগারেশন এবং RTCStatsReport এর মাধ্যমে পরিসংখ্যান পর্যবেক্ষণ।