عصر بخیر!

مجموع: سیستم مانیتورینگ مجموعه ای است که در حالت غیر نفوذی به شماره n ام لینک های اترنت 10 گیگابیتی متصل می شود که به طور مداوم انتقال تمام جریان های ویدئویی RTP موجود در ترافیک را "نظارت" می کند و اندازه گیری ها را در یک بازه زمانی مشخص به منظور ذخیره آنها بعدا به پایگاه. با توجه به داده های پایگاه داده، گزارش ها به طور منظم برای همه دوربین ها ساخته می شوند.

و چه چیزی اینقدر سخت است؟

در روند یافتن راه حل، چندین مشکل بلافاصله برطرف شد:

• اتصال غیر نفوذی سیستم مانیتورینگ به کانال‌هایی که از قبل کار می‌کنند متصل می‌شود، که در آن بیشتر اتصالات (از طریق RTSP) قبلاً برقرار شده‌اند، سرور و مشتری از قبل می‌دانند که تبادل در کدام پورت انجام می‌شود، اما ما از قبل این را نمی‌دانیم. یک پورت شناخته شده فقط برای پروتکل RTSP وجود دارد، اما جریان های UDP می توانند از طریق پورت های دلخواه عبور کنند (علاوه بر این، مشخص شد که آنها اغلب الزامات پورت SHOULD/فرد را نقض می کنند، به rfc3550 مراجعه کنید). چگونه تشخیص دهیم که این یا آن بسته از برخی از آدرس های IP متعلق به یک جریان ویدیویی است؟ به عنوان مثال، پروتکل BitTorrent به طور مشابه رفتار می کند - در مرحله برقراری یک اتصال، مشتری و سرور در مورد پورت ها توافق می کنند، و سپس تمام ترافیک UDP به نظر می رسد "فقط یک جریان کمی".
• پیوندهای متصل می توانند بیشتر از جریان های ویدئویی باشند. می‌توان HTTP، BitTorrent، و SSH و هر پروتکل دیگری که امروزه استفاده می‌کنیم وجود داشته باشد. بنابراین، سیستم باید جریان های ویدئویی را به درستی شناسایی کند تا آنها را از بقیه ترافیک جدا کند. چگونه با 8 لینک ده گیگابیتی این کار را در زمان واقعی انجام دهیم؟ البته معمولاً 100٪ پر نمی شوند ، بنابراین کل ترافیک 80 گیگابیت در ثانیه نیست ، بلکه حدود 50-60 خواهد بود ، اما این خیلی کم نیست.
• مقیاس پذیری. در جاهایی که در حال حاضر جریان های ویدیویی زیادی وجود دارد، ممکن است تعداد بیشتری از آنها وجود داشته باشد، زیرا نظارت تصویری مدت هاست که خود را به عنوان یک ابزار مؤثر ثابت کرده است. این نشان می دهد که باید حاشیه ای برای عملکرد و ذخیره ای برای پیوندها وجود داشته باشد.

به دنبال راه حل مناسب ...

طبیعتا سعی کردیم از تجربیات خودمان نهایت استفاده را ببریم. زمانی که تصمیم گرفته شد، ما قبلاً پردازش بسته های اترنت را در دستگاه مبتنی بر FPGA Bercut-MX (به طور ساده تر - MX) داشتیم. با کمک Bercut-MX توانستیم فیلدهای لازم برای تحلیل را از سربرگ بسته های اترنت بدست آوریم. متأسفانه، ما هیچ تجربه ای در پردازش چنین حجمی از ترافیک با استفاده از سرورهای "معمولی" نداشتیم، بنابراین با کمی نگرانی به چنین راه حلی نگاه کردیم ...

به نظر می رسد که تنها اعمال روش بر روی بسته های RTP باقی مانده است و کلید طلایی را در جیب خود خواهیم داشت، اما MX فقط می تواند ترافیک را پردازش کند، توانایی ثبت و ذخیره آمار را ندارد. حافظه کافی در FPGA برای ذخیره اتصالات یافت شده (ترکیبات IP-IP-port-port) وجود ندارد، زیرا در یک لینک 2x10 گیگابیتی که وارد ورودی می شود، می تواند حدود 15 هزار جریان ویدیویی وجود داشته باشد و برای هر یک باید " به یاد داشته باشید” تعداد بسته های دریافتی، تعداد بسته های گم شده و غیره... علاوه بر این، جستجو با چنین سرعتی و بر روی چنین حجمی از داده ها، مشروط به پردازش بدون تلفات، به یک کار غیر ضروری تبدیل می شود.

برای یافتن راه‌حل، مجبور شدیم «عمیق‌تر» کنیم و بفهمیم که از چه الگوریتم‌هایی برای اندازه‌گیری کیفیت و شناسایی جریان‌های ویدیویی استفاده خواهیم کرد.

چه چیزی را می توان با فیلدهای یک بسته RTP اندازه گیری کرد؟

از توضیحات می توان دریافت که از نظر اندازه گیری کیفیت در بسته RTP، ما به زمینه های زیر علاقه مند هستیم:

• شماره دنباله - شمارنده 16 بیتی که با ارسال هر بسته افزایش می یابد.
• برچسب زمانی - مهر زمانی، برای h.264 اندازه نمونه 1/90000 ثانیه است (یعنی مربوط به فرکانس 90 کیلوهرتز است).
• بیت نشانگر در rfc3550، به طور کلی توضیح داده شده است که این بیت برای تعیین رویدادهای "مهم" در نظر گرفته شده است، و در واقع، دوربین ها اغلب شروع یک فریم ویدئو و بسته های تخصصی با اطلاعات SPS / PPS را با این بیت نشان می دهند.

کاملاً واضح است که شماره دنباله به شما امکان می دهد پارامترهای جریان زیر را تعریف کنید:

• از دست دادن بسته (از دست دادن فریم)؛
• ارسال مجدد بسته (کپی)؛
• تغییر ترتیب ورود (سفارش مجدد)؛
• بارگذاری مجدد دوربین، با یک "شکاف" بزرگ در دنباله.

برچسب زمان به شما امکان می دهد اندازه گیری کنید:

• تغییرات تاخیری (همچنین جیتر نامیده می شود). در این مورد، یک شمارنده 90 کیلوهرتز باید در سمت گیرنده کار کند.
• در اصل، تاخیر در عبور بسته. اما برای این کار، باید زمان دوربین را با مهر زمان همگام کنید و این در صورتی امکان پذیر است که دوربین گزارش های فرستنده (RTCP SR) را ارسال کند، که معمولاً درست نیست، زیرا در زندگی واقعی، بسیاری از دوربین‌ها پیام RTCP SR را نادیده می‌گیرند (حدود نیمی از دوربین‌هایی که ما فرصت کار با آنها را داشتیم).

خوب، M-bit به شما امکان می دهد نرخ فریم را اندازه گیری کنید. درست است، فریم های SPS/PPS پروتکل h.264 یک خطا ایجاد می کند، زیرا فریم های ویدئویی نیستند اما می توان آن را با استفاده از اطلاعات هدر NAL-unit که همیشه از هدر RTP پیروی می کند، تراز کرد.

الگوریتم های دقیق برای اندازه گیری پارامترها خارج از محدوده مقاله است، من به آن نمی پردازم. در صورت علاقه، rfc3550 یک نمونه کد محاسبه ضرر و فرمولی برای محاسبه جیتر دارد. نتیجه گیری اصلی این است که تنها چند فیلد از بسته های RTP و واحدهای NAL برای اندازه گیری ویژگی های اساسی یک جریان انتقال کافی است. و بقیه اطلاعات در اندازه گیری ها دخالتی ندارد و می توان و باید دور انداخت!

چگونه جریان های RTP را شناسایی کنیم؟

برای حفظ آمار، اطلاعات به‌دست‌آمده از هدر RTP باید به شناسه دوربین (جریان ویدیویی) "ضمیمه" شود. دوربین را می توان به طور منحصر به فرد با پارامترهای زیر شناسایی کرد:

• آدرس IP منبع و مقصد
• پورت های منبع و مقصد
• SSRC هنگامی که چندین جریان از یک IP پخش می شود، از اهمیت ویژه ای برخوردار است. در مورد رمزگذار چند پورت.

جالب اینجاست که در ابتدا شناسایی دوربین را فقط با IP منبع و SSRC انجام می‌دادیم، با تکیه بر این واقعیت که SSRC باید تصادفی باشد، اما در عمل مشخص شد که بسیاری از دوربین‌ها SSRC را روی یک مقدار ثابت تنظیم می‌کنند (مثلاً 256). ظاهراً این به دلیل صرفه جویی در منابع است. در نتیجه مجبور شدیم پورت هایی را به شناسه دوربین اضافه کنیم. این مشکل منحصر به فرد بودن را به طور کامل حل کرد.

چگونه بسته های RTP را از سایر ترافیک ها جدا کنیم؟

سوال باقی می ماند: چگونه Berkut-MX با پذیرش بسته، متوجه می شود که RTP است؟ هدر RTP دارای شناسایی صریح مانند IP نیست، دارای چک جمع نیست، می توان آن را از طریق UDP با شماره پورت هایی که هنگام برقراری اتصال به صورت پویا انتخاب می شوند، منتقل کرد. و در مورد ما، بیشتر اتصالات مدتهاست برقرار شده اند و می توانید مدت زیادی برای نصب مجدد صبر کنید.

برای حل این مشکل، در rfc3550 (پیوست A.1) توصیه می شود بیت های نسخه RTP را بررسی کنید - اینها دو بیت هستند و فیلد Payload Type (PT) - هفت بیت، که در مورد یک نوع پویا یک مقدار طول می کشد. محدوده کوچک ما در عمل متوجه شده ایم که برای مجموعه دوربین هایی که با آنها کار می کنیم، PT در محدوده 96 تا 100 قرار می گیرد.

یک عامل دیگر وجود دارد - برابری بندر، اما همانطور که تمرین نشان داده است، همیشه رعایت نمی شود، بنابراین باید رها می شد.

بنابراین، رفتار Berkut-MX به شرح زیر است:

1. ما یک بسته دریافت می کنیم، آن را در فیلدها جدا می کنیم.
2. اگر نسخه 2 باشد و نوع payload در محدوده داده شده باشد، هدرها را به سرور ارسال می کنیم.

بدیهی است که با این رویکرد، نکات مثبت کاذب وجود دارد، زیرا. نه تنها بسته های RTP می توانند تحت چنین معیارهای ساده ای قرار گیرند. اما برای ما مهم است که بسته RTP را از دست ندهیم و سرور بسته های "اشتباه" را فیلتر می کند.

برای فیلتر موارد نادرست، سرور از مکانیزمی استفاده می کند که منبع ترافیک ویدیو را برای چندین بسته دریافتی متوالی ثبت می کند (یک شماره دنباله در بسته وجود دارد!). اگر چندین بسته با اعداد متوالی آمدند، پس این تصادفی نیست و ما شروع به کار با این جریان می کنیم. ثابت شد که این الگوریتم بسیار قابل اعتماد است.

در حال حرکت…

با درک اینکه تمام اطلاعاتی که در بسته‌ها برای اندازه‌گیری کیفیت و شناسایی جریان‌ها مورد نیاز نیست، تصمیم گرفتیم تمام کارهای پربار و حساس در زمان دریافت و جداسازی فیلدهای بسته‌های RTP را به Berkut-MX منتقل کنیم. FPGA. جریان ویدئو را "پیدا می کند"، بسته را تجزیه می کند، فقط فیلدهای مورد نیاز را باقی می گذارد و آن را به یک سرور معمولی در تونل UDP ارسال می کند. سرور برای هر دوربین اندازه گیری می کند و نتایج را در پایگاه داده ذخیره می کند.

در نتیجه، سرور با 50-60 گیگابیت بر ثانیه کار نمی کند، بلکه با حداکثر 5٪ کار می کند (این دقیقاً نسبت داده های ارسال شده به اندازه متوسط ​​بسته است). یعنی در ورودی کل سیستم 55 گیگابیت بر ثانیه و فقط بیش از 3 گیگابیت بر ثانیه به سرور نمی رسد!

در نتیجه، معماری زیر را دریافت کردیم:

و ما اولین نتیجه را در این پیکربندی دو هفته پس از تنظیم TOR اولیه دریافت کردیم!

نتیجه نهایی سرور چیست؟

بنابراین سرور در معماری ما چه می کند؟ وظایف او:

• به یک سوکت UDP گوش دهید و فیلدهایی را با هدرهای بسته بندی شده از آن بخوانید.
• بسته های دریافتی را تجزیه کنید و فیلدهای هدر RTP را به همراه شناسه های دوربین از آنجا استخراج کنید.
• فیلدهای دریافتی را با فیلدهایی که قبلاً دریافت شده اند مرتبط کنید و بفهمید که آیا بسته ها گم شده اند یا خیر، آیا بسته ها به طور مکرر ارسال شده اند یا خیر، آیا ترتیب رسیدن تغییر کرده است، تفاوت در تأخیر حمل و نقل بسته (جیتر) چقدر بوده است، و غیره.
• ثبت داده های اندازه گیری شده در پایگاه داده با توجه به زمان؛
• تجزیه و تحلیل پایگاه و تولید گزارش، ارسال تله در مورد رویدادهای مهم (از دست دادن بسته های زیاد، از دست دادن بسته ها از برخی دوربین ها و غیره).

علیرغم این واقعیت که کل ترافیک ورودی سرور حدود 3 گیگابیت بر ثانیه است، سرور حتی اگر از هیچ DPDK استفاده نکنیم کار می کند، اما به سادگی از طریق یک سوکت لینوکس کار می کند (البته پس از افزایش اندازه بافر برای سوکت) . علاوه بر این، امکان اتصال پیوندهای جدید و MX "ها وجود خواهد داشت، زیرا حاشیه عملکرد باقی می ماند.

این همان چیزی است که بالای سرور به نظر می رسد (این بالای یک ظرف lxc است، گزارش ها در دیگری تولید می شوند):

از آن می توان دریافت که کل بار برای محاسبه پارامترهای کیفیت و حسابداری آمار به طور مساوی در چهار فرآیند توزیع شده است. ما با استفاده از هش در FPGA موفق به دستیابی به چنین توزیعی شدیم: تابع هش توسط IP محاسبه می شود و کمترین بیت های هش دریافتی تعداد پورت UDP را تعیین می کند که آمار به آن می رود. بر این اساس، هر فرآیندی که در پورت خود گوش می دهد تقریباً همان میزان ترافیک را دریافت می کند.

مزایا و معایب

وقت آن است که لاف بزنیم و کاستی های راه حل را بپذیریم.

من با جوانب مثبت شروع می کنم:

• بدون ضرر در محل اتصال با لینک های 10G. از آنجایی که FPGA تمام "ضربه" را می گیرد، می توانیم مطمئن باشیم که هر بسته تجزیه و تحلیل خواهد شد.
• برای نظارت بر 55000 دوربین (یا بیشتر)، تنها یک سرور با یک کارت 10G مورد نیاز است. ما در حال حاضر از سرورهای مبتنی بر 2x Xeon با 4 هسته 2400 مگاهرتز استفاده می کنیم. به اندازه کافی با حاشیه: به موازات جمع آوری اطلاعات، گزارش ها تولید می شود.
• نظارت بر 8 "دوجین" (پیوندهای 10G) فقط در 2-3 واحد قرار می گیرد: همیشه فضای و قدرت زیادی در قفسه برای سیستم نظارت وجود ندارد.
• هنگام اتصال پیوندها از MX ها از طریق سوئیچ، می توانید پیوندهای جدید را بدون توقف نظارت اضافه کنید، زیرا شما نیازی به قرار دادن هیچ تابلویی در سرور ندارید و برای این کار نیازی به خاموش کردن آن ندارید.
• سرور با داده ها بارگیری نمی شود، فقط آنچه را که لازم است دریافت می کند.
• هدرهای MX در یک بسته اترنت جامبو می آیند، به این معنی که پردازنده با وقفه خفه نمی شود (علاوه بر این، ما ادغام وقفه را فراموش نمی کنیم).

انصافاً من معایب را در نظر خواهم گرفت:

• به دلیل بهینه سازی سنگین برای یک کار خاص، افزودن پشتیبانی از فیلدها یا پروتکل های جدید نیاز به تغییراتی در کد FPGA دارد. این منجر به زمان بیشتری نسبت به زمانی می شود که ما همین کار را روی پردازنده انجام دهیم. هم در توسعه و آزمایش و هم در حین استقرار.
• اطلاعات ویدئویی به هیچ وجه تجزیه و تحلیل نمی شود. دوربین می‌تواند از یخی که در جلوی آن آویزان است عکس بگیرد، یا به سمت اشتباه چرخانده شود. این واقعیت مورد توجه قرار نخواهد گرفت. البته ما امکان فیلم برداری از دوربین انتخابی را فراهم کرده ایم اما اپراتور نمی تواند از تمام 55000 دوربین عبور کند!
• یک سرور و دستگاه های مجهز به FPGA گران تر از یک یا دو سرور هستند؛)

خلاصه

در پایان، ما یک مجتمع نرم‌افزاری و سخت‌افزاری به دست آوردیم که در آن می‌توانیم هم قسمتی را که بسته‌ها را روی رابط‌ها تجزیه می‌کند و هم بخشی را که آمار را نگه می‌دارد، کنترل کنیم. کنترل کامل بر روی تمام گره های سیستم به معنای واقعی کلمه ما را نجات داد زمانی که دوربین ها شروع به تغییر حالت RTSP/TCP interleaved کردند. زیرا در این مورد، هدر RTP دیگر در بسته با یک افست ثابت قرار ندارد: می تواند در هر جایی باشد، حتی در مرز دو بسته (نیمه اول در یکی، دومی در دیگری). بر این اساس الگوریتم به دست آوردن هدر RTP و فیلدهای آن دستخوش تغییرات اساسی شده است. ما مجبور شدیم برای همه 50000 اتصال، دوباره TCP را روی سرور انجام دهیم - از این رو بار نسبتاً بالایی در بالا وجود دارد.

ما قبلاً هرگز در زمینه برنامه های کاربردی با بار بالا کار نکرده ایم، اما به دلیل مهارت های خود در FPGA توانستیم مشکل را حل کنیم و بسیار خوب ظاهر شد. حتی یک حاشیه وجود داشت - به عنوان مثال، 20-30 هزار جریان دیگر را می توان به سیستمی با 55000 دوربین متصل کرد.

تنظیم زیرسیستم های لینوکس (توزیع صف ها توسط وقفه ها، افزایش بافرهای دریافت، تخصیص مستقیم هسته ها به فرآیندهای خاص و غیره) را خارج از محدوده مقاله گذاشتم، زیرا. این موضوع در حال حاضر به خوبی پوشش داده شده است.

من به دور از همه چیز توضیح داده ام ، تعداد زیادی چنگک جمع آوری شده است ، بنابراین در صورت تمایل سوالات خود را بپرسید :)

با تشکر فراوان از همه کسانی که تا آخر خواندند!

رشد سریع اینترنت تقاضاهای جدیدی را در مورد سرعت و حجم انتقال داده ها ایجاد می کند. و برای برآورده ساختن همه این درخواست ها تنها افزایش ظرفیت شبکه کافی نیست، بلکه به روش های معقول و کارآمد برای مدیریت ترافیک و ازدحام خطوط انتقال نیاز است.

در برنامه های بلادرنگ، فرستنده جریانی از داده ها را با نرخ ثابت تولید می کند و گیرنده (یا گیرندگان) باید این داده ها را با همان سرعت در اختیار برنامه قرار دهند. از جمله برنامه های کاربردی می توان به کنفرانس صوتی و تصویری، ویدئوی زنده، تشخیص از راه دور پزشکی، تلفن کامپیوتری، شبیه سازی تعاملی توزیع شده، بازی ها، نظارت بر زمان واقعی و موارد دیگر اشاره کرد.

پرکاربردترین پروتکل لایه انتقال TCP است. اگرچه TCP می تواند طیف گسترده ای از برنامه های کاربردی توزیع شده را پشتیبانی کند، اما برای برنامه های بلادرنگ مناسب نیست.

این کار قرار است با پروتکل جدید حمل و نقل بلادرنگ حل شود - RTP(پروتکل حمل و نقل بلادرنگ)، که تحویل داده ها به یک یا چند مقصد را با تاخیر در محدوده های مشخص تضمین می کند، یعنی داده ها را می توان در زمان واقعی پخش کرد.

اصول ساخت پروتکل RTP

RTP از هیچ مکانیزمی برای تحویل بسته، اعتبار انتقال یا قابلیت اطمینان اتصال پشتیبانی نمی کند. همه این توابع به پروتکل حمل و نقل اختصاص داده شده است. RTP در بالای UDP اجرا می شود و می تواند از انتقال بیدرنگ داده بین چندین شرکت کننده در یک جلسه RTP پشتیبانی کند.

توجه داشته باشید

برای هر شرکت کننده RTP، یک جلسه با یک جفت آدرس انتقال بسته بسته (یک آدرس شبکه - IP و یک جفت پورت: RTP و RTCP) تعریف می شود.

بسته‌های RTP حاوی فیلدهای زیر هستند: شناسه فرستنده که نشان می‌دهد کدام طرف داده‌ها را تولید می‌کند، مهرهای زمانی تولید بسته به طوری که داده‌ها می‌تواند توسط طرف گیرنده در فواصل زمانی صحیح بازپخش شود، اطلاعات سفارش انتقال، و اطلاعات مربوط به ماهیت محتویات بسته، مانند نوع رمزگذاری ویدئو (MPEG، Indeo، و غیره). در دسترس بودن چنین اطلاعاتی تخمین مقدار تاخیر اولیه و اندازه بافر انتقال را ممکن می سازد.

توجه داشته باشید

در یک محیط بلادرنگ معمولی، فرستنده بسته ها را با نرخ ثابت تولید می کند. آنها در فواصل زمانی منظم ارسال می شوند، از طریق شبکه حرکت می کنند و توسط گیرنده دریافت می شوند، که داده ها را در زمان دریافت آن ها پخش می کند. با این حال، به دلیل تغییر در تاخیر زمانی که بسته ها از طریق شبکه منتقل می شوند، ممکن است در فواصل نامنظم برسند. برای جبران این اثر، بسته های دریافتی بافر می شوند، برای مدتی نگهداری می شوند و سپس با نرخ ثابت ارائه می شوند. نرم افزارکه خروجی را تولید می کند. بنابراین، برای عملکرد پروتکل بلادرنگ، لازم است که هر بسته حاوی یک مهر زمانی باشد - بنابراین گیرنده می تواند داده های دریافتی را با همان سرعت فرستنده بازتولید کند.

از آنجایی که RTP قالب محموله داده های ارسالی را تعریف می کند (و تنظیم می کند)، مفهوم همگام سازی مستقیماً با این ارتباط دارد، که مکانیزم ترجمه RTP، میکسر، تا حدی مسئول آن است. پس از دریافت جریان بسته های RTP از یک یا چند منبع، میکسر آنها را ترکیب کرده و جریان جدیدی از بسته های RTP را برای یک یا چند گیرنده ارسال می کند. میکسر به سادگی می تواند داده ها را ترکیب کند، و همچنین فرمت آن را تغییر دهد، به عنوان مثال، هنگام ترکیب چندین منبع صدا. بیایید وانمود کنیم که سیستم جدیدمی‌خواهد در جلسه شرکت کند، اما پیوند آن به شبکه ظرفیت کافی برای پشتیبانی از تمام جریان‌های RTP را ندارد، سپس میکسر تمام این جریان‌ها را دریافت می‌کند، آنها را در یکی ادغام می‌کند و آخرین مورد را به عضو جلسه جدید ارسال می‌کند. هنگام دریافت چندین جریان، میکسر به سادگی مقادیر PCM را اضافه می کند. هدر RTP تولید شده توسط میکسر شامل هویت فرستنده ای است که داده هایش در بسته موجود است.

یک دستگاه رله ساده تر یک بسته RTP خروجی برای هر بسته RTP ورودی ایجاد می کند. این مکانیسم ممکن است فرمت داده ها را در بسته تغییر دهد یا از مجموعه متفاوتی از پروتکل های سطح پایین برای انتقال داده ها از یک دامنه به دامنه دیگر استفاده کند. به عنوان مثال، یک گیرنده بالقوه ممکن است نتواند سیگنال ویدیویی پرسرعت مورد استفاده سایر شرکت کنندگان در جلسه را پردازش کند. مترجم ویدیو را به قالبی با کیفیت پایین‌تر تبدیل می‌کند که نیاز به فرمت متفاوتی دارد سرعت بالاانتقال داده

روش های کنترل کار

پروتکل RTP فقط برای انتقال داده های کاربر - معمولا چندپخشی - به همه شرکت کنندگان در جلسه استفاده می شود. همراه با RTP، پروتکل RTCP (پروتکل کنترل حمل و نقل در زمان واقعی) کار می کند که وظیفه اصلی آن ارائه کنترل بر انتقال RTP است. RTCP از همان پروتکل انتقال اولیه مانند RTP (معمولا UDP) استفاده می کند، اما از شماره پورت متفاوتی استفاده می کند.

RTCP چندین عملکرد را انجام می دهد:

1. اطمینان و نظارت بر کیفیت خدمات و بازخورد در صورت ازدحام. از آنجایی که بسته‌های RTCP چندپخشی هستند، همه شرکت‌کنندگان در جلسه می‌توانند میزان عملکرد و دریافت سایر شرکت‌کنندگان را ارزیابی کنند. پیام های فرستنده به گیرندگان اجازه می دهد تا نرخ داده و کیفیت انتقال را ارزیابی کنند. پیام های گیرندگان حاوی اطلاعاتی در مورد مشکلاتی است که آنها با آن مواجه می شوند، از جمله از دست دادن بسته و ریپل بیش از حد. بازخورد گیرنده نیز برای تشخیص خطاهای انتشار مهم است. با تجزیه و تحلیل پیام های همه شرکت کنندگان در جلسه، مدیر شبکه می تواند تعیین کند که آیا مشکل مربوط به یک شرکت کننده است یا ماهیت کلی دارد. اگر برنامه ارسال به این نتیجه برسد که مشکل برای کل سیستم معمول است، به عنوان مثال، به دلیل خرابی یکی از کانال های ارتباطی، می تواند درجه فشرده سازی داده ها را به دلیل کاهش کیفیت یا افزایش دهد. به طور کلی از انتقال ویدیو خودداری کنید - این به شما امکان می دهد داده ها را با ظرفیت کم اتصال منتقل کنید.
2. شناسایی فرستنده بسته های RTCP حاوی یک توصیف متنی استاندارد از فرستنده هستند. آنها اطلاعات بیشتری در مورد فرستنده بسته های داده نسبت به شناسه منبع همگام سازی تصادفی انتخاب شده ارائه می دهند. علاوه بر این، آنها به کاربر کمک می کنند تا موضوعات مربوط به جلسات مختلف را شناسایی کند.
3. اندازه و مقیاس بندی جلسه. برای اطمینان از کیفیت خدمات و بازخوردبه منظور کنترل تراکم، و همچنین به منظور شناسایی فرستنده، همه شرکت کنندگان به صورت دوره ای بسته های RTCP را ارسال می کنند. فرکانس ارسال این بسته ها با افزایش تعداد شرکت کنندگان کاهش می یابد. با تعداد کمی از شرکت کنندگان، حداکثر هر 5 ثانیه یک بسته RTCP ارسال می شود. RFC-1889 الگوریتمی را توصیف می کند که در آن شرکت کنندگان نرخ بسته های RTCP را بر اساس تعداد کل شرکت کنندگان محدود می کنند. هدف این است که ترافیک RTCP کمتر از 5٪ از کل ترافیک جلسه باشد.

فرمت هدر پروتکل RTP

RTP یک پروتکل جریان گرا است. سربرگ بسته RTP با در نظر گرفتن نیازهای انتقال بلادرنگ طراحی شده است. این شامل اطلاعاتی در مورد ترتیب بسته ها به طوری که جریان داده به درستی در انتهای گیرنده مونتاژ شود، و یک مهر زمانی برای درهم آمیختگی صحیح فریم در حین پخش و برای همگام سازی جریان های داده های متعدد، مانند ویدئو و صدا.

هر بسته RTP دارای یک هدر اصلی و احتمالاً فیلدهای اضافی ویژه برنامه است.

استفاده از TCP به عنوان پروتکل حمل و نقل برای این برنامه ها به چند دلیل امکان پذیر نیست:

1. این پروتکل فقط امکان برقراری ارتباط بین دو نقطه پایانی را فراهم می کند و بنابراین برای چند کستینگ مناسب نیست.
2. TCP امکان ارسال مجدد بخش‌های از دست رفته را فراهم می‌کند که زمانی می‌رسند که برنامه بلادرنگ دیگر منتظر آنها نیست.
3. TCP مکانیسم مناسبی برای مرتبط کردن اطلاعات زمان بندی با بخش ها ندارد که یک نیاز اضافی برای برنامه های بلادرنگ است.

یکی دیگر از پروتکل های لایه انتقال که به طور گسترده مورد استفاده قرار می گیرد، LJDP برخی از محدودیت های TCP را ندارد، اما ارائه نمی کند. اطلاعات حیاتیدر مورد همگام سازی

در حالی که هر برنامه بلادرنگ ممکن است مکانیسم های خاص خود را برای پشتیبانی از انتقال بلادرنگ داشته باشد، اما آنها ویژگی های مشترک بسیاری دارند که تعریف یک پروتکل واحد را بسیار مطلوب می کند.

پروتکل جدید حمل و نقل بلادرنگ RTP (پروتکل حمل و نقل بلادرنگ) برای حل این مشکل طراحی شده است که تحویل داده ها به یک یا چند گیرنده را با تاخیر در محدوده های مشخص شده تضمین می کند، یعنی داده ها را می توان در زمان واقعی بازتولید کرد. .

روی انجیر 1 ارائه شده است هدر RTP ثابت، که حاوی تعدادی فیلد برای شناسایی موارد مانند قالب بسته است، شماره سریال، منابع، محدوده ها و نوع بار. هدر ثابت ممکن است با فیلدهای دیگری حاوی اطلاعات اضافی در مورد داده ها دنبال شود.

0

2

3

4

8

16

31

شناسه منبع همگام سازی (SSRC).
شناسه های منبع کمک کننده (CSRC).

برنج. 1. هدر RTP ثابت.

V(2 بیت). فیلد نسخه نسخه فعلی نسخه دوم است.
آر(1 بیت). فیلد را پر کنید این فیلد وجود اکتت های بالشتکی را در انتهای محموله سیگنال می دهد. Padding زمانی اعمال می شود که یک برنامه نیاز دارد که اندازه بار بار مضرب مثلاً 32 بیت باشد. در این حالت آخرین اکتت تعداد اکتت های padding را نشان می دهد.
ایکس(1 بیت). فیلد پسوند هدر. هنگامی که این فیلد تنظیم می شود، سرصفحه اصلی با یک هدر اضافی که در پسوندهای RTP آزمایشی استفاده می شود، دنبال می شود.
اس اس(4 بیت). فیلد تعداد فرستنده. این فیلد شامل تعداد شناسه فرستنده هایی است که داده های آنها در بسته وجود دارد و خود شناسه ها از هدر اصلی پیروی می کنند.
م(1 بیت). فیلد نشانگر. معنای بیت نشانگر به نوع بار بستگی دارد. بیت نشانگر معمولاً برای نشان دادن مرزهای جریان داده استفاده می شود. در مورد ویدیو، انتهای فریم را تنظیم می کند. در مورد صدا، شروع گفتار را پس از مدتی سکوت مشخص می کند.
RT(7 بیت). فیلد نوع بار. این فیلد نوع محموله و فرمت داده، از جمله فشرده سازی و رمزگذاری را مشخص می کند. در حالت ثابت، فرستنده تنها از یک نوع بار در هر جلسه استفاده می کند، اما در صورت سیگنال دهی توسط پروتکل کنترل حمل و نقل بلادرنگ، می تواند آن را در پاسخ به شرایط تغییر تغییر دهد.
شماره ترتیب(16 بیت). فیلد شماره دنباله. هر منبع شروع به شماره گذاری بسته ها از یک عدد دلخواه می کند، سپس با ارسال هر بسته داده RTP یک عدد افزایش می یابد. این به شما امکان می دهد تا از دست رفتن بسته ها را شناسایی کنید و ترتیب بسته ها را با همان زمان مشخص کنید. اگر به طور منطقی در یک لحظه تولید شوند، ممکن است چندین بسته متوالی دارای مهر زمانی یکسانی باشند، مانند بسته هایی که متعلق به یک فریم ویدیویی هستند.
مهر زمان(32 بیت). فیلد مهر زمان. این فیلد حاوی نقطه زمانی است که در آن اولین اکتت داده محموله ایجاد شده است. واحدهایی که در آن زمان در این قسمت مشخص شده است به نوع محموله بستگی دارد. مقدار توسط ساعت محلی فرستنده تعیین می شود.
منبع همگام سازی شناسه (SSRC).(32 بیت). فیلد شناسه منبع همگام سازی: شماره ای که به طور تصادفی تولید می شود که به طور منحصر به فرد منبع را در یک جلسه شناسایی می کند و مستقل از آدرس شبکه است. این عدد نقش مهمی در پردازش بخش ورودی داده از یک منبع دارد.
شناسه منبع کمک کننده (CSRC).(32 بیت). فهرستی از فیلدهای شناسه منبع "مخلوط" در جریان اصلی، به عنوان مثال، با استفاده از میکسر. میکسر فهرست کاملی از شناسه‌های SSRC منابعی را که در ساخت این بسته RTP شرکت کرده‌اند درج می‌کند. این لیست CSRC نام دارد. تعداد عناصر موجود در لیست: از 0 تا 15. اگر تعداد شرکت کنندگان بیش از 15 نفر باشد، 15 نفر اول انتخاب می شوند. به عنوان مثال یک کنفرانس صوتی که در بسته های RTP آن، سخنرانی های همه شرکت کنندگان جمع آوری شده است، هر کدام با خود. SSRC خود - آنها لیست CSRC را تشکیل می دهند. در این مورد، کل کنفرانس دارای یک SSRC مشترک است.

پروتکل RTCP، مانند هر پروتکل کنترلی، هم از نظر ساختار و هم از نظر عملکردهایی که انجام می دهد بسیار پیچیده تر است (مثلاً پروتکل های IP و TCP را مقایسه کنید). اگرچه هسته پروتکل RTCP RTP است، اما حاوی بسیاری از فیلدهای اضافی است که با آنها توابع خود را پیاده سازی می کند.

پروتکل رزرو منابع - RSVP

برای حل مشکل اولویت داده‌های حساس به تاخیر، برخلاف داده‌های سنتی که تاخیر برای آن‌ها چندان حیاتی نیست، از پروتکل رزرو منابع - RSVP، که در حال حاضر توسط کارگروه مهندسی اینترنت (IETF) در حال بررسی است، استفاده می‌شود. RSVP اجازه می دهد سیستم های پایانیمنابع شبکه را برای به دست آوردن کیفیت مورد نیاز خدمات، به ویژه منابع گرافیکی بلادرنگ با استفاده از پروتکل RTP ذخیره کنید. RSVP در درجه اول به روترها مربوط می شود، اگرچه برنامه های کاربردی گره پایانی نیز باید بدانند که چگونه از RSVP استفاده کنند تا پهنای باند مورد نیاز را برای یک کلاس سرویس یا سطح اولویت خاص رزرو کنند.

RTP، همراه با استانداردهای دیگر توضیح داده شده، امکان انتقال موفقیت آمیز تصویر و صدا را از طریق شبکه های IP معمولی فراهم می کند. RTP/RTCP/RSVP یک راه حل استاندارد شده برای شبکه های داده بلادرنگ است. تنها عیب آن این است که فقط برای شبکه های IP است. با این حال، این محدودیت موقتی است: شبکه ها در این جهت یا به طریق دیگری توسعه خواهند یافت. این راه حل نوید حل مشکل انتقال داده های حساس به تاخیر از طریق اینترنت را می دهد.

ادبیات

شرح پروتکل RTP را می توان در RFC-1889 یافت.

نیاز به پشتیبانی از چندین نوع ترافیک با الزامات مختلف برای کیفیت خدمات بر اساس پشته پروتکل TCP / IP اکنون بسیار مرتبط است. این مشکل توسط پروتکل حمل و نقل بلادرنگ (RTP) که یک استاندارد IETF برای انتقال بی‌درنگ داده‌هایی مانند صدا یا ویدیو از طریق شبکه است که کیفیت خدمات را تضمین نمی‌کند، برطرف می‌شود.

پروتکل RTP تحویل داده ها به یک یا چند گیرنده را با تاخیری که از مقدار مشخص شده بیشتر نباشد تضمین می کند. برای انجام این کار، هدر پروتکل مهرهای زمانی لازم برای بازیابی موفقیت آمیز اطلاعات صوتی و تصویری و همچنین داده های مربوط به روش رمزگذاری اطلاعات را ارائه می دهد.

اگرچه پروتکل TCP تحویل داده‌های ارسالی را به ترتیب صحیح تضمین می‌کند، ترافیک ناهموار است، یعنی تاخیرهای غیرقابل پیش‌بینی در هنگام تحویل دیتاگرام‌ها رخ می‌دهد. از آنجایی که پروتکل RTP از محتوای دیتاگرام ها آگاه است و مکانیسم های تشخیص از دست دادن داده ها را دارد، می تواند تاخیر را تا حد قابل قبولی کاهش دهد.

طرح آدرس پروتکل IP

طرح آدرس دهی اینترنتی مورد استفاده در پروتکل IP در RFC 990 و RFC 997 توضیح داده شده است. این طرح بر اساس جداسازی شبکه های آدرس دهی از دستگاه های آدرس دهی در این شبکه ها است. این طرح مسیریابی را تسهیل می کند. در این مورد، آدرس ها باید به صورت منظم (متوالی) اختصاص داده شوند تا مسیریابی کارآمدتر شود.

هنگام استفاده از پشته پروتکل TCP / IP در شبکه، دستگاه های پایانی آدرس های منحصر به فردی را دریافت می کنند. چنین دستگاه هایی می توانند باشند کامپیوترهای شخصی، سرورهای رسانه ای، روترها و غیره. با این حال، برخی از دستگاه هایی که دارای چندین پورت فیزیکی هستند، مانند روترها، باید یک آدرس منحصر به فرد روی هر یک از پورت ها داشته باشند. بر اساس طرح آدرس دهی و این واقعیت که برخی از دستگاه های موجود در شبکه می توانند چندین آدرس داشته باشند، می توان نتیجه گرفت که این طرح آدرس دهی خود دستگاه را در شبکه توصیف نمی کند، بلکه یک اتصال خاص این دستگاه به شبکه است. این طرح منجر به تعدادی از ناراحتی ها می شود. یکی از آنها نیاز به تغییر آدرس دستگاه هنگام انتقال آن به شبکه دیگر است. اشکال دیگر این است که برای کار با دستگاهی که چندین اتصال در یک شبکه توزیع شده دارد، باید تمام آدرس های آن را که این اتصالات را شناسایی می کنند، بدانید.

بنابراین، برای هر دستگاه در شبکه های IP، می توانیم در مورد آدرس های سه سطح صحبت کنیم:

q آدرس فیزیکیدستگاه (به طور دقیق تر - یک رابط خاص). برای دستگاه های موجود در شبکه های اترنت، این آدرس MAC است کارت شبکهیا پورت روتر این آدرس ها توسط سازندگان سخت افزار اختصاص داده شده است. آدرس فیزیکی دارای شش بایت است: سه بایت بالا شناسه سازنده است، سه بایت پایین توسط سازنده تخصیص داده می شود.

q یک آدرس IP متشکل از چهار بایت. این آدرس برای لایه شبکهمدل مرجع OSI؛

q شناسه کاراکتر - نام. این شناسه می تواند به صورت دلخواه توسط مدیر اختصاص داده شود.

هنگامی که پروتکل IP در سپتامبر 1981 استاندارد شد، مشخصات آن مستلزم آن بود که هر دستگاه متصل به یک شبکه یک آدرس منحصر به فرد 32 بیتی داشته باشد. این آدرس به دو قسمت تقسیم می شود. قسمت اول آدرس شبکه ای را که دستگاه در آن قرار دارد مشخص می کند. بخش دوم به طور منحصر به فرد خود دستگاه را در شبکه شناسایی می کند. این طرح منجر به یک سلسله مراتب آدرس دو سطحی می شود (شکل 6.23).

حالا فیلد شماره شبکه در آدرس فراخوانی می شود پیشوند شبکه،زیرا شبکه را شناسایی می کند. همه ایستگاه های کاری در شبکه یک پیشوند شبکه مشترک دارند. در عین حال باید داشته باشند اعداد منحصر به فرددستگاه ها دو ایستگاه کاری واقع در شبکه های مختلف باید پیشوندهای شبکه متفاوتی داشته باشند، اما می توانند شماره دستگاه یکسانی نیز داشته باشند.

برای انعطاف در آدرس دهی شبکه های کامپیوترطراحان پروتکل تعیین کردند که فضای آدرس IP باید به سه کلاس مختلف تقسیم شود - A، B و C. با دانستن کلاس، می‌دانید که مرز بین پیشوند شبکه و شماره دستگاه در یک آدرس 32 بیتی کجاست. . روی انجیر شکل 6.24 فرمت های آدرس این کلاس های پایه را نشان می دهد.

یکی از مزایای اصلی استفاده از کلاس ها این است که می توانید از کلاس آدرس تعیین کنید که مرز بین پیشوند شبکه و شماره دستگاه کجاست. به عنوان مثال، اگر مهم ترین دو بیت آدرس 10 باشد، نقطه تقسیم بین بیت های 15 و 16 است.

عیب این روش نیاز به تغییر آدرس شبکه در هنگام اتصال است دستگاه های اضافی. به عنوان مثال، اگر تعداد کلدستگاه‌های موجود در شبکه کلاس C از 255 فراتر می‌رود، پس باید آدرس‌های آن را با آدرس‌های کلاس B جایگزین کرد. تغییر آدرس‌های شبکه به تلاش‌های بیشتری از سوی مدیر برای رفع اشکال شبکه نیاز دارد. مدیران شبکه نمی توانند انتقال آرام، انتقال بدون دردسربه یک کلاس آدرس جدید، زیرا کلاس ها به وضوح از هم جدا شده اند. شما باید استفاده از یک گروه کامل از آدرس‌های شبکه را ممنوع کنید، همه آدرس‌های دستگاه‌های این گروه را همزمان تغییر دهید و تنها پس از آن دوباره اجازه استفاده از آنها را در شبکه بدهید. علاوه بر این، معرفی کلاس های آدرس به طور قابل توجهی از نظر تئوری ممکن تعداد آدرس های فردی را کاهش می دهد. AT نسخه فعلیپروتکل IP (نسخه 4) تعداد کل آدرس ها می تواند 2 32 (4 294 967 296) باشد، زیرا پروتکل استفاده از 32 بیت را برای تعیین آدرس فراهم می کند. به طور طبیعی، استفاده از برخی بیت ها برای اهداف خدماتی، تعداد آدرس های موجود را کاهش می دهد.

کلاس A برای شبکه های بزرگ است. هر آدرس کلاس A یک پیشوند شبکه 8 بیتی دارد که مهم ترین بیت آن 1 است و هفت بیت بعدی برای شماره شبکه استفاده می شود. 24 بیت باقی مانده برای شماره دستگاه استفاده می شود. AT این لحظههمه آدرس های کلاس A قبلاً تخصیص داده شده اند. شبکه‌های کلاس A با نام «/8» نیز شناخته می‌شوند، زیرا آدرس‌های کلاس A دارای پیشوند شبکه 8 بیتی هستند.

حداکثر تعداد شبکه های کلاس A 126 است (2 7 -2 - دو آدرس از صفر و یک کم می شود). هر شبکه از این کلاس تا 16,777,214 (2 24 -2) دستگاه را پشتیبانی می کند. از آنجایی که یک بلوک آدرس کلاس A می تواند حداکثر 231 (2 147483648) آدرس جداگانه را در خود جای دهد، و IP نسخه 4 تنها می تواند حداکثر 232 آدرس (4294967296) را پشتیبانی کند، کلاس A 50٪ از کل فضای آدرس IP را اشغال می کند.

کلاس B برای شبکه های با اندازه متوسط ​​در نظر گرفته شده است. هر آدرس کلاس B یک پیشوند شبکه 16 بیتی دارد که دو بیت مهم آن 10 و 14 بیت بعدی برای شماره شبکه استفاده می شود. 16 بیت برای شماره دستگاه اختصاص داده شده است. شبکه‌های کلاس B با عنوان "/16" نیز شناخته می‌شوند، زیرا آدرس‌های کلاس B دارای پیشوند شبکه 16 بیتی هستند.

حداکثر تعداد شبکه های کلاس B 16382 (2 14 -2) است. هر شبکه از این کلاس تا 65534 (2 16 -2) دستگاه را پشتیبانی می کند. از آنجایی که کل یک بلوک آدرس کلاس B می تواند حداکثر 230 (1,073,741,824) آدرس جداگانه داشته باشد، 25٪ از کل فضای آدرس IP را اشغال می کند.

آدرس های کلاس C در شبکه هایی با تعداد کمی دستگاه استفاده می شود. هر شبکه کلاس C دارای یک پیشوند شبکه 24 بیتی است که در آن سه بیت مهم 110 بیت هستند و 21 بیت بعدی برای شماره شبکه استفاده می شود. 8 بیت باقیمانده به شماره دستگاه اختصاص داده شده است. شبکه‌های کلاس C با عنوان «/24» نیز شناخته می‌شوند، زیرا آدرس‌های کلاس C دارای پیشوند شبکه 24 بیتی هستند.

حداکثر تعداد شبکه های کلاس C 2,097,152 (221) است. هر شبکه از این کلاس حداکثر 254 (2 8 -2) دستگاه را پشتیبانی می کند. کلاس C 12.5٪ از کل فضای آدرس IP را اشغال می کند.

روی میز. 6.9 تجزیه و تحلیل ما از کلاس های شبکه را خلاصه می کند.

جدول 6.9. کلاس های شبکه

علاوه بر این سه کلاس آدرس، دو کلاس دیگر نیز وجود دارد. در کلاس D، مهم ترین چهار بیت 1110 است. این کلاس برای پخش چندگانه استفاده می شود. در کلاس E، چهار بیت بالایی 1111 است. برای آزمایش رزرو شده است.

برای سهولت خواندن آدرس ها در ادبیات فنی، برنامه های کاربردی و غیره، آدرس های IP به صورت چهار نشان داده شده است اعداد اعشاریبا نقطه از هم جدا شده اند هر یک از این اعداد مربوط به یک اکتت (8 بیت) از آدرس IP است. این فرمت اعشاری نقطه‌دار (Notation Decimal-Point) یا نماد اعشاری نقطه‌دار (شکل 6.25) نامیده می‌شود.

روی میز. 6.10 محدوده مقادیر اعشاری را برای سه کلاس آدرس فهرست می کند. روی میز. 6.10 ورودی XXX به معنای یک فیلد دلخواه است.

جدول 6.10. محدوده مقدار آدرس

برخی از آدرس های IP را نمی توان به دستگاه های موجود در شبکه اختصاص داد (جدول 6.11).

همانطور که در این جدول نشان داده شده است، در آدرس های IP رزرو شده، تمام بیت هایی که روی صفر تنظیم شده اند با هر یک از آنها مطابقت دارند این دستگاه، یا این شبکه و آدرس های IP که همه بیت های آن روی 1 تنظیم شده اند در پخش اطلاعات استفاده می شود. برای اشاره به کل شبکه IP به عنوان یک کل، از یک آدرس با شماره دستگاه استفاده می شود که همه بیت ها روی "0" تنظیم شده اند. آدرس شبکه کلاس A 127.0.0.0 برای Loopback محفوظ است و برای آزمایش ارتباط بین فرآیندها در همان ماشین معرفی شده است. هنگامی که یک برنامه از آدرس Loopback استفاده می کند، پشته پروتکل TCP/IP این داده ها را بدون ارسال چیزی به شبکه به برنامه برمی گرداند. علاوه بر این، این آدرس می تواند برای تعامل فرآیندهای جداگانه در یک ماشین استفاده شود. بنابراین، در شبکه های IP، تخصیص آدرس های IP که با 127 شروع می شود به دستگاه ها ممنوع است.

علاوه بر انتقال داده های هدایت شده به یک ایستگاه کاری خاص، انتقال پخش به طور فعال استفاده می شود که در آن تمام ایستگاه های موجود در شبکه فعلی یا مشخص شده اطلاعات را دریافت می کنند. دو نوع پخش در پروتکل IP وجود دارد: مستقیم و محدود.

پخش مستقیم به دستگاهی در یک شبکه راه دور اجازه می دهد تا یک دیتاگرام را به همه دستگاه های موجود در همان شبکه ارسال کند. شبکه فعلی. یک دیتاگرام با آدرس پخش فوروارد شده می‌تواند از مسیریاب‌ها عبور کند، اما فقط به همه دستگاه‌های موجود در شبکه مشخص شده تحویل داده می‌شود، نه به همه دستگاه‌ها. در یک پخش مستقیم، آدرس مقصد شامل یک شماره شبکه خاص و یک شماره دستگاه است که همه بیت های آن 0 یا 1 هستند. برای مثال، آدرس های 185.100.255.255 و 185.100.0.0 به عنوان آدرس های پخش مستقیم برای کلاس B در نظر گرفته می شوند. شبکه 185.100.xxx.xxx از نقطه نظر آدرس دهی، عیب اصلی پخش جهت دار این است که دانش شماره شبکه هدف مورد نیاز است.

شکل دوم پخش که پخش محدود نامیده می شود، در شبکه فعلی (شبکه ای که دستگاه فرستنده در آن قرار دارد) پخش می شود. دیتاگرام با آدرس پخش محدود هرگز از روتر عبور نخواهد کرد. در پخش محدود، بیت های شماره شبکه و شماره دستگاه همگی صفر یا یک هستند. بدین ترتیب یک دیتاگرام با آدرس مقصد 255.255.255.255 یا 0.0.0.0 به تمامی دستگاه های موجود در شبکه تحویل داده می شود. روی انجیر شکل 6.26 شبکه های متصل شده توسط روترها را نشان می دهد. روی میز. شکل 6.12 دریافت کنندگان دیتاگرام های پخش ارسال شده توسط ایستگاه کاری A را فهرست می کند.

پروتکل IP از سه روش آدرس دهی پشتیبانی می کند: تک (unicast)، پخش (پخش) و گروهی (مولتی کست).

جدول 6.12. پخش گیرنده های دیتاگرام

در آدرس دهی واحد، دیتاگرام ها به یک دستگاه خاص ارسال می شوند. اجرای این رویکرد دشوار نیست، اما اگر گروه کاریشامل ایستگاه های زیادی است، ممکن است توان عملیاتی کافی نباشد، زیرا همان دیتاگرام بارها ارسال می شود.

با آدرس دهی پخش، برنامه ها یک دیتاگرام واحد ارسال می کنند که به همه دستگاه های موجود در شبکه تحویل داده می شود. اجرای این رویکرد حتی ساده تر است، اما اگر در این مورد ترافیک پخش محدود به آن نباشد شبکه محلی(و به عنوان مثال، شبکه دیگری با استفاده از روترها ارسال می شود)، پس شبکه جهانی باید پهنای باند قابل توجهی داشته باشد. اگر اطلاعات فقط برای گروه کوچکی از دستگاه ها در نظر گرفته شده باشد، این رویکرد غیرمنطقی به نظر می رسد.

در چندپخشی، دیتاگرام ها به گروه خاصی از دستگاه ها تحویل داده می شوند. در عین حال (که هنگام کار در شبکه های توزیع شده بسیار مهم است) ترافیک اضافی ایجاد نمی شود. دیتاگرام های چندپخشی و تک آدرسی در آدرس متفاوت هستند. در هدر یک دیتاگرام IP با چندپخشی، به جای آدرس های IP کلاس های A، B، C، یک آدرس کلاس D، یعنی یک آدرس گروه وجود دارد.

یک آدرس گروه به برخی از دستگاه های گیرنده یا به عبارت دیگر به یک گروه اختصاص داده می شود. فرستنده این آدرس چندپخشی را در هدر دیتاگرام IP می نویسد. دیتاگرام به تمامی اعضای گروه تحویل داده خواهد شد. چهار بیت اول آدرس کلاس D 1110 است. بقیه آدرس (28 بیت) توسط شناسه گروه اشغال شده است (شکل 6.27).

در قالب اعشاری نقطه‌دار، آدرس‌های گروه از 224.0.0.0 تا 239.255.255.255 متغیر است. روی میز. شکل 6.13 طرح تخصیص آدرس کلاس D را نشان می دهد.

جدول 6.13. تخصیص آدرس کلاس D

همانطور که از جدول مشخص است. 6.13، 256 آدرس اول رزرو شده است. به طور خاص، این محدوده برای پروتکل های مسیریابی و سایر پروتکل های سطح پایین رزرو شده است. روی میز. 6.14 حاوی برخی از آدرس های IP کلاس D رزرو شده است.

بالاتر از این محدوده است گروه بزرگآدرس های اختصاص داده شده برای برنامه های کاربردی در حال اجرا در اینترنت. بالاترین محدوده آدرس (تقریبا 16 میلیون آدرس) برای اهداف اداری در شبکه های محلی است. آدرس های گروه کلاس D توسط یک سازمان ویژه به نام IANA به صورت مرکزی مدیریت و ثبت می شوند.

Multicast را می توان در دو سطح از مدل OSI - کانال (لایه پیوند داده) و شبکه (لایه شبکه) پیاده سازی کرد. پروتکل های انتقال لایه پیوند، مانند اترنت و FDDI، می توانند آدرس دهی تک، پخش و چندپخشی را پشتیبانی کنند. چندپخشی لایه پیوند به ویژه اگر در سخت افزار روی NIC پشتیبانی شود مؤثر است.

برای پشتیبانی از IANA multicasting، بلوکی از آدرس‌های اترنت چندپخشی اختصاص داده شده است که از 01-00-5E (با نماد هگزا دسیمال) شروع می‌شود. یک آدرس IP چندپخشی را می توان به آدرسی در این بلوک ترجمه کرد. اصل ترجمه بسیار ساده است: 23 بیت پایینی شناسه گروه IP در 23 بیت پایین آدرس اترنت کپی می شود. توجه داشته باشید که این طرح تا 32 گروه IP مختلف را با آدرس اترنت یکسان مرتبط می کند، زیرا 5 بیت بعدی شناسه گروه IP نادیده گرفته می شود.

جدول 6.14. آدرس های کلاس D رزرو شده

نشانی	هدف
224.0.0.1	همه دستگاه های موجود در زیر شبکه
224.0.0.2	همه روترها در زیر شبکه
224.0.0.4	همه روترهای DVMRP
224.0.0.5	همه روترهای MOSPF
224.0.0.9	RIP IP نسخه II
224.0.1.7	اخبار صوتی
224.0.1.11	صوتی IEFT
224.0.1.12	ویدئوی IEFT

اگر فرستنده و گیرنده متعلق به یک شبکه فیزیکی باشند، فرآیند ارسال و دریافت فریم های چندپخشی در لایه پیوند بسیار ساده است. فرستنده آدرس IP گروه گیرندگان را مشخص می کند و NIC این آدرس را به آدرس اترنت گروه مربوطه ترجمه کرده و فریم را ارسال می کند.

اگر فرستنده و گیرنده در زیرشبکه های مختلفی باشند که توسط روترها به هم متصل شده اند، تحویل دیتاگرام مشکل است. در این مورد، روترها باید یکی از پروتکل های مسیریابی چندپخشی (DVMRP، MOSPF، PIM - زیر را ببینید) پشتیبانی کنند. طبق این پروتکل‌ها، روتر یک درخت تحویل می‌سازد و ترافیک چندپخشی را به درستی ارسال می‌کند. علاوه بر این، هر روتر باید از پروتکل مدیریت گروه (IGMP) برای تعیین حضور اعضای گروه در زیرشبکه های متصل مستقیم پشتیبانی کند (شکل 6.28).

اگر روزی مجبور شوید به سرعت بفهمید VoIP (صدا از طریق IP) چیست و همه این اختصارات وحشی به چه معنا هستند، امیدوارم این راهنما به شما کمک کند. فوراً متذکر می شوم که مسائل مربوط به پیکربندی انواع اضافی خدمات تلفن (مانند انتقال تماس، پست صوتی، تماس های کنفرانسی و غیره) در اینجا در نظر گرفته نمی شوند.

بنابراین، آنچه در زیر برش به آن خواهیم پرداخت:

1. مفاهیم اولیه تلفن: انواع دستگاه ها، طرح های اتصال
2. بسته‌ای از پروتکل‌های SIP/SDP/RTP: چگونه کار می‌کند
3. نحوه انتقال اطلاعات در مورد دکمه های فشرده شده
4. انتقال صدا و فکس چگونه کار می کند؟
5. پردازش سیگنال دیجیتال و تضمین کیفیت صدا در تلفن IP

1. مفاهیم اولیه تلفن

به طور کلی، طرح اتصال یک مشترک محلی به یک ارائه دهنده تلفن از طریق یک خط تلفن معمولی به شرح زیر است:

در کنار ارائه دهنده (PBX)، یک ماژول تلفن با پورت FXS (مشترک تبادل خارجی) نصب شده است. یک دستگاه تلفن یا فکس با پورت FXO (Offreign EXchange Office) و ماژول شماره گیر در منزل یا دفتر کار نصب می شود.

توسط ظاهرپورت های FXS و FXO تفاوتی ندارند، آنها کانکتورهای معمولی 6 پین RJ11 هستند. اما با استفاده از یک ولت متر، تشخیص آنها بسیار آسان است - همیشه مقداری ولتاژ در پورت FXS وجود خواهد داشت: 48/60 ولت هنگامی که گوشی در قلاب است، یا 6-15 ولت در هنگام مکالمه. در FXO، اگر به خط وصل نباشد، ولتاژ همیشه 0 است.

برای انتقال داده ها از طریق یک خط تلفن، منطق اضافی در سمت ارائه دهنده مورد نیاز است که می تواند در ماژول SLIC (مدار رابط خط مشترک) و در سمت مشترک - با استفاده از ماژول DAA (ترتیب دسترسی مستقیم) پیاده سازی شود.

تلفن های بی سیم DECT (ارتباطات بی سیم اروپایی دیجیتال) در حال حاضر بسیار محبوب هستند. از نظر دستگاه، آنها شبیه تلفن های معمولی هستند: آنها همچنین دارای یک پورت FXO و یک ماژول شماره گیر هستند، اما یک ماژول نیز دارند. ارتباطات بی سیمایستگاه ها و گوشی ها با فرکانس 1.9 گیگاهرتز.

مشترکین به شبکه PSTN (شبکه تلفن سوئیچ شده عمومی) متصل می شوند - شبکه تلفناستفاده عمومی، PSTN، PSTN است. شبکه PSTN را می توان با استفاده از سازماندهی کرد فن آوری های مختلف: ISDN، اپتیک، POTS، اترنت. یک مورد خاص از PSTN، زمانی که از یک خط معمولی آنالوگ/مسی استفاده می شود - POTS (سرویس تلفن قدیمی ساده) - یک سیستم تلفن قدیمی ساده.

با توسعه اینترنت ارتباطات تلفنیبه سطح جدیدی منتقل شد. تلفن های ثابت بیشتر و کمتر مورد استفاده قرار می گیرند، عمدتاً برای نیازهای رسمی. تلفن های DECT کمی راحت تر هستند، اما محدود به محیط خانه هستند. تلفن های GSM حتی راحت تر هستند، اما توسط مرزهای کشور محدود می شوند (رومینگ گران است). اما برای تلفن های IP، آنها نیز نرم افزار (SoftPhone) هستند، هیچ محدودیتی وجود ندارد، به جز دسترسی به اینترنت.

اسکایپ معروف ترین نمونه از تلفن های نرم افزاری است. خیلی کارها می تواند انجام دهد، اما دو ایراد مهم دارد: معماری بسته و شنود استراق سمع که توسط مقامات مشخص است. به دلیل اولی، امکان ایجاد میکروشبکه تلفن خود وجود ندارد. و به دلیل دوم - وقتی از شما جاسوسی می شود، به خصوص در گفتگوهای شخصی و تجاری، چندان خوشایند نیست.

خوشبختانه، پروتکل‌های باز برای ایجاد شبکه‌های ارتباطی خود با موارد مثبت وجود دارد - اینها SIP و H.323 هستند. در پروتکل SIP چند گوشی نرم افزاری بیشتر از H.323 وجود دارد که می توان آن را با سادگی و انعطاف نسبی آن توضیح داد. اما گاهی اوقات این انعطاف‌پذیری می‌تواند چوب بزرگی را در چرخ قرار دهد. هر دو پروتکل SIP و H.323 از پروتکل RTP برای انتقال داده های رسانه استفاده می کنند.

در نظر گرفتن اصول اساسیپروتکل SIP برای درک چگونگی اتصال دو مشترک.

2. شرح بسته پروتکل های SIP/SDP/RTP

SIP (پروتکل شروع جلسه) - یک پروتکل برای ایجاد یک جلسه (نه فقط یک تلفن) یک پروتکل متنی روی UDP است. همچنین امکان استفاده از SIP از طریق TCP وجود دارد، اما این موارد نادر هستند.

SDP (پروتکل شرح جلسه) پروتکلی است برای مذاکره در مورد نوع داده های ارسال شده (برای صدا و تصویر این کدک ها و فرمت های آنها، برای فکس ها - سرعت ارسال و تصحیح خطا) و آدرس های مقصد آنها (IP و پورت) است. همچنین یک پروتکل متنی است. پارامترهای SDP در بدنه بسته های SIP ارسال می شوند.

RTP (پروتکل حمل و نقل بلادرنگ) یک پروتکل انتقال داده صوتی/تصویری است. این یک پروتکل باینری روی UDP است.

ساختار کلی بسته های SIP:

• خط شروع: فیلدی که روش SIP (فرمان) را هنگام درخواست یا نتیجه اجرای روش SIP هنگام پاسخگویی را نشان می دهد.
• سرصفحه ها: اطلاعات تکمیلیبه خط شروع، قالب بندی شده به عنوان رشته های حاوی جفت ATTRIBUTE: VALUE.
• متن: داده های باینری یا متنی. معمولاً برای ارسال پارامترها یا پیام های SDP استفاده می شود.

در اینجا یک نمونه از دو بسته SIP برای یک روش تنظیم تماس معمولی آورده شده است:

در سمت چپ محتوای بسته SIP INVITE است، در سمت راست پاسخ به آن است - SIP 200 OK.

فیلدهای اصلی قاب شده اند:

• Method/Request-URI شامل متد SIP و URI است. در مثال، جلسه برقرار است - روش INVITE، مشترک فراخوانی می شود [ایمیل محافظت شده]
• Status-Code - کد پاسخ برای دستور SIP قبلی. AT این مثالدستور با موفقیت انجام شد - کد 200، i.e. مشترک 555 تلفن را برداشت.
• از طریق - آدرسی که مشترک 777 منتظر پاسخ است. برای پیام 200 OK، این فیلد از پیام INVITE کپی می شود.
• From/To - نمایش نام و آدرس فرستنده و گیرنده پیام. برای پیام 200 OK، این فیلد از پیام INVITE کپی می شود.
• Cseq شامل شماره ترتیب دستور و نام روشی است که پیام داده شده به آن اشاره دارد. برای پیام 200 OK، این فیلد از پیام INVITE کپی می شود.
• Content-Type - نوع داده ای که در بلوک Body منتقل می شود، در این مورد داده SDP.
• اطلاعات اتصال - آدرس IP که مشترک دوم باید بسته های RTP را به آن ارسال کند (یا بسته های UDPTL در صورت ارسال فکس از طریق T.38).
• شرح رسانه - درگاهی که مشترک دوم باید داده های مشخص شده را به آن ارسال کند. در این مورد، اینها صدا (RTP/AVP صوتی) و لیستی از انواع داده های پشتیبانی شده - PCMU، PCMA، کدک های GSM و سیگنال های DTMF هستند.

یک پیام SDP از خطوطی شامل جفت FIELD=VALUE تشکیل شده است. زمینه های اصلی عبارتند از:

• o- مبدا، نام سازمان دهنده جلسه و شناسه جلسه.
• با- اطلاعات اتصال، فیلد قبلا توضیح داده شده است.
• متر- توضیحات رسانه، فیلد قبلا توضیح داده شده است.
• آ- ویژگی های رسانه، فرمت داده های ارسال شده را مشخص کنید. به عنوان مثال، آنها جهت صدا - دریافت یا انتقال (sendrecv) را نشان می دهند، برای کدک ها نرخ نمونه برداری و شماره اتصال (rtpmap) را نشان می دهند.

بسته‌های RTP حاوی داده‌های صوتی/تصویری هستند که در قالب خاصی کدگذاری شده‌اند. این قالبدر قسمت PT (نوع محموله) مشخص شده است. جدولی از نحوه مطابقت مقدار این فیلد با یک قالب خاص در نمایه ویدیوی صوتی https://wikipedia org wiki RTP آورده شده است.

همچنین، بسته‌های RTP حاوی یک شناسه SSRC منحصر به فرد (منبع جریان RTP را مشخص می‌کند) و یک مهر زمانی (مهر زمانی، برای پخش یکنواخت صدا یا ویدیو استفاده می‌شود).

نمونه ای از تعامل بین دو مشترک SIP از طریق سرور SIP (استریسک):

به محض راه اندازی یک تلفن SIP، اولین کاری که انجام می دهد این است که خودش را با آن ثبت کند سرور راه دور(SIP Registar)، یک پیام SIP REGISTER برای آن ارسال می کند.

هنگام تماس با مشترک، یک پیام SIP INVITE ارسال می شود که بدنه آن حاوی یک پیام SDP حاوی پارامترهای انتقال صدا / تصویر است (کدک ها پشتیبانی می شوند، کدام IP و پورت برای ارسال صدا و غیره).

هنگامی که مشترک از راه دور تلفن را برمی دارد، یک پیام SIP 200 OK نیز با پارامترهای SDP دریافت می کنیم، فقط مشترک از راه دور. با استفاده از پارامترهای SDP ارسالی و دریافتی، می توانید یک جلسه صوتی/تصویری RTP یا یک جلسه فکس T.38 را تنظیم کنید.

اگر پارامترهای SDP دریافتی مناسب ما نبود، یا سرور SIP میانی تصمیم گرفت ترافیک RTP را از طریق خود عبور ندهد، در این صورت روش مذاکره مجدد SDP، به اصطلاح REINVITE، انجام می شود. به هر حال، دقیقاً به دلیل این روش است که سرورهای پراکسی SIP رایگان یک اشکال دارند - اگر هر دو مشترک در یک شبکه محلی باشند و سرور پراکسی پشت NAT باشد، پس از هدایت ترافیک RTP، هیچ یک از مشترکین نمی شنوند. یکی دیگر.

پس از پایان مکالمه، مشترکی که تلفن را قطع کرده است یک پیام SIP BYE ارسال می کند.

3. انتقال اطلاعات در مورد دکمه های فشرده

گاهی اوقات، پس از برقراری جلسه، در حین تماس، دسترسی به خدمات اضافی (VAS) مورد نیاز است - توقف تماس، انتقال، پست صوتی و غیره. - که به ترکیب خاصی از دکمه های فشار داده شده واکنش نشان می دهند.

بنابراین، در یک خط تلفن معمولی، دو راه برای شماره گیری وجود دارد:

• پالس - از نظر تاریخی اولین مورد، عمدتاً در تلفن های دارای شماره گیر چرخشی استفاده می شد. شماره گیری به دلیل بسته شدن و باز شدن متوالی خط تلفن با توجه به رقم شماره گیری شده اتفاق می افتد.
• Tone - شماره گیری با کدهای DTMF (Dual-Tone Multi-Frequency) - هر دکمه تلفن دارای ترکیبی از دو سیگنال سینوسی (تن) است. با اجرای الگوریتم گورتزل، تعیین دکمه فشرده شده بسیار آسان است.

در طول مکالمه، روش پالس برای انتقال دکمه فشار داده شده ناخوشایند است. بنابراین، تقریباً 1 ثانیه طول می کشد تا "0" ارسال شود (10 پالس هر کدام 100 میلی ثانیه: 60 میلی ثانیه - شکست خط، 40 میلی ثانیه - بسته شدن خط) به اضافه 200 میلی ثانیه برای مکث بین ارقام. علاوه بر این، کلیک های مشخصه اغلب در طول شماره گیری پالس شنیده می شود. بنابراین در تلفن معمولی فقط از حالت تن دسترسی به VAS استفاده می شود.

در تلفن VoIP، اطلاعات مربوط به دکمه های فشرده شده را می توان به سه روش انتقال داد:

1. DTMF Inband - تولید یک آهنگ صوتی و انتقال آن در داخل داده های صوتی (کانال RTP فعلی) یک شماره گیری زنگ معمولی است.
2. RFC2833 - یک بسته RTP رویداد تلفنی ویژه ایجاد می شود که حاوی اطلاعاتی در مورد کلید فشرده، حجم و مدت زمان است. تعداد فرمت RTP که بسته های DTMF RFC2833 در آن ارسال خواهند شد در متن پیام SDP مشخص شده است. به عنوان مثال: a=rtpmap:98 phone-event/8000.
3. SIP INFO - یک بسته SIP INFO با اطلاعاتی در مورد کلید فشرده، حجم و مدت زمان تشکیل می شود.

انتقال DTMF در داخل داده های صوتی (Inband) دارای چندین معایب است - اینها منابع سربار هنگام تولید / جاسازی زنگ ها و هنگام تشخیص آنها، محدودیت های برخی از کدک ها که می توانند کدهای DTMF را تحریف کنند، و قابلیت اطمینان انتقال ضعیف (اگر بخشی از بسته ها از بین برود، پس تشخیص ممکن است با دو بار فشار دادن یک کلید رخ دهد).

تفاوت اصلی بین DTMF RFC2833 و SIP INFO: اگر سرور پروکسی SIP توانایی انتقال مستقیم RTP را بین مشترکین با دور زدن خود سرور داشته باشد (به عنوان مثال، canreinvite=yes در ستاره)، سرور متوجه بسته‌های RFC2833 نخواهد شد. نتیجه آن می شوند خدمات غیر قابل دسترس DVO. بسته های SIP همیشه از طریق سرورهای پروکسی SIP منتقل می شوند، بنابراین VAS همیشه کار خواهد کرد.

4. انتقال صدا و فکس

همانطور که قبلا ذکر شد، پروتکل RTP برای انتقال داده های رسانه استفاده می شود. بسته های RTP همیشه فرمت داده های ارسالی (کدک) را مشخص می کنند.

کدک های مختلفی برای انتقال صدا وجود دارد، با نسبت های مختلف بیت ریت / کیفیت / پیچیدگی، کدک های باز و بسته وجود دارد. هر نرم افزاری باید از کدک های G.711 alaw/ulaw پشتیبانی داشته باشد، پیاده سازی آنها بسیار ساده است، کیفیت صدا بد نیست، اما به پهنای باند 64 کیلوبیت بر ثانیه نیاز دارند. به عنوان مثال، کدک G.729 تنها به 8 کیلوبیت در ثانیه نیاز دارد، اما بسیار CPU فشرده است، و رایگان نیست.

برای ارسال فکس معمولا از کدک G.711 یا پروتکل T.38 استفاده می شود. ارسال فکس با استفاده از کدک G.711 مربوط به ارسال فکس با استفاده از پروتکل T.30 است، گویی که فکس از طریق یک خط تلفن معمولی ارسال شده است، اما در همان زمان سیگنال آنالوگاز خط بر اساس قانون alaw/ulaw دیجیتالی می شود. به این فکس Inband T.30 نیز می گویند.

فکس هایی که از پروتکل T.30 استفاده می کنند، پارامترهای خود را بررسی می کنند: سرعت انتقال، اندازه دیتاگرام، نوع تصحیح خطا. پروتکل T.38 بر اساس پروتکل T.30 است، اما برخلاف انتقال Inband، دستورات T.30 تولید شده و دریافتی مورد تجزیه و تحلیل قرار می گیرند. بنابراین، نه داده های خام، بلکه فرمان های کنترل فکس شناسایی می شود.

دستور T.38 با استفاده از پروتکل UDPTL که یک پروتکل مبتنی بر UDP است و فقط برای T.38 استفاده می شود، منتقل می شود. پروتکل‌های TCP و RTP نیز می‌توانند برای انتقال دستورات T.38 استفاده شوند، اما کمتر مورد استفاده قرار می‌گیرند.

مزایای اصلی T.38 کاهش بار شبکه و قابلیت اطمینان بیشتر در مقایسه با ارسال فکس Inband است.

مراحل ارسال فکس در حالت T.38 به شرح زیر است:

1. یک اتصال صوتی معمولی با استفاده از هر کدک برقرار می شود.
2. هنگامی که کاغذ در دستگاه فکس فرستنده بارگذاری می شود، به صورت دوره ای سیگنال T.30 CNG (Calling Tone) را ارسال می کند تا نشان دهد که آماده ارسال فکس است.
3. در سمت دریافت، یک سیگنال T.30 CED (به نام شناسایی ترمینال) تولید می شود - این آمادگی برای دریافت فکس است. این سیگنال یا پس از فشار دادن دکمه "دریافت فکس" ارسال می شود یا فکس آن را به طور خودکار انجام می دهد.
4. سیگنال CED در سمت ارسال کننده شناسایی می شود و رویه SIP REINVITE رخ می دهد و پیام SDP نوع T.38 را نشان می دهد: m=image 39164 udptl t38.

ارسال فکس از طریق اینترنت ترجیحاً در T.38. اگر فکس باید در داخل دفتر یا بین اشیایی که اتصال پایدار دارند ارسال شود، می توان از انتقال فکس Inband T.30 استفاده کرد. در این حالت، قبل از ارسال فکس، روش لغو اکو باید خاموش شود تا تحریف اضافی ایجاد نشود.

اطلاعات بسیار دقیق در مورد فکس در کتاب "فکس، مودم و متن برای تلفن IP" نوشته دیوید هانس و گونزالو سالگوئیرو نوشته شده است.

5. پردازش سیگنال دیجیتال (DSP). اطمینان از کیفیت صدا در تلفن IP، نمونه های تست

ما با پروتکل های ایجاد یک جلسه مکالمه (SIP / SDP) و روش انتقال صدا از طریق یک کانال RTP سروکار داشته ایم. یک سوال مهم وجود داشت - کیفیت صدا. از یک طرف، کیفیت صدا توسط کدک انتخاب شده تعیین می شود. اما از سوی دیگر، رویه های DSP اضافی (DSP - پردازش سیگنال دیجیتال) هنوز مورد نیاز است. این رویه ها ویژگی های تلفن VoIP را در نظر می گیرند: همیشه از هدست با کیفیت بالا استفاده نمی شود، بسته ها در اینترنت افت می کنند، گاهی اوقات بسته ها به طور ناهموار می رسند، توان عملیاتیشبکه ها نیز لاستیکی نیستند.

رویه های اساسی که کیفیت صدا را بهبود می بخشد:

VAD(ردیاب فعالیت صوتی) - روشی برای تعیین فریم هایی که حاوی صدا (قاب صدای فعال) یا سکوت (قاب صدای غیرفعال) هستند. این جداسازی می تواند بار شبکه را به میزان قابل توجهی کاهش دهد، زیرا انتقال اطلاعات در مورد سکوت به داده های بسیار کمتری نیاز دارد (برای انتقال سطح نویز کافی است یا اصلاً هیچ چیز وجود ندارد).

برخی از کدک ها از قبل حاوی رویه های VAD (GSM, G.729) هستند، در حالی که برخی دیگر (G.711, G.722, G.726) باید آنها را پیاده سازی کنند.

اگر VAD برای انتقال اطلاعات در مورد سطح نویز پیکربندی شده باشد، بسته های SID ویژه (توصیفگر درج سکوت) در قالب سیزدهم CN (نویز راحت) RTP ارسال می شود.

شایان ذکر است که بسته های SID را می توان توسط سرورهای پروکسی SIP رها کرد، بنابراین برای تأیید، توصیه می شود انتقال ترافیک RTP را از سرورهای SIP پیکربندی کنید.

CNG(تولید نویز راحتی) - روشی برای تولید نویز راحتی بر اساس اطلاعات بسته های SID. بنابراین، VAD و CNG با هم کار می کنند، اما روند CNG بسیار کمتر مورد تقاضا است، زیرا همیشه نمی توان به کار CNG، به ویژه در حجم کم، توجه کرد.

PLC(پنهان سازی از دست دادن بسته) - روش بازیابی جریان صوتی در صورت از دست دادن بسته. حتی با 50 درصد از دست دادن بسته، یک الگوریتم PLC خوب می تواند به کیفیت گفتار قابل قبولی دست یابد. تحریف، البته، خواهد بود، اما شما می توانید کلمات را تشخیص دهید.

ساده ترین راه برای شبیه سازی از دست دادن بسته ها (در لینوکس) استفاده از ابزار tc از بسته iproute با ماژول netem است. فقط شکل دهی ترافیک خروجی را انجام می دهد.

نمونه ای از اجرای شبیه سازی شبکه با از دست دادن بسته 50٪:

Tc qdisc change dev eth1 root netem از دست دادن 50%

غیرفعال کردن شبیه سازی:

ریشه Tc qdisc del dev eth1

بافر جیتر- روشی برای خلاص شدن از اثر جیتر، زمانی که فاصله بین بسته های دریافتی بسیار تغییر می کند و در بدترین حالت منجر به ترتیب نادرست بسته های دریافتی می شود. همچنین این اثر منجر به قطع گفتار می شود. برای از بین بردن اثر جیتر، لازم است یک بافر بسته در سمت دریافت کننده با اندازه کافی برای بازگرداندن ترتیب اولیه ارسال بسته ها در یک بازه زمانی مشخص، اجرا شود.

همچنین می توانید با استفاده از ابزار tc افکت جیتر را شبیه سازی کنید (فاصله بین لحظه مورد انتظار رسیدن بسته و لحظه واقعی می تواند تا 500 میلی ثانیه باشد):

tc qdisc افزودن dev eth1 ریشه netem تاخیر 500 میلی ثانیه ترتیب مجدد 99%

LEC(خطاکننده اکو خط) - روشی برای حذف اکو محلی هنگامی که مشترک از راه دور شروع به شنیدن صدای خود می کند. ماهیت آن این است که سیگنال دریافتی را با یک ضریب مشخص از سیگنال ارسالی کم کنید.

پژواک می تواند به دلایل مختلفی رخ دهد:

• اکو آکوستیک به دلیل مسیر صوتی با کیفیت پایین (صدای بلندگو وارد میکروفون می شود).
• اکو الکتریکی به دلیل عدم تطابق امپدانس بین تلفنو ماژول SLIC. در بیشتر موارد، این در مدارهایی رخ می دهد که یک خط تلفن 4 سیم را به 2 سیم تبدیل می کند.

پیدا کردن دلیل (اکوی صوتی یا الکتریکی) دشوار نیست: مشترکی که در سمت او اکو ایجاد شده است باید میکروفون را خاموش کند. اگر اکو همچنان رخ دهد، آنگاه الکتریکی است.

برای اطلاعات بیشتر در مورد رویه‌های VoIP و DSP، به پردازش سیگنال صوتی و فکس VoIP مراجعه کنید. پیش‌نمایش در Google Books موجود است.

این یک مرور نظری سطحی از VoIP را کامل می کند. اگر علاقه مند هستید، نمونه ای از اجرای عملی مینی سانترال بر روی پلت فرم سخت افزاری واقعی را می توان در مقاله بعدی در نظر گرفت.

[!?] پرسش ها و نظرات استقبال می شود. آنها توسط نویسنده مقاله دیمیتری والنتو، مهندس نرم افزار در مرکز طراحی الکترونیک Promwad پاسخ داده خواهد شد.

برچسب ها:

• برای مبتدی ها
• برای تازه کارها

افزودن برچسب