RTSP پروتکل کنترل پخش است، نه پروتکل انتقال تصویر. کار آن شبیه دکمه های یک ضبط صوت است: شروع، توقف، ادامه. تصویر واقعی را RTP حمل می کند. ONVIF رقیب RTSP نیست؛ لایه ای بالاتر است که به شما می گوید آدرس RTSP دوربین چیست. برای پخش داخل مرورگر، RTSP به تنهایی کافی نیست و باید در سرور به WebRTC یا HLS تبدیل شود؛ اولی برای پایش زنده و دومی برای پخش آرشیو.
اگر تا به حال آدرسی شبیه rtsp://192.168.1.10:554/stream1 در تنظیمات یک دوربین دیده اید، با RTSP سر و کار داشته اید. این پروتکل، زبان مشترک تقریبا همه دوربین های تحت شبکه است و به همین دلیل ستون فقرات هر سامانه چندبرندی است. اما درباره اش سوءتفاهم هایی رایج است که در پروژه های واقعی گران تمام می شوند و بخش بزرگی از این نوشته درباره همان هاست.
RTSP دقیقا چه کار می کند
نخستین نکته ای که باید روشن شود این است: RTSP خودش تصویر را جابه جا نمی کند. نام کامل آن Real Time Streaming Protocol است و کارش کنترل جریان است، نه حمل آن. RTSP به دوربین می گوید چه چیزی داری، این جریان را شروع کن، نگه دار، ادامه بده، تمام. تصویر و صدا از مسیر دیگری می آیند.
مقایسه ساده اش این است: RTSP نقش ریموت کنترل را دارد و RTP نقش کابل تصویر. وقتی دکمه پخش را می زنید، ریموت فرمان می دهد ولی تصویر از کابل می آید. همین جدایی باعث می شود بتوان کنترل را روی یک مسیر قابل اتکا و تصویر را روی مسیری سبک تر و سریع تر فرستاد.
چرخه یک اتصال RTSP
وقتی سرور VMS به یک دوربین وصل می شود، یک گفت وگوی کوتاه و مشخص انجام می گیرد. دانستن این مراحل در عیب یابی به شدت به کار می آید، چون هر مرحله شکست خودش را دارد.
OPTIONS نخستین پرسش است: از چه فرمان هایی پشتیبانی می کنی؟ سپس DESCRIBE می پرسد چه جریان هایی داری و با چه مشخصاتی. پاسخ این مرحله یک توصیف متنی به نام SDP است که کدک، رزولوشن و شماره کانال ها را می گوید. بعد SETUP مسیر انتقال را تعیین می کند و PLAY جریان را راه می اندازد. در پایان TEARDOWN اتصال را می بندد.
در عمل، محل شکست معمولا یکی از این دو است: احراز هویت در همان ابتدا رد می شود، یا مرحله SETUP به دلیل مسدود بودن پورت های انتقال شکست می خورد. تفکیک این دو، نیمی از عیب یابی است.
UDP یا TCP، انتخابی که در پروژه اثر دارد
در مرحله SETUP تصمیم گرفته می شود که تصویر چطور منتقل شود، و این انتخاب پیامد عملی دارد.
در حالت UDP، بسته ها بدون تضمین تحویل فرستاده می شوند. سبک و کم تاخیر است، اما اگر بسته ای گم شود دوباره فرستاده نمی شود و نتیجه اش همان بلوک های خراب یا پرش تصویر است که در شبکه های شلوغ می بینید.
در حالت TCP، بسته ها داخل همان اتصال کنترلی تونل می شوند. تحویل تضمین شده است و از دیوارهای آتش و NAT راحت تر عبور می کند، به قیمت تاخیر کمی بیشتر و سربار بالاتر.
توصیه عملی: در شبکه محلی تمیز و کنترل شده UDP انتخاب خوبی است. در هر مسیری که از یک شبکه ناشناخته، اینترنت یا چند دیوار آتش عبور می کند، TCP را انتخاب کنید. اگر تصویر یک دوربین گاهی بلوک بلوک می شود و بقیه سالم اند، پیش از هر کار دیگری همین تنظیم را روی TCP بگذارید.
ONVIF رقیب RTSP نیست
این پرتکرارترین سوءتفاهم در این حوزه است. ONVIF و RTSP در یک سطح نیستند و کار یکدیگر را انجام نمی دهند.
ONVIF یک استاندارد کشف و مدیریت است. با آن می توان دوربین های روی شبکه را پیدا کرد، مشخصاتشان را خواند، تنظیمات را تغییر داد، PTZ را کنترل کرد و از همه مهم تر آدرس RTSP جریان ها را گرفت. یعنی ONVIF به شما می گوید در RTSP کجا را بزنید.
RTSP پس از آن وارد می شود و همان جریان را باز می کند. به همین دلیل است که یک سامانه چندبرندی معمولا هر دو را با هم به کار می برد: ONVIF برای افزودن خودکار دوربین و خواندن قابلیت هایش، RTSP برای گرفتن تصویر. اگر دوربینی ONVIF نداشته باشد ولی آدرس RTSP آن را بدانید، همچنان می توانید آن را اضافه کنید؛ فقط افزودنش دستی است نه خودکار. مشخصات رسمی این استاندارد در پروفایل های ONVIF منتشر شده است.
مقایسه پروتکل های انتقال تصویر
RTSP یکی از چند پروتکلی است که در یک سامانه نظارت تصویری با آن سر و کار دارید. هر کدام برای کار متفاوتی ساخته شده اند و انتخاب اشتباه، خودش را به شکل تاخیر بالا یا ناسازگاری با مرورگر نشان می دهد.
| پروتکل | نقش | تاخیر معمول | پخش مستقیم در مرورگر | کاربرد اصلی |
|---|---|---|---|---|
| RTSP | کنترل جریان | کم | خیر | گرفتن تصویر از دوربین |
| RTP | حمل تصویر و صدا | کم | خیر | همراه RTSP |
| ONVIF | کشف و مدیریت | ندارد | خیر | افزودن و تنظیم دوربین |
| WebRTC | پخش زنده دوطرفه | زیر یک ثانیه | بله | پایش زنده در مرورگر |
| HLS | پخش قطعه ای | چند ثانیه تا ده ها ثانیه | بله | پخش آرشیو و مقیاس بالا |
| RTMP | ارسال به سرور پخش | چند ثانیه | خیر | پخش زنده اینترنتی، امروز کم کاربرد |
ستون سوم را با احتیاط بخوانید: تاخیر به شبکه، کدک و پیکربندی بستگی دارد و این ستون فقط ترتیب نسبی را نشان می دهد، نه عدد قطعی.
چرا مرورگر RTSP را باز نمی کند
سوالی که تقریبا در هر پروژه ای پیش می آید: چرا نمی توانم آدرس RTSP را مستقیم در مرورگر باز کنم؟ پاسخ کوتاه این است که مرورگرهای امروزی از RTSP پشتیبانی نمی کنند و این تصمیم عمدی است، نه یک کاستی.
در گذشته این کار با افزونه هایی مثل فلش و ActiveX انجام می شد. همان افزونه ها یکی از بزرگ ترین منابع آسیب پذیری امنیتی بودند و امروز از همه مرورگرها حذف شده اند. نتیجه اینکه هر سامانه ای که هنوز برای پخش زنده به نصب افزونه یا کلاینت مجزا نیاز دارد، در واقع هنوز محدودیتی از دوران گذشته را با خود دارد.
راه حل امروزی این است که سرور، جریان RTSP دوربین را بگیرد و آن را به چیزی تبدیل کند که مرورگر می فهمد. برای پایش زنده این یعنی WebRTC، که در همان کلاس تاخیر RTSP کار می کند و بومی مرورگر است. برای پخش آرشیو معمولا HLS مناسب تر است، چون تاخیر آنجا اهمیت ندارد ولی پایداری و قابلیت جست وجو در فایل اهمیت دارد. جزئیات این تبدیل را در موتور پخش زنده توضیح داده ایم.
یک دوربین، یک اتصال
نکته ای که در معماری اهمیت زیادی دارد و در سامانه های ضعیف نادیده گرفته می شود: هر اتصال RTSP یک بار پردازشی و شبکه ای روی دوربین می گذارد، و دوربین ها ظرفیت محدودی برای اتصال همزمان دارند. بسیاری از مدل ها بیش از چند اتصال همزمان را نمی پذیرند.
حالا تصور کنید سامانه ای به ازای هر اپراتوری که تصویر را نگاه می کند، یک اتصال جدید به دوربین باز کند. با پنج اپراتور، دوربین به سقف می رسد و تصویر برای همه خراب می شود. طراحی درست این است که سرور یک بار از دوربین بگیرد و همان جریان را برای ضبط و برای همه بیننده ها پخش کند. این تفاوت در یک سامانه ده دوربینی دیده نمی شود و در یک سامانه پانصد دوربینی، تفاوت میان کار کردن و کار نکردن است.
احراز هویت و جایی که رمز عبور رد و بدل می شود
هر دوربین سازمانی، جریان خود را پشت نام کاربری و رمز نگه می دارد و RTSP دو شیوه برای این کار دارد. تفاوتشان در پروژه واقعی اهمیت دارد.
در روش ساده، اطلاعات ورود با کدگذاری برگشت پذیری فرستاده می شود که رمزنگاری محسوب نمی شود؛ هر کسی که ترافیک را ببیند می تواند آن را بخواند. در روش دوم، به جای خود رمز یک اثر انگشت رمزنگاری شده از آن فرستاده می شود که با یک مقدار تصادفی از سمت دوربین ترکیب شده است. روش دوم به مراتب بهتر است و تقریبا همه دوربین های امروزی پشتیبانی می کنند.
نکته عملی این است که اگر دوربینی فقط روش ساده را می پذیرد، آن دوربین را در یک شبکه بسته نگه دارید و هرگز جریانش را از مسیری که قابل شنود است عبور ندهید. و نکته ای که در عیب یابی وقت زیادی می گیرد: بعضی دوربین ها اگر رمز کاراکتر خاصی داشته باشد، احراز هویت را رد می کنند. اگر همه چیز درست به نظر می رسد ولی اتصال برقرار نمی شود، پیش از هر کاری رمز را به یک رشته ساده تغییر دهید و دوباره امتحان کنید.
جریان اصلی و جریان فرعی
تقریبا همه دوربین های تحت شبکه، همزمان بیش از یک جریان با کیفیت های متفاوت منتشر می کنند. معمولا یک جریان اصلی با بالاترین رزولوشن دارند و یک یا چند جریان فرعی با رزولوشن پایین تر. هر کدام آدرس RTSP خودشان را دارند.
این قابلیت، ابزار مهمی برای مدیریت بار است. یک سامانه درست، برای ضبط از جریان اصلی استفاده می کند تا کیفیت آرشیو حفظ شود، ولی وقتی اپراتور شانزده دوربین را همزمان در یک صفحه می بیند، جریان فرعی را نشان می دهد. دلیلش ساده است: در یک کاشی کوچک روی صفحه نمایش، تفاوت ۴K و ۷۲۰p دیده نمی شود، ولی تفاوت بار پردازشی و شبکه بسیار زیاد است.
وقتی همان اپراتور روی یک دوربین تمام صفحه می رود، سامانه به جریان اصلی سوییچ می کند. این رفتار در سامانه های حرفه ای خودکار است و کاربر متوجهش نمی شود؛ فقط می بیند که اتاق کنترل روان کار می کند. اگر سامانه ای همیشه جریان اصلی را پخش کند، در دیوار ویدیویی چند دوربینه به سرعت به سقف می خورد. انتخاب کدک هر جریان هم روی همین بار اثر مستقیم دارد؛ مقایسه اش در H.264 یا H.265 آمده است.
RTSP از پشت NAT و شبکه های جدا
وقتی دوربین ها در یک شبکه و سرور در شبکه دیگری است، یا وقتی باید از بیرون به سامانه دسترسی داشت، RTSP رفتار خاصی پیدا می کند که باید برایش برنامه داشت.
در حالت UDP، دوربین بسته های تصویر را به آدرس و پورتی می فرستد که در مرحله SETUP توافق شده. اگر بین این دو یک NAT باشد، آن بسته ها معمولا مسیرشان را پیدا نمی کنند و نتیجه این است که اتصال RTSP برقرار می شود ولی هیچ تصویری نمی آید. این دقیقا همان علامتی است که مهندسان شبکه را ساعت ها سرگردان می کند: لاگ می گوید اتصال موفق بود، ولی صفحه سیاه است.
پاسخ در بیشتر موارد، انتقال روی TCP است. چون بسته های تصویر داخل همان اتصالی می آیند که از ابتدا برقرار شده، هیچ مسیر جدیدی لازم نیست باز شود. توصیه معماری این است که اصلا کار را به اینجا نکشانید: دوربین ها را در شبکه بسته نگه دارید، سرور را در همان شبکه بگذارید، و دسترسی بیرونی را فقط به خود سامانه بدهید نه به دوربین ها. این همان الگویی است که در معماری یک سامانه VMS توضیح داده ایم.
عیب یابی مشکلات رایج RTSP
اتصال برقرار نمی شود. اول پورت را بررسی کنید؛ پیش فرض ۵۵۴ است ولی بسیاری از دوربین ها آن را تغییر می دهند. سپس نام کاربری و رمز را بررسی کنید و بعد درستی آدرس مسیر جریان را. هر برند مسیر خودش را دارد و ONVIF این کار را ساده می کند: به جای حدس زدن مسیر، آن را از خود دوربین می پرسد.
تصویر بلوک بلوک می شود. معمولا از دست رفتن بسته در حالت UDP است. اتصال را روی TCP بگذارید و دوباره امتحان کنید. اگر مشکل ماند، سراغ بار شبکه و پیکربندی سوییچ بروید.
جریان بعد از چند دقیقه قطع می شود. اغلب مربوط به نگه داشتن اتصال است؛ برخی دوربین ها اتصال بی فرمان را پس از مدتی می بندند. سامانه باید به صورت دوره ای پیام زنده نگه دارنده بفرستد.
صدا نمی آید ولی تصویر سالم است. معمولا کدک صوتی است. بعضی دوربین ها صدا را با فرمت هایی می فرستند که مرورگر رمزگشایی نمی کند و سامانه باید آن را تبدیل کند.
سوالات متداول درباره RTSP
آیا RTSP امن است؟
RTSP به تنهایی رمزنگاری ندارد و اطلاعات ورود در برخی حالت ها به شکل ضعیفی محافظت می شود. در شبکه محلی و جدا شده این معمولا مسئله نیست، ولی هرگز نباید پورت RTSP یک دوربین را مستقیم روی اینترنت باز کرد. طراحی درست این است که دوربین ها در شبکه بسته بمانند و دسترسی بیرونی فقط از طریق سامانه و روی مسیر رمزنگاری شده انجام شود.
تفاوت RTSP و ONVIF چیست؟
این دو رقیب نیستند و کار متفاوتی می کنند. ONVIF استاندارد کشف و مدیریت است و به شما می گوید دوربین چه قابلیت هایی دارد و آدرس جریان هایش چیست. RTSP پروتکلی است که با آن همان جریان را باز می کنید. در عمل یک سامانه چندبرندی هر دو را با هم به کار می برد.
چرا نمی توانم آدرس RTSP را در مرورگر باز کنم؟
چون مرورگرهای امروزی از RTSP پشتیبانی نمی کنند و افزونه هایی که در گذشته این کار را می کردند به دلایل امنیتی حذف شده اند. راه حل این است که سرور جریان را به WebRTC یا HLS تبدیل کند تا مرورگر بتواند آن را پخش کند؛ همان کاری که یک سامانه تحت وب انجام می دهد.
RTSP بهتر است یا WebRTC؟
پرسش درستی نیست چون هر کدام جای خودشان را دارند. RTSP برای گرفتن تصویر از دوربین است و WebRTC برای رساندن همان تصویر به مرورگر اپراتور. در یک سامانه کامل هر دو حضور دارند: RTSP در سمت دوربین و WebRTC در سمت کاربر.
آیا همه دوربین ها RTSP دارند؟
تقریبا همه دوربین های تحت شبکه، بله. دوربین های آنالوگ خیر، چون اصلا روی شبکه نیستند و برای اتصالشان به دستگاه تبدیل نیاز است. برخی دوربین های خانگی ارزان قیمت هم RTSP را عمدا غیرفعال می کنند تا کاربر مجبور به استفاده از سرویس ابری خودشان باشد؛ همین یکی از دلایلی است که چنین دوربین هایی برای پروژه سازمانی مناسب نیستند.
اگر می خواهید ببینید یک سامانه چطور جریان RTSP ده ها برند دوربین را می گیرد و بدون نصب هیچ افزونه ای در مرورگر پخش می کند، صفحه مدیریت دستگاه و موتور پخش زنده را ببینید، یا دموی زنده درخواست دهید.