สร้างบริการแบ็กเอนด์ที่จำเป็นสำหรับแอป WebRTC

Sam Dutton

การส่งสัญญาณคืออะไร

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

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

กระบวนการส่งสัญญาณนี้จำเป็นต้องมีวิธีที่ลูกค้าจะสามารถส่งข้อความกลับไปกลับมา WebRTC API ไม่ได้ติดตั้งใช้งานกลไกดังกล่าว คุณต้องสร้างมันขึ้นมาด้วยตัวเอง ในส่วนต่อไปของบทความนี้ คุณจะได้เรียนรู้วิธีสร้างบริการส่งสัญญาณ อย่างไรก็ตาม ก่อนอื่นคุณต้องมีบริบทเล็กน้อย

เพราะเหตุใด WebRTC จึงไม่ได้กำหนดสัญญาณ

มาตรฐาน WebRTC ไม่ได้ระบุวิธีการและโปรโตคอลการส่งสัญญาณไว้ เพื่อหลีกเลี่ยงความซ้ำซ้อนและเพื่อเพิ่มความสามารถในการใช้งานร่วมกันกับเทคโนโลยีที่มีอยู่ให้ได้มากที่สุด แนวทางนี้ระบุไว้ในโปรโตคอลการสร้างเซสชัน JavaScript (JSEP) ดังนี้

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

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

JSEP กำหนดให้มีการแลกเปลี่ยนระหว่างกลุ่มของ offer และ answer ซึ่งเป็นข้อมูลเมตาของสื่อที่กล่าวถึงข้างต้น ระบบจะรับส่งข้อเสนอและคำตอบในรูปแบบ Session Description Protocol (SDP) ซึ่งมีลักษณะดังนี้

v=0
o=- 7614219274584779017 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS
m=audio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:W2TGCZw2NZHuwlnf
a=ice-pwd:xdQEccP40E+P0L5qTyzDgfmW
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9c1AHz27dZ9xPI91YNfSlI67/EMkjHHIHORiClQe
a=rtpmap:111 opus/48000/2
…

อยากรู้จริงๆ ว่าคำหยาบของ SDP พวกนี้หมายถึงอะไร ลองดูตัวอย่าง Internet Engineering Task Force (IETF)

โปรดทราบว่า WebRTC ออกแบบมาให้สามารถปรับแต่งข้อเสนอหรือคำตอบก่อนที่จะตั้งค่าเป็นคำอธิบายในเครื่องหรือจากระยะไกลโดยการแก้ไขค่าในข้อความ SDP เช่น สามารถใช้ฟังก์ชัน preferAudioCodec() ใน appr.tc เพื่อตั้งค่าตัวแปลงรหัสและอัตราบิตเริ่มต้น SDP ค่อนข้างยุ่งยากในการจัดการกับ JavaScript และมีการพูดคุยว่า WebRTC เวอร์ชันในอนาคตควรใช้ JSON แทนหรือไม่ แต่การใช้ SDP ต่อไปก็มีข้อดี

RTCPeerConnection API และการส่งสัญญาณ: ข้อเสนอ คำตอบ และผู้สมัคร

RTCPeerConnection เป็น API ที่แอป WebRTC ใช้งานเพื่อสร้างการเชื่อมต่อระหว่างแอปเทียบเท่าและสื่อสารเสียงและวิดีโอ

ในการเริ่มต้นกระบวนการนี้ RTCPeerConnection มีงาน 2 งานดังนี้

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

เมื่อตรวจสอบข้อมูลในระบบเรียบร้อยแล้ว จะต้องมีการแลกเปลี่ยนข้อมูลผ่านกลไกการส่งสัญญาณกับเครื่องระยะไกล

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

  1. อรวรรณสร้างออบเจ็กต์ RTCPeerConnection
  2. อรวรรณสร้างข้อเสนอ (คำอธิบายเซสชัน SDP) ด้วยเมธอด RTCPeerConnection createOffer()
  3. อรวรรณโทรหา setLocalDescription() พร้อมแจ้งข้อเสนอ
  4. อรวรรณจึงร้อยเรียงข้อเสนอและใช้กลไกการส่งสัญญาณเพื่อส่งข้อเสนอดังกล่าวให้นัท
  5. อลิสาโทรหา setRemoteDescription() ด้วยข้อเสนอของอลิซ เพื่อให้ RTCPeerConnection ของเธอทราบเกี่ยวกับการตั้งค่าของอลิซ
  6. อีฟโทรหา createAnswer() และการเรียกกลับสำเร็จสำหรับกรณีนี้มีการส่งรายละเอียดเซสชันในเครื่อง ซึ่งเป็นคำตอบของอีฟ
  7. อัสนีกำหนดคำตอบของเธอเป็นคำอธิบายในพื้นที่โดยโทรไปที่ setLocalDescription()
  8. จากนั้นอีฟจึงใช้กลไกการส่งสัญญาณเพื่อส่งคำตอบที่เป็นสตริงให้อลิซ
  9. อรวรรณกำหนดคำตอบของอั้มเป็นคำอธิบายเซสชันระยะไกลโดยใช้ setRemoteDescription()

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

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

JSEP รองรับการหลอกล่อผู้สมัครของ ICE ซึ่งช่วยให้ผู้โทรบอกผู้สมัครได้ทีละน้อยหลังจากรับข้อเสนอเริ่มต้น และเพื่อให้ผู้ได้รับเชิญเริ่มรับสายและสร้างการเชื่อมต่อโดยไม่ต้องรอให้ผู้สมัครทั้งหมดมาถึง

โค้ด WebRTC สำหรับการส่งสัญญาณ

ข้อมูลโค้ดต่อไปนี้เป็นตัวอย่างโค้ด W3C ที่สรุปกระบวนการส่งสัญญาณที่สมบูรณ์ โค้ดนี้สันนิษฐานว่ามีกลไกการส่งสัญญาณบางอย่างอยู่ SignalingChannel โดยจะกล่าวถึงการส่งสัญญาณอย่างละเอียดในภายหลัง

// 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);
  }
};

// After 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);
  }
};

หากต้องการดูการทำงานของข้อเสนอ/คำตอบและข้อเสนอใน Exchange ที่เป็นตัวเลือก โปรดดูที่ simpl.info RTCPeerConnection และดูตัวอย่างวิดีโอแชทในหน้าเดียวจากบันทึกคอนโซล หากคุณต้องการเพิ่มเติม ให้ดาวน์โหลดข้อมูลการส่งสัญญาณและสถิติ WebRTC ที่สมบูรณ์จากหน้า about://webrtc-internals ใน Google Chrome หรือหน้า opera://webrtc-internals ใน Opera

การค้นพบแอปเทียบเท่า

นี่เป็นวิธีการที่ยอดเยี่ยมในการถามว่า "ฉันจะหาคนคุยด้วยได้อย่างไร"

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

WebRTC ไม่ได้เป็นผู้กำหนดกลไกการค้นพบแอปเทียบเท่า และคุณจะไม่ต้องดำเนินการตามตัวเลือกดังกล่าวที่นี่ ขั้นตอนนี้ทำได้ง่ายๆ เพียงส่งอีเมลหรือส่งข้อความถึง URL สำหรับแอปวิดีโอแชท เช่น Talky, tawk.to และการประชุมเบราว์เซอร์ คุณสามารถเชิญผู้คนให้เข้าร่วมสายด้วยการแชร์ลิงก์ที่กำหนดเอง Chris Ball ได้สร้างการทดสอบ serverless-webrtc ที่น่าสนใจซึ่งช่วยให้ผู้เข้าร่วมการโทรผ่าน WebRTC แลกเปลี่ยนข้อมูลเมตาโดยบริการรับส่งข้อความที่ต้องการ เช่น IM, อีเมล หรือ Homing Pigeon

คุณจะสร้างบริการส่งสัญญาณได้อย่างไร

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

ข้อความสื่อสารที่ค่อนข้างเล็กและส่วนใหญ่จะได้รับการส่งสัญญาณเมื่อเริ่มต้นการโทร จากการทดสอบด้วย appr.tc สำหรับเซสชันวิดีโอแชท พบว่าบริการส่งสัญญาณจะจัดการข้อความทั้งหมดประมาณ 30-45 ข้อความ โดยข้อความทั้งหมดมีขนาดรวมประมาณ 10 KB

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

พุชข้อความจากเซิร์ฟเวอร์ไปยังไคลเอ็นต์

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

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

WebSocket เป็นโซลูชันที่มีความเป็นธรรมชาติมากขึ้น ออกแบบมาสำหรับการสื่อสารระหว่างไคลเอ็นต์และเซิร์ฟเวอร์แบบ 2 ด้านอย่างสมบูรณ์ กล่าวคือ สามารถส่งข้อความได้ทั้งสองทิศทางพร้อมกัน ข้อดีอย่างหนึ่งของบริการส่งสัญญาณที่สร้างด้วย WebSocket ที่แท้จริงหรือเหตุการณ์ที่ส่งจากเซิร์ฟเวอร์ (EventSource) คือแบ็กเอนด์ของ API เหล่านี้สามารถนำไปใช้งานในเว็บได้หลากหลายรูปแบบซึ่งโดยทั่วไปจะใช้งานกับแพ็กเกจเว็บโฮสติ้งส่วนใหญ่สำหรับภาษาต่างๆ เช่น PHP, Python และ Ruby

เบราว์เซอร์รุ่นใหม่ทั้งหมดยกเว้น Opera Mini สนับสนุน WebSocket และที่สำคัญกว่าเบราว์เซอร์ทั้งหมดที่สนับสนุน WebRTC ยังสนับสนุน WebSocket ทั้งบนเดสก์ท็อปและอุปกรณ์เคลื่อนที่ ควรใช้ TLS สำหรับการเชื่อมต่อทั้งหมดเพื่อให้มั่นใจว่าข้อความจะไม่ถูกสกัดกั้นโดยที่ไม่ได้เข้ารหัส และเพื่อลดปัญหาเกี่ยวกับการส่งผ่านพร็อกซี (สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ WebSocket และการส่งผ่านพร็อกซี โปรดดูบทของ WebRTC ในเครือข่ายเบราว์เซอร์ประสิทธิภาพสูงของ Ilya Grigorik)

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

สเกลการส่งสัญญาณ

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

  • eXtensible Messaging and Presence Protocol (XMPP) ซึ่งเดิมเรียกว่าโปรโตคอล Jabber-a ที่พัฒนาขึ้นเพื่อการรับส่งข้อความโต้ตอบแบบทันทีที่สามารถใช้ในการส่งสัญญาณ (การใช้งานเซิร์ฟเวอร์ ได้แก่ ejabberd และ Openfire ไคลเอ็นต์ JavaScript เช่น Strophe.js ใช้ BOSH เพื่อจำลองสตรีมมิงแบบสองทิศทาง แต่สำหรับเหตุผลต่างๆ BOSH อาจมีประสิทธิภาพไม่ดีเท่าๆ กัน (แทนเจนต์ว่า Jingle เป็นส่วนขยาย XMPP สำหรับเปิดใช้เสียงและวิดีโอ โปรเจ็กต์ WebRTC ใช้คอมโพเนนต์เครือข่ายและการรับส่งข้อมูลจากไลบรารี libjingle ซึ่งเป็นการใช้งาน C++ ของ Jingle)

  • ไลบรารีโอเพนซอร์ส เช่น ZeroMQ (ตามที่ TokBox ใช้สำหรับบริการRumour) และ OpenMQ (NullMQ นำแนวคิด ZeroMQ ไปใช้กับแพลตฟอร์มเว็บโดยใช้โปรโตคอล STOMP บน WebSocket)

  • แพลตฟอร์มการรับส่งข้อความในระบบคลาวด์เชิงพาณิชย์ที่ใช้ WebSocket (แม้ว่าอาจจะเปลี่ยนไปใช้แบบสำรวจที่ใช้เวลานาน) เช่น Pusher, Kaazing และ PubNub (PubNub ยังมี API สำหรับ WebRTC ด้วย)

  • แพลตฟอร์ม WebRTC เชิงพาณิชย์ เช่น vLine

(คู่มือเทคโนโลยีเว็บแบบเรียลไทม์ของ Phil Leggetter นักพัฒนาแอปมีรายการบริการรับส่งข้อความและไลบรารีที่ครอบคลุม)

สร้างบริการส่งสัญญาณด้วย Socket.io บน Node

ต่อไปนี้คือโค้ดสำหรับเว็บแอปแบบง่ายที่ใช้บริการส่งสัญญาณด้วย Socket.io ใน Node การออกแบบของ Socket.io ทำให้การสร้างบริการเพื่อแลกเปลี่ยนข้อความเป็นเรื่องง่าย ส่วน Socket.io เหมาะสำหรับการส่งสัญญาณ WebRTC โดยเฉพาะ เนื่องจากมีแนวคิดในตัวของห้อง ตัวอย่างนี้ไม่ได้ออกแบบมาเพื่อปรับขนาดเพื่อให้บริการส่งสัญญาณระดับการผลิต แต่เข้าใจได้ง่ายสำหรับผู้ใช้จำนวนค่อนข้างน้อย

Socket.io ใช้ WebSocket ที่มีวิดีโอสำรอง ได้แก่ การหยั่งสัญญาณแบบยาว AJAX, การสตรีมแบบหลายส่วนของ AJAX, Forever Iframe และ JSONP Polling ซึ่งมีการย้ายไปใช้แบ็กเอนด์ที่หลากหลาย แต่น่าจะเป็นที่รู้จักกันมากที่สุดจากเวอร์ชันโหนดที่ใช้ในตัวอย่างนี้

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

นี่คือไคลเอ็นต์ index.html:

<!DOCTYPE html>
<html>
  <head>
    <title>WebRTC client</title>
  </head>
  <body>
    <script src='/socket.io/socket.io.js'></script>
    <script src='js/main.js'></script>
  </body>
</html>

นี่คือไฟล์ JavaScript main.js ที่อ้างอิงในไคลเอ็นต์

const isInitiator;

room = prompt('Enter room name:');

const socket = io.connect();

if (room !== '') {
  console.log('Joining room ' + room);
  socket.emit('create or join', room);
}

socket.on('full', (room) => {
  console.log('Room ' + room + ' is full');
});

socket.on('empty', (room) => {
  isInitiator = true;
  console.log('Room ' + room + ' is empty');
});

socket.on('join', (room) => {
  console.log('Making request to join room ' + room);
  console.log('You are the initiator!');
});

socket.on('log', (array) => {
  console.log.apply(console, array);
});

ต่อไปนี้เป็นแอปเซิร์ฟเวอร์แบบสมบูรณ์

const static = require('node-static');
const http = require('http');
const file = new(static.Server)();
const app = http.createServer(function (req, res) {
  file.serve(req, res);
}).listen(2013);

const io = require('socket.io').listen(app);

io.sockets.on('connection', (socket) => {

  // Convenience function to log server messages to the client
  function log(){
    const array = ['>>> Message from server: '];
    for (const i = 0; i < arguments.length; i++) {
      array.push(arguments[i]);
    }
      socket.emit('log', array);
  }

  socket.on('message', (message) => {
    log('Got message:', message);
    // For a real app, would be room only (not broadcast)
    socket.broadcast.emit('message', message);
  });

  socket.on('create or join', (room) => {
    const numClients = io.sockets.clients(room).length;

    log('Room ' + room + ' has ' + numClients + ' client(s)');
    log('Request to create or join room ' + room);

    if (numClients === 0){
      socket.join(room);
      socket.emit('created', room);
    } else if (numClients === 1) {
      io.sockets.in(room).emit('join', room);
      socket.join(room);
      socket.emit('joined', room);
    } else { // max two clients
      socket.emit('full', room);
    }
    socket.emit('emit(): client ' + socket.id +
      ' joined room ' + room);
    socket.broadcast.emit('broadcast(): client ' + socket.id +
      ' joined room ' + room);

  });

});

(คุณไม่จำเป็นต้องเรียนรู้เกี่ยวกับโหนดแบบคงที่สำหรับกรณีนี้ เพียงแต่มีการใช้ในตัวอย่างนี้)

หากต้องการเรียกใช้แอปนี้บน localhost คุณต้องติดตั้ง Node, Socket.IO และ node-static ก่อน ดาวน์โหลดโหนดได้จาก Node.js (ติดตั้งได้ง่ายและรวดเร็ว) หากต้องการติดตั้ง Socket.IO และ Node-static ให้เรียกใช้ Node Package Manager จากเทอร์มินัลในไดเรกทอรีของแอป ดังนี้

npm install socket.io
npm install node-static

หากต้องการเริ่มต้นเซิร์ฟเวอร์ ให้เรียกใช้คำสั่งต่อไปนี้จากเทอร์มินัลในไดเรกทอรีแอป

node server.js

เปิด localhost:2013 จากเบราว์เซอร์ เปิดแท็บหรือหน้าต่างใหม่ในเบราว์เซอร์ใดก็ได้แล้วเปิด localhost:2013 อีกครั้ง หากต้องการดูสิ่งที่เกิดขึ้น ให้ตรวจสอบคอนโซล ใน Chrome และ Opera คุณสามารถเข้าถึงคอนโซลผ่านเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Google Chrome โดยใช้ Ctrl+Shift+J (หรือ Command+Option+J บน Mac)

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

สัญญาณ Getcha ที่ส่งสัญญาณ

  • RTCPeerConnection จะไม่เริ่มรวบรวมผู้สมัครจนกว่าจะมีการเรียกใช้ setLocalDescription() ซึ่งระบุไว้ในฉบับร่างของ JSEP IETF
  • ใช้ประโยชน์จาก Trickle ICE โปรดโทรหา addIceCandidate() ทันทีที่ผู้สมัครมาถึง

เซิร์ฟเวอร์ส่งสัญญาณสำเร็จรูป

หากไม่ต้องการรวมเซิร์ฟเวอร์ของคุณเอง คุณสามารถใช้เซิร์ฟเวอร์การส่งสัญญาณ WebRTC หลายเซิร์ฟเวอร์ซึ่งใช้ Socket.IO เหมือนกับตัวอย่างก่อนหน้านี้ และผสานรวมเข้ากับไลบรารี JavaScript ของไคลเอ็นต์ WebRTC ดังนี้

  • webRTC.io เป็นหนึ่งในไลบรารี Abstraction แรกๆ สำหรับ WebRTC
  • Signalmaster เป็นเซิร์ฟเวอร์การส่งสัญญาณที่สร้างขึ้นเพื่อใช้กับไลบรารีของไคลเอ็นต์ JavaScript SimpleWebRTC

หากไม่ต้องการเขียนโค้ดเลย คุณสามารถใช้แพลตฟอร์ม WebRTC เชิงพาณิชย์ทั้งหมดได้จากบริษัทต่างๆ เช่น vLine, OpenTok และ Asterisk

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

ความปลอดภัยในการส่งสัญญาณ

"ความปลอดภัยคือศิลปะในการทำให้ไม่มีอะไรเกิดขึ้นเลย"

ซัลแมน รัชดี

คอมโพเนนต์ WebRTC ทั้งหมดจำเป็นต้องเข้ารหัส

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

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

หลังส่งสัญญาณ: ใช้ ICE เพื่อรับมือกับ NAT และไฟร์วอลล์

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

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

การเชื่อมต่อแบบเพียร์ทูเพียร์แบบง่าย
โลกที่ไม่มี NAT และไฟร์วอลล์

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

เพียร์ที่อยู่เบื้องหลัง NAT และไฟร์วอลล์
ชีวิตจริง

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

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

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

ทุกเซิร์ฟเวอร์ TURN รองรับ STUN เซิร์ฟเวอร์ TURN คือเซิร์ฟเวอร์ STUN ที่มีฟังก์ชันการส่งต่อในตัวเพิ่มเติม นอกจากนี้ ICE ยังรับมือกับความซับซ้อนของการตั้งค่า NAT ด้วย ในความเป็นจริง การเจาะรู NAT อาจต้องการมากกว่าที่อยู่ IP:พอร์ต สาธารณะ

แอป WebRTC อาจระบุ URL สำหรับเซิร์ฟเวอร์ STUN และ/หรือ TURN ในออบเจ็กต์การกำหนดค่า iceServers ซึ่งเป็นอาร์กิวเมนต์แรกของตัวสร้าง RTCPeerConnection สำหรับ appr.tc ค่าดังกล่าวจะมีลักษณะเช่นนี้

{
  'iceServers': [
    {
      'urls': 'stun:stun.l.google.com:19302'
    },
    {
      'urls': 'turn:192.158.29.39:3478?transport=udp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    },
    {
      'urls': 'turn:192.158.29.39:3478?transport=tcp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    }
  ]
}

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

หยุดชั่วขณะ

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

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

เซิร์ฟเวอร์ STUN ไม่จำเป็นต้องทำอะไรมากหรือจำอะไรมาก เซิร์ฟเวอร์ STUN ที่มีสเปคที่ค่อนข้างต่ำจึงรองรับคำขอจำนวนมากได้

การเรียกใช้ WebRTC ส่วนใหญ่ประสบความสำเร็จด้วยการเชื่อมต่อโดยใช้ STUN - 86% จากข้อมูลของ Webrtcstats.com แม้ว่าการโทรระหว่างเครือข่ายที่มีไฟร์วอลล์และการกำหนดค่า NAT ที่ซับซ้อนจะน้อยกว่านี้ได้

การเชื่อมต่อแบบเพียร์ทูเพียร์โดยใช้เซิร์ฟเวอร์ STUN
การใช้เซิร์ฟเวอร์ STUN เพื่อรับที่อยู่ IP:พอร์ต สาธารณะ

เปิด

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

ขอย้ำอีกครั้งว่า TURN ใช้เพื่อส่งต่อเสียง วิดีโอ และสตรีมมิงข้อมูลระหว่างแอปเทียบเท่า ไม่ใช่ส่งสัญญาณข้อมูล

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

การเชื่อมต่อแบบเพียร์ทูเพียร์โดยใช้เซิร์ฟเวอร์ STUN
เต็มมอนตี: STUN, TURN และการส่งสัญญาณ

แผนภาพนี้แสดงการทำงานของ "TURN" STUN อย่างเดียวไม่ประสบความสำเร็จ เพื่อนแต่ละคนจึงใช้เซิร์ฟเวอร์ TURN

การทำให้เซิร์ฟเวอร์ STUN และ TURN ใช้งานได้

สำหรับการทดสอบ Google จะเรียกใช้เซิร์ฟเวอร์ STUN สาธารณะ stun.l.google.com:19302 ตามที่ใช้โดย appr.tc สำหรับบริการ STUN/TURN เวอร์ชันที่ใช้งานจริง ให้ใช้ rfc5766-turn-server ซอร์สโค้ดสำหรับเซิร์ฟเวอร์ STUN และ TURN มีอยู่ใน GitHub ซึ่งคุณยังค้นหาลิงก์ไปยังแหล่งข้อมูลต่างๆ เกี่ยวกับการติดตั้งเซิร์ฟเวอร์ได้ด้วย มีอิมเมจ VM สำหรับ Amazon Web Services ด้วย

อีกเซิร์ฟเวอร์ TURN คือเซิร์ฟเวอร์สำรอง ซึ่งพร้อมใช้งานเป็นซอร์สโค้ดและสำหรับ AWS ด้วย วิธีตั้งค่าที่เหลือบน Compute Engine มีดังนี้

  1. เปิดไฟร์วอลล์ตามที่จำเป็นสำหรับ tcp=443, udp/tcp=3478
  2. สร้าง 4 อินสแตนซ์ แต่ละอินสแตนซ์สำหรับ IP สาธารณะแต่ละแบบ ซึ่งก็คืออิมเมจ Standard Ubuntu 12.06
  3. ตั้งค่าการกำหนดค่าไฟร์วอลล์ในเครื่อง (อนุญาตใดก็ได้จากใดก็ได้)
  4. ติดตั้งเครื่องมือ: shell sudo apt-get install make sudo apt-get install gcc
  5. ติดตั้ง libre จาก creytiv.com/re.html
  6. เรียกข้อมูลที่เหลือจาก creytiv.com/restund.html และคลายการแพคข้อมูล/
  7. wget hancke.name/restund-auth.patch และสมัครโดยใช้ patch -p1 < restund-auth.patch
  8. เรียกใช้ make, sudo make install สำหรับ libre และส่วนที่เหลือของส่วนที่เหลือ
  9. ปรับ restund.conf ตามความต้องการของคุณ (แทนที่ที่อยู่ IP และตรวจสอบว่ามีข้อมูลลับที่ใช้ร่วมกันเดียวกัน) แล้วคัดลอกไปยัง /etc
  10. คัดลอก restund/etc/restund ไปยัง /etc/init.d/
  11. กำหนดค่าส่วนที่เหลือโดยทำดังนี้
    1. ตั้งค่า LD_LIBRARY_PATH
    2. คัดลอก restund.conf ไปยัง /etc/restund.conf
    3. ตั้งค่า restund.conf เพื่อใช้ 10 รายการที่ถูกต้อง ที่อยู่ IP
  12. เรียกใช้เรสซุนด์
  13. ทดสอบโดยใช้ไคลเอ็นต์ Stund จากเครื่องระยะไกล: ./client IP:port

เป็นมากกว่าหนึ่งต่อหนึ่ง: WebRTC แบบหลายฝ่าย

คุณอาจต้องการดูมาตรฐาน IETF ที่ Justin Uberti เสนอสำหรับ REST API สำหรับการเข้าถึงบริการ TURN

เราคงนึกภาพกรณีการใช้งานสำหรับสตรีมมิงสื่อที่นอกเหนือไปจากการโทรแบบ 1 ต่อ 1 ได้ง่ายๆ ตัวอย่างเช่น การประชุมทางวิดีโอระหว่างกลุ่มเพื่อนร่วมงานหรือกิจกรรมสาธารณะที่มีวิทยากร 1 คนและผู้ชมหลายร้อยหรือล้านคน

แอป WebRTC สามารถใช้ RTCPeerConnection หลายรายการเพื่อให้ปลายทางทั้งหมดเชื่อมต่อกับปลายทางอื่นๆ ทั้งหมดในการกำหนดค่า Mesh ซึ่งเป็นแนวทางที่แอปต่างๆ เช่น talky.io ใช้ และมีประสิทธิภาพดีเยี่ยมสําหรับแอปเทียบเท่าจำนวนไม่มาก ยิ่งไปกว่านั้น การประมวลผลและการใช้แบนด์วิดท์ก็จะมากเกินไป โดยเฉพาะกับไคลเอ็นต์ที่ใช้อุปกรณ์เคลื่อนที่

ตาข่าย: การโทร N ทางขนาดเล็ก
โทโพโลยีแบบ Full Mesh: ทุกคนเชื่อมต่อกับทุกคน

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

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

หน่วยควบคุมหลายจุด

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

คุณซื้อแพ็กเกจฮาร์ดแวร์ MCU ที่สมบูรณ์ได้หรือสร้างแพ็กเกจฮาร์ดแวร์ขึ้นเอง

มุมมองด้านหลังของ Cisco MCU5300
ด้านหลังของ Cisco MCU

มีซอฟต์แวร์ MCU แบบโอเพนซอร์สให้เลือกหลายรายการ ตัวอย่างเช่น Licode (เดิมชื่อ Lynckia) จะสร้าง MCU แบบโอเพนซอร์สสำหรับ WebRTC OpenTok มี Mantis

ไม่ใช่แค่เบราว์เซอร์: VoIP, โทรศัพท์ และการรับส่งข้อความ

ลักษณะที่เป็นมาตรฐานของ WebRTC ช่วยให้สร้างการสื่อสารระหว่างแอป WebRTC ที่ทำงานในเบราว์เซอร์กับอุปกรณ์หรือแพลตฟอร์มที่ทำงานบนแพลตฟอร์มการสื่อสารอื่น เช่น โทรศัพท์หรือระบบการประชุมทางวิดีโอ

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

เครือข่ายโทรศัพท์พื้นฐาน (Public Switched Telephone Network หรือ PSTN) เป็นเครือข่ายแบบสลับวงจรของโทรศัพท์แอนะล็อก "แบบเก่า" ทั้งหมด สำหรับการโทรระหว่างเว็บแอป WebRTC กับโทรศัพท์ การรับส่งข้อมูลจะต้องผ่านเกตเวย์ PSTN ในทำนองเดียวกัน เว็บแอป WebRTC จำเป็นต้องมีเซิร์ฟเวอร์ XMPP ตัวกลางเพื่อสื่อสารกับปลายทาง Jingle เช่น ไคลเอ็นต์ IM Google ได้พัฒนา Jingle ขึ้นมาเป็นส่วนขยายของ XMPP เพื่อเปิดใช้เสียงและวิดีโอสำหรับบริการรับส่งข้อความ การใช้งาน WebRTC ในปัจจุบันจะอิงตามไลบรารี libjingle ของ C++ ซึ่งเป็นการใช้งาน Jingle ที่พัฒนาขึ้นสำหรับ Talk

แอป ไลบรารี และแพลตฟอร์มจำนวนมากใช้ความสามารถของ WebRTC ในการสื่อสารกับโลกภายนอก ดังนี้

  • sipML5: ไคลเอ็นต์ SIP โอเพนซอร์ส JavaScript
  • jsSIP: ไลบรารี SIP ของ JavaScript
  • Phono: API โทรศัพท์ JavaScript แบบโอเพนซอร์สที่สร้างขึ้นเป็นปลั๊กอิน
  • Zingaya: วิดเจ็ตโทรศัพท์แบบฝังได้
  • Twilio: เสียงและการรับส่งข้อความ
  • Uberconference: การประชุม

นักพัฒนาซอฟต์แวร์ sipML5 ยังสร้างเกตเวย์ webrtc2sip อีกด้วย Tethr และ Tropo ได้แสดงให้เห็นถึงกรอบการทำงานสำหรับการสื่อสารเมื่อเกิดภัยพิบัติ "ในกระเป๋าเอกสาร" โดยใช้เซลล์ OpenBTS เพื่อเปิดใช้การสื่อสารระหว่างฟีเจอร์โฟนและคอมพิวเตอร์ผ่าน WebRTC นั่นคือการสื่อสารทางโทรศัพท์โดยไม่ต้องใช้ผู้ให้บริการ

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

WebRTC Codelab จะแสดงวิธีการแบบทีละขั้นตอนในการสร้างแอปแชทผ่านวิดีโอและข้อความโดยใช้บริการส่งสัญญาณ Socket.io ที่ทำงานบน Node

การนำเสนอ Google I/O WebRTC จากปี 2013 กับ Justin Uberti หัวหน้าฝ่ายเทคโนโลยี WebRTC

การนำเสนอ SFHTML5 ของ Chris Wilson - ข้อมูลเบื้องต้นเกี่ยวกับแอป WebRTC

หนังสือที่มี 350 หน้าคือ WebRTC: API และโปรโตคอล RTCWEB ของเว็บแบบเรียลไทม์ HTML5 มีรายละเอียดมากมายเกี่ยวกับข้อมูลและเส้นทางการส่งสัญญาณ และมีแผนภาพโทโพโลยีเครือข่ายโดยละเอียดอีกมากมาย

WebRTC และ Signaling: "สิ่งที่ 2 ปีสอนเรา" - บล็อกโพสต์ของ TokBox ที่อธิบายว่าทำไมการปล่อยสัญญาณโดยไม่มีข้อกำหนดจึงเป็นความคิดที่ดี

คำแนะนำเชิงปฏิบัติในการสร้างแอป WebRTC ของ Ben Strong มีข้อมูลมากมายเกี่ยวกับโทโพโลยีและโครงสร้างพื้นฐาน WebRTC

บทของ WebRTC ในเครือข่ายเบราว์เซอร์ประสิทธิภาพสูงของ Ilya Grigorik จะเจาะลึกเกี่ยวกับสถาปัตยกรรม WebRTC, กรณีการใช้งาน และประสิทธิภาพ

เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ

อัปเดตล่าสุด 2013-11-04 UTC