تکنولوژی WebRTC
نویسنده : امیرحسین پوریا ، کارشناسی ارشد نرم افزار
در تاریخ 1 ژوئن 2011 ، گوگل فناوری جدیدی تحت عنوان WebRTC منتشر کرد. وب آر تی سی مخفف Web Real-Time Communications به معنی ارتباطات بلادرنگ در وب است. WebRTC یک فریمورک متن باز است که توسط گوگل و موزیلا حمایت مالی می شود و کمک می کند تا صدا،ویدیو و دیتا را بدون پلاگین، اپلیکیشن نیتیو و یا هرگونه نرم افزار به اصطلاح third-party بصورت نظیر به نظیر انتقال دهید. ( همچنین مایکروسافت در تلاش است تا استانداردی را تعریف کند که به توسعه دهندگان وب با Html و Javascript ، اجازه دسترسی به میکروفن و وب کم دستگاه ها از وب را بدهد. )
این تکنولوژی از انواع پروتکل ها و استاندارد ها از جمله SDP و SIP و NAT و ICE و TCP/UDP و پروتکل های بسیار دیگری استفاده می کند تا بتواند امنیت،تعامل پذیری(بین مرورگر ها) و ارتباطات بلادرنگ نظیربه نظیر مبتنی بر مرورگر را ارئه دهد.
طی چندسال پس از طراحی این فناوری، این پروژه با چندین پروژه دیگر کنفرانس تحت وب آزمایش شد. در سال 2014، WebRTC با ظرفیت محدود در Google Hangouts پیاده سازی شد. توسعه دهندگان پیروزی ها و شکست های زیادی داشتند. آنها بازخورد های زیادی دریافت کردند که به آنها در تکمیل فناوری کمک کرد. اولین انتشار پایدار پروژه WebRTC در می 2018 بود و در ژانویه 2021، WebRTC در لیست پیشنهادی های W3C قرار گرفت.
چندین برنامه اصلی وجود دارد که احتمالا در گذشته از آنها استفاده کرده اید که توسط WebRTC پشتیبانی می شوند. برخی از این موارد عبارتند از:
یک . Google Meet
دو . Google Hangout
سه . Slack
چهار . WhatsApp
پنج . Discord
شش . Facebook Messenger
هفت . Gotomeeting
هشت . Snapchat
نه . Houseparty
ویژگی های WebRTC :
از شاخص ترین ویژگی های WebRTC امکان ارتباط زنده صوتی و تصویری را بر روی مرورگر ها و اپلیکیشن های موبایل می باشد. به عبارت دیگر، هدف نهایی این فناوری جدید، ایجاد ارتباطات صوتی/تصویری سریع در مرورگرهایی است که از استاندارد HTML5 پشتیبانی می کنند. البته این مرورگرها باید درخود، امکان پیادهسازی WebRTC را داشته باشند.
در این روش نیازی به استفاده از برنامه و اکستنشن هایی جانبی مانند نرم افزارهای (جاوا ، فلش ، اکتیو ایکس ، پلاگین و …) برای برقراری ارتباط صوتی / تصویری مطمئن بین مرورگرها نیست. از دیگر ویژگی ها می توان به موارد زیر اشاره کرد :
- تاخیر بسیار کم ( Ultra-Low/Real-Time Latency )
مزیت اصلی WebRTC توانایی آن در پشتیبانی از استریم صدا و تصویر با تاخیر کم است. در واقع، WebRTC قادر به پخش در زمان واقعی است که به این معنی است که عملاً هیچ تاخیری وجود ندارد. - متن باز ( Open-Source )
ماهیت متن باز WebRTC این امکان را برای توسعه دهندگان فراهم می کند که که یک پلتفرم کنفرانس ویدیویی اختصاصی در سایت یا برنامه خود بگنجانند. البته شما برای اینکار نیازمند این هستید که با تیم توسعه دهنده خود مشورت کنید و نیاز سنجی های پیاده سازی آن را برآورد کنید ، چه از نظر هزینه ای و چه از نظر پیچیدگی پیاده سازی و دانش تیم. - کاملا رایگان ( Free )
استفاده از WebRTC کاملا رایگان است، که این مورد آن را بسیار در دسترس می کند. در همین راستا، توسعهدهندگان میتوانند بدون تعهد مالی، این پروژه را آزمایش کنند، که قطعاً یک شرایط برد-برد است. - سازگاری بسیار بالا ( Ultra-Compatibility )
این پروژه تقریباً با هر دستگاه یا مرورگری سازگار است. این سازگاری بیش از هر زمان دیگری مهم است، چرا که کاربران شما در پلتفرم های ویدیو کنفرانس با طیف گسترده ای از دستگاه ها وارد می شوند.
علاوه بر مرورگر کروم، موزیلا نیز با فناوری WebRTC در نسخه های بعد از Firefox 18 سازگاری کامل دارد. مرورگر Opera هم، در نسخه تلفن همراه خود با WebRTC سازگار است. دیگر مرورگرها هم این فناوری را به قابلیتهای خود اضافه کردهاند یا در حال توسعه آن هستند.
بسیار مهم است که مشخص شود این فناوری صددرصد با دستگاه های تلفن همراه سازگار باشد؛ زیرا بسیاری از مردم از تلفن های هوشمند و تبلت های خود برای کنفرانس ویدیویی استفاده می کنند.
- امنیت بالا ( Secure )
در ابتدا، نگرانی هایی در مورد امنیت WebRTC وجود داشت. با این حال، اکنون این پروژه رمزگذاری را در هر تبادل صوتی و تصویری امکان پذیر می کند. این از شنود شدن (Sniffing) کنفرانس های وب شما در برابر اقدامات سودجو و یا رکورد مکالمه شما توسط هکرها محافظت می کند.
از آنجایی که WebRTC داده های در حال مبادله را رمزگذاری می کند، استفاده از شبکه های وای فای عمومی برای تماس ها بی خطر است. - کیفیت بالا ( High-Quality Voice and Video )
WebRTC قادر به برگزاری کنفرانس های وب با کیفیت بسیار بالا است. این بدان معناست که تا زمانی که اینترنت کاربر سریع است، تماس ها با کیفیت صوتی و تصویری عالی انجام می شود. - تطبیق پذیر ( Adaptive )
در WebRTC کیفیت تصویر و صوت به صورت خودکار با سرعت اینترنت شما افزایش و کاهش پیدا میکند و این مورد توسط webRTC تشخیص داده میشود. درضمن نگاوید هم از قابلیت Adaptive BitRate پشتیبانی میکند. - دسترسی به رسانه ها
مشخصات WebRTC با نیاز به مجوز صریح استفاده از دوربین و میکروفن، نگرانیهای احتمالی دسترسی به منابع رسانه ای را برطرف کرده است. دسترسی به یک برنامه WebRTC بدون رضایت کاربر امکان پذیر نیست. به علاوه، هر زمان که دستگاهی استفاده میشود، در رابط کاربری مشتری و سخت افزار آنها نشان داده میشود. - استفاده در کنار سایر تکنولوژی ها
یکی دیگر از مزایای WebRTC قابلیت همکاری با سایر فناوری های ارتباطی از جمله VoIP و ویدئو است. این بدان معناست که WebRTC می تواند با برنامه هایی که از سایر فناوری های ارتباطی مبتنی بر اینترنت استفاده می کنند، با موفقیت ارتباط برقرار کند. - سهولت در استفاده از WebRTC
یکی از ویژگیهای شاحص این فناوری، سهولت استفاده آن است. به این شکل که پس از باز کردن مرورگر، فقط با یک کلیک، قادر به یک چت یا یک تماس تصویری خواهید بود.
در حال حاضر ، گروه کاری مرورگر Chrome در حال کار روی برنامهای هستند که به توسعه دهندگان اجازه دهد، پیش نمایش API جدید Javascript را داشته باشند. در آینده شاهد افزایش قابلیت های این فناوری در کروم خواهیم بود.
Google قبلاً با Chrome (از نسخه 23) در این زمینه همکاری داشته است. Mozilla Firefox با نسخه بتای این روند را ادامه خواهد داد. دیگر مرورگرها هم در صدد اضافه کردن این قابلیت هستند.
فناوری پشت WebRTC بر اساس پایهای است که با فناوری VoIP اولیه پایهگذاری شده بود. اگر آشنایی ندارید، VoIP مخفف Voice Over Internet Protocol است. در اصل، این به تماس های تلفنی اشاره دارد که توسط اینترنت انجام می شود.از آنجایی که این پروژه به طور کامل از ابتدا ساخته نشده است، بسیار سریع توسعه و اجرا شده است.
WebRTC مسئول دو جنبه اصلی در کنفرانس های ویدیویی است. اول، مسئول ضبط رسانه در دستگاه شما است. این بدان معناست که WebRTC فناوری است که به دستگاه شما میگوید ضبط را شروع کند. دوم اینکه وظیفه انتقال داده ها بین دو دستگاه را بر عهده دارد.
برای مخابره کردن ویدیو آن هم با کیفیتها و بیتریتهای مختلف هم API خاصی وجود دارد. یکی دیگر از APIهای WebRTC که نام آن MediaStream API است، به توسعهدهنده اجازه میدهد که صدا را سریع پردازش کند، قطع یا متوقف کند و همینطور صداهای دیگری را اضافه کند.
بنابراین WebRTC یکی از کاربردیترین تکنولوژیهای وب است و توانمندیهای بسیاری دارد؛ ویژگی مشترک کاربردهای WebRTC همان ارتباط آنی یا Realtime است.
سرویس Hello موزیلا نمونه ای از کاربردهای WebRTC برای تماس ویدیویی است و این روزها سرویسهای مشابه زیادی میبینیم. حتی Skype هم با نسخهی خاصی به اسم Skype for Web از توانمندی WebRTC بهره گرفته تا چت ویدیویی را سادهتر کند.
در بازیهای آنلاین هم میتوان از WebRTC بهره گرفت. بازی The Hobbit: The Battle for Five Armies یکی از نمونههای این کاربرد است و قبل از معرفی نسخهی نهایی که به صورت نصبی است، توجه گیمرها را به خود جلب میکند.
طبق معمول مرورگر پیشرفتهی گوگل کروم و موزیلا فایرفاکس بهترین پشتیبانی را به عمل میآورند ولیکن این دو مورد هم کمی ناقص به نظر میرسند. مثلاً فایرفاکس از Simulcast که امکان مخابره کردن ویدیو با کیفیتهای مختلف را فراهم میکند، پشتیبانی نمیکند و گوگل کروم هم از استریم ویدیوهای فشرده شده طبق استاندارد H.264 پشتیبانی نمیکند.
مرورگر Opera هم با توجه به استفاده از موتور رندرینگ گوگل کروم، وضعیت خوبی دارد اما نه به کاملی گوگل کروم. مثلا Screen Sharing یا همان به اشتراک گذاری صفحه در آن وجود ندارد!
به لیست کامل پشتیبانیها توجه فرمایید، متأسفانه اینترنت اکسپلورر مایکروسافت و سافاری اپل در پشتیبانی از APIهای WebRTC بسیار ضعیف یا دقیقتر بگوییم کاملاً ناتوان هستند.
خبر ناگوار این است که مایکروسافت و اپل هیچ اشارهای به پشتیبانی از WebRTC در آینده نکردهاند و تنها امیدی که وجود دارد، استفاده از ابزارهای جانبی برای اضافه کردن قابلیتهای WebRTC به این مرورگرهاست. مثلاً افزونهی temasys که این وظیفهی مهم را به صورت رایگان برعهده میگیرد و البته یک اشکال مهم دارد، پشتیبانی نکردن از تمام سایتها و سرویسها.
ادوبی فلش یکی از آن روشهای کهن برقراری ارتباط از طریق مرورگر بود و به دلایل مختلف که یکی از مهمترینها موضوع امنیت است، تقریباً کنار گذاشته شده است. تکنولوژی Flash پر از حفرههای امنیتی است و هکرها به آن علاقهی وافری دارند. البته راه حلی که استیو جابز پیشنهاد کرده یعنی استفاده نکردن از ادوبی فلش هم راه حل جالبی نیست چرا که این روزها مرورگر گوگل کروم به عنوان یک مرورگر امن، از فلش به صورت دیگری پشتیبانی میکند و در حقیقت فلش را در محیط سطل شن (اصطلاحی امنیتی به معنی اجرای اپلیکیشن در محیط حفاظت شده) اجرا مینماید.
WebRTC یک API خاص نیست، گروهی از APIهاست و به همین علت است که امنیت آن به مراتب بالاتر از فلش است. قطعاً WebRTC هم گرفتار مشکلات امنیتی میشود اما عمق فاجعه بسیار کمتر از مشکلاتی است که فلش به دنبال داشته است.
سال پیش بود که یکی از اشکالات WebRTC کشف شد: با نوشتن چند خط کد جاوااسکریپت و استفاده از بخشی از WebRTC میتوان آدرس اینترنتی یا همان IP کاربر VPN را کشف کرد!
هنوز هم دوایی برای درد این مشکل امنیتی پیشنهاد نشده! البته میتوان با افزونهی Disable WebRTC فایرفاکس یا Stop WebRTC کروم، WebRTC را به کلی متوقف کرد. راه دیگر هم ممانعت از اجرای کدهای جاوااسکریپ در مرورگر است. اما هیچ راه حلی که به معنی استفاده نکردن از WebRTC باشد، معرفی نشده است.
( اگر راهی پیدا کردین ، نصف نصف ??)
اساس WebRTC یک سری از APIهای جاوا اسکریپت است. سه API اصلی آن شامل :
«getUserMedia»، «RTCPeerConnection» و «RTCDataChannel»
یک . GetUserMedia (یا MediaStream API)
این API برای دسترسی به وب کم یا میکروفون دستگاه مورد استفاده قرار میگیرد و توسعهدهندگان را قادر میسازد تا به آبجکتهای استریم ویدئو/صدا دسترسی داشته باشند.
این API در انتخاب دستگاه ورودی مورد نظر از بین چندین دستگاه ضبط رسانه کمک میکند. خواه گرفتن عکس پروفایل یک کاربر باشد، یا جمعآوری نمونههای صوتی یا ضبط صدا/ویدئو، این API، وظیفه اجرای این تسکها را برعهده میگیرد.
به عنوان مثال، برای باز کردن یک دستگاه چندرسانهای پیشفرض، به روش زیر عمل میکند:
- فراخوانی متد getUserMedia فوراً درخواست مجوز را ایجاد میکند که برای دسترسی به MediaStream باید توسط کاربر پذیرفته شود.
- در صورت رد مجوز، PermissionDeniedError رخ میدهد.
- اگر هیچ دستگاه سازگاری پیدا نکرد، NotFoundError رخ میدهد.
دو . RTCPeerConnection
این بخش پیچیدهترین و مهمترین قسمت وبآرتیسی است و تمام وظایفی را که در ارتباطات نظیربهنظیر انجام میشود، انجام میدهد.
این وظایف عبارتند از:
- راه اندازی و ایجادکانکشن نظیربهنظیر
- مدیریت Session
- مدیریت کلیه مبادلات پیام پروتکل توصیف Session(SDP) و هندل کردن مذاکرات از طریق کاندیدهای ICE ( در صورت لزوم از STUN و Turn استفاده میکند)
- رمزگذاری و رمزگشایی همزمان جریانهای رسانهای (صوتی/تصویری/متنی)
- رسیدگی به کلیه مسائل مربوط به شبکه مانند تخمین پهنای باند، از دست دادن بسته و غیره
پس از ایجاد کانکشن بین مرورگرها، میتوان جریانهای مولتیمدیا را به مرورگر راه دور ارسال کرد. گرچه، این کار به دلیل وجود سه سناریوی احتمالی زیر آسان به نظر نمیرسد:
- به احتمال زیاد هر دو کانکشن ممکن است در شبکههای خصوصی خود یا در پشت لایههای مختلف NAT نهفته باشند. در نتیجه، هیچ یک از آنها قابل دسترسی نیست.
- آنها اطلاعات اولیه شبکه، مانند IP، پورت و لوکیشن یکدیگر را که برای برقراری ارتباط ضروری است، ندارند.
- و در نهایت، هر دو نیاز به پیمایش NAT دارند.
درک صحیح علت به وجود آمدن این سناریوها در وهله اول مهم است. دلیل ساده آن این است که اینترنت مدتها پیش از پارادایم سرور-کلاینت فراتر رفته است.
تکنولوژی WebRTC به پیمایش NAT جهت میدهد.
قبل از شروع ارتباط بین مرورگرها، به سه چیز نیاز دارد:
- شناسایی کانکشنهای نظیربهنظیر
- تبادل توصیفات Session برای راه اندازی پورتهای رسانه و IPها
- اطلاعات مربوط به دیتای رسانهای که از طریق SDP (پروتکل توصیف Session) منتقل میشود
- امروزه، افراد ترجیح میدهند به وب پشت فایروال یا NAT دسترسی داشته باشند که آدرس IP اصلی شما را پنهان میکند. آنچه عموم مردم به عنوان IP میبینند میتواند با IP اولیه کاربر که در پشت فایروال پنهان شده است بسیار متفاوت باشد و برخی از دستگاهها ترافیک ناخواسته به سمت شبکه کاربران را مسدود میکنند. برخی از شرکتها بدون بررسی اجازه هیچگونه ترافیکی به شبکه خود را نمیدهند. در نتیجه، همیشه نمیتوان با مرورگر همتا که در شبکه خصوصی قرار دارد ارتباط برقرار کرد.
اینجاست که نقش سرورهای STUN (Session Traversal Utilities for NAT) و TURN (Traversl Using Relays around NAT) نمایان میشود.
روند کار به این گونه است:
- درخواست آدرس IP عمومی به سرورهای STUN/TURN ارسال میشود.
- حالا، این سرور با آدرس آی پی که صحیح میداند پاسخ میدهد.
- این مجموعه ای از ارتباطات تعاملی (ICE) ایجاد می کند که شامل آدرس IP ، پورت و پروتکل های انتقال است.
- با این اطلاعات در مورد آیپی عمومی و پورت، به راحتی با همتای خود ارتباط برقرار میکند
- از سوی دیگر، مرورگر همتا همین کار را هنگام استفاده از سرور STUN یا TURN انجام میدهد.
در اینجا لازم به ذکر است که سیگنالینگ، بخشی از فریمورک WebRTC نیست و به دلایلی کنار گذاشته شد. برنامههای مختلف ممکن است به پروتکلهای متفاوتی نیاز داشته باشند و گروه WebRTC نمیخواهد انتخابهای توسعه دهندگان را محدود کند.
اتصال همتا هسته اصلی استاندارد WebRTC است. اتصال همتا راهی برای شرکت کنندگان فراهم میکند تا بدون نیاز به سرور واسطه (فراتر از سیگنالینگ) ارتباط مستقیم با همتایان خود برقرار کنند. هر شرکت کننده، رسانه ایجاد شده از API جریان رسانه را میگیرد و آن را به اتصال همتا متصل میکند تا یک خوراک صوتی یا تصویری ایجاد کند. PeerConnection API در پشت صحنه بسیار پیچیده و مهم است. اتصال همتا RTCمذاکرات SDP، پیاده سازی کدکها ، NAT Traversal، از دست دادن بستهها، مدیریت پهنای باند و انتقال رسانه را مدیریت میکند. این ویژگی کمک خواهد که یک ارتباط بدون جیتر برقرار کنید.
سه . RTCDataChannel
RTCDataChannel API برای انتقال دادههای دو جهته از هر نوع داده -رسانه یا غیر از آن- مستقیماً بین طرفین تماس تنظیم شده است. این کانال برای تقلید از API WebSocket طراحی شده است، اما به جای تکیه بر اتصال TCP که تاخیر بالایی دارد و مستعد ابتلا به گلوگاه است، کانالهای داده از جریانهای مبتنی بر UDP با تنظیمات پروتکل انتقال جریان کنترل (SCTP) استفاده میکنند. تحویل قابل اعتماد مانند TCP با کاهش ازدحام در شبکه مانند UDP به کمک این api امکان پذیر است.
به غیر از صدا و تصویر، WebRTC انتقال دوطرفه دادههای دلخواه از جمله چتهای متنی، بازیها و سایر فایلها را از طریق ایپیآی RTCDataChannel مدیریت میکند. هر کانال دیتا از طریق این API متصل میشود.
اهمیت وب آر تی سی در ارتباط نظیر به نظیر آشکار است، اما بهتر است عوامل متعددی مانند واحد کنفرانس چندگانه (MCU)، اجاره چندگانه (multitenancy)، یکپارچهسازی SIP هنگام ساختن یک راهحل برای تماس ویدیویی قابل اعتماد و قوی مورد توجه قرار گیرد. برای توسعهدهندگان، راه بهتری برای ایجاد راه حل تماس ویدیویی وجود دارد - آنها میتوانند یک ارائه دهنده خدمات CPaaS را انتخاب کنند که تمام ویژگیها، بلوکهای سازنده و SDKها را برای ایجاد راهحلهای تماس ویدیویی هیجان انگیز و مقیاس پذیر ارائه میدهد.
برای فعال کردن ارتباطات وبآرتیسی، چهار مرحله زیر مورد نیاز است :
مرحله1: دسترسی به استریم چندرسانهای از طریق وبکم یا میکروفون (توسط متد GetUserMedia که مربوط به API استریم جاوااسکریپت است.)
مرحله 2: اطلاعات اساسی مربوط به شبکه مانند پورتها و آدرسهای IP و این اطلاعات باید از طریق سیگنالدهی با مرورگرهای دیگر به اشتراک گذاشته شوند (قابل انجام توسط متد RTCPeerConnection که توسط API جاوااسکریپت قابل دسترسی است.)
مرحله 3: اطلاعات در مورد پارامترهای دیتای چندرسانهای (قابل انجام توسط RTCPeerConnection که توسط API جاوااسکریپت قابل دسترسی است.)
مرحله 4: انتقال دیتای چندرسانهای (قابل انجام توسط RTCDataChannel که توسط API جاوااسکریپت قابل دسترسی است.)
اضافه کردن صفحه کلید تلفن به مرورگر با WebRTC
یکی دیگر از قابلیت های WebRTC اضافه کردن صفحه کلید تلفن به مرورگرتان است. تصور کنید کارمندان شما بصورت دورکاری در حال کار هستند، اگر بخواهید کارمندانتان در منزل پاسخگوی تلفنها باشند ،بایستی برای هرکدام یک تلفن تحت شبکه تهیه کنید و یا به روش ارزانتر با نصب سافت فون هایی مانند زویپر Zoiper یا آی بیم eyeBaem بر روی کامیپوتر یا لب تاپشان داخلی آنها را نصب و راه اندازی کنید. ولی درنظر داشته باشید برای امنیت تماس تلفنی آنها بایستی به یکی از روش های ارتباطی مانند VPN یا انواع تانل های ارتباطی مانند GRE Tunnel و … به سرور ویپ شما متصل شوند. حال با راه اندازی WebRTC آنها میتوانند بدون نیاز به هیچگونه تلفن سخت افزاری یا تلفن نرم افزاری ( سافت فون ) و حتی عدم نیاز به بستر ارتباط مستقیم با سرور ویپ ،در هرجاییکه به اینترنت دسترسی داشتند ، مرورگر خود را باز کنند. سپس به پروفایل تلفن خود رفته و با وارد کردن نام کاربری و رمزعبور به پنل تلفن WebRTC خود وارد شوند. به همین راحتی میتوانید در هرکجای دنیا کارمند داشته باشید. و آنها به سرور تلفن ویپ شما متصل می شوند.
اتصال مرورگر به مرورگر
پروتکل WebRTC در الستیکس یا ایزابل با استفاده از استانداردهای تعیین شده در مدیریت جریان رسانه برنامهها (SRTP / SRTPC با پروتکل ICE برای مدیریت NAT) ، میتواند مستقیماً از یک مرورگر با مرورگر دیگر، ارتباط برقرار کند. ( الستیکس – Elastix یک سیستم تلفنی مبتنی بر استریسک Asterisk است . الستیکس به عنوان محبوبترین سیستم کدباز شناخته می شود. استریسک نام نرم افزاری در حوزه تلفن های ویپ است. به کمک آن می توان بین چند نقطه تماس تلفنی برقرار کرد. یعنی شخصی در یک مکان میتواند اقدام به شماره گیری کند)
اتصال مرورگر به VoIP
پروتکل WebRTC در ایزابل یا الستیکس، با یک درگاه مناسب، میتواند پیامها را از پروتکل SIP به HTTP (برای سازگاری کامل با سیستمهای VoIP ) تبدیل کند.
در فناوریهای متن باز (Open Source)، مانند Asterisk, Kamailio و … گیتویها و پروکسیهای در دسترسی وجود دارد، که اجازه میدهند، از طریق اتصال به وب، تماسهای سیستم ویپ VoIP ، مدیریت شود.(استریسک Asterisk محبوب ترین سیستم تلفنی ویپ کد باز در دنیا است. در حال حاضر بسیاری از IPPBX های موجود بر مبنای آن تولید شدهاند. این سیستم در اینجا وظیفه جستجو بین شماره ها را دارد. همچنین می تواند مکان مقصد را پیدا کند. )
استریسک 11 با پشتیبانی محلی WebRTC ، به شما امکان می دهد یک مرورگر را به وب سرور استریسک متصل کنید. و با هر دستگاه متصل به Asterisk ارتباط برقرار کنید.
کدک ها ( Codecs )
هر رسانهای قبل از ارسال از طریق اتصال همکار، باید فشرده شود. صدا و تصویر خام برای ارسال کارآمد در زیرساخت های اینترنت فعلی ما خیلی بزرگ هستند. به همین دلیل پس از دریافت رسانه از طریق اتصال همتا، باید از حالت فشرده خارج شود. یک کدک رسانه (رمزگذار-رمزگشای) دقیقاً این کار را انجام میدهد. WebRTC از سه کدک صوتی و دو کدک ویدیویی استفاده میکند:
Audio – PCMU (G.711μ) running at 8,000Hz with a single channel (mono) ;
Audio – PCMA (G.711a) running at 8,000Hz with a single channel (mono) ;
Audio – Opus running at 48,000Hz with two channels (stereo) ;
Video – VP ;
Video – H.264/AVC using Constrained Baseline Profile Level 1.2
کدکهای رسانهای آینده مانند VP9 و H.265 میتوانند در برخی موارد در آینده به استاندارد WebRTC اضافه شوند، اما در حال حاضر اجرایی نیستند. کارشناسان RTC اغلب قادر به اضافه کردن پشتیبانی رمزگذار سفارشی برای تأمین نیازهای مشتری هستند.
منابع
مطلبی دیگر از این انتشارات
جمع آوری لاگ های Kubernetes Pods با استفاده از Fluentd - بخش دوم
مطلبی دیگر از این انتشارات
نصب و کرک Jfrog Artifactory pro در debian10
مطلبی دیگر از این انتشارات
جمع آوری لاگ های Kubernetes Pods با استفاده از Fluentd - بخش اول