دو سامانه ممکن است هر دو SIP داشته باشند، اما هنوز دربارهٔ قالبِ رسانه توافق نکرده باشند. SDP توضیحِ جلسه را حمل می‌کند و مدلِ offer/answer مشخص می‌کند دو سمت چگونه دربارهٔ جریان‌ها مذاکره کنند. برایِ عیب‌یابیِ اولیه، فهرستِ قالب‌ها، نگاشتِ payload، ساعت و کانال را کنارِ هم بگذارید؛ وجودِ یک نامِ مشابه کافی نیست.
نمونه را از سامانهٔ واقعی جدا نگه داریم
فایلِ تمرین یک SDPِ ساخته‌شده با نشانیِ مستنداتیِ۱۹۲٫۰٫۲٫۱۰ دارد؛ هیچ اتصال یا تماس از آن برقرار نمی‌شود. خطِ m سه payloadِ۰،۸ و۱۰۱ را فهرست می‌کند و rtpmapهایِ صریح به‌ترتیب PCMU/8000،PCMA/8000 وtelephone-event/8000 را می‌دهند. عددِ payload بدونِ نگاشت و زمینهٔ قرارداد، معنیِ کاملِ رسانه نیست.
بازرسِ ما فقط یک خطِ رسانهٔ audio با RTP/AVP و نگاشتِ صریح را می‌پذیرد. برایِ ساده‌شدنِ تمرین حتی برایِ قالب‌هایِ ایستا rtpmap می‌خواهد؛ این سخت‌گیریِ خودِ نمونه است، نه ادعایِ نامعتبر بودنِ همهٔ SDPهایِ بدونِ آن. parserِ جامعِ استاندارد و همهٔ ویژگی‌هایِ سرور پیاده نشده‌اند.
یک کلیدِ تطبیقِ پایه بسازیم
در کد، هر قابلیتِ فرضیِ سمتِ دوم سه‌تاییِ نامِ قالب، ساعت و تعدادِ کانال است. نام به حروفِ کوچک تبدیل می‌شود و کانالِ حذف‌شده در rtpmapِ این مثال یک در نظر گرفته می‌شود. شمارهٔ payloadهایِ خودِ offer برایِ گزارش حفظ می‌شوند؛ این سه‌تایی، پایانِ بررسیِ سازگاری نیست.
تنظیم‌هایِ fmtp، جهتِ جریان، امنیتِ رسانه، ظرفیتِ تبدیل و مسیرِ شبکه اینجا بررسی نشده‌اند. ممکن است تطبیقِ پایه داشته باشیم ولی شرایطِ دیگر نپذیرد. پس خروجی عمداً full_compatibility_proven ندارد و یک چکِ اولیه را «تماسِ صوتیِ برقرار» معرفی نمی‌کنیم.
پنج حالتِ واقعاً اجراشده چه نتیجه‌ای داشتند؟
سمتِ دوم در هر حالت یک قابلیتِ ساختگی دارد. تطبیقِ کاملِ سه‌تاییِ PCMU/8000/1 به payloadِ۰ می‌رسد؛ همان نام با ساعت۱۶۰۰۰ یا دو کانال تطبیق نمی‌یابد. PCMA/8000/1 به۸ می‌رسد. فقط داشتنِ telephone-event به معنیِ داشتنِ قالبِ مشترکِ گفتار نیست.
| قابلیتِ فرضیِ سمتِ دوم | قالبِ پایهٔ گفتارِ مشترک در تمرین |
|---|---|
| PCMU/8000/1 | ۰ |
| PCMU/16000/1 | خالی |
| PCMU/8000/2 | خالی |
| telephone-event/8000/1 | خالی؛ این رویدادِ کلید است |
| PCMA/8000/1 | ۸ |
ردِ جریان را با حذفِ خط اشتباه نگیریم
در قطعهٔ آموزشیِ نتیجه، اگر قالبِ پایه نداریم، port را صفر می‌گذاریم و یک قالب از offer را نگه می‌داریم. این فقط خطِ mِ نمونه است، نه answerِ کامل و نه پاسخِ SIP. مرجعِ offer/answer برایِ ردِ جریان، خطِ متناظر با portِ صفر را توضیح می‌دهد؛ مقاله کدِ وضعیتِ سرورِ شما را از این محاسبه تعیین نمی‌کند.
در حالتِ تطبیق، شمارهٔ portِ۴۹۱۷۲ هم صرفاً عددِ ساختگیِ متن است؛ بازبودنِ درگاه یا مجازبودنِ مسیر را ثابت نمی‌کند. این فایل را به‌جایِ پیکربندیِ آمادهٔ سانترال کپی نکنید. گزارش برایِ دیدنِ فرقِ فهرستِ قالب و شاهدِ ارتباط است.
خطاهایِ قراردادِ کوچک را روشن گزارش کنیم
حذفِ rtpmapِ لازم برایِ زیرمجموعه، افزودنِ خطِ رسانهٔ دوم و تکرارِ payload سه ورودیِ منفیِ واقعاً آزموده‌شده‌اند. ردِ خطِ دوم می‌گوید این بازرس چندرسانه‌ای نیست؛ اصلِ داشتنِ صوت و تصویر در یک SDP را غلط نمی‌نامد. معنایِ خطایِ ابزار باید از اعتبارِ کلِ استاندارد جدا بماند.
برایِ بررسیِ واقعی، offer وanswerِ همان نوبت، نسخهٔ دو سمت و قراردادهایِ قالب را در مسیرِ مجاز به مسئولِ فنی بدهید. هر شماره، نشانی و اطلاعاتِ خصوصیِ لاگ را پیش از ارائهٔ عمومی پوشش دهید. نبودِ اشتراک می‌تواند نیازمندِ تنظیمِ مجاز یا سازگارکننده باشد؛ این تمرین خرید یا تغییرِ خودکار را تجویز نمی‌کند.
بعد از اشتراکِ قالب هنوز چه چیزی مانده است؟
نقشهٔ خط و سانترال محلِ مسئولیت را روشن می‌کند و تفکیکِ سیگنالینگ و رسانه یادآوری می‌کند پیامِ موفق با صدایِ دوطرفه یکی نیست. برایِ درخواستِ منشیِ تلفنیِ اپرا، سامانهٔ فعلی و نوعِ نیاز را مطرح کنید؛ این مثال پشتیبانیِ همهٔ کدک‌ها یا اتصالِ فوری را وعده نمی‌دهد.
فایل تمرین و منبع
زیرمجموعهٔ SDP و پنج تطبیقِ نام/ساعت/کانال را اجرا کنید · متنِ offerِ ساختگی، قابلیت‌هایِ فرضی و قطعهٔ mِ نتیجه
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.