SDP مخفف Session Description Protocol یا «پروتکل توصیف جلسه» است. برخلاف چیزی که ممکن است از نام آن برداشت شود، SDP خودش مسئول برقراری یا انتقال تماس نیست؛ بلکه یک قالب استاندارد برای توصیف ویژگیهای یک جلسه چندرسانهای به شمار میرود. به زبان ساده، SDP اطلاعاتی را در اختیار دو طرف ارتباط قرار میدهد که برای برقراری جریان صوتی یا تصویری به آن نیاز دارند.
SDP دقیقاً چه اطلاعاتی را توصیف میکند؟
مثلا در یک تماس VoIP، باید مشخص شود چه نوع رسانهای قرار است منتقل شود، این رسانه از چه پروتکل انتقالی استفاده میکند، در چه آدرس IP و پورتی باید دریافت شود و چه فرمتهایی برای آن قابل استفاده است.
SDP این اطلاعات را به شکل متنی و ساختاریافته منتقل میکند. بنابراین وقتی درباره کدک VoIP صحبت میکنیم، SDP یکی از جاهایی است که قابلیتها و پارامترهای مربوط به آن در جریان مذاکره تماس مشخص میشود.
نکته مهم این است که SDP خودش صدا را منتقل نمیکند. در یک تماس معمول SIP، SIP وظیفه سیگنالینگ و کنترل برقراری جلسه را بر عهده دارد، SDP مشخصات رسانه را توصیف و در مدل Offer/Answer برای توافق پارامترها استفاده میشود و انتقال واقعی صدای تماس معمولاً از طریق RTP انجام میگیرد. این تفکیک وظایف یکی از مهمترین نکاتی است که برای عیبیابی تماسهای VoIP باید بهخوبی درک شود.
دستهبندی اطلاعات موجود در SDP
برای اینکه نقش SDP ملموستر شود، میتوان اطلاعات آن را به چند دسته اصلی تقسیم کرد:
اطلاعات | کاربرد در تماس VoIP |
|---|---|
نوع رسانه | مشخص میکند جریان مربوط به صوت، تصویر یا نوع دیگری از رسانه است |
آدرس IP | آدرسی را مشخص میکند که رسانه باید به آن ارسال یا از آن دریافت شود |
شماره پورت | محل ارسال یا دریافت جریان رسانه روی شبکه را مشخص میکند |
پروتکل انتقال | مشخص میکند رسانه با چه پروتکلی منتقل میشود؛ در تماسهای VoIP معمولاً RTP مطرح است |
فرمتهای رسانه | قابلیتهای قابل استفاده، از جمله Payload Type و نگاشت کدکها را معرفی میکند |
ویژگیهای رسانه | پارامترهایی مثل جهت ارسال/دریافت یا برخی تنظیمات اختصاصی رسانه را مشخص میکند |
در عمل، همین اطلاعات است که به دو Endpoint یا نقطه پایانی تماس کمک میکند یک «زبان مشترک» برای انتقال رسانه پیدا کنند. به همین دلیل، بررسی SDP هنگام تحلیل تماسهای ناموفق یا تماسهایی که با مشکل صدا مواجهاند، اهمیت زیادی دارد.
پروتکل SDP چطور در SIP کار میکند؟
برای فهم ارتباط SDP و SIP، بهتر است یک تماس ساده را از لحظه شروع دنبال کنیم. فرض کنید کاربر A با یک تلفن تحت شبکه با کاربر B تماس میگیرد. ابتدا SIP وظیفه دارد پیامهای لازم برای راهاندازی جلسه را جابهجا کند. یکی از این پیامها میتواند یک INVITE باشد. پیامی که از طرف تماسگیرنده برای آغاز جلسه ارسال میشود.
اگر SDP داخل این پیام قرار گرفته باشد، تماسگیرنده در واقع علاوه بر درخواست برقراری تماس، پیشنهاد خود درباره پارامترهای رسانه را هم ارسال کرده است.
یک مثال ساده بزنیم...
برای مثال، یک بخش سادهشده از SDP ممکن است چیزی شبیه این باشد:
v=0
o=user1 12345 12345 IN IP4 192.168.1.10
s=VoIP Call
c=IN IP4 192.168.1.10
t=0 0
m=audio 49170 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
لازم نیست در این مرحله تمام خطوط را حفظ کنید. نکته اصلی این است که در این چند خط، اطلاعاتی درباره نوع رسانه، آدرس، پورت، فرمتهای قابل استفاده و ویژگی جریان صوتی وجود دارد.
طرف مقابل این پیشنهاد را بررسی میکند و پاسخ خود را در قالب SDP ارائه میدهد. این همان چیزی است که در مدل Offer/Answer اتفاق میافتد: یک طرف پیشنهادی برای جلسه ارائه میکند و طرف دیگر پاسخ میدهد که کدام بخش از آن پیشنهاد را میتواند بپذیرد.
این فرایند ممکن است در پیامهای مختلف SIP اتفاق بیفتد و محل قرار گرفتن SDP به سناریوی تماس و نحوه پیادهسازی بستگی دارد.
در نتیجه، میتوان رابطه این سه جزء را خیلی ساده اینطور دید:
SIP: جلسه را راهاندازی و کنترل میکند.
SDP: مشخصات رسانه و پارامترهای مورد توافق را توصیف میکند.
RTP: رسانه، مثل صدای تماس، را منتقل میکند.
ساختار پیام SDP را چگونه بخوانیم؟
یکی از بهترین راهها برای فهمیدن SDP این است که بهجای حفظ کردن تعریفها، یک نمونه واقعی را باز کنیم و ببینیم هر خط دقیقاً چه چیزی را به طرف مقابل میگوید.
ساختار SDP عمدا ساده و متنی طراحی شده و هر خط با یک حرف مشخص شروع میشود. طبق استاندارد RFC 8866، یک Session Description از بخش اطلاعات کلی جلسه شروع میشود و سپس میتواند شامل یک یا چند بخش توصیف رسانه باشد. هر بخش مدیا نیز با خط m= آغاز میشود.
برای مثال، فرض کنید در جریان یک تماس SIP با چنین بخشی از SDP مواجه شدهایم:
v=0
o=- 37476321 37476321 IN IP4 192.168.1.20
s=VoIP Call
c=IN IP4 192.168.1.20
t=0 0
m=audio 40000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
در نگاه اول شاید این متن شبیه مجموعهای از کدهای نامفهوم باشد؛ اما اگر هر خط را جداگانه بررسی کنیم، دقیقاً میبینیم که چه اطلاعاتی در حال مذاکره است.
v= همان نسخه SDP است...
خط v=0 نسخه پروتکل SDP را مشخص میکند. در استاندارد فعلی SDP، مقدار تعریفشده برای این خط 0 است. بنابراین دیدن v=0 در ابتدای SDP کاملاً طبیعی است و به معنی نسخه صفر SDP است، نه نسخه یک یا دو.
o= همان اطلاعات ایجادکننده و شناسه جلسه است...
خط o= یا Origin اطلاعاتی درباره ایجادکننده توصیف جلسه و شناسه آن در اختیار گیرنده قرار میدهد. این خط شامل چند بخش است که برای شناسایی نسخه و هویت توصیف جلسه استفاده میشوند.
s= همان نام جلسه است...
خط s= نام جلسه را مشخص میکند. در تماسهای VoIP معمولاً اطلاعات زیادی از این قسمت به دست نمیآید و ممکن است مقدار سادهای مثل s=VoIP Call یا حتی s=- دیده شود.
c= به معنی آدرس اتصال است...
خط c= یکی از مهمترین بخشهای SDP برای عیبیابی تماس است:
c=IN IP4 192.168.1.20
این خط نوع شبکه، نوع آدرس و آدرس اتصال را مشخص میکند. در یک سناریوی IP، معمولاً با IN IP4 یا IN IP6 مواجه میشویم. طبق استاندارد، c= میتواند در سطح Session قرار بگیرد و برای Media Descriptionها اعمال شود، مگر اینکه در سطح همان رسانه مقدار دیگری تعیین شده باشد.
به زبان ساده، وقتی در یک SDP به دنبال این هستید که «رسانه قرار است به کجا فرستاده شود؟»، یکی از اولین جاهایی که باید بررسی کنید همین c= است.
t= یعنی زمان جلسه...
در خیلی از سناریوهای SIP، این خط را به شکل زیر میبینید:
t=0 0
این خط محدوده زمانی جلسه را توصیف میکند. در کاربردهای معمول تماس VoIP، دوصفر کنار هم بهعنوان مقدار رایج برای جلسهای استفاده میشود که زمان شروع و پایان مشخصی در این قالب ندارد. بنابراین نباید از دیدن آن در SDP تماسهای SIP تعجب کنید.
m= همان مهمترین خط برای توصیف رسانه است...
حالا به خطی میرسیم که برای عیبیابی تماس اهمیت بسیار زیادی دارد:
m=audio 40000 RTP/AVP 0 8 101
ساختار کلی آن به شکل زیر است:
m=<media> <port> <protocol> <format>
در مثال ما:
audio یعنی رسانه موردنظر صوت است.
40000 شماره پورتی است که برای این Media Description اعلام شده است.
RTP/AVP پروفایل انتقال رسانه را مشخص میکند.
اعداد 0، 8 و 101 شناسههای Payload Type هستند که برای قالبهای رسانه استفاده میشوند.
این قسمت خیلی مهم است، چون ممکن است یک تماس از نظر SIP کاملاً برقرار شود اما رسانه به پورت یا آدرسی ارسال شود که از سمت دیگر قابل دسترسی نیست. در چنین شرایطی، «تماس برقرار شده» لزوماً به معنی «صدای تماس برقرار است» نیست.
a= جایی که جزئیات مهمتر ظاهر میشوند...
خطوط a= Attributeهای SDP هستند و اطلاعات تکمیلی مربوط به Session یا Media را مشخص میکنند. SDP از Attributeها برای افزودن ویژگیها و پارامترهای مختلف استفاده میکند.
برای مثال:
a=rtpmap:0 PCMU/8000
مشخص میکند Payload Type شماره 0 به چه نوع Encoding یا کدکی نگاشت شده است. به همین ترتیب:
a=rtpmap:8 PCMA/8000
نوع دیگری از Codec را معرفی میکند. همچنین:
a=sendrecv
جهت جریان رسانه را مشخص میکند؛ یعنی رسانه هم برای ارسال و هم دریافت در نظر گرفته شده است. اگر این Attribute وجود نداشته باشد، در حالت معمول sendrecv بهعنوان حالت پیشفرض در نظر گرفته میشود.
در واقع اگر یک تکنسین VoIP بخواهد یک SDP را سریع بررسی کند، معمولاً باید بیش از هر چیز به ارتباط میان c=، m= و Attributeهای رسانه توجه کند. همین چند خط میتوانند سرنخ مهمی درباره علت یک مشکل صوتی در اختیار او بگذارند.
Codec در SDP؛ دو طرف با چه فرمتی صحبت کنند؟
Codec یا Codec/Encoder-Decoder روشی برای کدگذاری و بازسازی دادههای صوتی است. در VoIP، Codec تعیین میکند صدای خام چگونه به داده قابل انتقال روی شبکه تبدیل شود و در سمت گیرنده چگونه دوباره به صدا تبدیل شود.
در SDP، Codecها معمولاً از طریق Payload Typeها و Attributeهایی مانند a=rtpmap معرفی میشوند. برای مثال، یک Endpoint ممکن است چند Codec را در Offer خود اعلام کند و Endpoint مقابل بر اساس قابلیتهای خودش، یکی یا چند مورد قابل استفاده را در Answer بپذیرد.
به همین دلیل، اگر دو سمت هیچ Codec مشترکی نداشته باشند، مذاکره رسانه نمیتواند برای یک جریان صوتی قابل استفاده به نتیجه برسد. در مستندات PJSIP نیز یکی از خطاهای مشخص مذاکره SDP، نبودن Codec مناسب برای Offer طرف مقابل است.
RTP چه ارتباطی با SDP دارد؟
RTP یا Real-time Transport Protocol پروتکلی است که برای انتقال دادههای بلادرنگ، مانند صوت و تصویر، استفاده میشود. SDP وظیفه انتقال این صدا را ندارد؛ بلکه اطلاعات لازم برای برقراری Media Session را توصیف میکند تا دو طرف بدانند چگونه باید جریان RTP را برقرار کنند.
بنابراین اگر بخواهیم مسیر را ساده کنیم:
SIP: مذاکره و کنترل Session
SDP: توصیف پارامترهای Media و مذاکره آنها
RTP: انتقال Media
فرض کنید یک سیستم تلفنی سازمانی با یک سرویس SIP Trunk تماس میگیرد. در پیام SIP، SDP مشخص میکند سیستم چه Codecهایی را پیشنهاد میدهد و Media را روی چه IP و Portی انتظار دارد. سمت مقابل نیز SDP خود را ارائه میکند. پس از توافق، جریان صوتی RTP بر اساس پارامترهای نهایی شکل میگیرد.
در نتیجه، وقتی یک شرکت از سرویسهایی مانند تلفن اینترنتی VoIP تلفنچی استفاده میکند، تجربهای که کاربر در ظاهر فقط به شکل «تماس گرفتن» میبیند، در لایه شبکه شامل چند مرحله جداگانه برای Signaling، Negotiation و Media Transport است.
جمعبندی
اگر بخواهیم تمام بحث را در یک تصویر ذهنی ساده خلاصه کنیم، SIP مسئول این است که دو طرف را برای برقراری یک Session هماهنگ کند، SDP مشخص میکند این Session از نظر رسانهای چه مشخصاتی دارد و RTP داده صوتی یا تصویری را منتقل میکند.
اهمیت SDP زمانی بیشتر مشخص میشود که یک تماس در ظاهر برقرار است اما مشکلی در صدا وجود دارد. در چنین شرایطی بررسی خطوط کدهایی که بالاتر توضیح دادیم، برای عیبیابی اهمیت زیادی خواهد داشت.
اگر با زیرساختهایی مثل SIP Trunk، PJSIP یا تلفن اینترنتی VoIP سروکار دارید، شناخت SDP به شما کمک میکند بفهمید در پشت یک تماس ساده، دقیقاً چه اطلاعاتی میان دو سیستم ردوبدل میشود و هنگام بروز مشکل باید از کجا شروع به بررسی کنید.
نظرات و تجربههای شما
هنوز دیدگاهی ثبت نشده است؛ اولین دیدگاه را شما بنویسید.