เริ่มต้นใช้งาน WebRTC

Sam Dutton

WebRTC เป็นหน้าใหม่ในสงครามอันยาวนานเพื่อเว็บที่เปิดกว้างและไร้ข้อจำกัด

Brendan Eich ผู้คิดค้น JavaScript

การสื่อสารแบบเรียลไทม์โดยไม่ต้องใช้ปลั๊กอิน

ลองจินตนาการถึงโลกที่โทรศัพท์ ทีวี และคอมพิวเตอร์สื่อสารกันได้บนแพลตฟอร์มเดียวกัน ลองจินตนาการว่าการเพิ่มวิดีโอคอลและการแชร์ข้อมูลแบบ peer-to-peer ลงในเว็บแอปนั้นเป็นเรื่องง่าย นั่นคือวิสัยทัศน์ของ WebRTC

หากอยากลองใช้ WebRTC พร้อมใช้งานบนเดสก์ท็อปและอุปกรณ์เคลื่อนที่ใน Google Chrome, Safari, Firefox และ Opera วิธีที่ง่ายที่สุดในการเริ่มต้นคือแอปวิดีโอแชทง่ายๆ ที่ appr.tc

  1. เปิด appr.tc ในเบราว์เซอร์
  2. คลิกเข้าร่วมเพื่อเข้าร่วมห้องแชทและอนุญาตให้แอปใช้เว็บแคม
  3. เปิด URL ที่แสดงที่ท้ายหน้าในแท็บใหม่ หรือจะเปิดในคอมพิวเตอร์เครื่องอื่นเลยก็ได้

การเริ่มใช้งานอย่างง่าย

หากไม่มีเวลาอ่านบทความนี้หรือต้องการเพียงโค้ด

หรือจะข้ามไปที่ Codelab ของ WebRTC ก็ได้ ซึ่งเป็นคู่มือแบบทีละขั้นตอนที่อธิบายวิธีสร้างแอปวิดีโอแชทที่สมบูรณ์ รวมถึงเซิร์ฟเวอร์การรับส่งสัญญาณแบบง่าย

ประวัติโดยย่อของ WebRTC

หนึ่งในความท้าทายสำคัญล่าสุดของเว็บคือการทำให้มนุษย์สื่อสารกันได้ผ่านเสียงและวิดีโอ ซึ่งก็คือการสื่อสารแบบเรียลไทม์หรือ RTC นั่นเอง RTC ควรใช้งานในเว็บแอปได้อย่างเป็นธรรมชาติเหมือนกับการป้อนข้อความในอินพุตข้อความ หากไม่มีข้อมูลเชิงลึก คุณจะไม่สามารถสร้างสรรค์และพัฒนาวิธีใหม่ๆ ให้ผู้ชมโต้ตอบได้

ที่ผ่านมา RTC เป็นเทคโนโลยีระดับองค์กรที่มีความซับซ้อน ซึ่งต้องใช้เทคโนโลยีเสียงและวิดีโอที่มีราคาแพงในการขอใบอนุญาตหรือพัฒนาขึ้นเอง การผสานรวมเทคโนโลยี RTC เข้ากับเนื้อหา ข้อมูล และบริการที่มีอยู่นั้นเป็นเรื่องยากและใช้เวลานาน โดยเฉพาะบนเว็บ

วิดีโอแชทของ Gmail เริ่มได้รับความนิยมในปี 2008 และในปี 2011 Google ได้เปิดตัว Hangouts ซึ่งใช้ Talk (เช่นเดียวกับ Gmail) Google ซื้อ GIPS ซึ่งเป็นบริษัทที่พัฒนาคอมโพเนนต์จำนวนมากที่จําเป็นสําหรับ RTC เช่น โค้ดและเทคนิคการลดเสียงสะท้อน Google ได้เปิดแหล่งที่มาของเทคโนโลยีที่พัฒนาโดย GIPS และมีส่วนร่วมกับหน่วยงานมาตรฐานที่เกี่ยวข้องที่ Internet Engineering Task Force (IETF) และ World Wide Web Consortium (W3C) เพื่อให้มั่นใจว่าอุตสาหกรรมจะยอมรับ ในเดือนพฤษภาคม 2011 Ericsson ได้สร้างการใช้งาน WebRTC ครั้งแรก

WebRTC ใช้มาตรฐานแบบเปิดสำหรับการสื่อสารแบบเรียลไทม์ด้วยวิดีโอ เสียง และข้อมูลแบบไม่มีปลั๊กอิน ความต้องการนี้เกิดขึ้นจริง

  • เว็บเซอร์วิสจำนวนมากใช้ RTC แต่จำเป็นต้องมีการดาวน์โหลด แอปที่มาพร้อมเครื่อง หรือปลั๊กอิน ซึ่งรวมถึง Skype, Facebook และ Hangouts
  • การดาวน์โหลด การติดตั้ง และการอัปเดตปลั๊กอินมีความซับซ้อน ทำให้เกิดข้อผิดพลาดได้ง่าย และน่ารำคาญ
  • การใช้ การเพิ่มประสิทธิภาพ แก้ไขข้อบกพร่อง แก้ปัญหา ทดสอบ และดูแลรักษาปลั๊กอินนั้นทำได้ยาก และอาจต้องมีการขอใบอนุญาตและการผสานรวมกับเทคโนโลยีที่ซับซ้อนและมีราคาแพง บ่อยครั้งที่การโน้มน้าวให้ผู้ใช้ติดตั้งปลั๊กอินนั้นเป็นเรื่องยาก

หลักการสำคัญของโปรเจ็กต์ WebRTC คือ API ของโปรเจ็กต์ควรเป็นแบบโอเพนซอร์ส ใช้งานได้ฟรี เป็นไปตามมาตรฐาน ติดตั้งไว้ในเว็บเบราว์เซอร์ และมีประสิทธิภาพมากกว่าเทคโนโลยีที่มีอยู่

ตอนนี้เราอยู่ที่ไหน

WebRTC ใช้ในแอปต่างๆ เช่น Google Meet นอกจากนี้ WebRTC ยังผสานรวมกับแอปเนทีฟ WebKitGTK+ และ Qt ด้วย

WebRTC ใช้ API 3 รายการต่อไปนี้ - MediaStream (หรือที่เรียกว่า getUserMedia) - RTCPeerConnection - RTCDataChannel

API เหล่านี้จะระบุไว้ในข้อกําหนด 2 ข้อต่อไปนี้

Chrome, Safari, Firefox, Edge และ Opera รองรับทั้ง 3 API บนอุปกรณ์เคลื่อนที่และเดสก์ท็อป

getUserMedia: ดูตัวอย่างและโค้ดได้ที่ตัวอย่าง WebRTC หรือลองใช้ตัวอย่างที่ยอดเยี่ยมของ Chris Wilson ที่ใช้ getUserMedia เป็นอินพุตสำหรับเสียงบนเว็บ

RTCPeerConnection: ดูการสาธิตแบบง่ายและแอปวิดีโอแชทที่ใช้งานได้อย่างเต็มรูปแบบได้ที่ WebRTC samples Peer connection และ appr.tc ตามลำดับ แอปนี้ใช้ adapter.js ซึ่งเป็นชิม JavaScript ที่ Google ดูแลรักษาโดยได้รับความช่วยเหลือจากชุมชน WebRTC เพื่อแยกความแตกต่างของเบราว์เซอร์และการเปลี่ยนแปลงข้อกำหนด

RTCDataChannel: หากต้องการดูวิธีการใช้งาน ให้ดูตัวอย่าง WebRTC เพื่อดูการสาธิตช่องทางข้อมูลรายการใดรายการหนึ่ง

โค้ดแล็บ WebRTC แสดงวิธีใช้ API ทั้ง 3 รายการเพื่อสร้างแอปง่ายๆ สําหรับวิดีโอแชทและการแชร์ไฟล์

WebRTC รายการแรกของคุณ

แอป WebRTC ต้องทำสิ่งต่างๆ ต่อไปนี้

  • รับสตรีมเสียง วิดีโอ หรือข้อมูลอื่นๆ
  • รับข้อมูลเครือข่าย เช่น ที่อยู่ IP และพอร์ต แล้วแลกเปลี่ยนกับไคลเอ็นต์ WebRTC อื่นๆ (เรียกว่าเพียร์) เพื่อเปิดใช้การเชื่อมต่อ แม้ผ่าน NAT และไฟร์วอลล์ก็ตาม
  • ประสานงานการสื่อสารเกี่ยวกับสัญญาณเพื่อรายงานข้อผิดพลาด และเริ่มหรือปิดเซสชัน
  • แลกเปลี่ยนข้อมูลเกี่ยวกับสื่อและความสามารถของไคลเอ็นต์ เช่น ความละเอียดและโค้ดรูปแบบ
  • สื่อสารเสียง วิดีโอ หรือข้อมูลสตรีมมิง

WebRTC ใช้ API ต่อไปนี้เพื่อรับและสื่อสารข้อมูลสตรีมมิง

  • MediaStream ได้รับสิทธิ์เข้าถึงสตรีมข้อมูล เช่น จากกล้องและไมโครโฟนของผู้ใช้
  • RTCPeerConnection เปิดใช้การโทรด้วยเสียงหรือวิดีโอพร้อมสิ่งอำนวยความสะดวกสำหรับการจัดการการเข้ารหัสและแบนด์วิดท์
  • RTCDataChannel เปิดใช้การสื่อสารแบบเพียร์ต่อเพียร์ของข้อมูลทั่วไป

(จะมีการพูดคุยเกี่ยวกับเครือข่ายและการส่งสัญญาณของ WebRTC โดยละเอียดในภายหลัง)

MediaStream API (หรือที่เรียกว่า getUserMedia API)

MediaStream API แสดงสตรีมสื่อที่ซิงค์กัน เช่น สตรีมจากอินพุตกล้องและไมโครโฟนจะมีแทร็กวิดีโอและเสียงที่ซิงค์กัน (อย่าสับสนระหว่าง MediaStreamTrack กับองค์ประกอบ <track> ซึ่งเป็นสิ่งแตกต่างออกไปโดยสิ้นเชิง)

วิธีที่ง่ายที่สุดในการทำความเข้าใจ MediaStream API คือการดูการใช้งานจริง

  1. ในเบราว์เซอร์ ให้ไปที่ตัวอย่าง WebRTC getUserMedia
  2. เปิดคอนโซล
  3. ตรวจสอบตัวแปร stream ซึ่งอยู่ในขอบเขตส่วนกลาง

MediaStream แต่ละรายการจะมีอินพุต ซึ่งอาจเป็น MediaStream ที่ getUserMedia() สร้างขึ้น และเอาต์พุต ซึ่งอาจส่งไปยังองค์ประกอบวิดีโอหรือ RTCPeerConnection

เมธอด getUserMedia() ใช้พารามิเตอร์ออบเจ็กต์ MediaStreamConstraints และแสดงผล Promise ที่แปลงเป็นออบเจ็กต์ MediaStream

MediaStream แต่ละรายการมี label เช่น 'Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ' เมธอด getAudioTracks() และ getVideoTracks() จะแสดงผลอาร์เรย์ของ MediaStreamTrack

สําหรับตัวอย่าง getUserMedia stream.getAudioTracks() จะแสดงผลอาร์เรย์ว่าง (เนื่องจากไม่มีเสียง) และสมมติว่าเชื่อมต่อเว็บแคมที่ใช้งานได้ stream.getVideoTracks() จะแสดงผลอาร์เรย์ MediaStreamTrack 1 รายการที่แสดงสตรีมจากเว็บแคม MediaStreamTrack แต่ละรายการมีประเภท ('video' หรือ 'audio') label (เช่น 'FaceTime HD Camera (Built-in)') และแสดงช่องเสียงหรือวิดีโออย่างน้อย 1 ช่อง ในกรณีนี้ มีแทร็กวิดีโอเพียงแทร็กเดียวและไม่มีเสียง แต่เราจินตนาการถึงกรณีการใช้งานที่มีแทร็กมากกว่านี้ได้ง่ายๆ เช่น แอปรับแชทที่รับสตรีมจากกล้องหน้า กล้องหลัง ไมโครโฟน และแอปที่แชร์หน้าจอ

คุณสามารถแนบ MediaStream กับองค์ประกอบวิดีโอได้โดยการตั้งค่าแอตทริบิวต์ srcObject ก่อนหน้านี้ การตั้งค่านี้ทำได้โดยการตั้งค่าแอตทริบิวต์ src เป็น URL ของออบเจ็กต์ที่สร้างด้วย URL.createObjectURL() แต่เราเลิกใช้งานวิธีนี้แล้ว

getUserMedia ยังใช้เป็นโหนดอินพุตสําหรับ Web Audio API ได้ด้วย

// Cope with browser differences.
let audioContext;
if (typeof AudioContext === 'function') {
  audioContext = new AudioContext();
} else if (typeof webkitAudioContext === 'function') {
  audioContext = new webkitAudioContext(); // eslint-disable-line new-cap
} else {
  console.log('Sorry! Web Audio not supported.');
}

// Create a filter node.
var filterNode = audioContext.createBiquadFilter();
// See https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#BiquadFilterNode-section
filterNode.type = 'highpass';
// Cutoff frequency. For highpass, audio is attenuated below this frequency.
filterNode.frequency.value = 10000;

// Create a gain node to change audio volume.
var gainNode = audioContext.createGain();
// Default is 1 (no change). Less than 1 means audio is attenuated
// and vice versa.
gainNode.gain.value = 0.5;

navigator.mediaDevices.getUserMedia({audio: true}, (stream) => {
  // Create an AudioNode from the stream.
  const mediaStreamSource =
    audioContext.createMediaStreamSource(stream);
  mediaStreamSource.connect(filterNode);
  filterNode.connect(gainNode);
  // Connect the gain node to the destination. For example, play the sound.
  gainNode.connect(audioContext.destination);
});

แอปและส่วนขยายที่ใช้ Chromium ยังใช้ getUserMedia ได้ด้วย การเพิ่มสิทธิ์ audioCapture และ/หรือ videoCapture ลงในไฟล์ Manifest จะทำให้สามารถส่งคำขอและได้รับสิทธิ์เพียงครั้งเดียวเมื่อติดตั้ง หลังจากนั้น ระบบจะไม่ขอสิทธิ์เข้าถึงกล้องหรือไมโครโฟนจากผู้ใช้

คุณให้สิทธิ์ getUserMedia() ได้เพียงครั้งเดียว ครั้งแรกที่เปิดใช้ ปุ่ม "อนุญาต" จะปรากฏในinfobarของเบราว์เซอร์ Chrome ได้เลิกใช้งานการเข้าถึง HTTP สำหรับ getUserMedia() เมื่อสิ้นปี 2015 เนื่องจากจัดว่าเป็นฟีเจอร์ที่มีประสิทธิภาพ

เจตนาอาจเป็นไปได้ว่าต้องการเปิดใช้ MediaStream สำหรับแหล่งข้อมูลสตรีมมิงใดๆ ไม่ใช่แค่กล้องหรือไมโครโฟน ซึ่งจะช่วยให้สตรีมจากข้อมูลที่จัดเก็บไว้หรือแหล่งข้อมูลที่กำหนดเองได้ เช่น เซ็นเซอร์หรืออินพุตอื่นๆ

getUserMedia() จะทำงานได้อย่างเต็มที่เมื่อใช้ร่วมกับ JavaScript API และไลบรารีอื่นๆ ต่อไปนี้

  • Webcam Toy เป็นแอปตู้ถ่ายที่ใช้ WebGL เพื่อเพิ่มเอฟเฟกต์แปลกๆ และน่าทึ่งให้กับรูปภาพ ซึ่งสามารถแชร์หรือบันทึกไว้ในเครื่องได้
  • FaceKat เป็นเกมการติดตามใบหน้าที่สร้างด้วย headtrackr.js
  • กล้อง ASCII ใช้ Canvas API เพื่อสร้างรูปภาพ ASCII
รูปภาพ ASCII ที่สร้างขึ้นโดย idevelop.ro/ascii-camera
ภาพ ASCII ของ gUM

ข้อจำกัด

คุณสามารถใช้ข้อจำกัดเพื่อกำหนดค่าความละเอียดของวิดีโอสำหรับ getUserMedia() นอกจากนี้ ยังช่วยให้รองรับข้อจำกัดอื่นๆ เช่น สัดส่วนภาพ โหมดการหันกล้อง (กล้องหน้าหรือหลัง) อัตราเฟรม ความสูงและความกว้าง และวิธีการ applyConstraints()

โปรดดูตัวอย่างที่หัวข้อตัวอย่าง WebRTC getUserMedia: เลือกความละเอียด

การตั้งค่าค่าข้อจำกัดที่ไม่อนุญาตจะให้ DOMException หรือ OverconstrainedError ตัวอย่างเช่น หากไม่มีวิธีแก้ปัญหาที่ขอ หากต้องการดูการทํางานของฟีเจอร์นี้ ให้ดูการสาธิตในตัวอย่าง WebRTC getUserMedia: เลือกความละเอียด

การจับภาพหน้าจอและแท็บ

แอป Chrome ยังช่วยให้คุณแชร์วิดีโอสดของแท็บเบราว์เซอร์เดียวหรือทั้งเดสก์ท็อปผ่าน chrome.tabCapture และ chrome.desktopCapture API ได้ด้วย (ดูการสาธิตและข้อมูลเพิ่มเติมที่หัวข้อการแชร์หน้าจอด้วย WebRTC) บทความนี้เขียนไว้เมื่อ 2-3 ปีก่อน แต่ยังคงน่าสนใจอยู่)

นอกจากนี้ คุณยังใช้การจับภาพหน้าจอเป็นแหล่งที่มาของ MediaStream ใน Chrome โดยใช้ข้อจำกัด chromeMediaSource แบบทดลองได้ด้วย โปรดทราบว่าการจับภาพหน้าจอต้องใช้ HTTPS และควรใช้เพื่อการพัฒนาเท่านั้น เนื่องจากเปิดใช้ผ่าน Flag บรรทัดคำสั่งตามที่อธิบายไว้ในโพสต์นี้

การส่งสัญญาณ: การควบคุมเซสชัน เครือข่าย และข้อมูลสื่อ

WebRTC ใช้ RTCPeerConnection เพื่อสื่อสารข้อมูลสตรีมมิงระหว่างเบราว์เซอร์ (หรือที่เรียกว่าเพียร์) แต่ต้องมีกลไกในการประสานการสื่อสารและส่งข้อความควบคุมด้วย ซึ่งเป็นกระบวนการที่เรียกว่า "การส่งสัญญาณ" WebRTC ไม่ได้ระบุวิธีการและโปรโตคอลการส่งสัญญาณ การส่งสัญญาณไม่ได้เป็นส่วนหนึ่งของ RTCPeerConnection API

แต่นักพัฒนาแอป WebRTC จะเลือกโปรโตคอลการรับส่งข้อความที่ต้องการได้ เช่น SIP หรือ XMPP และช่องทางการสื่อสารแบบ 2 ทาง (แบบ 2 ทิศทาง) ที่เหมาะสม ตัวอย่าง appr.tc ใช้ XHR และ Channel API เป็นกลไกการส่งสัญญาณ Codelab ใช้ Socket.io ที่ทำงานบนเซิร์ฟเวอร์ Node

การส่งสัญญาณใช้เพื่อแลกเปลี่ยนข้อมูล 3 ประเภท ได้แก่

  • ข้อความควบคุมเซสชัน: เพื่อเริ่มต้นหรือปิดการสื่อสารและรายงานข้อผิดพลาด
  • การกำหนดค่าเครือข่าย: ที่อยู่ IP และพอร์ตของคอมพิวเตอร์ที่ปรากฏต่อโลกภายนอก
  • ความสามารถของสื่อ: เบราว์เซอร์และเบราว์เซอร์ที่ต้องการสื่อสารด้วยจัดการโค้ดและความละเอียดใดได้บ้าง

การแลกเปลี่ยนข้อมูลผ่านการส่งสัญญาณต้องเสร็จสมบูรณ์ก่อนจึงจะเริ่มสตรีมมิงแบบ peer-to-peer ได้

ตัวอย่างเช่น สมมติว่า Alice ต้องการสื่อสารกับ Bob ต่อไปนี้คือตัวอย่างโค้ดจากข้อกำหนด W3C WebRTC ซึ่งแสดงกระบวนการส่งสัญญาณ โค้ดจะถือว่ามีกลไกการส่งสัญญาณบางอย่างที่สร้างขึ้นในเมธอด createSignalingChannel() นอกจากนี้ โปรดทราบว่าขณะนี้ Chrome และ Opera จะใช้ RTCPeerConnection เป็นคำนำหน้า

// handles JSON.stringify/parse
const signaling = new SignalingChannel();
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
const pc = new RTCPeerConnection(configuration);

// Send any ice candidates to the other peer.
pc.onicecandidate = ({candidate}) => signaling.send({candidate});

// Let the "negotiationneeded" event trigger offer generation.
pc.onnegotiationneeded = async () => {
  try {
    await pc.setLocalDescription(await pc.createOffer());
    // Send the offer to the other peer.
    signaling.send({desc: pc.localDescription});
  } catch (err) {
    console.error(err);
  }
};

// Once remote track media arrives, show it in remote video element.
pc.ontrack = (event) => {
  // Don't set srcObject again if it is already set.
  if (remoteView.srcObject) return;
  remoteView.srcObject = event.streams[0];
};

// Call start() to initiate.
async function start() {
  try {
    // Get local stream, show it in self-view, and add it to be sent.
    const stream =
      await navigator.mediaDevices.getUserMedia(constraints);
    stream.getTracks().forEach((track) =>
      pc.addTrack(track, stream));
    selfView.srcObject = stream;
  } catch (err) {
    console.error(err);
  }
}

signaling.onmessage = async ({desc, candidate}) => {
  try {
    if (desc) {
      // If you get an offer, you need to reply with an answer.
      if (desc.type === 'offer') {
        await pc.setRemoteDescription(desc);
        const stream =
          await navigator.mediaDevices.getUserMedia(constraints);
        stream.getTracks().forEach((track) =>
          pc.addTrack(track, stream));
        await pc.setLocalDescription(await pc.createAnswer());
        signaling.send({desc: pc.localDescription});
      } else if (desc.type === 'answer') {
        await pc.setRemoteDescription(desc);
      } else {
        console.log('Unsupported SDP type.');
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

ขั้นแรก Alice และ Bob จะแลกเปลี่ยนข้อมูลเครือข่าย (คำว่าการค้นหาผู้สมัครหมายถึงกระบวนการค้นหาอินเทอร์เฟซเครือข่ายและพอร์ตโดยใช้เฟรมเวิร์ก ICE)

  1. Alice สร้างออบเจ็กต์ RTCPeerConnection ที่มีตัวแฮนเดิล onicecandidate ซึ่งจะทํางานเมื่อผู้สมัครเครือข่ายพร้อมใช้งาน
  2. Alice ส่งข้อมูลผู้สมัครแบบซีเรียลไปให้ Bob ผ่านช่องทางการรับส่งสัญญาณที่ใช้อยู่ เช่น WebSocket หรือกลไกอื่นๆ
  3. เมื่อ Bob ได้รับข้อความเกี่ยวกับผู้สมัครจาก Alice เขาจะโทรหา addIceCandidate เพื่อเพิ่มผู้สมัครลงในคำอธิบายของคู่สนทนาระยะไกล

นอกจากนี้ ลูกค้า WebRTC (หรือที่เรียกว่าเพียร์ หรือ Alice และ Bob ในตัวอย่างนี้) ยังต้องตรวจสอบและแลกเปลี่ยนข้อมูลสื่อเสียงและวิดีโอในเครื่องและจากระยะไกล เช่น ความละเอียดและความสามารถของตัวแปลงสัญญาณ การส่งสัญญาณเพื่อแลกเปลี่ยนข้อมูลการกำหนดค่าสื่อจะดำเนินการโดยการแลกเปลี่ยนข้อเสนอและคำตอบโดยใช้โปรโตคอลคําอธิบายเซสชัน (SDP) ดังนี้

  1. Alice เรียกใช้เมธอด RTCPeerConnection createOffer() ผลลัพธ์จากนี้จะส่งผ่าน RTCSessionDescription - คำอธิบายเซสชันในเครื่องของ Alice
  2. ในการเรียกกลับ Alice จะตั้งค่าคำอธิบายในเครื่องโดยใช้ setLocalDescription() จากนั้นส่งคำอธิบายเซสชันนี้ไปยัง Bob ผ่านช่องทางการรับส่งสัญญาณ โปรดทราบว่า RTCPeerConnection จะไม่เริ่มรวบรวมผู้สมัครจนกว่าจะมีการเรียกใช้ setLocalDescription() ข้อมูลนี้มีการระบุไว้ในร่าง JSEP IETF
  3. บัญชาตั้งค่าคำอธิบายที่ขวัญใจส่งให้เป็นการอธิบายจากระยะไกลโดยใช้ setRemoteDescription()
  4. Bob เรียกใช้เมธอด RTCPeerConnection createAnswer() โดยส่งคําอธิบายระยะไกลที่ได้รับจาก Alice เพื่อให้ระบบสร้างเซสชันในเครื่องที่เข้ากันได้กับเซสชันของ Alice มีการส่ง RTCSessionDescription ไปยัง Callback ของ createAnswer() บ๊อบตั้งค่าข้อความนั้นเป็นคำอธิบายในร้านและส่งให้อลิซ
  5. เมื่อได้รับคําอธิบายเซสชันของบัญชา ขวัญใจจะตั้งค่าเป็นคําอธิบายระยะไกลด้วย setRemoteDescription
  6. ปิ๊ง

ออบเจกต์ RTCSessionDescription คือ Blob ที่เป็นไปตาม Session Description Protocol หรือ SDP เมื่อเป็นรูปแบบอนุกรม ออบเจ็กต์ SDP จะมีลักษณะดังนี้

v=0
o=- 3883943731 1 IN IP4 127.0.0.1
s=
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126

// ...

a=ssrc:2223794119 label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh810

การรับและแลกเปลี่ยนข้อมูลเครือข่ายและสื่อทำได้พร้อมกัน แต่ทั้ง 2 กระบวนการต้องเสร็จสมบูรณ์ก่อนจึงจะเริ่มสตรีมเสียงและวิดีโอระหว่างคู่สนทนาได้

สถาปัตยกรรมข้อเสนอ/คำตอบที่อธิบายไปก่อนหน้านี้เรียกว่า JavaScript Session Establishment Protocol หรือ JSEP (มีภาพเคลื่อนไหวที่ยอดเยี่ยมซึ่งอธิบายกระบวนการส่งสัญญาณและสตรีมมิงในวิดีโอสาธิตของ Ericsson สำหรับการใช้งาน WebRTC ครั้งแรก)

แผนภาพสถาปัตยกรรม JSEP
สถาปัตยกรรม JSEP

เมื่อกระบวนการส่งสัญญาณเสร็จสมบูรณ์แล้ว ระบบจะสตรีมข้อมูลแบบ peer-to-peer โดยตรงระหว่างผู้โทรและผู้รับสาย หรือหากไม่สำเร็จ ระบบจะสตรีมผ่านเซิร์ฟเวอร์รีเลย์สื่อกลาง (ดูข้อมูลเพิ่มเติมในภายหลัง) การสตรีมเป็นหน้าที่ของ RTCPeerConnection

RTCPeerConnection

RTCPeerConnection คือคอมโพเนนต์ WebRTC ที่จัดการการสื่อสารข้อมูลสตรีมมิงระหว่างคู่สนทนาอย่างมีประสิทธิภาพและเสถียร

ต่อไปนี้คือแผนภาพสถาปัตยกรรม WebRTC ที่แสดงบทบาทของ RTCPeerConnection คุณจะเห็นว่าส่วนที่เป็นสีเขียวมีความซับซ้อน

แผนภาพสถาปัตยกรรม WebRTC
สถาปัตยกรรม WebRTC (จาก webrtc.org)

จากมุมมองของ JavaScript สิ่งสำคัญที่ควรทำความเข้าใจจากแผนภาพนี้คือ RTCPeerConnection ช่วยปกป้องนักพัฒนาเว็บจากความซับซ้อนมากมายที่ซ่อนอยู่เบื้องหลัง โค้ดและโปรโตคอลที่ WebRTC ใช้ทำงานอย่างหนักเพื่อให้การสื่อสารแบบเรียลไทม์เป็นไปได้ แม้ในเครือข่ายที่ไม่เสถียรก็ตาม

  • การปกปิดการสูญเสียแพ็กเก็ต
  • การตัดเสียงก้อง
  • การปรับแบนด์วิดท์
  • การบัฟเฟอร์ Jitter แบบไดนามิก
  • การควบคุมค่าเกนอัตโนมัติ
  • การลดและตัดเสียงรบกวน
  • การปรับแต่งรูปภาพ

โค้ด W3C ก่อนหน้านี้แสดงตัวอย่าง WebRTC ที่เข้าใจง่ายจากมุมมองการส่งสัญญาณ ต่อไปนี้เป็นคำแนะนำแบบทีละขั้นตอนสำหรับ 2 แอป WebRTC ที่ใช้งานได้ ตัวอย่างแรกเป็นตัวอย่างง่ายๆ เพื่อสาธิต RTCPeerConnection และตัวอย่างที่ 2 เป็นไคลเอ็นต์วิดีโอแชทที่ใช้งานได้อย่างเต็มรูปแบบ

RTCPeerConnection ที่ไม่มีเซิร์ฟเวอร์

โค้ดต่อไปนี้นำมาจากตัวอย่างการเชื่อมต่อแบบ Peer ของ WebRTC ซึ่งมี RTCPeerConnection และระยะไกล (และวิดีโอในเครื่องและระยะไกล) ในหน้าเว็บเดียว การดำเนินการนี้ไม่ได้มีประโยชน์มากนัก เนื่องจากผู้เรียกและผู้รับอยู่ในหน้าเดียวกัน แต่ทำให้การทำงานของ RTCPeerConnection API ชัดเจนขึ้นเล็กน้อย เนื่องจากออบเจ็กต์ RTCPeerConnection ในหน้าเว็บสามารถแลกเปลี่ยนข้อมูลและข้อความได้โดยตรงโดยไม่ต้องใช้กลไกการรับส่งสัญญาณสื่อกลาง

ในตัวอย่างนี้ pc1 แสดงถึงคู่สนทนาในเครื่อง (ผู้โทร) และ pc2 แสดงถึงคู่สนทนาระยะไกล (ผู้รับสาย)

ผู้โทร

  1. สร้าง RTCPeerConnection ใหม่และเพิ่มสตรีมจาก getUserMedia() โดยทำดังนี้ ```js // Servers is an optional configuration file. (ดูการพูดคุยเรื่อง TURN และ STUN ภายหลัง) pc1 = new RTCPeerConnection(servers); // ... localStream.getTracks().forEach((track) => { pc1.addTrack(track, localStream); });
  1. สร้างข้อเสนอและกำหนดให้เป็นคำอธิบายในร้านสำหรับ pc1 และเป็นคำอธิบายระยะไกลสำหรับ pc2 ซึ่งทําได้โดยตรงในโค้ดโดยไม่ต้องใช้สัญญาณ เนื่องจากทั้งผู้โทรและผู้รับอยู่ในหน้าเดียวกัน js pc1.setLocalDescription(desc).then(() => { onSetLocalSuccess(pc1); }, onSetSessionDescriptionError ); trace('pc2 setRemoteDescription start'); pc2.setRemoteDescription(desc).then(() => { onSetRemoteSuccess(pc2); }, onSetSessionDescriptionError );

ผู้รับสาย

  1. สร้าง pc2 และเมื่อเพิ่มสตรีมจาก pc1 ให้แสดงสตรีมนั้นในองค์ประกอบวิดีโอ โดยทำดังนี้ js pc2 = new RTCPeerConnection(servers); pc2.ontrack = gotRemoteStream; //... function gotRemoteStream(e){ vid2.srcObject = e.stream; }

RTCPeerConnection API และเซิร์ฟเวอร์

ในการใช้งานจริง WebRTC ต้องใช้เซิร์ฟเวอร์ แม้ว่าจะเป็นเซิร์ฟเวอร์แบบง่ายก็ตาม ดังนั้นจึงอาจเกิดเหตุการณ์ต่อไปนี้ได้

  • ผู้ใช้ค้นพบกันและแลกเปลี่ยนรายละเอียดในชีวิตจริง เช่น ชื่อ
  • แอปไคลเอ็นต์ WebRTC (เพียร์) จะแลกเปลี่ยนข้อมูลเครือข่าย
  • โดยพาร์ทเนอร์จะแลกเปลี่ยนข้อมูลเกี่ยวกับสื่อ เช่น รูปแบบและความละเอียดของวิดีโอ
  • แอปไคลเอ็นต์ WebRTC จะผ่านเกตเวย์ NAT และไฟร์วอลล์

กล่าวคือ WebRTC ต้องใช้ฟังก์ชันฝั่งเซิร์ฟเวอร์ 4 ประเภท ได้แก่

  • การค้นพบและการติดต่อผู้ใช้
  • การส่งสัญญาณ
  • การส่งผ่าน NAT/ไฟร์วอลล์
  • เซิร์ฟเวอร์รีเลย์ในกรณีที่การสื่อสารแบบ peer-to-peer ไม่สำเร็จ

การข้าม NAT, เครือข่ายแบบเพียร์ต่อเพียร์ และข้อกำหนดในการสร้างแอปเซิร์ฟเวอร์สำหรับการค้นพบและส่งสัญญาณของผู้ใช้อยู่นอกเหนือขอบเขตของบทความนี้ สรุปคือเฟรมเวิร์ก ICE ใช้โปรโตคอล STUN และส่วนขยาย TURN เพื่อให้ RTCPeerConnection จัดการกับการข้าม NAT และปัญหาอื่นๆ ของเครือข่ายได้

ICE เป็นเฟรมเวิร์กสำหรับเชื่อมต่อคู่สนทนา เช่น โปรแกรมรับส่งข้อความวิดีโอ 2 โปรแกรม ในขั้นต้น ICE จะพยายามเชื่อมต่อกับคู่สนทนาโดยตรงโดยมีเวลาในการตอบสนองต่ำที่สุดผ่าน UDP ในกระบวนการนี้ เซิร์ฟเวอร์ STUN มีงานเพียงอย่างเดียวคือช่วยให้เพียร์ที่อยู่เบื้องหลัง NAT ค้นหาที่อยู่และพอร์ตสาธารณะได้ (ดูข้อมูลเพิ่มเติมเกี่ยวกับ STUN และ TURN ได้ที่สร้างบริการแบ็กเอนด์ที่จําเป็นสําหรับแอป WebRTC)

การค้นหาผู้สมัครการเชื่อมต่อ
การค้นหาผู้สมัครการเชื่อมต่อ

หาก UDP ไม่สำเร็จ ICE จะลองใช้ TCP หากการเชื่อมต่อโดยตรงไม่สำเร็จ โดยเฉพาะเนื่องจาก NAT Traversal และไฟร์วอลล์ขององค์กร ICE จะใช้เซิร์ฟเวอร์ TURN สื่อกลาง (Relay) กล่าวคือ ICE จะใช้ STUN กับ UDP เพื่อเชื่อมต่อกับคู่สนทนาโดยตรงก่อน หากไม่สำเร็จก็จะเปลี่ยนไปใช้เซิร์ฟเวอร์รีเลย์ TURN คำว่าการค้นหาผู้สมัครหมายถึงกระบวนการค้นหาอินเทอร์เฟซและพอร์ตเครือข่าย

เส้นทางข้อมูล WebRTC
เส้นทางข้อมูล WebRTC

Justin Uberti วิศวกร WebRTC ให้ข้อมูลเพิ่มเติมเกี่ยวกับ ICE, STUN และ TURN ในการนำเสนอ WebRTC ของ Google I/O ปี 2013 (สไลด์งานนำเสนอแสดงตัวอย่างการใช้งานเซิร์ฟเวอร์ TURN และ STUN)

ไคลเอ็นต์วิดีโอแชทที่ใช้งานง่าย

เว็บไซต์สาธิตวิดีโอแชทที่ appr.tc เป็นตัวเลือกที่ดีในการลองใช้ WebRTC ซึ่งมาพร้อมการส่งสัญญาณและการข้าม NAT/ไฟร์วอลล์โดยใช้เซิร์ฟเวอร์ STUN แอปนี้ใช้ adapter.js ซึ่งเป็นชิมเพื่อปกป้องแอปจากการเปลี่ยนแปลงข้อกำหนดและความแตกต่างของคำนำหน้า

โค้ดจะแสดงข้อมูลการบันทึกอย่างละเอียด ตรวจสอบคอนโซลเพื่อทำความเข้าใจลำดับเหตุการณ์ ต่อไปนี้เป็นคำแนะนำแบบละเอียดเกี่ยวกับโค้ด

โทโพโลยีเครือข่าย

WebRTC ที่ใช้ในปัจจุบันรองรับเฉพาะการสื่อสารแบบ 1:1 แต่สามารถใช้ในสถานการณ์เครือข่ายที่ซับซ้อนมากขึ้นได้ เช่น กับเพียร์หลายรายที่สื่อสารกันโดยตรงหรือผ่าน Multipoint Control Unit (MCU) ซึ่งเป็นเซิร์ฟเวอร์ที่รองรับผู้เข้าร่วมจำนวนมากและสามารถส่งต่อสตรีมแบบเลือก รวมถึงผสมหรือบันทึกเสียงและวิดีโอ

แผนภาพโทโพโลยีของหน่วยควบคุมแบบหลายจุด
ตัวอย่างโทโปโลยีของ Multipoint Control Unit

แอป WebRTC ที่มีอยู่จำนวนมากจะแสดงเฉพาะการสื่อสารระหว่างเว็บเบราว์เซอร์ แต่เซิร์ฟเวอร์เกตเวย์ช่วยให้แอป WebRTC ที่ทำงานบนเบราว์เซอร์โต้ตอบกับอุปกรณ์ต่างๆ ได้ เช่น โทรศัพท์ (หรือที่เรียกว่า PSTN) และระบบ VOIP ในเดือนพฤษภาคม 2012 Doubango Telecom ได้เปิดรหัส sipml5 SIP client ที่สร้างขึ้นด้วย WebRTC และ WebSocket ซึ่ง (นอกเหนือจากการใช้งานอื่นๆ ที่เป็นไปได้) ช่วยให้วิดีโอคอลระหว่างเบราว์เซอร์และแอปที่ทำงานบน iOS และ Android ได้ ที่ Google I/O ทาง Tethr และ Tropo ได้สาธิตเฟรมเวิร์กการสื่อสารสำหรับภัยพิบัติ ในกระเป๋าเอกสารโดยใช้เซลล์ OpenBTS เพื่อเปิดใช้การสื่อสารระหว่างโทรศัพท์ฟีเจอร์และคอมพิวเตอร์ผ่าน WebRTC การสื่อสารทางโทรศัพท์โดยไม่ต้องใช้ผู้ให้บริการ

การสาธิต Tethr/Tropo ที่ Google I/O 2012
Tethr/Tropo: การสื่อสารเกี่ยวกับภัยพิบัติในกระเป๋าเอกสาร

RTCDataChannel API<

WebRTC รองรับการสื่อสารแบบเรียลไทม์สำหรับข้อมูลประเภทอื่นๆ นอกเหนือจากเสียงและวิดีโอ

RTCDataChannel API ช่วยให้สามารถแลกเปลี่ยนข้อมูลแบบกำหนดเองแบบ peer-to-peer ได้โดยใช้เวลาในการตอบสนองต่ำและอัตราการส่งข้อมูลสูง ดูการสาธิตแบบหน้าเดียวและวิธีสร้างแอปการโอนไฟล์ง่ายๆ ได้ที่ตัวอย่าง WebRTC และ Codelab สำหรับ WebRTC ตามลำดับ

กรณีการใช้งานที่เป็นไปได้ของ API นี้มีหลายกรณี เช่น

  • เกม
  • แอปเดสก์ท็อประยะไกล
  • แชทด้วยข้อความแบบเรียลไทม์
  • การโอนไฟล์
  • เครือข่ายแบบกระจายอำนาจ

API นี้มีฟีเจอร์หลายอย่างเพื่อใช้ประโยชน์จาก RTCPeerConnection ให้ได้มากที่สุดและช่วยให้การสื่อสารแบบ peer-to-peer มีประสิทธิภาพและยืดหยุ่น

  • ใช้ประโยชน์จากการตั้งค่าเซสชัน RTCPeerConnection
  • หลายแชแนลพร้อมกันโดยจัดลําดับความสําคัญ
  • ความหมายของการนำส่งที่เชื่อถือได้และไม่เชื่อถือได้
  • การรักษาความปลอดภัยในตัว (DTLS) และการควบคุมความแออัด
  • ความสามารถในการใช้โดยมีหรือไม่มีเสียงหรือวิดีโอ

ไวยากรณ์นี้จงใจให้คล้ายกับ WebSocket โดยมีเมธอด send() และเหตุการณ์ message

const localConnection = new RTCPeerConnection(servers);
const remoteConnection = new RTCPeerConnection(servers);
const sendChannel =
  localConnection.createDataChannel('sendDataChannel');

// ...

remoteConnection.ondatachannel = (event) => {
  receiveChannel = event.channel;
  receiveChannel.onmessage = onReceiveMessage;
  receiveChannel.onopen = onReceiveChannelStateChange;
  receiveChannel.onclose = onReceiveChannelStateChange;
};

function onReceiveMessage(event) {
  document.querySelector("textarea#send").value = event.data;
}

document.querySelector("button#send").onclick = () => {
  var data = document.querySelector("textarea#send").value;
  sendChannel.send(data);
};

การสื่อสารเกิดขึ้นระหว่างเบราว์เซอร์โดยตรง ดังนั้น RTCDataChannel จึงเร็วกว่า WebSocket มาก แม้ว่าจะต้องใช้เซิร์ฟเวอร์รีเลย์ (TURN) เมื่อการเจาะช่องโหว่เพื่อรับมือกับไฟร์วอลล์และ NAT ไม่สำเร็จก็ตาม

RTCDataChannel พร้อมใช้งานใน Chrome, Safari, Firefox, Opera และ Samsung Internet เกม Cube Slam ใช้ API เพื่อสื่อสารสถานะเกม เล่นเป็นเพื่อนหรือเล่นเป็นหมีก็ได้ แพลตฟอร์มนวัตกรรมอย่าง Sharefest ที่เปิดใช้การแชร์ไฟล์ผ่าน RTCDataChannel และ peerCDN ได้แสดงให้เห็นว่า WebRTC สามารถเปิดใช้การเผยแพร่เนื้อหาแบบ peer-to-peer ได้อย่างไร

ดูข้อมูลเพิ่มเติมเกี่ยวกับ RTCDataChannel ได้ที่ข้อกำหนดโปรโตคอลฉบับร่างของ IETF

ความปลอดภัย

แอปหรือปลั๊กอินการสื่อสารแบบเรียลไทม์อาจทำให้ระบบผ่อนปรนเรื่องความปลอดภัยได้หลายวิธี เช่น

  • สื่อหรือข้อมูลที่ไม่มีการเข้ารหัสอาจถูกดักรับระหว่างเบราว์เซอร์ หรือระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์
  • แอปอาจบันทึกและเผยแพร่วิดีโอหรือเสียงโดยที่ผู้ใช้ไม่รู้
  • อาจมีการติดตั้งมัลแวร์หรือไวรัสไว้พร้อมกับปลั๊กอินหรือแอปที่ดูเหมือนจะไม่เป็นอันตราย

WebRTC มีฟีเจอร์หลายอย่างที่ช่วยหลีกเลี่ยงปัญหาเหล่านี้

  • การใช้งาน WebRTC ใช้โปรโตคอลที่ปลอดภัย เช่น DTLS และ SRTP
  • การเข้ารหัสเป็นสิ่งจำเป็นสำหรับคอมโพเนนต์ WebRTC ทั้งหมด รวมถึงกลไกการส่งสัญญาณ
  • WebRTC ไม่ใช่ปลั๊กอิน โดยคอมโพเนนต์จะทํางานใน Sandbox ของเบราว์เซอร์ ไม่ใช่ในกระบวนการแยกต่างหาก คอมโพเนนต์ไม่จำเป็นต้องติดตั้งแยกต่างหากและจะอัปเดตทุกครั้งที่อัปเดตเบราว์เซอร์
  • สิทธิ์เข้าถึงกล้องและไมโครโฟนต้องได้รับอนุญาตอย่างชัดเจน และอินเทอร์เฟซผู้ใช้จะแสดงสถานะนี้อย่างชัดเจนเมื่อกล้องหรือไมโครโฟนทำงานอยู่

การพูดคุยเรื่องความปลอดภัยของสื่อสตรีมมิงอย่างละเอียดนั้นอยู่นอกขอบเขตของบทความนี้ ดูข้อมูลเพิ่มเติมได้ที่สถาปัตยกรรมความปลอดภัย WebRTC ที่เสนอโดย IETF

สรุป

API และมาตรฐานของ WebRTC สามารถทำให้เครื่องมือสำหรับการสร้างเนื้อหาและการสื่อสารเป็นประชาธิปไตยและกระจายอำนาจได้ ซึ่งรวมถึงการโทร เกม การผลิตวิดีโอ การแต่งเพลง และการรวบรวมข่าว

เทคโนโลยีนี้ถือเป็นเทคโนโลยีที่พลิกโฉมวงการอย่างมาก

ตามที่บล็อกเกอร์ Phil Edholm กล่าวไว้ว่า "WebRTC และ HTML5 อาจทําให้เกิดการเปลี่ยนแปลงแบบเดียวกันสําหรับการสื่อสารแบบเรียลไทม์ได้เช่นเดียวกับที่เบราว์เซอร์รุ่นแรกทํากับข้อมูล"

เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์

ดูข้อมูลเพิ่มเติม

  • เซสชัน WebRTC ของ Justin Uberti ที่ Google I/O 2012
  • Alan B. Johnston และ Daniel C. ตอนนี้ Burnett ดูแลหนังสือ WebRTC ฉบับที่ 3 ในรูปแบบสิ่งพิมพ์และ eBook ที่ webrtcbook.com
  • webrtc.org เป็นศูนย์รวมข้อมูลเกี่ยวกับ WebRTC ทั้งหมด รวมถึงการสาธิต เอกสารประกอบ และการพูดคุย
  • discuss-webrtc เป็น Google Group สําหรับการสนทนาทางเทคนิคเกี่ยวกับ WebRTC
  • @webrtc
  • เอกสารประกอบของ Talk สำหรับนักพัฒนาซอฟต์แวร์ของ Google มีข้อมูลเพิ่มเติมเกี่ยวกับการข้าม NAT, STUN, เซิร์ฟเวอร์รีเลย์ และการรวบรวมผู้สมัคร
  • WebRTC ใน GitHub
  • Stack Overflow เป็นแพลตฟอร์มที่เหมาะสำหรับการค้นหาคำตอบและถามคำถามเกี่ยวกับ WebRTC

มาตรฐานและโปรโตคอล

สรุปการรองรับ WebRTC

MediaStream และ getUserMedia API

  • Chrome บนเดสก์ท็อป 18.0.1008 ขึ้นไป Chrome สำหรับ Android 29 ขึ้นไป
  • Opera 18 ขึ้นไป และ Opera สำหรับ Android 20 ขึ้นไป
  • Opera 12, Opera Mobile 12 (ใช้เครื่องมือ Presto)
  • Firefox 17 ขึ้นไป
  • Microsoft Edge 16 ขึ้นไป
  • Safari 11.2 ขึ้นไปใน iOS และ 11.1 ขึ้นไปใน macOS
  • UC 11.8 ขึ้นไปใน Android
  • Samsung Internet 4 ขึ้นไป

RTCPeerConnection API

  • Chrome บนเดสก์ท็อปเวอร์ชัน 20 ขึ้นไป Chrome สำหรับ Android เวอร์ชัน 29 ขึ้นไป (ไม่มี Flag)
  • Opera 18 ขึ้นไป (เปิดอยู่โดยค่าเริ่มต้น) Opera สำหรับ Android 20 ขึ้นไป (เปิดอยู่โดยค่าเริ่มต้น)
  • Firefox 22 ขึ้นไป (เปิดอยู่โดยค่าเริ่มต้น)
  • Microsoft Edge 16 ขึ้นไป
  • Safari 11.2 ขึ้นไปใน iOS และ 11.1 ขึ้นไปใน macOS
  • Samsung Internet 4 ขึ้นไป

RTCDataChannel API

  • เวอร์ชันทดลองใน Chrome 25 แต่เสถียรมากขึ้น (และทำงานร่วมกันได้กับ Firefox) ใน Chrome 26 ขึ้นไป และ Chrome สำหรับ Android 29 ขึ้นไป
  • เวอร์ชันเสถียร (และสามารถทำงานร่วมกันกับ Firefox ได้) ใน Opera 18 ขึ้นไป และ Opera สำหรับ Android 20 ขึ้นไป
  • Firefox 22 ขึ้นไป (เปิดอยู่โดยค่าเริ่มต้น)

ดูข้อมูลโดยละเอียดเพิ่มเติมเกี่ยวกับการรองรับ API แบบข้ามแพลตฟอร์ม เช่น getUserMedia และ RTCPeerConnection ได้ที่ caniuse.com และสถานะ Chrome Platform

นอกจากนี้ Native API สำหรับ RTCPeerConnection ยังดูได้ที่เอกสารประกอบใน webrtc.org