تکنولوژی WebRTC چیست؟ از تماس تصویری تا ارتباط مستقیم در مرورگر

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

WebRTC چیست و چطور ارتباط صوتی و تصویری را به مرورگرها آورد؟

WebRTC فقط یک ابزار برای تماس تصویری نیست. این فناوری مجموعه‌ای از استانداردها و APIهاست که مرورگر را قادر می‌کند صوت، تصویر و حتی داده را با تاخیر کم بین دو دستگاه جابه‌جا کند. برای اینکه دقیقا متوجه شویم این فرایند چطور اتفاق می‌افتد، باید کمی از ظاهر سادۀ تماس در مرورگر فاصله بگیریم و ببینیم پشت صحنه چه اتفاقی می‌افتد.

WebRTC مخفف Web Real-Time Communication به معنای «ارتباطات بلادرنگ وب» است. مجموعه‌ای از استانداردها و رابط‌های برنامه‌نویسی (API) که به مرورگر اجازه می‌دهد صوت، تصویر و داده را در ارتباطات بلادرنگ بین کاربران منتقل کند. نکته مهم اینجاست که این قابلیت بدون نیاز به نصب افزونه یا نرم‌افزار جداگانه در مرورگرهای مدرن در دسترس است.

مرورگر می‌تواند مستقیما قابلیت‌های صوتی و تصویری دستگاه را در اختیار برنامه وب قرار دهد و در شرایط مناسب، یک ارتباط Peer-to-Peer یا P2P ایجاد کند. یعنی دو دستگاه تا حد امکان مستقیما با یکدیگر ارتباط برقرار کنند.

از عبارت «ارتباط مستقیم» نباید سوءبرداشت شود!

تکنولوژی WebRTC به این معنا نیست که همیشه و در هر شبکه‌ای، دو مرورگر بدون هیچ سروری به هم متصل می‌شوند. برای راه‌اندازی ارتباط و عبور از محدودیت‌های شبکه ممکن است به سرویس‌هایی مثل سرور Signaling، سرور STUN یا در بعضی شرایط TURN نیاز باشد. 

خود WebRTC مسئول بخش‌های مختلف برقراری ارتباط است، اما معماری کامل یک سرویس WebRTC معمولا فراتر از خود API مرورگر است.

یک مثال ساده از WebRTC بزنیم...

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

اگر مسیر مناسبی بین دو طرف وجود داشته باشد، صوت و تصویر می‌توانند از طریق ارتباط Peer-to-Peer منتقل شوند. اگر به دلیل ساختار شبکه، NAT یا فایروال این ارتباط مستقیم امکان‌پذیر نباشد، معماری WebRTC می‌تواند از یک TURN Server به عنوان واسط انتقال ترافیک استفاده کند. 

وقتی سرویس‌هایی مانند تلفن اینترنتی VoIP یا مرکز تماس تحت وب را با WebRTC ترکیب می‌کنید، باید علاوه بر رابط کاربری مرورگر، موضوعاتی مثل مسیریابی تماس، سیگنالینگ، NAT، امنیت، کیفیت شبکه و ارتباط با زیرساخت تلفنی را هم در نظر بگیرید.

تکنولوژی WebRTC دقیقاً چطور کار می‌کند؟

برای فهم WebRTC بهتر است یک تماس تصویری را مرحله‌به‌مرحله دنبال کنیم. 

مرحله اول) دریافت دسترسی به دوربین و میکروفون

اولین مرحله، دریافت رسانه از دستگاه کاربر است. WebRTC از APIای به نام getUserMedia() استفاده می‌کند. این API به برنامه وب اجازه می‌دهد، با دریافت مجوز کاربر، به دوربین و میکروفون دسترسی پیدا کند و یک MediaStream شامل جریان صوتی و تصویری ایجاد کند.

به همین دلیل است که هنگام ورود به یک تماس تصویری در مرورگر، معمولا پیامی مثل «اجازه استفاده از میکروفون و دوربین را می‌دهید؟» نمایش داده می‌شود. اگر کاربر مجوز لازم را ندهد یا دستگاه موردنظر در دسترس نباشد، برنامه نمی‌تواند جریان صوتی یا تصویری را دریافت کند.

WebRTC صرفا تصویر خام دوربین یا صدای خام میکروفون را بدون پردازش به طرف مقابل نمی‌فرستد. رسانه باید در قالبی مناسب برای انتقال روی شبکه آماده شود و اینجا موضوعاتی مثل کدک VoIP اهمیت پیدا می‌کنند. کدک، الگوریتمی است که داده صوتی یا تصویری را برای فشرده‌سازی، انتقال و در سمت گیرنده برای بازسازی پردازش می‌کند.

مرحله دوم) ایجاد ارتباط میان دو طرف

پس از آماده شدن رسانه، WebRTC باید یک اتصال میان دو Peer ایجاد کند. Peer در اینجا به یکی از دو نقطه انتهایی ارتباط، مثلا مرورگر کاربر و مرورگر کارشناس، گفته می‌شود.

ابزار اصلی این مرحله RTCPeerConnection است. RTCPeerConnection یک API مرورگر برای ایجاد، مدیریت و کنترل ارتباط میان دستگاه محلی و دستگاه طرف مقابل است. این رابط، بخش مهمی از فرایند مذاکره، انتخاب مسیر ارتباطی و انتقال جریان‌های صوتی و تصویری را مدیریت می‌کند.

دو مرورگر از کجا می‌فهمند که طرف مقابل چه قابلیت‌هایی دارد؟ 

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

در خیلی از معماری‌ها، برای این کار از فناوری‌هایی مثل WebSocket یا ارتباط HTTP استفاده می‌شود. بنابراین وقتی گفته می‌شود WebRTC ارتباط Peer-to-Peer ایجاد می‌کند، نباید تصور کنیم که از ابتدا تا انتهای فرایند هیچ سروری درگیر نیست؛ سرور می‌تواند برای هماهنگ کردن دو طرف لازم باشد، حتی اگر جریان اصلی رسانه بعدا مستقیما بین دو Peer منتقل شود.

مرحله سوم) پیدا کردن بهترین مسیر شبکه

یکی از پیچیده‌ترین قسمت‌های WebRTC این است که دو کاربر ممکن است پشت روتر، NAT یا فایروال قرار داشته باشند. NAT یا Network Address Translation فناوری‌ای است که به دستگاه‌های یک شبکه خصوصی اجازه می‌دهد از طریق یک آدرس عمومی به اینترنت دسترسی پیدا کنند. همین موضوع می‌تواند برقراری ارتباط مستقیم بین دو دستگاه را دشوار کند.

WebRTC برای پیدا کردن مسیر قابل استفاده، از سازوکار ICE یا Interactive Connectivity Establishment استفاده می‌کند. ICE مجموعه‌ای از روش‌ها برای جمع‌آوری و آزمایش مسیرهای احتمالی ارتباط است تا مناسب‌ترین مسیر میان دو طرف انتخاب شود.

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

مرحله چهارم) انتقال صوت و تصویر

بعد از اینکه مسیر ارتباط مشخص شد، جریان‌های صوتی و تصویری می‌توانند از طریق اتصال WebRTC منتقل شوند. در این مرحله، انتخاب روش مناسب برای فشرده‌سازی رسانه اهمیت زیادی دارد؛ چون ارسال صدای خام یا ویدیوی خام روی شبکه به پهنای باند بسیار زیادی نیاز دارد.

برای نمونه، در یک ارتباط صوتی، کدک داده صوتی را به شکلی مناسب برای انتقال تبدیل می‌کند و گیرنده آن را دوباره به صدای قابل پخش تبدیل می‌کند. در دنیای VoIP، انتخاب کدک می‌تواند روی کیفیت صدا، مصرف پهنای باند و رفتار تماس در شرایط مختلف شبکه اثر بگذارد.

نقش SIP در سیگنالینگ و مدیریت نشست‌های ارتباطی

پروتکل SIP مخفف Session Initiation Protocol است. یعنی SIP برای ایجاد، تغییر و پایان دادن به نشست‌های ارتباطی مانند تماس صوتی توسعه داده می‌شود. WebRTC نیز می‌تواند در سمت مرورگر، لایه ارتباط بلادرنگ را فراهم کند و از طریق یک معماری مناسب به سیستم تلفنی متصل شود.

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

اجزای اصلی WebRTC را بشناسیم …

اگر بخواهیم تکنولوژی WebRTC را به زبان ساده به چند قطعه اصلی تقسیم کنیم، سه جزء بیش از همه در معماری آن به چشم می‌آیند: دریافت رسانه از دستگاه، ایجاد ارتباط میان Peerها و انتقال داده میان آنها.

آیا WebRTC واقعا بدون سرور کار می‌کند؟!

خیلی‌ها فکر می‌کنند چون فناوری WebRTC برای ارتباط Peer-to-Peer طراحی شده، پس دو مرورگر باید بتوانند بدون دخالت هیچ سروری مستقیما یکدیگر را پیدا کنند. در عمل، ماجرا کمی پیچیده‌تر است.

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

Signaling؛ هماهنگ کردن دو طرف قبل از شروع تماس

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

نکته مهم این است که خود WebRTC روش مشخصی را برای پیاده‌سازی سرور Signaling تحمیل نمی‌کند؛ توسعه‌دهنده می‌تواند متناسب با معماری سیستم از روش‌هایی مانند WebSocket یا HTTP برای این کار استفاده کند.

ICE؛ پیدا کردن مسیری که واقعا کار کند

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

اینجا ICE یا Interactive Connectivity Establishment وارد عمل می‌شود. ICE سازوکاری برای پیدا کردن و آزمایش مسیرهای مختلف ارتباطی بین دو Peer است تا در نهایت یک مسیر قابل استفاده انتخاب شود. این فرایند به WebRTC کمک می‌کند حتی زمانی که دو دستگاه پشت NAT یا فایروال هستند، گزینه‌های مختلف اتصال را بررسی کنند.

هر مسیر احتمالی در این فرایند به عنوان یک ICE Candidate شناخته می‌شود. Candidate در واقع اطلاعاتی درباره یک روش ممکن برای برقراری ارتباط است؛ مثلا آدرس و پورت و نوع مسیر ارتباطی. دو طرف این Candidateها را از طریق Signaling برای یکدیگر ارسال می‌کنند و ICE آنها را بررسی می‌کند تا یک مسیر مناسب پیدا شود.

STUN؛ پیدا کردن آدرس قابل دسترس از اینترنت

STUN یا Session Traversal Utilities for NAT سرویسی است که به یک دستگاه کمک می‌کند بفهمد از دید اینترنت با چه آدرس عمومی و پورتی قابل مشاهده است. این اطلاعات می‌تواند یکی از Candidateهایی باشد که ICE هنگام تلاش برای ایجاد ارتباط مستقیم از آن استفاده می‌کند.

برای مثال، ممکن است لپ‌تاپ شما در شبکه داخلی آدرسی مانند 192.168.x.x داشته باشد، اما این آدرس خصوصی از اینترنت قابل دسترسی مستقیم نباشد. STUN به دستگاه کمک می‌کند اطلاعات مربوط به آدرس عمومی مشاهده‌شده در سمت شبکه را به دست آورد تا در فرایند ICE مورد استفاده قرار گیرد.

نکته مهم این است که STUN خودش قرار نیست تمام ترافیک تماس را از خودش عبور دهد. در سناریوی ارتباط مستقیم، STUN بیشتر نقش «کمک به کشف مسیر» را دارد؛ بنابراین با TURN نباید آن را یکی دانست.

TURN؛ وقتی ارتباط مستقیم ممکن نیست...

گاهی شبکه آنقدر محدود است که حتی با کمک STUN هم دو Peer نمی‌توانند ارتباط مستقیمی برقرار کنند. فایروال‌های سخت‌گیر، بعضی انواع NAT و محدودیت‌های شبکه می‌توانند چنین شرایطی ایجاد کنند.

در این وضعیت TURN یا Traversal Using Relays around NAT وارد عمل می‌شود. TURN یک سرور واسط یا Relay فراهم می‌کند تا ترافیک بین دو Peer از طریق آن عبور کند. بنابراین برخلاف STUN، در اینجا سرور TURN می‌تواند در مسیر واقعی انتقال رسانه قرار بگیرد.

این موضوع از نظر عملی بسیار مهم است. اگر یک سرویس تماس تحت وب فقط روی اتصال مستقیم حساب کند، ممکن است در شبکه‌ای خاص به‌خوبی کار کند اما در شبکه‌ای دیگر تماس برقرار نشود. به همین دلیل، طراحی یک سامانه WebRTC قابل اتکا معمولا باید سناریوی TURN را هم در نظر بگیرد.

WebRTC چه کاربردهایی دارد؟!

WebRTC می‌تواند برای انتقال بلادرنگ صوت، تصویر و داده استفاده شود و همین موضوع باعث شده در طیف متنوعی از سرویس‌های تحت وب مورد استفاده قرار بگیرد.

کاربرد اول) تماس صوتی و تصویری در مرورگر

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

در حوزه تلفن سازمانی هم می‌توان WebRTC را در معماری‌هایی به کار گرفت که کارشناس از طریق مرورگر به سیستم تلفنی متصل می‌شود. در چنین ساختاری، WebRTC لزوما جایگزین کامل فناوری‌هایی مانند SIP نمی‌شود؛ بلکه می‌تواند بخشی از معماری ارتباطی باشد و در سمت مرورگر نقش مهمی ایفا کند.

کاربرد دوم) Click-to-Call و تماس از داخل سایت

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

البته WebRTC به خودی خود یک سیستم کامل مرکز تماس نیست. امکاناتی مانند صف تماس، داخلی‌ها، گزارش‌گیری، ضبط مکالمه، مسیریابی تماس و مدیریت کارشناسان به لایه‌های دیگری از زیرساخت تلفنی نیاز دارند. اینجا تفاوت میان «فناوری انتقال ارتباط» و «سرویس تلفنی کامل» اهمیت پیدا می‌کند.

کاربرد سوم) جلسات آنلاین و ویدئوکنفرانس

WebRTC برای ساخت سرویس‌های ویدئوکنفرانس هم مناسب است؛ جایی که چند کاربر باید به صورت هم‌زمان صوت و تصویر خود را ارسال و جریان رسانه‌ای سایر کاربران را دریافت کنند.

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

کاربرد چهارم) اشتراک صفحه

یکی دیگر از کاربردهای WebRTC، اشتراک‌گذاری صفحه نمایش است. مرورگر می‌تواند با استفاده از APIهای مربوط به Capture، محتوای صفحه، یک پنجره یا یک تب مرورگر را برای انتقال آماده کند و سپس آن را از طریق ارتباط WebRTC در اختیار طرف مقابل قرار دهد.

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

البته WebRTC فقط برای Media طراحی نشده است. RTCDataChannel امکان انتقال داده میان دو Peer را فراهم می‌کند و می‌توان از آن برای پیام‌رسانی، انتقال فایل یا تبادل داده‌های کنترلی استفاده کرد.

کاربرد پنجم) سرویس‌های تلفنی و مراکز تماس

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

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

در سرویس‌هایی مانند تلفنچی نیز این تفکیک اهمیت دارد. یک کسب‌وکار ممکن است در لایه خدمات خود به امکانات مختلفی مثل تلفن گویا (IVR) تلفنچی برای هدایت تماس‌ها یا منشی تلفنی تلفنچی برای مدیریت تماس‌های ورودی نیاز داشته باشد؛ در حالی که WebRTC صرفا یکی از فناوری‌هایی است که می‌تواند در لایه ارتباط مرورگری به کار گرفته شود.

جمع‌بندی

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

برای مجموعه‌هایی که به دنبال توسعه زیرساخت ارتباطی خود هستند، شناخت تفاوت میان فناوری‌هایی مانند WebRTC، SIP و تلفن ابری کمک می‌کند انتخاب فنی دقیق‌تری داشته باشند. سرویس‌هایی مانند تلفنچی نیز می‌توانند در کنار این فناوری‌ها، بخش‌های مختلف زیرساخت ارتباطی کسب‌وکار را پوشش دهند.