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 منتشر شد. این پروتکل در ابتدا برای اعلام جلسات multicast در چارچوب Mbone (Multicast Backbone) ایجاد شد. با توسعه VoIP و کنفرانس‌های ویدئویی، دامنه کاربرد SDP گسترش یافت و در سال 2006 مشخصات به‌روز شده RFC 4566 منتشر شد.

پیشرفت واقعی در استفاده از SDP با ظهور WebRTC در سال 2011 رخ داد. گوگل SDP را به عنوان مکانیسم اصلی توصیف جلسات رسانه در چارچوب خود برای ارتباط بلادرنگ مرورگر یکپارچه کرد. از آن زمان، SDP به یک مؤلفه اجباری هر پیاده‌سازی WebRTC تبدیل شده است — از مرورگرها گرفته تا برنامه‌های موبایل در iOS و Android.

در سال 2021، گروه کاری IETF مشخصات فعلی SDP یعنی RFC 8866 را منتشر کرد که جایگزین 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 یا پروتکل دیگر پیاده‌سازی می‌کند، حل می‌شود.

فرآیند با ایجاد پیشنهاد SDP — Offer توسط آغازگر (تماس‌گیرنده) شروع می‌شود. برای این کار، مرورگر متد createOffer() را روی شی RTCPeerConnection فراخوانی می‌کند. توصیف SDP تولید شده شامل تمام پارامترهای جلسه از طرف آغازگر است: کدک‌های پشتیبانی شده، آدرس‌های شبکه، کاندیداهای ICE و الزامات امنیتی.

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

// ایجاد پیشنهاد SDP در Android
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);

// Send SDP to remote peer via signaling channel
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 (fingerprint) و پارامترهای 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 برای ایجاد Offer از کلاس PeerConnection با متد createOffer() مشابه API مرورگر استفاده می‌شود. توصیف 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) { }
})

// Create SDP Offer on Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Send SDP string to remote peer
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

امکان کار مستقیم با رشته SDP به توسعه‌دهندگان انعطاف‌پذیری می‌دهد: می‌توان SDP را قبل از ارسال تغییر داد، کدک‌های خاصی را اضافه یا حذف کرد، پارامترهای ICE را پیکربندی کرد یا ویژگی‌های سفارشی اضافه کرد. برای برنامه‌های Android اغلب نیاز است که ویدیو در SDP هنگام پهنای باند پایین شبکه غیرفعال شود — این کار با حذف خطوط m= مربوطه از توصیف SDP انجام می‌شود.

SDP در توسعه موبایل

در توسعه موبایل، SDP عمدتاً در زمینه WebRTC استفاده می‌شود — برای ایجاد برنامه‌های تماس ویدیویی، چت‌های صوتی و استریمینگ. برنامه‌های موبایل در Android و iOS می‌توانند هم در نقش آغازگر و هم در نقش گیرنده پیام‌های SDP عمل کنند که امکان ایجاد اتصالات همتا به همتای متقارن را فراهم می‌کند.

ویژگی برنامه‌های موبایل نیاز به کار با SDP در شرایط کیفیت متغیر شبکه است. هنگام جابجایی بین Wi-Fi و اینترنت موبایل، و همچنین هنگام تغییر پهنای باند، ممکن است نیاز به تولید یک توصیف SDP جدید باشد. برای این کار از مکانیسم renegotiation — تبادل مجدد 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 که یک API کامل برای مدیریت SDP فراهم می‌کند. برای iOS از WebRTC.framework با عملکرد مشابه استفاده می‌شود. هر دو کتابخانه به طور خودکار SDP را تولید و تجزیه می‌کنند، اما در صورت نیاز به رشته خام SDP دسترسی می‌دهند.

برای کنترل دقیق‌تر روی SDP، راه‌حل‌های شخص ثالثی وجود دارند: sdp-transform (JavaScript یا Node.js) برای تجزیه و تغییر SDP، NICENICE (Java) برای کار با کاندیداهای ICE و SDKهای آماده از ارائه‌دهندگان زیرساخت WebRTC که کل تبادل سیگنالینگ از جمله SDP را بر عهده می‌گیرند.