SDP — ما هو، تنسيق وصف الجلسات ودوره في WebRTC

ما هو SDP (Session Description Protocol)؟

SDP هو بروتوكول طبقة تطبيقات مصمم لوصف معلمات الجلسات الوسائطية بتنسيق نصي. تم تطويره ضمن فريق عمل MMUSIC (Multiparty Multimedia Session Control) التابع لـ IETF وتم توحيده لأول مرة في RFC 2327 في عام 1998. في عام 2021، صدرت المواصفات الحالية RFC 8866 لتحل محل الإصدار السابق RFC 4566.

المهمة الرئيسية لـ SDP هي تزويد المشاركين في الجلسة بجميع المعلومات اللازمة لإنشاء اتصال: ما تدفقات الوسائط التي سيتم إرسالها، وأي الترميزات مدعومة، وعبر أي عناوين شبكة ومنافذ سيتم الإرسال. لا ينقل SDP بيانات الوسائط نفسها، بل يصف فقط كيف يجب تنظيم الاتصال.

وفقًا لـ IETF RFC 8866، يتكون تنسيق SDP من مجموعة من الأسطر، يبدأ كل منها بنوع مكون من حرف واحد، متبوعًا بعلامة يساوي وقيمة. على سبيل المثال، السطر m=audio 5004 RTP/AVP 0 يعني أن الجلسة تتضمن تدفقًا صوتيًا على المنفذ 5004 مع بروتوكول نقل RTP/AVP وترميز PCMU (نوع 0).

تاريخ SDP وتوحيده

تم نشر الإصدار الأول من SDP في RFC 2327 في أبريل 1998 كنتيجة لعمل فريق MMUSIC. تم إنشاء البروتوكول في الأصل للإعلان عن جلسات البث المتعدد ضمن Mbone (Multicast Backbone). مع تطور VoIP ومؤتمرات الفيديو، توسع نطاق تطبيق SDP، وفي عام 2006 صدرت المواصفات المحدثة RFC 4566.

حدث الاختراق الحقيقي في استخدام SDP مع ظهور WebRTC في عام 2011. قامت Google بدمج 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 يشبه ترميز HTML الذي يصف هيكل الصفحة، بينما RTP هو الصور والنص الفعليين. بدون SDP، لا يعرف المشاركون في الجلسة كيفية الاتصال ببعضهم البعض، حتى لو كان اتصال الشبكة قائمًا بالفعل. تعتمد آلية NAT traversal (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

يظهر المثال أعلاه مقطع SDP نموذجي لجلسة WebRTC. يشير السطر 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 traversal.

كيف يعمل SDP في WebRTC

في بنية WebRTC، يعمل SDP كـ بروتوكول إشارات لوصف والتفاوض على معلمات الجلسة الوسائطية بين مشاركين. لا يحدد SDP نفسه آلية نقل هذه الأوصاف — هذه المهمة يعالجها قناة الإشارات، التي ينفذها المطور بشكل مستقل عبر WebSocket أو HTTP أو بروتوكول آخر.

تبدأ العملية عندما يقوم البادئ (caller) بإنشاء عرض SDP — Offer. للقيام بذلك، يستدعي المتصفح طريقة createOffer() على كائن RTCPeerConnection. يحتوي وصف 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
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// أرسل SDP إلى النظير البعيد عبر قناة الإشارات
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

بعد إنشاء Offer وتعيين الوصف المحلي عبر setLocalDescription()، يرسل البادئ سلسلة SDP إلى المشارك البعيد عبر قناة الإشارات. يقوم المشارك البعيد، بعد استلام SDP Offer، بإنشاء رد SDP — Answer — وإرساله مرة أخرى. يسمى هذا التبادل بتبادل الإشارات (signaling exchange) وهو خطوة إلزامية قبل إنشاء اتصال نظير إلى نظير.

وفقًا لمواصفات W3C WebRTC، يجب أن يحدث تبادل SDP قبل بدء مرشحي ICE. في الممارسة العملية، ترسل العديد من التطبيقات مرشحي ICE بالتوازي مع SDP باستخدام آلية ICE trickle. هذا يقلل من وقت إنشاء الاتصال، خاصة للشبكات المحمولة ذات زمن الوصول العالي.

دور ICE في SDP

ICE (Interactive Connectivity Establishment) هي آلية تستخدم سمات SDP لنقل معلومات حول مرشحي الشبكة. يصف مرشحو ICE مسارات الاتصال المحتملة: host (العنوان المحلي)، srflx (العنوان بعد NAT، تم الحصول عليه عبر STUN) و relay (عنوان خادم TURN).

في SDP، يتم نقل مرشحي ICE عبر سمات a=candidate:، وكذلك عبر حقلي ice-ufrag و ice-pwd لمصادقة حركة ICE. يتضمن كل مرشح بروتوكول النقل (UDP، TCP) وعنوان IP والمنفذ والأولوية. يتم إنشاء اتصال ناجح عبر أول مرشح يجتاز فحوصات الاتصال. تتيح آلية ICE restart تحديث الاتصال عند تغير الشبكة.

بالنسبة للتطبيقات المحمولة، تعتبر مرشحي ICE مهمة بشكل خاص لأن الأجهزة غالبًا ما تكون خلف NAT أو جدران الحماية المؤسسية. تتيح آلية ICE إيجاد مسار عمل حتى في ظروف الشبكة المعقدة، ويعمل SDP كحاوية نقل لهذه المعلومات.

أمان SDP في WebRTC

SDP في WebRTC يتضمن بالضرورة سمات أمان، ولا سيما بصمة 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. بعد إنشاء Offer عبر createOffer() وتعيينه كوصف محلي، يدخل الاتصال في حالة have-local-offer. بعد استلام Answer وتعيينه كوصف بعيد عبر setRemoteDescription()، يدخل الاتصال في حالة stable — الحالة النهائية الجاهزة لنقل الوسائط.

استخدام SDP في حزم SDK المحمولة

حزم SDK المحمولة لـ WebRTC — Google WebRTC لنظام Android و WebRTC.framework لنظام iOS — تدعم بالكامل تبادل SDP عبر Offer و Answer. على Android، يتم استخدام فئة PeerConnection مع طريقة createOffer()، المشابهة لواجهة برمجة تطبيقات المتصفح. يتم نقل وصف SDP الناتج كسلسلة عبر قناة الإشارات.

على iOS، يتم العمل مع SDP من خلال فئة RTCSessionDescription من إطار WebRTC. عند التهيئة، يتم تحديد النوع (RTCSdpTypeOffer أو RTCSdpTypeAnswer) وسلسلة SDP. تقوم المنصة تلقائيًا بتحليل SDP وتكوين الاتصال وفقًا للمعلمات المنقولة.

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

// إنشاء عرض SDP على Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // أرسل سلسلة SDP إلى النظير البعيد
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

إمكانية العمل مباشرة مع سلسلة SDP تمنح المطورين مرونة: يمكنهم تعديل SDP قبل الإرسال، بإضافة أو إزالة ترميزات محددة، أو تكوين معلمات ICE، أو إضافة سمات مخصصة. لتطبيقات Android، غالبًا ما يكون من الضروري تعطيل الفيديو في SDP عندما يكون عرض النطاق الترددي للشبكة منخفضًا — يتم ذلك عن طريق إزالة أسطر m= المقابلة من وصف SDP.

SDP في تطوير التطبيقات المحمولة

في تطوير التطبيقات المحمولة، يُستخدم SDP بشكل أساسي في سياق WebRTC — لإنشاء تطبيقات مع مكالمات الفيديو والدردشات الصوتية والبث المباشر. يمكن للتطبيقات المحمولة على Android و iOS أن تعمل كبادئ وكمستقبل لرسائل SDP، مما يتيح اتصالات نظير إلى نظير متماثلة.

ميزة التطبيقات المحمولة هي الحاجة إلى العمل مع SDP في ظروف جودة شبكة متغيرة. عند التبديل بين Wi-Fi والإنترنت المحمول، وكذلك عند تغير عرض النطاق الترددي، قد يكون من الضروري إنشاء وصف SDP جديد. يتم ذلك باستخدام آلية إعادة التفاوض — تبادل SDP متكرر عبر createOffer() و setLocalDescription().

وفقًا لفريق Google WebRTC (2023)، يتضمن تحسين تبادل SDP للأجهزة المحمولة استخدام ICE restart عند تغير الشبكة، وأولوية الترميزات منخفضة معدل البت (opus للصوت، VP8 للفيديو) وتقليل حجم سلسلة SDP عن طريق استبعاد تدفقات الوسائط غير الضرورية. الميزة الرئيسية هي تقليل زمن الوصول عند إنشاء اتصال في ظروف الشبكات المحمولة.

تحسين SDP للشبكات المحمولة

إحدى المهام الرئيسية عند العمل مع SDP على الأجهزة المحمولة هي تقليل حجم وصف SDP. يمكن أن يستهلك SDP الكامل لجلسة WebRTC نموذجية مع الصوت والفيديو 2–5 كيلوبايت، وهو حجم كبير للشبكات البطيئة. يشمل التحسين استخدام BUNDLE (دمج التدفقات)، وإزالة الترميزات غير المدعومة، وضغط مرشحي ICE.

مشكلة إضافية للأجهزة المحمولة هي العمر المحدود لـ SDP. في ظروف الاتصال غير المستقرة، قد يصبح SDP قديمًا قبل أن يتمكن المشارك البعيد من معالجته. الحل هو استخدام مهلات زمنية قصيرة لاستلام Answer وإعادة إرسال SDP عند الضرورة. تتيح آلية ICE restart تحديث الاتصال دون إعادة إنشاء RTCPeerConnection بالكامل. السمة a=ice-lite تبسط تنفيذ ICE على جانب الخادم.

المكتبات الشائعة للعمل مع SDP

مطورو التطبيقات المحمولة لديهم إمكانية الوصول إلى مكتبات جاهزة تبسط العمل مع SDP. libjingle_peerconnection (Google WebRTC) هي المكتبة الرئيسية لنظام Android، وتوفر واجهة برمجة تطبيقات كاملة لإدارة SDP. لنظام iOS، يُستخدم WebRTC.framework بوظائف مماثلة. تقوم كلتا المكتبتين تلقائيًا بإنشاء وتحليل SDP، ولكن توفران الوصول إلى سلسلة SDP الخام عند الحاجة.

للتحكم الدقيق في SDP، توجد حلول طرف ثالث: sdp-transform (JavaScript أو Node.js) لتحليل وتعديل SDP، و NICENICE (Java) للعمل مع مرشحي ICE، وحزم SDK جاهزة من موفري البنية التحتية لـ WebRTC التي تتولى جميع تبادلات الإشارات، بما في ذلك SDP.