آشنایی با WebRTC و نقش آن در آینده صنعت مخابرات و سرویس های ارتباطی
- مــــــوضوع : آشنایی با WebRTC و نقش آن در آینده صنعت مخابرات و سرویس های ارتباطی
- تهيه كننده : رسول ابوالحسنی یکتا
محتویات
[نهفتن]
- ۱ چکیده
- ۲ مقدمه
- ۳ بررسی ادبیات موضوع
- ۴ بدنه تحقیق
- ۵ نتیجه گیری
- ۶ مراجع
چکیده
مقدمه
یکی از چالشهای بزرگ برای وب ، فراهم کردن راهی برای ارتباط انسان ها به وسیله صوت و تصویر بوده وهمواره ارتباط بلادرنگ کاری پیچیده و هزینه بر بوده است . دنیای امروز ما با اینترنتی عجین شده که همان اینترنت سادهی ۱۰ سال پیش نیست. ارتباطاتی که در حال حاضر میتوان از طریق اینترنت برقرار کرد، فقط ایمیلهای سادهی دیروز نیست. حتی ایمیل هم آمیخته به سرویسهای ابری قدرتمند شده ولیکن از همه مهمتر ارتباطاتی است که سالها پیش به پلاگینها و اپلیکیشنهای خاص نیاز داشت و مشکلات زیادی هم در راهکارهای آن روز به چشم میخورد. ارتباطات ویدیویی و صوتی این روزها بسیار ساده شده و WebRTC هم یکی از مقولات جدیدی است که به این سادگی و در عین حال توانمندی کمک زیادی کرده است.
WebRTC به توسعه دهندگانی که به دنبال ایجاد ارتباطات آنی هستند، استفاده از تکنولوژیهای متداول وب یعنی HTML5 ، جاوااسکریپت و CSS را پیشنهاد میکند. مثلاً بخش چت یک بازی مالتیپلیر آنلاین یا یک سایت ساده برای ویدیوکنفرانس را در نظر بگیرید، WebRTC ارتباطات آنی این اپلیکیشنها را ساده میکند.
WebRTC واسط برنامهنویسی یا همان API است، اما نه به شکل یک محصول خاص یا یک واسط برنامهنویسی ویژه؛ در واقع WebRTC شامل گروهی از APIها برای تکمیل بخشهای مختلف یک اپلیکیشن یا ارتباط تحت وب است و هر بخش هم به شکلهای مختلفی در مرورگرها پشتیبانی میشود.
برخی از واسطهای برنامهنوسی (API) در WebRTC مسئول دسترسی به وبکم و میکروفون یک کامپیوتر هستند و برخی دیگر وظایف محیرالعقول دیگری را انجام میدهند. مثلاً API خاصی برای به اشتراکگذاری صفحه با مخاطبین وجود دارد، منظورم از صفحه همان دستاپ یا نرمافزارهای اجرا شدهای است که روی دستاپ نمایش داده میشوند. حتی برای مخابره کردن ویدیو آن هم با کیفیتها و بیتریتهای مختلف هم API خاصی وجود دارد. یکی دیگر از APIهای WebRTC که نام آن MediaStream API است، به توسعهدهنده اجازه میدهد که صدا را سریع پردازش کند، قطع یا متوقف کند و همینطور صداهای دیگری را اضافه کند.
بنابراین WebRTC یکی از کاربردیترین تکنولوژیهای وب است و توانمندیهای بسیاری دارد؛ ویژگی مشترک کاربردهای WebRTC همان ارتباط آنی یا Realtime است.
بررسی ادبیات موضوع
جدول دانش
درخت دانش
بدنه تحقیق
ارتباطات چند رسانه ای تعاملی زمان واقعی از موضوعات تحقیقاتی فعال در زمینه ارتباطات راه دور در سال های اخیر بوده است. کنفرانس های راه دور به طور عمده توسط سیستم های اختصاصی و گران بر اساس دو پروتکل سیگنالینگ برجسته H.323 وSIP مورد حمایت قرار می گرفتند که SIP تطبیق پذیری بیشتری بدست آورد و از این رو تبدیل به استاندارد بالفعل برای VOIP و ویدئو کنفرانس شد . این سیستم ها معمولا نیازمند نرم افزار خاصی بودند که بایستی دانلود و نصب می شد که معمولا یک برنامه سفارشی یا یک افزونه بر روی مرورگر بود . در طول این سالها، ثابت شده است که تهدیدات امنیتی، بی ثباتی سیستم و ناسازگاری ناشی از پشتیبانی از پلاگین مرورگر ممکن است برای هر سیستم عامل متفاوت باشد. با این حال، همگرایی خدمات بسوی محیط وب در حال وقوع است.
اخیرا استانداردهایی برای ارتباطات زمان واقعی نظیر به نظیر منتشر شده است که بطور گسترده توسط مرورگرهای وب مدرن پشتیبانی می شوند بنابر این دیگر نیازی به استفاده از نرم افزارهای خاص برای برقراری ارتباطات real-time وجود ندارد .
WebRTC(Web Real-Time Communication) یک استاندارد و تلاش صنعت برای توسعه مدل مرورگر وب می باشد . برای اولین بار مرورگرها قادر به تبادل رسانه ی زمان واقعی (real-time media) بطور مستقیم با دیگر مرورگرها بصورت نظیر به نظیر (peer-to-peer) شدند .
کنسرسیوم شبکه جهانی وب (W3C) و نیروی ضربت مهندسی اینترنت (IETF) به طور مشترک ، API های جاوا اسکریپت ، استاندارد تگ های HTML5 و پروتوکل های ارتباطی زیرساختی را برای راه اندازی و مدیریت یک کانال ارتباطی قابل اعتماد بین هر جفت از مرورگرهای وب نسل بعدی تعریف کردند .
هدف این استانداردسازی معرفی یک API برای WebRTC است که برنامه تحت وب را قادر می سازد بر روی هر دستگاهی اجرا شود و دسترسی امنی به لوازم جانبی ورودی مانند وبکم و میکروفون داشته باشد تا بتواند دیتا و مدیای زمان واقعی را با یک سیستم راه دور تبادل کند .
WebRTC مجموعه ای از رابط های برنامه نویسی کاربردی جاوا اسکریپت برای استفاده از پروتکل های استاندارد در ارتباطات صوتی، تصویری و دیگر انواع داده های زمان واقعی بصورت نظیر به نظیر در مرورگرهای وب است که بطور گسترده توسط مرورگرهای وب دسکتاپ و موبایل پشتیبانی می شود و ساخت و توسعه ی خدمات ارتباطی بی درنگ بدون هیچ افزونه یا نرم افزار جانبی را امکان پذیر نموده است .
WebRTC ویژگی های از قبیل حق امتیاز کدک های رایگان، حمل و نقل داده ها به صورت امن با پروتکل امن زمان واقعی حمل و نقل (SRTP)، NAT و ... را فراهم می کند. WebRTC هیچ پروتکل سیگنالینگی را به برنامه نویس تحمیل نمی کند و برنامه نویس مختار است تا مکانیزم سیگنالینگ خود را انتخاب کند و می تواند از پروتکل های سیگنالینگ موجود برای ارتباط تلفن های قدیمی و یا سیستم های VOIP استفاده کند و بسته به توپولوژی سیگنالینگ، مدل های مختلف کنفرانس می تواند با WebRTC پیاده سازی شود.
استاندارد WebRTC در حال حاضر تحت فعالیت development.It بصورت یک تلاش مشترک از IETF RTCWeb و گروه های کاری W3C WebRTC می باشد . گروه کاری IETF RTCWeb بر روی پروتکل های اساسی تمرکز دارند و تمرکز W3C WebRTC بر روی توسعه API های جاوااسکریپ برای استفاده مرورگرهاست . Webrtc ارتباط صوتی و تصویری و داده را بین کاربران بصورت نظیر به نظیر بسیار امن تر ، سریعتر و ساده تر با امکان استفاده بر روی دستگاه های مختلف فراهم می سازد. مزایای Webrtc نسبت به تکنولوژی های قدیمی تری که امکان برقراری ارتباط صوتی و تصویری بین کاربران اینترنت را فراهم می کردند را می توان به چند عنوان اصلی تقسیم کرد :
1- کاربردپذیری (Useability)
در تکنولوژی های قدیمی تر برای ارتباط با درایورهای سخت افزار نیاز به نصب افزونه هایی بود که بایستی متناسب با سیستم عامل دستگاه کاربر بر روی سیستم نصب می شد تا مکان استفاده از وبکم ، میکروفن و دیگر سخت افزار ها را فراهم می کرد ، ولی در Webrtc درصورتی که مرورگر دستگاه این تکنولوژی را ساپورت کند فارق از اینکه این دستگاه یک کامپیوتر رومیزی می باشد یا یک لپ تاپ یا تبلت یا موبایل یا هر دستگاه دیگری که قابلیت اتصال به اینترنت داشته باشد و برای مشاهده وب از مرورگر استفاده کند مانند تلوزیون ، تلفن و ... نیاز به نصب هیچ افزونه ای وجود ندارد واین امر باعث خواهد شد این تکنولوژی در مبحث اینترنت اشیا بسیار پرکاربرد باشد .
2- امنیت و حریم خصوصی (security & Privacy)
در تکنولوژی های قدیمی تر مانند Silverlight برای ارتباط صوتی و تصویری میان کاربران لازم بود تا ارتباط هر یک با سرور برقرار باشد و صوت و تصویر را ابتدا برای سرور ارسال نموده و سرور اقدام به ارسال این صوت و تصویر به کاربر مقصد نمایند . به همین دلیل همواره این نگرانی وجود داشت تا شرکت ارائه دهنده خدمات از این اطلاعات استفاده های سوء نمایند و حریم خصوصی کاربران خود را نقض کند و اقدام به فروش این اطلاعات با مقاصد اقتصادی یا سیاسی نماید ولی در Webrtc ارتباط نظیر به نظیر بین مرورگرهای کاربران برقرار می شود و اطلاعات صوتی و تصویری و داده ها به هیچ وجه به سرور واسط آنها ارسال نمی گردد و این امر تضمینی برای حفظ امنیت و حریم خصوصی افراد است .
3- کاهش هزینه
شرکت هایی که خدمات ویدئو کنفرانس یا کلاس های مجازی و یا ارتباطات تصویری دوطرفه را ارائه می دهند با هزینه های فزاینده ترافیک اینترنت و پردازش بسیار بالا بر روی سرورهای خود هستند زیرا بایستی تمام فایل های صوتی و تصویری ابتدا به سرور ارسال و سپس از آنحا به کاربر مقصد ارسال شود و این امر بار پردازشی سرور و پهنای باند بسیار زیادی را به سرور تحمیل می کند . صاحبان این شرکت ها نیز برای تامین هزینه های ناشی از این سربار فزاینده به ناچار قیمت خدمات خود را افزایش می دادند . در Webrtc چون سرور فقط نقش هماهنگ کننده را بین کاربران دارد و اطلاعات به سرور ارسال نمی شود به همین دلیل سربار پردازشی و پهنای باند نخواهد داشت و هزینه های نگهداری سرور به شدت کاهش پیدا می کند .
4- افزایش کیفیت
در تلنولوژی های قدیمی تر چون ارتباط کلاینت – سروری بود و تمام اطلاعات به سرور ارسال می شد و از آنجا مجدد برای کاربر مقصد ارسال می شد ، توان پردازشی و پهنای باند سرور و همچنین میزان بار سرور در کیفیت ارتباط تاثیرگزار بود و در بهترین شرایط که میزان بار سرور کمینه بود و ازقدرت پردازشی و پهنای باند خوبی هم برخوردار بود ، به علت راسال مجدد اطلاعات و رفت و برگشت اضافی اطلاعات تاخیر بیشتری به وجود می آمد ولی در Webrtc به دلیل اینکه Connection بین مرورگرهای کاربران برقرار می گردد و اطلاعات بصورت Stream بین دو کاربر تبادل می شود کیفیت خدمات به شدت افزایش می یابد .
معماری وب
معماری کلاسیک وب Client-Server می باشد که بر اساس آن مرورگرها درخواست های HTTP خود را برای دریافت محتوا به سرور ارسال می کنند و سرور نیز به این درخواست ها پاسخ می دهد . در سناریوی برنامه های تحت وب، سرور می تواند برخی از کد جاوا اسکریپت را در صفحه HTML ی که برای کاربر می فرستد جاسازی کنید. این کدها می توانند با مرورگرها ازطریق API های استاندارد جاوا اسکریپت و با کاربران از طریق رابط کاربری تعامل کنند.
معماری WebRTC
WebRTC مدل کلاینت-سرور سنتی را با معرفی ارتباط نظیر به نظیر بین مرورگرها گسترش داده است . مدل عمومی تر معماری WebRTC که از مدل SIP(Session Initiation Protocol) الهام گرفته شده است و در شکل زیر نمایش داده شده است WebRTC Trapezoid نامیده می شود . 
در مدل WebRTC Trapezoid هر دو مرورگر یک برنامه تحت وب را اجرا می کنند که بر روی وب سرور های متفاوت قرار داده شده است . پیام های سیگنالینگ برای راه اندازی و خاتمه ارتباط استفاده می شوند . این پیام ها از طریق پروتکل HTTP یا WebSocket بین وب سرور ها منتقل می شوند که می تواند در صورت نیاز آنها را تغییر ، ترجمه و یا مدیریت کند .بایستی توجه شود که ارتباط سیگنالینگ بین مرورگر و سرور درWebRTC استاندارد نشده است و توسعه دهنده مختار است تا از پروتکل های موجود در سازمان و یا هر پروتوکل دلخواه دیگری برای برقراری این ارتباط استفاده کند . بعد از اینکه مرورگرها از طریق این پروتکل سیگنالینگ و سرورها از مشخصات و توانایی های یکدیگر اطلاع پیدا کردند ، PeerConnection به آنها این امکان را می دهد تا یک کانکشن مستقیم بین یکدیگر برای انتقال اطلاعات بدون دخالت سرورهابرقرار کنند . سرور ها برای ارتباطات سیگنالینگ می توانند از پروتکل های استاندارد سیگنالینگ مانند SIP یا Jingle استفاده کنند .
یکی دیگر از مدل های معماری رایج WebRTC این است که هر دو مرورگر برنامه تحت وب را بر روی یک سرور اجرا کنند . این مدل معماری به WebRTC Triangle معروف است و مطابق با شکل زیر می باشد . 
WebRTC در مرورگرها
یک برنامه تحت وب WebRTC که ترکیبی از HTML و کدهای جاوااسکریپت می باشد ، از طریق API های استاندارد WebRTC با مرورگرها تعامل می کند و این امکان را فراهم می کند که برنامه کاربردی وب از توابع real-time مرورگر به درستی بهره برداری و استفاده نماید به عنوان مثال به وب کم یا میکروفن دسترسی داشته باشد . بنابراین API های WebRTC بایستی عملیات های وسیعی ازجمله مدیریت اتصال ، توانایی Encoding/Decoding ، کنترل استریم و ... را فراهم کند
طراحی API های WebRTC با یک مسئله چالش برانگیز مواجه است و آن این است که در این سناریو یک جریان زمان واقعی از داده ها در سراسر شبکه به منظور امکان ارتباط مستقیم بین دو مرورگر بدون واسطه ، در طول مسیر لازم است . این امر به وضوح نشان دهنده یک رویکرد انقلابی در ارتباطات مبتنی بر وب است .
فرض کنید می خواهیم یک ارتباط صوتی و تصویری آنلاین بین دو مرورگر بر قرار کنیم . در اینجا لازم است یک جریان داده مستقیم (media direct stream) بین دو مرورگر بر قرار باشد که این نیازمند یه Connection مستقیم بین دو مرورگر است . فعل و انفعالاتی که در این سناریو بایستی انجام شود توسط این عوامل انجام می گیرد : • مرورگر تماس گیرنده و نرم افزار تماس گیرنده جاوا اسکریپت (برای مثال، از طریق API جاوا اسکریپتی ذکر شده ( • نرم افزار تماس گیرنده جاوا اسکریپت و ارائه دهنده برنامه (به طور معمول، یک وب سرور) • ارائه دهنده نرم افزار و برنامه پذیرنده جاوا اسکریپت • نرم افزار جاوا اسکریپت پذیرنده و مرورگر پذیرنده (باز از طریق API جاوا اسکریپت نرم افزار مرورگر (
سیگنالینگ
ایده کلی در طراحی WebRTC این است که بطور کامل مشخص شود که چگونه قرار است ارتباط رسانه ای کنترل شود در حالیکه پلن سیگنالینگ تا آنجایی که ممکن است در لایه کاربردی رها شده است . منطق این کار این است که برنامه های کاربردی مختلف ممکن است ترجیح دهند تا از پروتکل های استاندارد سیگنالینگ مختلفی استفاده کنند مانند : SIP یا XMPP یا حتی یک پروتکل شخصی سازی شده .
توضیحات جلسه (Session description) اطلاعات بسیار مهمی را نشان می دهد که نیاز به رد و بدل شدن دارد. از جمله اطلاعات حمل و نقل (ICE) ، نوع رسانه ، فرمت و همچنین تنظیمات مورد نیاز برای ایجاد یک Connection مستقیم و انتقال یک جریان داده در بستر آن .
از آنجا که ایده اصلی برای تبادل اطلاعات توضیحات جلسه (Session description) در قالب پروتکل توصیف نشست (SDP) در حال حاضر کاستی های بسیاری دارد ،IETF در حال حاضر از استاندارد ایجاد پروتکل جلسه جاوا اسکریپت (JSEP) استفاده می کند . JSEP رابط مورد نیاز یک برنامه کاربردی برای ایجاد مذاکره بین توضیحات جلسه محلی (local Session description) و توضیحات جلسه راه دور Session description) (Remoteرا فراهم می کند .
در واقع مرورگرها برای ایجاد یک Connection مستقیم نظیر به نظیر بین خود و برقراری جریان داده در این مسیر نیاز به اطلاعاتی از توانایی ها و پروتکل های مورد پشتیبانی یکدیگر دارند که این اطلاعات تحت عنوان توضیحات جلسه (Session description) بین آنها مبادکه می شود . روند مبادله این اطلاعات بدین گونه است که ابتدا یکی از طرفین که شروع کننده ارتباط است یه Affer برای طرف مقابل می فرستد و گیرنده نیز با توجه به این Affer یک پاسخ برای طرف دیگر ارسال می کند و طی یک فرایند مذاکره بر سر پروتکل ها و استانداردهای مورد پشتیبانی طرفین به توافق می رسند و ارتباط را بر مبنای آن شکل می دهند . 
برای برقراری یک ارتباط WebRTC گام های زیر بایستی برداشته شود : 1- ایجاد یک شیء های MediaStream از دستگاه های محلی خود (به عنوان مثال، میکروفون، وب کم). 2- بدست آوردن یک URL از MediaStream محلی . 3- استفاده از URL محلی برای پیش نمایش محلی . 4- ایجاد یک شی RTCPeerConnection 5- افزودن استریم محلی به Connection ایجاد شده . 6- ارسال Session description خود برای طرف مقابل به عنوان یک Affer 7- دریافت Seeeion Description طرف مقابل به عوان یک Affer 8- پردازش Session description دریافتی و افزودن remote stream به RTCPeerConnection خود . 9- بدست آوردن Url برای RemoteStream 10- استفاده از Url بدست آمده و نمایش فیلم یا صوت طرف مقابل
روش های سیگنالینگ توسط WebRTC مشخص نشده است تا از افزونگی جلوگیری شود و بیشترین انطباق را با تکنولوژی های موجود در سازمان ها داشته باشد . فرایند سیگنالیگ مربوط به پروتکل های مانند SIP (Session Initiation Protocol) ، XMPP (Extensible Messaging and Presence Protocol) ، XHR(XML HTTP Requsest) و SIP over WebSocket می باشد. 
WebSocket یک افزونه جدید به مرورگرها است که در سال 2011 استاندارد شد . مهمترین مزیت WebSocket این است که هنگامیکه یک Session از جانب کلایت به سمت سرور ایجاد می کند ، تا زمانیکه Session بسته نشود آن را باز نگه می دارد . پیام ها می توانند متنی یا باینری باشند. نمودار دنباله پیام ارتباطات WebRTC جریان ارتباط بین طرفین و سرور را توصیف میکند. این نمودار در زیر نشام داده شده است . در راه کار سیگنالینگ 4 نوع پیام کنترلی ایجاد می شود : - Initialize - Initiator - got user media - peerChannel
این پیام های کنترلی متنی هستند و از آنها به منظور تنظیم Flag ها برای راه اندازی مکانیزم خاص استفاده می شود . در ابتدا Peer1 پیام initialize را به سمت سرور ارسال می کند تا به سرور اعلام کند که آغازگر جلسه است . پس از آن Peer1 رسانه های کاربر را که می تواند صوت با تصویر یا داده باشد را پس از دریافت پیام کنترلی Got user media از طرف سرور پیکربندی می کند . پس از آن peer1 در حال انتظار باقی می ماند تا Peer2 آماده شود . پس از فعال سازی Peer2 پیام سیگنالینگ معادل را ارسال می کند و وقتی متوجه می شود که آغازگر جلسه نیست ابتدا peerChannel و got user media را انجام می دهد و پس از آن هر دو طرف می توانند ارتباط Peer to Peer را برپا کنند .
پیام Affer و پاسخ آن با فرمت SDP (Session Description Protocol) ارسال می شود . SDP نقش اساسی در برپایی جلسه WebRTC ایفا می کند. SDP پروتکلی است که از طرف IETF و W3C برای تبادل اطلاعات رسانه بین طرفین انتخاب شده است. SDP اطلاعاتی مانند نوع مدیا ، فرمت ، Codec و دیگر خصوصیات مورد نیاز که برای یرپایی یک جلسه انتقال رسانه نیاز است را حمل می کند. همانطور که در دیاگرام زیر مشاهده می کنید که Peer1 یک SDP offer و یک ICE candidates به سمت سرور ارسال می کند و سرور آن را به Peer2 می فرستد . Peer2 هم یک SDP answer و یک ICE candidates را برای سرور ارسال می کند تا سرور برای Peer1 ارسال کند . پس از آن ارتباط Peer to Peer برپا می شود و از این پس طرفین می توانند بدون حضور سرور با یکدیگر تبادل پیام و صوت و تصویر داشته باشند .
تمام سیگنالینگ های SDP و پیام های کنترلی در برنامه WebRTC بصورت یک آبجکت JSON منتل می شوند . بطور خلاصه سه فاز دیاگرام بالا در شکل زیر نمایش داده شده است .
در فاز اول طرفین اقدام به تبادل پیام های کنترلی با سرور می کنند . در فاز دوم اقدام به ایجاد یک Peer Connection بر مبنای تبادل پیام از طریق SDP می کنند و در فاز سوم ارتیاط نظیر به نظیر برقرار شده و طرفین می توانند بصورت مستقیم تبادل پیام انجام دهند .
اجزای اصلی WebRTC API
اجزای اصلی WebRTC API عبارتند از :
MediaStream :
به یک مرورگر وب اجازه دسترسی به میکروفن و دوربین را می دهد . این API وظیفه کنترل جریان داده را دارد که دارای ورودی و خروجی است . منبع ورودی ممکن است یک دستگاه سخت افزاری مانند دوربین یا میکروفن باشد و خروجی ممکن است به یک یا چند مقصد مانند یک تگ ویدئو یا یک آبجکت PeerConnection ارسال شود . دو کامپوننت اصلی در MediaStream API ، MediaStream interface و MediaStreamTrack می باشد . MediaStream interface محتوای جریان داده را فراهم می کند . جریان داده می تواند قسمت های مختلفی اشته باشد ، این قسمت ها باعنوان Track شناخته می شوند که هر کدام از آنها نوع صریحی مانند Audio ، Video دارند . 
MediaStreamTrack نوع داده ای را که از وردی گرفته شده است را مشخص می کند برای مثال نوع داده ورودی از میکروفن، Audio می باشد .
RTCPeerConnection :
تماس صوتی یا تصویری را برقرار می کند. این API به طرفین این امکان را می دهد تا یک ارتباط مستقیم مرورگر به مرورگر داشته باشند . WebRTC چارچوبی برای امکان برقراری ارتباط زمان واقعی فراهم می کند . معماری WebRTC سه بخش اساسی دارد . بخش اول شامل Audio ، Video و مکانیزمی برای انتقال می باشد . وضیفه اصلی مکانیزم Audio کاهش نویز و echo cancellation می باشد . مکایزم Video وظیفه بهبود تصاویر و بافر کردن ویدئو را دارد . بهبود تصاویر با استفاده از Codec VP8 انجام می گیرد .
RTCDataChannel :
به مرورگر اجازه می دهد تا داده را از کانال ارتباطی Peer to Peer ارسال کند . ین API یک ارتباط دو طرفه بین دو طرفین فراهم می کند تا بتوانند داده ی دلخواه را بین خود تبادل کنند . هر RTCDataChannel می توان برای ارئه های مختلف پیکربندی شود : - تحویل قابل اعتماد یا غیر قابل اعتماد از پیام؛ - تحویل پیام بصورت in-order یا out-of-order تحویل in-order و قابل اعتماد معادل TCP می باشد و تحویل Out-of-order و غیر قابل اعتماد معادل UDP می باشد .
Interactive Connectivity Establishment (ICE)
سیستم آدرس دهی اینترنتی که کماکان مورد استفاده قرار می گیرد IPV4 می باشد و به همین دلیل بسیاری از دستگاه هایی که به اینترنت متصل می شوند به ناچار در پشت لایه هایی از NAT قرار می گیرند . NAT مکانیزمی برای نگاشت آدرس های اینترنتی اختصاصی به آدرس های اینترنتی عمومی است و این مکانیزم می تواند توسط ISP ها یا حتی توسط یک روتر WiFi خانگی انجام پذیرد .
توسعه دهندگان تکنولوژی WebRTC می توانند با استفاده از ICE پیچیدگی های سیستم آدرس دهی اینترنتی را ساده سازی کنند ، برای این کار لازم است تا آدرس سرور ICE را به PeerConnection ارسال کنند. ICE تلاش خواهد کرد تا بهترین مسیر را برای اتصال طرفین پیدا کند . ICE از دو نوع سرور STUN (Session Traversal Utilities for NAT) و TURN (Traversal Using Relays around NAT) استفاده می کند ، از سرور STUN برای یافتن این که چه آدرس خارجی ای را به طرف مقابل اختصاص بدهد استفاده می کند و اگر این روال با مشکل مواجه شود از سرور TURN برای مسیریابی استفاده می کند .
E-learning
امروزه، با توسعه روش های نوین ارتباطی (اینترنت، تلفن همراه، و کامپیوتر) ،دانشگاه های سنتی از جمله دانشگاه آموزش الکترونیکی و مجازی با چالش های فاصله مواجه هستند ، آموزش الکترونیکی که در ابتدا توسط افراد حرفه ای که می خواستند برای تکمیل آموزش خود از این روش استفاده کنند مورد توجه قرار گرفت ، امروزه مورد توجه همگان قرار گرفته است . افراد با تجربه و مهارت کمتر در حوزه ارتباطات بایستی برای کار کردن با سیستم های آموزش الکترونیک ، دانش کافی را کسب کنند . برای آموزش مجازی سیستم های یادگیری از راه دور بسیاری وجود دارد که شامل خودارزیابی و ارزیابی آنلاین می باشند . یکی از این سیستم ها Moodle است که توسط دانشگاه های زیادی مورد استفاده قرار می گیرد . پس از معرفی WebRTC توسط گوگل که کمک شایانی در برقراری ارتباط زمان واقعی می کند انقلابی در سیستم های یادگیری آنلاین اتفاق افتاد .
یکپارچه سازی WebRTC با سیستم آموزش الکترونیکی Moddle توسط پلاگینی از WebRTC برای Moddle تست شده است ولی فقط ارتباطات پایه ای صوت و تصویر امکان پذیر است و هنوز تمام امکانات ارائه شده توسط WebRTC در آن پیاده سازی نشده است . مشکل دیگری که دانشگاه های مجازی با آن مواجه هستند ، ارزیابی دانش آموزان در دوره های زبان و STEM است . برای رفع این محدوذیت می توان از امکانات تکنولوژی جدید WebRTC استفاده کرد و قابلیت های زیر را به پلاگین Moddle اضافه کرد : - Presentation of the virtual classroom - Language oral exam - Whiteboard - Mathematical editor - File Transfert
Performance
تعامل مستقیم کاربران با استفاده از WebRTC ، زمان پاسخ و عملکرد آن را حیاتی کرده است . نیاز WebRTC به توان پردازشی و پهنای باند بالا ، سیستم ها بویژه دستگاه های تلفن همران با منابع محدود را به بهبود منابع فرا می خواند .
اندازه گیری از قابلیت های اساسی و پیشرفته از پیاده سازی فعلی و آینده از WebRTC به ویژه در این مرحله از استاندارد و توسعه مهم است. برای این منظور جنبه های مختلف یک سیستم WebRTC مورد ارزیابی قرار گرفته است . برای مثال در مقالات متعددی چگونگی انجام کنترل ازدحام و زمان تاخیر در توپولوژی های مختلف نشان داده شده است . مطالعه دیگری نشان می دهد ، کیفیت ویدیو در راه اندازی واقع بینانه برای دستگاه هایی که در فضای شبکه در حال حرکت هستند چگونه تغییر می کند .
نتایج یکی از آزمایش های انجام شده برای ارزیابی پارامترهای مختلف یک سیستم WebRTC بر روی گوشی Galaxy S5 به شرح زیر می باشد . - اندازه STUN BINDING REQUEST برای اتصال درخواست 154 بایت - اندازه STUN BINDING RESPONSE برای پاسخ به درخواست 106 بایت - درخواست های STUN برای هر 500ms ارسال می شد . جدول زیر تجزیه و تحلیل مربوط به استفاده از پهنای باند در هر ثانیه تنها برای پاسخ به درخواست STUN را نمایش می هد . With Bundle Without Bundle 520 bytes 1040 bytes Bandwidth Utilization این تجزیه و تحلیل با گرفتن نمونه های تصادفی از مصرف پهنای باند در طول فرآیندجلسه و با در نظر گرفتن متوسط نمونه ها انجام شده است . 
این تجزیه و تحلیل با گرفتن نمونه های تصادفی از مصرف پهنای باند در طول فرآیندجلسه و با در نظر گرفتن متوسط نمونه ها انجام شده است . همچنین میزان استفاده از باتری برای برپایی یک جلسه صوتی و تصویری با استفاده از Bundle و بدون استفاده از آن شبیه سازی شده است . در فرایند شبیه سازی برای ارسال صوت و تصویر از بسته های RTP و RTCP بر روی یک ارتباط تکی استفاده شده است .
Battery usage without Bundle :
Battery usage with Bundl :
در نهایت WebRTC یک محیط سازگار برای تضمین استقرار جلسه صوتی و تصویری بین مرورگر های شرکت های مختلف فراهم می کند و همچنین محیطی توسعه پذیرتر و توسعه پسندتر نسبت به سیستم های پلاگین محور فراهم می کند . آزمایشات انجام شده نشان می دهد یکپارچه سازی بسته نرم افزاری در WebRTC مصرف باتری و میزان استفاده از پهنای باند را به شدت کاهش می دهد و بهره وری سیستم را بهبود می بخشد .
نتیجه گیری
نتیجه ای که در نهایت حاصل شده است.
مراجع
- [۱] Samuel Ouya ,Khalifa Sylla,Pape Mamadou Djidiack Faye,Mouhamadou Yaya Sow and Claude Lishou. "Impact of integrating WebRTC in universities' e-learning platforms" Information and Communication Technologies (WICT) (Dec. 2015 ): 14-16
- [۲]Branislav Sredojev ,Dragan Samardzija and Dragan Posarac. "WebRTC technology overview and signaling solution design and implementation" Information and Communication Technology, Electronics and Microelectronics (MIPRO) (May 2015 ): 25-29
- [۳]Chuan-Yen Chiang ,Yen-Lin Chen,Pei-Shiun Tsai and Shyan-Ming Yuan. "A Video Conferencing System Based on WebRTC for Seniors" Trustworthy Systems and their Applications (TSA) (June 2014): 9-10
- [۴] Michael Adeyeye ,Ishmeal Makitla and Thomas Fogwill. "Determining the signalling overhead of two common WebRTC methods: JSON via XMLHttpRequest and SIP over WebSocket" AFRICON (Sept. 2013): 9-12
- [۵]Kiran Kumar Guduru and Sachin Dev. "Web RTC Implementation Analysis and Impact of Bundle Feature" Communication Systems and Network Technologies (CSNT) (April 2015): 4-6
