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

Sam Dutton

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

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

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

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

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

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

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

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

• หากต้องการดูภาพรวมของ WebRTC ให้ดูวิดีโอ Google I/O ต่อไปนี้หรือดูสไลด์เหล่านี้
• หากยังไม่ได้ใช้ getUserMedia API โปรดดูบันทึกเสียงและวิดีโอใน HTML5 และ simpl.info getUserMedia
• ดูข้อมูลเกี่ยวกับ RTCPeerConnection API ได้จากตัวอย่างต่อไปนี้และ "simpl.info RTCPeerConnection"
• ดูวิธีที่ WebRTC ใช้เซิร์ฟเวอร์สำหรับการส่งสัญญาณ รวมถึงการข้ามไฟร์วอลล์และ NAT ได้จากโค้ดและบันทึกคอนโซลจาก appr.tc
• หากไม่ต้องการรอและอยากลองใช้ WebRTC เลย ลองใช้เดโมกว่า 20 รายการที่ใช้ API ของ JavaScript สำหรับ WebRTC
• หากมีปัญหาเกี่ยวกับอุปกรณ์และ WebRTC ไปที่เครื่องมือแก้ปัญหา WebRTC

หรือจะไปที่ 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 รายการต่อไปนี้

• WebRTC
• getUserMedia

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

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

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

RTCDataChannel: หากต้องการดูการทำงานของฟีเจอร์นี้ โปรดดูตัวอย่าง WebRTC เพื่อดูตัวอย่างช่องข้อมูล

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

WebRTC แรกของคุณ

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

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

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

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

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

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

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

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

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 หนึ่งรายการซึ่งแสดงสตรีมจากเว็บแคม MediaStreamTrackแต่ละรายการจะมีประเภท ('video' หรือ 'audio') label (เช่น 'FaceTime HD Camera (Built-in)') และแสดงถึงช่องเสียงหรือวิดีโออย่างน้อย 1 ช่อง ในกรณีนี้ มีเพียงแทร็กวิดีโอ 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() เพียงครั้งเดียว ในครั้งแรก ปุ่มอนุญาตจะแสดงในแถบข้อมูลของเบราว์เซอร์ Chrome เลิกใช้งานการเข้าถึง HTTP สำหรับ getUserMedia() เมื่อสิ้นปี 2015 เนื่องจากมีการจัดประเภทเป็นฟีเจอร์ที่มีประสิทธิภาพสูง

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

getUserMedia() จะมีประสิทธิภาพอย่างแท้จริงเมื่อใช้ร่วมกับ JavaScript API และไลบรารีอื่นๆ

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

ข้อจำกัด

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

ดูตัวอย่างได้ที่ตัวอย่าง WebRTC getUserMedia: เลือกความละเอียด

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

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

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

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

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

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

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

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

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

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

ตัวอย่างเช่น สมมติว่าอลิสต้องการสื่อสารกับบ็อบ ต่อไปนี้คือตัวอย่างโค้ดจากข้อกำหนด WebRTC ของ W3C ซึ่งแสดงกระบวนการส่งสัญญาณที่ใช้งานอยู่ โค้ดจะถือว่ามีกลไกการส่งสัญญาณบางอย่างที่สร้างขึ้นในเมธอด 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);
  }
};

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

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

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

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

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 ครั้งแรก)

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

RTCPeerConnection

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

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

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

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

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

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

โค้ดต่อไปนี้มาจากตัวอย่างการเชื่อมต่อเพียร์ของ 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 );

Callee

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/ไฟร์วอลล์
• เซิร์ฟเวอร์รีเลย์ในกรณีที่การสื่อสารแบบเพียร์ทูเพียร์ไม่สำเร็จ

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

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

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

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

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

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

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

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

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

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

RTCDataChannel API<

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

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

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

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

API มีฟีเจอร์หลายอย่างที่จะช่วยให้คุณใช้ RTCPeerConnection ได้อย่างเต็มที่ และช่วยให้การสื่อสารแบบเพียร์ทูเพียร์มีประสิทธิภาพและยืดหยุ่น ดังนี้

• การใช้ประโยชน์จากการตั้งค่าเซสชัน 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 ช่วยให้กระจายเนื้อหาแบบเพียร์ทูเพียร์ได้อย่างไร

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

ความปลอดภัย

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

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

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

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

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

สรุป

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

เทคโนโลยีพลิกโฉมได้มากกว่านี้

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

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

• สถิติ WebRTC สำหรับเซสชันที่กำลังดำเนินอยู่จะอยู่ที่
  • about://webrtc-internals ใน Chrome
  • opera://webrtc-internals ใน Opera
  • about:webrtc ใน Firefox

    

• หมายเหตุเกี่ยวกับการทำงานร่วมกันของเบราว์เซอร์
• adapter.js คือ JavaScript Shim สำหรับ WebRTC ที่ Google ดูแลรักษาโดยได้รับความช่วยเหลือจากชุมชน WebRTC ซึ่งจะแยกคำนำหน้าของผู้ให้บริการ ความแตกต่างของเบราว์เซอร์ และการเปลี่ยนแปลงในข้อกำหนด
• ดูข้อมูลเพิ่มเติมเกี่ยวกับกระบวนการส่งสัญญาณ WebRTC ได้โดยตรวจสอบเอาต์พุตบันทึกของ appr.tc ไปยังคอนโซล
• หากต้องการลดความซับซ้อน คุณอาจเลือกใช้เฟรมเวิร์ก WebRTC หรือแม้แต่บริการ WebRTC แบบสมบูรณ์
• เรายินดีรับรายงานข้อบกพร่องและคำขอฟีเจอร์เสมอ
  • ข้อบกพร่องของ WebRTC
  • ข้อบกพร่องใน Chrome
  • ข้อบกพร่องของ Opera
  • ข้อบกพร่องของ Firefox
  • ข้อบกพร่องในเดโม WebRTC
  • ข้อบกพร่องของ Adapter.js

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

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

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

• ฉบับร่างของเอดิเตอร์ WebRTC W3C
• ฉบับร่างของเอดิเตอร์ W3C: การจับภาพและสตรีมสื่อ (หรือที่เรียกว่า getUserMedia)
• กฎบัตรของกลุ่มทำงาน IETF
• ร่างโปรโตคอลช่องข้อมูล WebRTC ของ IETF
• ร่าง JSEP ของ IETF
• มาตรฐานที่ IETF เสนอสำหรับ ICE
• ร่างอินเทอร์เน็ตของกลุ่มทำงาน RTCWEB ของ IETF: กรณีการใช้งานและข้อกำหนดของ Web Real-Time Communication

สรุปการรองรับ 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 ด้วย