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 nominated pairs کے میکانزم کا استعمال کرتا ہے: تمام امیدواروں کو اکٹھا کرنے کے بعد، STUN درخواستوں کے ذریعے جوڑے در جوڑے ٹیسٹ کیا جاتا ہے۔ سب سے پہلے تصدیق پاس کرنے والا جوڑا nominated (مقرر شدہ) قرار دیا جاتا ہے اور ملٹی میڈیا کی منتقلی کے لیے استعمال ہوتا ہے۔ باقی جوڑے کنیکشن ٹوٹنے کی صورت میں ریزرو میں رہتے ہیں۔

WebRTC اسٹیک میں ICE کا کردار

WebRTC P2P مواصلات کا ایک کھلا معیار ہے، لیکن NAT (Network Address Translation) اور فائروالز کی وجہ سے آلات کے درمیان براہراست کنیکشن اکثر ناممکن ہے۔ ICE Candidate متعدد متبادل کنیکشن راستے پیش کرکے اس مسئلے کو حل کرتا ہے۔ ICE (Interactive Connectivity Establishment) پروٹوکول WebRTC کا ایک لازمی جزو ہے اور W3C WebRTC (2025) تخصیص میں بیان کیا گیا ہے۔

بہت سے موبائل ایپ ڈویلپرز Google WebRTC (Android کے لیے) اور iOS کے لیے نیٹو ریپرز جیسی WebRTC لائبریریز استعمال کرتے ہیں۔ ان میں سے ہر ایک میں ICE عمل خودکار طور پر منتظم ہوتا ہے، لیکن امیدواروں کی اقسام کو سمجھنا ڈویلپر کو سرور بنیادی ڈھانچے کو ترتیب دینے اور کنیکشن کے معیار کو بہتر بنانے میں مدد کرتا ہے۔

ICE امیدواروں کے ساتھ SDP فارمیٹ

ICE Candidate SDP پیغام میں a=candidate خوبی کے طور پر منتقل ہوتا ہے۔ ہر سطر میں foundation، component ID، ٹرانسپورٹ پروٹوکول، ترجیح، IP پتہ، پورٹ اور امیدوار کی قسم شامل ہوتی ہے۔ ذیل میں مختلف اقسام کے تین امیدواروں کے ساتھ SDP فرگمنٹ کی مثال دی گئی ہے:

// ایک SDP مثال ICE امیدواروں کے ساتھ
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 آلات کے Hairpinning کی حمایت کرنے کی صورت میں مختلف NAT کے پیچھے ہم سائیروں کے درمیان براہراست کنیکشن قائم کرنے کی اجازت دیتا ہے۔

PRFLX (Peer Reflexive) امیدوار اس وقت متحرک طور پر دریافت ہوتا ہے جب ایک ہم سائیر سے STUN درخواست ایک غیر متوقع پتے پر پہنچتی ہے۔ یہ قسم اس وقت واقع ہوتی ہے جب دونوں ہم سائیر بیک وقت درخواستیں بھیجتے ہیں اور NAT عارضی بائنڈنگ بناتا ہے۔ PRFLX امیدوار کی srflx سے زیادہ ترجیح ہوتی ہے لیکن host سے کم۔

موبائل ایپلیکیشنز میں، srflx امیدوار WiFi اور سیلولر نیٹ ورک کے درمیان سوئچنگ کے دوران خاص طور پر اہم ہوتے ہیں۔ جب آلہ نیٹ ورک بدلتا ہے، IP پتہ بدل جاتا ہے اور ICE کو امیدواروں کو دوبارہ اکٹھا کرنا ہوتا ہے۔ اس عمل کو ICE restart کہا جاتا ہے اور اسے ایک نئے 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 سرور سے ریلے پتہ کی درخواست کرتا ہے۔ ایک ہی وقت میں، آلہ ایک ہم سائیر سے آنے والی STUN درخواست موصول ہونے پر prflx امیدوار دریافت کر سکتا ہے۔

موبائل ڈویلپمنٹ میں یہ مرحلہ کنیکشن قیام کے وقت کے لیے انتہائی اہم ہے۔ iOS اور Android پر، امیدواروں کا اکٹھا نیٹ ورک کی رفتار، STUN/TURN سرورز کی دستیابی اور فعال نیٹ ورک انٹرفیسز کی تعداد کے مطابق 200 ms سے 2 سیکنڈ تک کا وقت لے سکتا ہے۔

مرحلہ 2: جوڑوں کی تشکیل اور ترتیب دینا

سگنلنگ چینل کے ذریعے دور دراز ہم سائیر سے امیدواروں کی فہرست موصول ہونے کے بعد، مقامی ICE انجن تمام ممکن امیدوار جوڑے (مقامی + دور دراز) بناتا ہے۔ ہر جوڑے کو RFC 8445 کے فارمولے کے مطابق، دونوں امیدواروں کی ترجیحات اور سمت (اندر آنی/باهر جانی) کو مدنظر رکھتے ہوئے ایک ترجیح ملتی ہے۔

جوڑے اترتی ترجیح کے مطابق ترتیب دیے جاتے ہیں۔ بهترین جوڑے سب سے پہلے ٹیسٹ کیے جاتے ہیں۔ الگورتھم اس بات کی ضمانت دیتا ہے کہ host-host جوڑا host-srflx، host-relay یا relay-relay سے پہلے چیک کیا جائے گا، سادہ نیٹ ورک کنفگریشنز میں کنیکشن میں تاخیر کو کم سے کم کرتا ہے۔

مرحلہ 3: ٹیسٹ اور تقرری

ICE ہر امیدوار جوڑے کے لیے STUN-binding درخواستیں بھیجتا ہے۔ اگر STUN جواب موصول ہوتا ہے تو جوڑا موزی ہے۔ پہلا موزی جوڑا nominated (مقرر شدہ) کے طور پر متعین کیا جاتا ہے۔ WebRTC انجن اس جوڑے کے ذریعے میڈیا منتقل کرنا شروع کرتا ہے، جبکہ باقی جوڑے اصلی کے ناکام ہونے کی صورت میں چیک کیے جاتے رہتے ہیں۔

ٹیسٹ کا عمل بڑی تعداد میں امیدواروں کے ساتھ کئی سیکنڈ تک لے سکتا ہے۔ WebRTC ٹائمرز استعمال کرتا ہے: host جوڑوں کے لیے تیز (20 ms)، relay کے لیے زیادہ قدامت پسند (200 ms)۔ موبائل ایپ ڈویلپرز ICE سرورز کی تعداد کو محدود کرکے یا iceTransportPolicy کو ترتیب دے کر کنیکشن کو تیز کر سکتے ہیں۔

ICE Restart

ICE restart پورے RTCPeerConnection کو دوبارہ تیار کیے بغیر ICE عمل کو دوبارہ شروع کرنا ہے۔ یہ نیٹ ورک تبدیلی، کنیکشن کے ختم ہونے یا WiFi اور موبائل نیٹ ورک کے درمیان سوئچنگ کے وقت ضروری ہے۔ دوبارہ شروع کرنے پر تمام موجودہ امیدوار ریسیٹ ہو جاتے ہیں اور عمل نئے ufrag اور pwd کی تخلیق کے ساتھ نئے سرے سے شروع ہوتا ہے۔

iOS ڈویلپمنٹ میں ICE restart کو RTCPeerConnection پر restartIce() کے طریقے سے بلایا جاتا ہے۔ Android پر Google WebRTC کے PeerConnection کلاس میں ایک مماثل طریقہ استعمال ہوتا ہے۔ ICE restart کی مناسب ہینڈلنگ غیر مستحکم نیٹ ورک کنیکشن کے ساتھ کام کرنے والے موبائل آلات پر ایپلیکیشنز کے لیے ایک اہم ضرورت ہے۔

ICE میں STUN اور TURN سرور

STUN (Session Traversal Utilities for NAT) اور TURN (Traversal Using Relays around NAT) ایسے اہم سرور جزو ہیں جن کے بغیر ICE Candidate حقیقی انٹرنیٹ کی حالات میں کامیاب کنیکشن کی ضمانت نہیں دے سکتا۔ ان کی مناسب ترتیب موبائل ایپلیکیشنز میں کال کے معیار کو براہراست متاثر کرتی ہے۔

STUN: بیرونی پتے کی دریافت

STUN سرور آلے کو اپنا عوامی IP پتہ اور وہ پورٹ جاننے کی اجازت دیتا ہے جو NAT نے باہر جانے والے کنیکشن کے لیے مختص کیا ہے۔ STUN پروٹوکول RFC 8489 میں تعریف کیا گیا ہے اور UDP پورٹ 3478 پر کام کرتا ہے، اور 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 پالیسی کا انتظام کر سکتا ہے — relay موڈ صرف 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 کو restart کرنا ہوگا، ورنہ میڈیا سٹریم رک جائے گا۔ ڈویلپرز NetworkManager (iOS) یا ConnectivityManager (Android) کی نگرانی نافذ کرتے ہیں تاکہ خودکار طور پر restartIce() کو کال کیا جا سکے۔

موبائل ایپلیکیشن میں ICE کا کامیاب نفاذ مندرجہ ذیل پر مشتمل ہے: قابل بھروسہ STUN/TURN سرورز کا انتخاب، نیٹ ورک تبدیلی پر ICE restart کی مناسب ہینڈلنگ، کنیکشن UI سٹیٹس کی نمائش کے لیے iceConnectionState ترتیب اور RTCStatsReport کے ذریعے شماریات کی نگرانی۔