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

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
• หากต้องการดูข้อมูลเกี่ยวกับ API ของ RTCPeerConnection โปรดดูตัวอย่างต่อไปนี้และ 'simpl.info RTCPeerConnection'
• หากต้องการทราบวิธีที่ WebRTC ใช้เซิร์ฟเวอร์ในการส่งสัญญาณ รวมถึงไฟร์วอลล์และ NAT Traversal โปรดดูโค้ดและบันทึกคอนโซลจาก appr.tc
• หากอดใจรอไม่ไหวแล้วและต้องการลองใช้ WebRTC ในตอนนี้ ลองใช้การสาธิตมากกว่า 20 รายการบางรายการที่ใช้งาน WebRTC JavaScript API
• หากมีปัญหากับเครื่องและ WebRTC ไปที่เครื่องมือแก้ปัญหา WebRTC

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

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 เป็นอินพุตสำหรับเสียงในเว็บ

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

RTCDataChannel: หากต้องการดูการใช้งานจริง ให้ดูตัวอย่าง WebRTC เพื่อดูตัวอย่างแชแนลข้อมูล

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

WebRTC แรกของคุณ

แอป WebRTC ต้องดำเนินการหลายอย่างดังนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

getUserMedia() กลับมามีชีวิตอีกครั้งเมื่อใช้ร่วมกับ JavaScript API และไลบรารีอื่นๆ:

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

ข้อจำกัด

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

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

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

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

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

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

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

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

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

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

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

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

ตัวอย่างเช่น สมมติว่าอลิซต้องการสื่อสารกับบ๊อบ นี่คือตัวอย่างโค้ดจากข้อกำหนด 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);
  }
};

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

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

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

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

ออบเจ็กต์ RTCSessionDescription เป็น Blob ที่สอดคล้องกับโปรโตคอลคำอธิบายเซสชัน, 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 Variantment 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 แสดงถึงเพียร์ระยะไกล (Callee)

ผู้โทร

1. สร้าง RTCPeerConnection ใหม่และเพิ่มสตรีมจาก getUserMedia(): ```js // เซิร์ฟเวอร์เป็นไฟล์การกำหนดค่าที่ไม่บังคับ (ดูการสนทนา TURN และ STUN ภายหลัง) pc1 = RTCPeerConnection(servers); // ... localStream.getTracks().forในทุกๆ((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; }

API พร้อมเซิร์ฟเวอร์ RTCPeerConnection รายการ

ในความเป็นจริง 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 นิพจน์ตัวเลือกการค้นหาหมายถึงกระบวนการค้นหาอินเทอร์เฟซและพอร์ตของเครือข่าย

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

โปรแกรมวิดีโอแชทอย่างง่าย

วิดีโอสาธิตที่ appr.tc เหมาะสำหรับการลองใช้ WebRTC ที่พร้อมการส่งสัญญาณและการส่งผ่าน NAT/ไฟร์วอลล์โดยใช้เซิร์ฟเวอร์ STUN แอปนี้ใช้ 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 และ WebRTC Codelab ตามลำดับ

ตัวอย่างการใช้งานที่เป็นไปได้สำหรับ API มีดังนี้

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

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

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

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

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

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

ข้อมูลสรุปการสนับสนุน 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 ขึ้นไป

API RTCPeerConnection

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

API RTCDataChannel

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

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

นอกจากนี้ยังมี API แบบเนทีฟสำหรับ RTCPeerConnection ที่เอกสารประกอบใน webrtc.org