แก้ไขปัญหาการเชื่อมต่อหลุดใน Jitsi Meet ที่แสดงข้อความ “คุณถูกตัดการเชื่อมต่อ”

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

รายการตรวจสอบการคัดกรองเบื้องต้นอย่างรวดเร็ว

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

ขั้นแรก ให้ระบุว่าการเชื่อมต่อใดล้มเหลว

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

จดบันทึกเวลาที่การเชื่อมต่อหลุด ว่าเบราว์เซอร์แสดงข้อความแจ้งให้เชื่อมต่อใหม่หรือไม่ มีผู้เข้าร่วมคนอื่นได้รับผลกระทบหรือไม่ และการประชุมจัดขึ้นที่ meet.jit.si หรือบนโดเมน Jitsi ส่วนตัว หลีกเลี่ยงการโพสต์ URL ของการประชุมส่วนตัว ชื่อห้อง โทเค็นการเข้าถึง หรือบันทึกการประชุมที่ไม่ได้รับการแก้ไขลงในที่สาธารณะ

ตรวจสอบผู้เข้าร่วมโดยใช้เบราว์เซอร์

1. เชื่อมต่อใหม่อีกครั้งและยืนยันลิงก์การประชุม

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

2. ทดสอบกับเบราว์เซอร์ที่รองรับและอัปเดตแล้ว

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

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

3. เปรียบเทียบเครือข่าย

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

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

4. ตรวจสอบสภาพของอุปกรณ์และแอปพลิเคชัน

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

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

ปิดกล้องชั่วคราวแล้วดูว่าเสียงกลับมาใช้งานได้ปกติหรือไม่ วิธีนี้อาจช่วยลดการใช้แบนด์วิดท์ได้ แต่ไม่ได้แก้ไขปัญหาเส้นทางเซิร์ฟเวอร์ที่เสียหาย หากเสียงและวิดีโอใช้งานไม่ได้พร้อมกันในเครือข่ายหนึ่ง แต่ใช้งานได้ในเครือข่ายอื่น ให้ตรวจสอบข้อจำกัดของไฟร์วอลล์หรือ NAT คู่มือการโฮสต์ด้วยตนเองของ Jitsi ระบุว่า TCP 443 ใช้สำหรับการเข้าถึงเว็บทั่วไป UDP 10000 สำหรับการประชุมเสียง/วิดีโอปกติ และ TCP 5349 สำหรับการใช้งาน coturn เมื่อ UDP ถูกบล็อก การใช้งาน STUN ที่เป็นตัวเลือกอาจเกี่ยวข้องกับ UDP 3478 ด้วย นี่คือข้อกำหนดในการติดตั้งฝั่งเซิร์ฟเวอร์ ไม่ใช่พอร์ตที่ผู้เข้าร่วมควรเปิดบนอุปกรณ์ส่วนตัว โปรดดูคำแนะนำเกี่ยวกับไฟร์วอลล์และ NAT ของ Jitsi ในปัจจุบัน

หากการประชุมใช้งานได้บนการเชื่อมต่ออื่น ให้รายงานการเปรียบเทียบนั้นให้ผู้ดูแลระบบเครือข่ายทราบ ขอให้พวกเขาทบทวนกฎขององค์กรเกี่ยวกับชื่อโฮสต์ Jitsi และการรับส่งข้อมูล WebRTC แทนที่จะขอให้ปิดไฟร์วอลล์ทั้งหมด

ตรวจสอบหาผู้ดูแลระบบ Jitsi ที่ติดตั้งด้วยตนเอง

ยืนยันการเข้าถึงและเส้นทางสื่อ

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

sudo ufw status verbose
sudo ss -lntup

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

ตรวจสอบการตั้งค่า TLS, รีเวิร์สพร็อกซี และ Docker

สำหรับการใช้งานแบบ Reverse Proxy ตรวจสอบให้แน่ใจว่า HTTPS ทำงานได้ และ Proxy ส่งต่อสัญญาณ WebSocket อย่างถูกต้องคู่มืออย่างเป็นทางการของ Docker ได้ระบุ/xmpp-websocketเส้นทางและส่วนหัวที่จำเป็นในตัวอย่าง Nginx ไว้แล้ว Proxy ที่แสดงหน้าเว็บได้ แต่ละเลย WebSocket อาจทำให้ผู้ใช้ไม่สามารถรักษาเซสชันการประชุมไว้ได้

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

เชื่อมโยงบันทึกเซิร์ฟเวอร์กับเวลาที่เกิดเหตุ

เปรียบเทียบเวลาที่การตัดการเชื่อมต่อเกิดขึ้นกับบันทึกการบริการ ในการติดตั้งแพ็กเกจ Debian หรือ Ubuntu นั้น Jitsi จะบันทึกไฟล์บันทึกต่างๆ รวมถึง/var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.log, และ/var/log/prosody/prosody.logส่วนการใช้งาน Docker นั้น บันทึกจะถูกจัดเก็บผ่านคอนเทนเนอร์ ดังนั้นให้ตรวจสอบเอาต์พุตของคอนเทนเนอร์ที่เกี่ยวข้องและไดเร็กทอรีการกำหนดค่าสำหรับเวอร์ชันที่คุณติดตั้ง

sudo tail -n 150 /var/log/jitsi/jvb.log
sudo tail -n 150 /var/log/jitsi/jicofo.log
sudo tail -n 150 /var/log/prosody/prosody.log

ตรวจสอบช่วงเวลาใกล้เคียงกับเหตุการณ์ที่เกิดขึ้นเพื่อหาการรีสตาร์ทบริการ การเปลี่ยนแปลงการลงทะเบียนบริดจ์ ความล้มเหลวของ WebSocket ข้อผิดพลาดของใบรับรอง หรือการหมดเวลาการเชื่อมต่อซ้ำๆ ควรลบข้อมูลระบุตัวตนของผู้เข้าร่วม ชื่อห้อง ที่อยู่ IP และโทเค็นออกก่อนที่จะแชร์บันทึก นอกจากนี้ คู่มือการโฮสต์ด้วยตนเองของ Debian/Ubuntuยังแนะนำให้ลองใช้เบราว์เซอร์อื่น ตรวจสอบการรองรับ WebRTC และตรวจสอบกฎไฟร์วอลล์/NAT เป็นขั้นตอนการแก้ไขปัญหาเบื้องต้นด้วย

รายการตรวจสอบการยกระดับปัญหา

• บันทึกข้อมูลเกี่ยวกับโฮสต์ของ Jitsi เวลาโดยประมาณและเขตเวลา อุปกรณ์ ระบบปฏิบัติการ เวอร์ชันของเบราว์เซอร์หรือแอป และระบุว่าปัญหาดังกล่าวส่งผลกระทบต่อบุคคลเพียงคนเดียวหรือทั้งการประชุม
• โปรดสังเกตว่าการใช้เบราว์เซอร์หรือเครือข่ายที่แตกต่างกันส่งผลต่อผลลัพธ์หรือไม่
• สำหรับเซิร์ฟเวอร์ที่ดูแลเอง โปรดระบุการอัปเกรดพร็อกซี ไฟร์วอลล์ DNS ใบรับรอง หรือ Jitsi ล่าสุดด้วย
• เปิดเผยเฉพาะข้อมูลการวินิจฉัยที่จำเป็นขั้นต่ำเท่านั้น โดยลบรายละเอียดห้องส่วนตัวและข้อมูลประจำตัวออก
• หากใช้ meet.jit.si หรือโฮสต์ที่ได้รับการจัดการอื่นๆ โปรดส่งรายงานไปยังผู้จัดประชุมหรือฝ่ายสนับสนุนบริการ ผู้เข้าร่วมไม่สามารถเปลี่ยนแปลงไฟร์วอลล์หรือการกำหนดค่าเซิร์ฟเวอร์ของโฮสต์นั้นได้

วิธีตรวจสอบความถูกต้องของการแก้ไข

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