RTSPکنترلِ جلسهٔ تحویلِ رسانه را انجام می‌دهد؛RTPمی‌تواند حاملِ بسته‌های رسانه باشد وHTTPهم می‌تواند بایتِ فایل را تحویل دهد. این سه اسم،سه مرحلهٔ قابل‌جایگزینِ یک کار نیستند. برای عیب‌یابی،شاهدِ فرمانِ پخش را از شاهدِ رسیدنِ داده و رمزگشاییِ صوت جدا کنید. تمرینِ این صفحه یک مدلِ محلیِ محدود ازRTSP۲٫۰است؛هیچ سرور یا استریمِ واقعی اجرا نمی‌شود.
اول SETUP،سپس PLAY
در مدلِ اصیل،وضعیتِ آغازInitاست و جلسه‌ای نداریم. SETUPموفق،یکSessionآموزشی وTransportمنتخب می‌سازد و وضعیتReadyمی‌شود. درRFC7826،SETUPبرای تعیینِ حملِ رسانه و ایجادِ جلسه یا تغییرِ پارامترها تعریف شده؛تمرینِ ما فقط ایجادِ اولیهٔ یک جلسهٔ تک‌رسانه‌ای را اجرا می‌کند.
PLAYباید به همانSessionاشاره کند تا مدل واردPlayشود. درخواستِ پیش ازSETUPیاباSessionاشتباه رد می‌شود و حالتِ قبلی ثابت می‌ماند. این کد پیامِ روی سیم راparseنمی‌کند؛فیلدها از قبل به‌شکلِ عادی‌شده به تابع داده می‌شوند. احرازِ هویت،timeout،تغییرِTransportوسطِ پخش و جلسهٔ چندرسانه‌ای بیرونِ دامنه‌اند.
پاسخِ موفق هنوز دادهٔ دریافت‌شده نیست
بلافاصله پس ازPLAYموفق،شمارِ رکوردهای رسانه در تمرین صفر است. سپس نویسنده دو مشاهدهٔ مستقلِ ساختگی باsequenceهای۱۰۰و۱۰۱وtimestampهای۸۰۰۰۰و۸۰۱۶۰اضافه می‌کند. این‌ها بستهٔ شنودشده نیستند؛رکوردهای اصیلِ تمرین‌اند تا دو نوعِ شاهد از هم جدا بمانند.
| شاهد | چه چیزی ثبت می‌کند؟ | چه چیزی ثابت نمی‌کند؟ |
|---|---|---|
| SETUPموفق | Sessionوحملِ منتخب | رسیدنِ صوت |
| PLAYموفق | پذیرشِ شروعِ تحویل درمدل | رمزگشایی یا شنیده‌شدن |
| رکوردِ رسانه | دادهٔ مشاهده‌شدهٔ جدا | کیفیتِ قابل‌قبولِ مکالمه |
PAUSE با پایانِ جلسه یکی نیست
در مسیرِ آموزشی،PAUSEازPlayبهReadyبرمی‌گردد وSessionرا نگه می‌دارد؛PLAYبعدی دوباره فعال می‌شود. TEARDOWNباSessionدرست،جلسه را از بین می‌برد و بهInitمی‌رود. پس از آن،PLAYبا شناسهٔ قدیمی پذیرفته نمی‌شود. درخواستِTEARDOWNبا شناسهٔ اشتباه نیز هیچ تغییری نمی‌دهد.
دفترِ خروجی ده رویدادِ کنترل دارد و وضعیت و شمارِ رسانهٔ هر گام را ثبت می‌کند. تابعِ افزودنِ مشاهده در حالتِPauseرد می‌شود؛این سیاستِ همین مدل است،نه ادعایِ نبودِ بستهٔ درراه در شبکهٔ واقعی. رکوردهای قبلی برای مشاهدهٔ تاریخچه حفظ می‌شوند؛باقی‌بودنِ تاریخچه به معنیِ بازماندنِ جلسه نیست.
سه واحد را مخلوط نکنیم
npt=10-12 درRTSPبه بازهٔ زمانِ رسانه مربوط است. bytes=10-12 درHTTPسه بایتِ شاملِ دو انتها را می‌خواهد. timestampِRTPهم شمارندهٔ ساعتِ همان جریان است. شباهتِ عددِ۱۰در این سه عبارت،رابطهٔ مستقیمِ ثانیه و بایت و تیک نمی‌سازد.
برای توضیحِ دو رکوردِ ساختگی،ساعت را صریحاً۸۰۰۰تیک درثانیه فرض کرده‌ایم؛اختلاف۱۶۰تیک برابر۰٫۰۲ثانیهٔ رسانه است. این عدد تأخیرِ شبکه یا ساعتِ واقعی نیست. واحدِ timestampاز قراردادِpayloadمی‌آید؛از اندازهٔ۱۶۰بایتیِ داده نمی‌توان نرخِ ساعت را برای هر کدک حدس زد.
RTP را مساوی UDP نگیریم
منبعِRTP،استفادهٔ رایج ازUDPو امکانِ حمل روی زیرساخت‌های مناسبِ دیگر را توضیح می‌دهد. درمدل،Transportِمنتخب عمداًRTP/AVP/TCPاست تا فرقِ قراردادِ رسانه و حمل دیده شود؛درخواستِ حملِ خارج از دو گزینهٔ محلی رد می‌شود. نه همهٔ رسانه‌ها الزاماًRTPهستند و نه اسمِRTSPتضمین می‌کند مسیرِ شبکه باز است.
نسخهٔ اجراPython۳٫۱۲٫۱۴است؛کد کتابخانهٔ شبکه،دوربین،فایلِ خصوصی یاdecoderندارد. خروجی صرفاً رفتارِ مدلِ تعریف‌شده را تأیید می‌کند. برای منبعِ واقعی،نسخهٔ پروتکل،روشِ راه‌اندازی،Session،حملِ منتخب و نقطهٔ مشاهدهٔ رسانه را از قراردادِ همان سامانه بگیرید.
گامِ بعدیِ عیب‌یابی
راهنمایHTTP Range پاسخِ بایتی را بررسی می‌کند؛نگاشتِ ساعتِRTP واحدِ زمان را باز می‌کند و متنِ موقت و نهاییِ گفتار مرحلهٔ نتیجهٔ تشخیص را توضیح می‌دهد. دریافتِ رسانه با نهایی‌شدنِ متن یکی نیست.
اگر برای اپرانگار ورودیِ زنده می‌خواهید،نوعِ منبع و نیازِ تحویل را هنگامِ درخواست مطرح کنید. این نوشته پشتیبانیِRTSPیاAPIاستریم در محصول را تأیید نمی‌کند؛نمونهٔ مجاز و قراردادِ واقعی باید جدا بررسی شوند.
فایل تمرین و منبع
کدِ کاملِ محلیِ تمرین و کنترل‌هایش · دادهٔ اصیل و نتیجهٔ اجرای واقعی؛ نویسه‌های کنترلی escape شده‌اند
- RFC7826،دسامبر۲۰۱۶؛بخش‌های۴٫۴٫۲،۱۳٫۳،۱۳٫۴٫۱،۱۳٫۶و۱۳٫۷٫۱؛مدل محدود است،نه پیاده‌سازی کامل
- RFC3550،ژوئیه۲۰۰۳؛مقدمه و فیلدهای۵٫۱ برای نقشِRTP،حمل وtimestamp؛بخش‌های مرتبط خوانده شدند
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.