SDP — یہ کیا ہے، سیشن کی وضاحت کا فارمیٹ اور WebRTC میں کردار

SDP (Session Description Protocol) کیا ہے؟

SDP ایک ایپلیکیشن پرت پروٹوکول ہے جو ٹیکسٹ فارمیٹ میں ملٹی میڈیا سیشن کے پیرامیٹرز کی وضاحت کرنے کے لیے ڈیزائن کیا گیا ہے۔ اسے IETF کے MMUSIC (Multiparty Multimedia Session Control) ورکنگ گروپ کے تحت تیار کیا گیا تھا اور پہلی بار 1998 میں RFC 2327 میں معیاری بنایا گیا تھا۔ 2021 میں، موجودہ تفصیلات RFC 8866 شائع کی گئی، جس نے پچھلے ورژن RFC 4566 کی جگہ لی۔

SDP کا بنیادی کام سیشن کے شرکاء کو کنیکشن قائم کرنے کے لیے تمام ضروری معلومات فراہم کرنا ہے: کون سے میڈیا اسٹریمز منتقل کی جائیں گی، کون سے کوڈیکس تعاون یافتہ ہیں، اور کس نیٹ ورک ایڈریس اور پورٹ پر منتقلی ہوگی۔ SDP خود میڈیا ڈیٹا منتقل نہیں کرتا، بلکہ صرف یہ بتاتا ہے کہ کنیکشن کو کیسے منظم کیا جانا چاہیے۔

IETF RFC 8866 کے مطابق، SDP فارمیٹ لائنوں کے ایک سیٹ پر مشتمل ہے، جن میں سے ہر ایک ایک حرف کی قسم سے شروع ہوتی ہے، جس کے بعد مساوی علامت اور ایک قدر ہوتی ہے۔ مثال کے طور پر، لائن m=audio 5004 RTP/AVP 0 کا مطلب ہے کہ سیشن میں پورٹ 5004 پر RTP/AVP ٹرانسپورٹ پروٹوکول اور PCMU کوڈیک (قسم 0) کے ساتھ ایک آڈیو اسٹریم شامل ہے۔

SDP کی تاریخ اور معیاری بنانا

SDP کا پہلا ورژن اپریل 1998 میں MMUSIC گروپ کے کام کے نتیجے میں RFC 2327 میں شائع کیا گیا تھا۔ یہ پروٹوکول اصل میں Mbone (Multicast Backbone) کے تحت ملٹی کاسٹ سیشنز کے اعلان کے لیے بنایا گیا تھا۔ VoIP اور ویڈیو کانفرنسنگ کی ترقی کے ساتھ، SDP کے اطلاق کا دائرہ وسیع ہوا اور 2006 میں اپ ڈیٹ شدہ تفصیلات RFC 4566 شائع کی گئی۔

SDP کے استعمال میں ایک حقیقی پیش رفت 2011 میں WebRTC کی آمد کے ساتھ ہوئی۔ گوگل نے براؤزر پر مبنی ریئل ٹائم کمیونیکیشن فریم ورک میں میڈیا سیشنز کی وضاحت کے لیے SDP کو بنیادی میکانزم کے طور پر ضم کیا۔ اس کے بعد سے، SDP کسی بھی WebRTC نفاذ کا لازمی جزو بن گیا ہے — براؤزرز سے لے کر iOS اور Android پر موبائل ایپلیکیشنز تک۔

2021 میں، IETF ورکنگ گروپ نے RFC 8866 شائع کیا — SDP کی موجودہ تفصیلات، جس نے RFC 4566 کی جگہ لی۔ اپ ڈیٹ شدہ ورژن نے ICE (Interactive Connectivity Establishment) پروسیسنگ کو واضح کیا، DTLS (Datagram Transport Layer Security) سپورٹ کو بہتر کیا، اور گروپ سیشنز کی وضاحت کی صلاحیتوں کو بڑھایا۔

SDP اور ٹرانسپورٹ پروٹوکولز کے درمیان فرق

SDP ٹرانسپورٹ پروٹوکولز سے بنیادی طور پر مختلف ہے کیونکہ یہ ڈیٹا کی منتقلی میں حصہ نہیں لیتا۔ یہ خالصتاً وضاحتی کام انجام دیتا ہے — ملٹی میڈیا فائل میٹا ڈیٹا کی طرح۔ جبکہ RTP (Real-time Transport Protocol) آڈیو اور ویڈیو پیکٹ منتقل کرتا ہے، اور RTCP منتقلی کے معیار کو کنٹرول کرتا ہے، SDP صرف یہ بتاتا ہے کہ کون سے کوڈیکس اور پورٹس استعمال کرنے ہیں۔

ویب ڈویلپمنٹ سے ایک مشابہت: SDP ایچ ٹی ایم ایل مارک اپ کی طرح ہے جو صفحہ کی ساخت بیان کرتا ہے، جبکہ RTP حقیقی تصاویر اور متن ہے۔ SDP کے بغیر، سیشن کے شرکاء نہیں جانتے کہ ایک دوسرے سے کیسے جڑیں، چاہے نیٹ ورک کنیکشن پہلے سے قائم ہو۔ NAT ٹراورسل میکانزم (ICE) بھی نیٹ ورک امیدواروں کے بارے میں معلومات منتقل کرنے کے لیے SDP پر انحصار کرتا ہے۔

SDP کی ساخت کیسی ہے

SDP کی ساخت ٹیکسٹ لائنوں کی ایک ترتیب کے طور پر منظم ہے، جن میں سے ہر ایک type=value فارمیٹ کی پیروی کرتی ہے۔ ایک حرف کی قسم لائن کے مقصد کی وضاحت کرتی ہے، اور قدر میں متعلقہ قدر ہوتی ہے۔ تمام لائنیں CRLF کریکٹر سے الگ ہوتی ہیں۔

RFC 8866 معیار کئی لازمی اور اختیاری فیلڈز کی وضاحت کرتا ہے۔ لازمی فیلڈز میں پروٹوکول ورژن (v=)، سیشن کا نام (s=) اور سیشن شروع ہونے اور ختم ہونے کا وقت (t=) شامل ہیں۔ باقی فیلڈز اختیاری ہیں، لیکن WebRTC سیشنز کے لیے میڈیا کی وضاحت (m=)، خصوصیات (a=) اور نیٹ ورک کی معلومات (c=) بھی ضروری ہیں۔

v=0
o=- 46116397 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 5004 RTP/SAVPF 111 103 104
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
m=video 5006 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

اوپر دی گئی مثال WebRTC سیشن کے لیے ایک عام SDP سیگمنٹ دکھاتی ہے۔ v=0 لائن پروٹوکول ورژن کی نشاندہی کرتی ہے۔ o= فیلڈ میں سیشن کے مالک کا شناخت کنندہ اور ورژن ہوتا ہے۔ s=- لائن سیشن کا نام بتاتی ہے (ڈیش کا مطلب خالی نام ہے)۔ t=0 0 فیلڈ ظاہر کرتا ہے کہ سیشن وقت میں محدود نہیں ہے۔

a=group:BUNDLE audio video فیلڈ ایک خصوصیت ہے جو ایک سے زیادہ میڈیا اسٹریمز کو ایک ٹرانسپورٹ چینل میں گروپ کرتی ہے۔ BUNDLE میکانزم ایک کنیکشن کے ذریعے آڈیو اور ویڈیو منتقل کرکے نیٹ ورک وسائل بچانے کی اجازت دیتا ہے۔ یہ محدود بینڈوتھ والے موبائل آلات کے لیے خاص طور پر اہم ہے۔

SDP کے لازمی فیلڈز

RFC 8866 تفصیلات لازمی اور اختیاری فیلڈز کا ایک سیٹ بتاتی ہے۔ لازمی فیلڈز میں v= (ورژن)، s= (سیشن کا نام) اور t= (وقت) شامل ہیں۔ o= (مالک) فیلڈ، اگرچہ RFC کے مطابق سختی سے لازمی نہیں ہے، حقیقی نفاذ میں تقریباً ہمیشہ موجود ہوتا ہے۔

m= (media) فیلڈ سب سے اہم فیلڈز میں سے ایک ہے۔ یہ ایک مخصوص میڈیا اسٹریم کی وضاحت کرتا ہے اور اس میں میڈیا کی قسم (audio, video, text, application)، پورٹ، ٹرانسپورٹ پروٹوکول اور معاون کوڈیکس کی فہرست شامل ہوتی ہے۔ WebRTC میں، سب سے زیادہ استعمال ہونے والی قسمیں audio اور video ہیں جن کے ٹرانسپورٹ پروٹوکول RTP/SAVPF (Secure Audio/Video Profile with Feedback) یا UDP/TLS/RTP/SAVPF ہیں۔

a= (attribute) فیلڈ سب سے زیادہ لچکدار اور قابل توسیع ہے۔ یہ rtpmap (کوڈیک نمبر کو نام سے نقشہ بنانا)، fmtp (کوڈیک پیرامیٹرز)، fingerprint (DTLS کلید کا فنگر پرنٹ)، ice-ufrag اور ice-pwd (ICE اسناد) اور بہت سی دوسری خصوصیات پر مشتمل ہو سکتا ہے۔ خصوصیات کے ذریعے، SDP جدید حفاظتی میکانزم اور NAT ٹراورسل کو سپورٹ کرتا ہے۔

WebRTC میں SDP کیسے کام کرتا ہے

WebRTC آرکیٹیکچر میں، SDP دو شرکاء کے درمیان میڈیا سیشن کے پیرامیٹرز کی وضاحت اور گفت و شنید کے لیے ایک سگنلنگ پروٹوکول کے طور پر کام کرتا ہے۔ SDP خود ان وضاحتوں کو منتقل کرنے کا طریقہ کار متعین نہیں کرتا — یہ کام سگنلنگ چینل سنبھالتا ہے، جسے ڈویلپر WebSocket، HTTP یا کسی اور پروٹوکول کے ذریعے آزادانہ طور پر نافذ کرتا ہے۔

عمل اس وقت شروع ہوتا ہے جب شروع کرنے والا (caller) ایک SDP Offer بناتا ہے۔ ایسا کرنے کے لیے، براؤزر RTCPeerConnection آبجیکٹ پر createOffer() طریقہ کو کال کرتا ہے۔ پیدا کردہ SDP وضاحت میں شروع کرنے والے کی طرف سے سیشن کے تمام پیرامیٹرز شامل ہوتے ہیں: معاون کوڈیکس، نیٹ ورک ایڈریسز، ICE امیدوار اور حفاظتی تقاضے۔

const configuration = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };
const pc = new RTCPeerConnection(configuration);

// createOffer سے پہلے میڈیا ٹریکس شامل کریں
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// SDP Offer بنائیں
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// سگنلنگ چینل کے ذریعے دور دراز پیر کو SDP بھیجیں
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Offer بنانے اور setLocalDescription() کے ذریعے مقامی وضاحت سیٹ کرنے کے بعد، شروع کرنے والا سگنلنگ چینل کے ذریعے SDP سٹرنگ دور دراز کے شریک کو بھیجتا ہے۔ دور دراز کا شریک، SDP Offer وصول کرکے، ایک SDP Answer بناتا ہے اور واپس بھیجتا ہے۔ اس تبادلے کو سگنلنگ ایکسچینج کہا جاتا ہے اور یہ پیئر ٹو پیئر کنیکشن قائم کرنے سے پہلے ایک لازمی مرحلہ ہے۔

W3C WebRTC تفصیلات کے مطابق، SDP کا تبادلہ ICE امیدواروں کے شروع ہونے سے پہلے ہونا چاہیے۔ عملی طور پر، بہت سے نفاذ ICE trickle میکانزم کا استعمال کرتے ہوئے SDP کے متوازی ICE امیدوار بھیجتے ہیں۔ یہ کنیکشن قائم کرنے کا وقت کم کرتا ہے، خاص طور پر زیادہ تاخیر والے موبائل نیٹ ورکس کے لیے۔

SDP میں ICE کا کردار

ICE (Interactive Connectivity Establishment) ایک میکانزم ہے جو نیٹ ورک امیدواروں کے بارے میں معلومات منتقل کرنے کے لیے SDP خصوصیات استعمال کرتا ہے۔ ICE امیدوار ممکنہ کنیکشن راستوں کی وضاحت کرتے ہیں: host (مقامی ایڈریس)، srflx (NAT کے بعد کا ایڈریس، STUN کے ذریعے حاصل کردہ) اور relay (TURN سرور کا ایڈریس)۔

SDP میں، ICE امیدوار a=candidate: خصوصیات کے ذریعے، نیز ICE ٹریفک کی تصدیق کے لیے ice-ufrag اور ice-pwd فیلڈز کے ذریعے منتقل کیے جاتے ہیں۔ ہر امیدوار میں ٹرانسپورٹ پروٹوکول (UDP, TCP)، IP ایڈریس، پورٹ اور ترجیح شامل ہوتی ہے۔ کامیاب کنیکشن پہلے امیدوار کے ذریعے قائم ہوتا ہے جو کنیکٹیویٹی چیک پاس کرتا ہے۔ ICE restart میکانزم نیٹ ورک تبدیل ہونے پر کنیکشن کو اپ ڈیٹ کرنے کی اجازت دیتا ہے۔

موبائل ایپلیکیشنز کے لیے، ICE امیدوار خاص طور پر اہم ہیں کیونکہ آلات اکثر NAT یا کارپوریٹ فائر والز کے پیچھے ہوتے ہیں۔ ICE میکانزم پیچیدہ نیٹ ورک حالات میں بھی کام کرنے والا راستہ تلاش کرنے کی اجازت دیتا ہے، اور SDP اس معلومات کے لیے ٹرانسپورٹ کنٹینر کے طور پر کام کرتا ہے۔

WebRTC میں SDP سیکیورٹی

WebRTC میں SDP میں لازمی طور پر حفاظتی خصوصیات شامل ہوتی ہیں، خاص طور پر DTLS فنگر پرنٹ اور SRTP پیرامیٹرز۔ a=fingerprint:sha-256 فیلڈ میں DTLS سرٹیفکیٹ کا فنگر پرنٹ ہوتا ہے، جو میڈیا اسٹریم کی تصدیق اور خفیہ کاری کے لیے استعمال ہوتا ہے۔ اس خصوصیت کے بغیر، WebRTC کنیکشن قائم نہیں ہوگا۔

اضافی حفاظتی میکانزم میں a=setup: خصوصیت شامل ہے، جو DTLS مصافحہ کے کردار (active, passive, actpass) کی وضاحت کرتی ہے، اور a=ice-lite: سرور کی طرف آسان ICE نفاذ کے لیے۔ یہ تمام پیرامیٹرز SDP کے اندر منتقل کیے جاتے ہیں اور میڈیا ڈیٹا کی منتقلی شروع ہونے سے پہلے دونوں فریقوں کی طرف سے تصدیق کیے جاتے ہیں۔

SDP کی اقسام: Offer اور Answer

WebRTC ماڈل میں، SDP پیغامات کی دو اقسام ہیں: Offer (تجویز) اور Answer (جواب)۔ Offer کنیکشن شروع کرنے والے کے ذریعے بنایا جاتا ہے اور اس میں مطلوبہ میڈیا سیشن کی مکمل وضاحت ہوتی ہے۔ Answer دور دراز کے شریک کے ذریعے Offer کے جواب میں بنایا جاتا ہے اور اس میں تجویز کی طرف سے عائد کردہ رکاوٹوں کو مدنظر رکھتے ہوئے اس کی صلاحیتیں شامل ہوتی ہیں۔

Offer اور Answer کے درمیان بنیادی فرق خصوصیات کے معنی میں ہے۔ Offer تمام معاون کوڈیکس، ٹرانسپورٹ پروٹوکولز اور نیٹ ورک ایڈریسز کو فہرست کرتا ہے جو شروع کرنے والا تجویز کر سکتا ہے۔ Answer ان صلاحیتوں کا ایک ذیلی سیٹ منتخب کرتا ہے جسے دور دراز کا فریق سپورٹ کرتا ہے۔ مثال کے طور پر، اگر Offer opus، ISAC اور PCMU تجویز کرتا ہے، تو Answer سب سے ترجیحی کوڈیک کے طور پر صرف opus کا انتخاب کر سکتا ہے۔

تبادلے کا عمل W3C WebRTC تفصیلات کے ذریعے منظم کیا جاتا ہے اور اس میں RTCPeerConnection کی کئی حالتیں شامل ہیں۔ createOffer() کے ذریعے Offer بنانے اور اسے مقامی وضاحت کے طور پر سیٹ کرنے کے بعد، کنیکشن have-local-offer حالت میں داخل ہوتا ہے۔ Answer وصول کرنے اور setRemoteDescription() کے ذریعے اسے دور دراز کی وضاحت کے طور پر سیٹ کرنے کے بعد، کنیکشن stable حالت میں داخل ہوتا ہے — میڈیا کی منتقلی کے لیے تیار حتمی حالت۔

موبائل SDK میں SDP کا استعمال

WebRTC کے لیے موبائل SDK — Android کے لیے Google WebRTC اور iOS کے لیے WebRTC.framework — Offer اور Answer کے ذریعے SDP کے تبادلے کو مکمل طور پر سپورٹ کرتے ہیں۔ Android پر، براؤزر API کی طرح، PeerConnection کلاس createOffer() طریقہ کے ساتھ Offer بنانے کے لیے استعمال ہوتی ہے۔ نتیجے میں آنے والی SDP وضاحت سگنلنگ چینل کے ذریعے ایک سٹرنگ کے طور پر منتقل کی جاتی ہے۔

iOS پر، SDP کے ساتھ کام WebRTC فریم ورک کی RTCSessionDescription کلاس کے ذریعے کیا جاتا ہے۔ ابتدا کرتے وقت، قسم (RTCSdpTypeOffer یا RTCSdpTypeAnswer) اور SDP سٹرنگ مخصوص کی جاتی ہے۔ پلیٹ فارم خود بخود SDP کو پارس کرتا ہے اور منتقل کردہ پیرامیٹرز کے مطابق کنیکشن ترتیب دیتا ہے۔

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// Android پر SDP Offer بنائیں
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // دور دراز پیر کو SDP سٹرنگ بھیجیں
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

SDP سٹرنگ کے ساتھ براہ راست کام کرنے کی صلاحیت ڈویلپرز کو لچک دیتی ہے: وہ بھیجنے سے پہلے SDP میں ترمیم کر سکتے ہیں، مخصوص کوڈیکس شامل یا ہٹا سکتے ہیں، ICE پیرامیٹرز ترتیب دے سکتے ہیں یا حسب ضرورت خصوصیات شامل کر سکتے ہیں۔ Android ایپلیکیشنز کے لیے، جب نیٹ ورک بینڈوتھ کم ہو تو SDP میں ویڈیو کو غیر فعال کرنا اکثر ضروری ہوتا ہے — یہ SDP وضاحت سے متعلقہ m= لائنیں ہٹا کر کیا جاتا ہے۔

موبائل ڈویلپمنٹ میں SDP

موبائل ڈویلپمنٹ میں، SDP بنیادی طور پر WebRTC کے سیاق و سباق میں استعمال ہوتا ہے — ویڈیو کالز، وائس چیٹس اور سٹریمنگ کے ساتھ ایپلیکیشنز بنانے کے لیے۔ Android اور iOS پر موبائل ایپلیکیشنز SDP پیغامات کے شروع کرنے والے اور وصول کنندہ دونوں کے طور پر کام کر سکتی ہیں، جو ہم آہنگ پیئر ٹو پیئر کنیکشنز کو قابل بناتی ہیں۔

موبائل ایپلیکیشنز کی ایک خصوصیت متغیر نیٹ ورک کوالٹی کے حالات میں SDP کے ساتھ کام کرنے کی ضرورت ہے۔ Wi-Fi اور موبائل انٹرنیٹ کے درمیان سوئچ کرتے وقت، نیز بینڈوتھ تبدیل ہونے پر، نئی SDP وضاحت پیدا کرنے کی ضرورت ہو سکتی ہے۔ یہ دوبارہ گفت و شنید میکانزم کا استعمال کرتے ہوئے کیا جاتا ہے — createOffer() اور setLocalDescription() کے ذریعے بار بار SDP کا تبادلہ۔

Google WebRTC ٹیم (2023) کے مطابق، موبائل آلات کے لیے SDP تبادلے کو بہتر بنانے میں نیٹ ورک کی تبدیلیوں کے دوران ICE restart کا استعمال، کم بٹ ریٹ کوڈیکس (آڈیو کے لیے opus، ویڈیو کے لیے VP8) کو ترجیح دینا، اور غیر ضروری میڈیا اسٹریمز کو خارج کرکے SDP سٹرنگ کے سائز کو کم کرنا شامل ہے۔ بنیادی فائدہ موبائل نیٹ ورک کے حالات میں کنیکشن قائم کرتے وقت تاخیر کو کم کرنا ہے۔

موبائل نیٹ ورکس کے لیے SDP کی اصلاح

موبائل آلات پر SDP کے ساتھ کام کرتے وقت اہم کاموں میں سے ایک SDP وضاحت کے سائز کو کم کرنا ہے۔ آڈیو اور ویڈیو کے ساتھ ایک عام WebRTC سیشن کے لیے مکمل SDP 2–5 KB پر محیط ہو سکتا ہے، جو سست نیٹ ورکس کے لیے اہم ہے۔ اصلاح میں BUNDLE (اسٹریم ملٹی پلیکسنگ) کا استعمال، غیر معاون کوڈیکس کو ہٹانا، اور ICE امیدواروں کو کمپریس کرنا شامل ہے۔

موبائل آلات کے لیے ایک اضافی مسئلہ SDP کی محدود عمر ہے۔ غیر مستحکم کنیکشن کے حالات میں، SDP اس سے پہلے متروک ہو سکتا ہے کہ دور دراز کا شریک اسے پروسیس کر سکے۔ حل Answer وصول کرنے کے لیے مختصر ٹائم آؤٹ استعمال کرنا اور ضرورت پڑنے پر SDP دوبارہ بھیجنا ہے۔ ICE restart میکانزم RTCPeerConnection کو مکمل طور پر دوبارہ بنائے بغیر کنیکشن کو اپ ڈیٹ کرنے کی اجازت دیتا ہے۔ a=ice-lite خصوصیت سرور کی طرف ICE نفاذ کو آسان بناتی ہے۔

SDP کے ساتھ کام کرنے کے لیے مشہور لائبریریاں

موبائل ایپلیکیشن ڈویلپرز کے پاس تیار شدہ لائبریریاں ہیں جو SDP کے ساتھ کام کو آسان بناتی ہیں۔ libjingle_peerconnection (Google WebRTC) Android کے لیے اہم لائبریری ہے، جو SDP کے انتظام کے لیے مکمل API فراہم کرتی ہے۔ iOS کے لیے، اسی طرح کی فعالیت کے ساتھ WebRTC.framework استعمال کیا جاتا ہے۔ دونوں لائبریریاں خود بخود SDP پیدا اور پارس کرتی ہیں، لیکن ضرورت پڑنے پر خام SDP سٹرنگ تک رسائی فراہم کرتی ہیں۔

SDP پر زیادہ باریک کنٹرول کے لیے، تیسرے فریق کے حل موجود ہیں: SDP کو پارس اور تبدیل کرنے کے لیے sdp-transform (JavaScript یا Node.js)، ICE امیدواروں کے ساتھ کام کرنے کے لیے NICENICE (Java)، اور WebRTC انفراسٹرکچر فراہم کرنے والوں سے تیار SDK جو SDP سمیت تمام سگنلنگ تبادلے کو سنبھالتے ہیں۔