แก้ไขคุณภาพการโทรวิดีโอ Nextcloud Talk และเปิดการเชื่อมต่อเซิร์ฟเวอร์

ปัญหาการโทรใน Nextcloud Talk มักถูกอธิบายว่า “คุณภาพวิดีโอไม่ดี” แต่สาเหตุที่แท้จริงนั้นไม่เหมือนกันทั้งหมด ผู้ใช้อาจมีแบนด์วิดท์เพียงพอแต่ยังคงเชื่อมต่อไม่ได้เนื่องจากไฟร์วอลล์บล็อกการรับส่งข้อมูล WebRTC แบบ peer-to-peer การโทรอีกครั้งอาจเชื่อมต่อได้สำเร็จผ่าน TURN แต่รู้สึกว่าช้าลงเพราะสื่อทั้งหมดถูกส่งต่อ การประชุมขนาดใหญ่อาจประสบปัญหาแม้ว่าเซิร์ฟเวอร์ TURN จะทำงานได้อย่างสมบูรณ์เพราะการใช้งานยังคงใช้โครงสร้างแบบ peer-to-peer ในตัวแทนที่จะใช้ High Performance Backend

ดังนั้น แนวทางการแก้ไขปัญหาที่มีประโยชน์ที่สุดคือการแยกการเชื่อมต่อเส้นทางสื่อและความสามารถในการขยายขนาดณ วันที่ 6 ตุลาคม 2026 เอกสาร Talk ของ Nextcloud ยังคงอธิบายว่า TURN เป็นทางเลือกสำรองเมื่อไม่สามารถเชื่อมต่อ WebRTC โดยตรงได้ และแนะนำให้ใช้พอร์ต 443 เพื่อความเข้ากันได้สูงสุด นอกจากนี้ยังระบุว่าอาจยังคงต้องใช้เซิร์ฟเวอร์ TURN เมื่อใช้ High Performance Backend ดูเอกสาร TURN อย่างเป็นทางการของ Nextcloud Talkและ คำแนะนำการตั้งค่า coturn อย่างเป็นทางการ สำหรับTalk

คุณควรแก้ไขปัญหาใดก่อน: แบนด์วิดท์, TURN หรือแบ็กเอนด์ประสิทธิภาพสูง?

ใช้รูปแบบอาการเพื่อเลือกการดำเนินการถัดไป แทนที่จะเปลี่ยนการตั้งค่าหลายอย่างพร้อมกัน

ขั้นตอนที่ 1: ระบุว่าปัญหาเกิดจากการเชื่อมต่อหรือคุณภาพของสื่อ

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

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

ขั้นตอนที่ 2: ตั้งค่า coturn สำหรับ Nextcloud Talk

สำหรับการใช้งานแบบโฮสต์เอง coturn เป็นการใช้งาน TURN ที่พบได้บ่อยที่สุดและมีการบันทึกไว้ในเอกสารของ Nextcloud Nextcloud แนะนำให้ใช้การตรวจสอบสิทธิ์ด้วยรหัสลับร่วม (shared-secret authentication) สำหรับการผสานรวมนี้ สร้างรหัสลับแบบสุ่มที่มีความปลอดภัยสูง และใช้ค่าเดียวกันทั้งใน coturn และการตั้งค่าการดูแลระบบของ Talk

openssl rand -hex 32

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

listening-port=443
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_RANDOM_SECRET
realm=turn.example.com
total-quota=0
bps-capacity=0
stale-nonce
no-multicast-peers

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

หาก coturn อยู่หลัง NAT ให้กำหนดค่าการแมปที่อยู่สาธารณะไปยังที่อยู่ส่วนตัวให้ถูกต้อง เอกสารอ้างอิงการกำหนดค่าของ coturn เองได้อธิบายexternal-ipการแมปไว้แล้ว และกำหนดให้พอร์ตรีเลย์ต้องแมปอย่างสม่ำเสมอผ่าน NAT ดูตัวอย่างการกำหนดค่า coturnต้นทาง

UDP, TCP หรือ TLS: คุณควรเปิดใช้งานตัวไหน?

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

เพื่อให้สามารถเข้าถึงได้มากที่สุด Nextcloud แนะนำให้รับฟังการเชื่อมต่อที่พอร์ต 443 และรองรับ TURN/TLS การใช้ทั้งสองอย่างturn:จะturns:ช่วยเพิ่มความเข้ากันได้ แต่ก็หมายความว่าต้องจัดการใบรับรองและเส้นทางการส่งข้อมูลเพิ่มเติม หากผู้ใช้ทั้งหมดอยู่ในเครือข่ายที่มีการควบคุมซึ่งทราบว่า UDP ทำงานได้ การออกแบบที่เน้น UDP เป็นหลักอาจใช้งานง่ายกว่า หากผู้ใช้เชื่อมต่อจากโรงแรม สถานที่ของลูกค้า สำนักงานที่มีการรักษาความปลอดภัยสูง หรือ VPN เป็นประจำ การใช้ TCP/TLS เป็นตัวเลือกสำรองมักคุ้มค่ากับการตั้งค่าเพิ่มเติม

ขั้นตอนที่ 3: เปิดพอร์ตผู้ฟังและพอร์ตรีเลย์ให้ถูกต้อง

ข้อผิดพลาดที่พบบ่อยคือการเปิดเฉพาะพอร์ต TURN listener เท่านั้น ไคลเอ็นต์จะติดต่อ coturn ผ่าน listener ก่อน แต่ coturn ยังจัดสรร relay endpoint สำหรับสื่อด้วย โดยค่าเริ่มต้นของ coturn จะใช้พอร์ต UDP 49152-65535สำหรับการจัดสรร relay หากช่วงพอร์ตนั้นถูกบล็อกโดยไฟร์วอลล์ของโฮสต์ กลุ่มความปลอดภัยบนคลาวด์ เราเตอร์ต้นทาง หรืออุปกรณ์ NAT การตรวจสอบสิทธิ์อาจสำเร็จในขณะที่สื่อยังคงล้มเหลว

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

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

ขั้นตอนที่ 4: เพิ่มเซิร์ฟเวอร์ TURN ใน Nextcloud Talk

เปิดพื้นที่การจัดการ Nextcloud แล้วไปที่การตั้งค่า Talk เพิ่มเซิร์ฟเวอร์ TURN โดยใช้ชื่อโฮสต์และพอร์ตโดยตรง ไม่ใช่URL เอกสาร Talk ปัจจุบันของ Nextcloud ระบุว่ารูปแบบ TURN จะถูกเลือกแยกต่างหาก ดังนั้นช่องเซิร์ฟเวอร์ควรอยู่ในรูปแบบ <hostname> . http://<port>.< ...https://turn.example.com:443

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

ห้ามเปิดเผยรหัสลับที่ใช้ร่วมกันในภาพหน้าจอ ตั๋ว หรือตัวอย่างการกำหนดค่าสาธารณะ Nextcloud ใช้รหัสลับนี้เพื่อสร้างข้อมูลรับรอง TURN ชั่วคราวสำหรับไคลเอ็นต์

ขั้นตอนที่ 5: ทดสอบผู้สมัคร ICE จากนั้นทดสอบจากเครือข่ายที่มีข้อจำกัด

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

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

คุณควรเพิ่มระบบแบ็กเอนด์ประสิทธิภาพสูงเมื่อใด?

TURN และ High Performance Backend แก้ปัญหาที่แตกต่างกัน TURN ทำหน้าที่ส่งต่อทราฟฟิกเมื่อไคลเอ็นต์ไม่สามารถสร้างเส้นทาง WebRTC ที่จำเป็นได้ ในขณะที่ High Performance Backend เปลี่ยนวิธีการจัดการสื่อที่มีผู้เข้าร่วมหลายคน เพื่อให้ผู้เข้าร่วมแต่ละคนไม่จำเป็นต้องอัปโหลดสตรีมแยกต่างหากไปยังผู้เข้าร่วมคนอื่นๆ

อินเทอร์เฟซ Talk ของ Nextcloud เองเตือนว่า การใช้งานโดยไม่ใช้ High Performance Backend นั้นเหมาะสำหรับสายสนทนาขนาดเล็กมากเท่านั้น ซึ่งโดยทั่วไปในโครงการจะอธิบายได้ว่ามีผู้เข้าร่วมประมาณสองถึงสามคน หากปัญหาของคุณเกิดขึ้นเฉพาะเมื่อจำนวนผู้เข้าร่วมเพิ่มขึ้น การเพิ่ม TURN อาจทำให้สามารถเข้าถึงไคลเอ็นต์ได้มากขึ้น แต่จะไม่ช่วยลดภาระการอัปโหลดแบบ peer-to-peer และ CPU ตรวจสอบข้อกำหนดของระบบ Nextcloud Talkและคำแนะนำเกี่ยวกับ High Performance Backend ของโครงการก่อนที่จะขยายขนาดการโทรแบบกลุ่ม

แม้จะมีแบ็กเอนด์ประสิทธิภาพสูงแล้ว ก็ควรเปิดใช้งาน TURN ไว้เมื่อผู้ใช้เชื่อมต่อจากเครือข่ายที่มีข้อจำกัด Nextcloud ได้ระบุช่วงพอร์ตสื่อ WebRTC เริ่มต้น20000-40000สำหรับแบ็กเอนด์ไว้ และระบุอย่างชัดเจนว่าไคลเอ็นต์ที่จำกัดเฉพาะพอร์ต 443 อาจยังคงต้องการ TURN เพื่อส่งต่อแพ็กเก็ตไปยังช่วงพอร์ตแบ็กเอนด์นั้น

TURN ที่ติดตั้งเองเทียบกับ TURN ที่ได้รับการจัดการ

รายการตรวจสอบการปรับแต่งเชิงปฏิบัติ

• ควรเลือกใช้ WebRTC โดยตรงเมื่อเป็นไปได้เพราะมักจะช่วยลดต้นทุนการส่งต่อข้อมูลและเวลาแฝงได้
• จัดให้มี TURN เพื่อความน่าเชื่อถือใช้เป็นเส้นทางสำรองในกรณีที่เกิดปัญหาเกี่ยวกับ NAT และไฟร์วอลล์
• ควรใช้ UDP ก่อน แล้วจึงใช้ TCP/TLS เพื่อความเข้ากันได้พอร์ต 443 เป็นพอร์ตที่เหมาะสมที่สุดสำหรับไฟร์วอลล์และเป็นตัวเลือกที่แนะนำโดย Nextcloud
• เปิดช่วงรีเลย์ ไม่ใช่แค่ตัวรับฟังเท่านั้นจับคู่กฎไฟร์วอลล์และ NAT กับการกำหนดค่าmin-port/ จริงmax-port
• ตรวจสอบแบนด์วิดท์ของ TURNการโทรแบบรีเลย์สามารถส่งปริมาณข้อมูลสื่อจำนวนมากผ่านโฮสต์ TURN ดังนั้นความจุของเครือข่ายจึงมักมีความสำคัญมากกว่า CPU
• แยกปัญหาเรื่องขนาดออกจากปัญหาเรื่องการเชื่อมต่อสำหรับการประชุมขนาดใหญ่ ควรประเมินประสิทธิภาพของระบบแบ็กเอนด์ระดับสูงแทนที่จะบังคับให้มีการรับส่งข้อมูลผ่าน TURN มากขึ้น
• ตรวจสอบความถูกต้องจากเครือข่ายผู้ใช้จริงการทดสอบ ICE เป็นสิ่งจำเป็น แต่เครือข่ายโรงแรม เครือข่ายองค์กร เครือข่าย VPN และเครือข่ายมือถืออาจทำงานแตกต่างกัน

สรุปแล้ว

หาก Nextcloud Talk ใช้งานได้บนบางเครือข่ายแต่ไม่ได้บนเครือข่ายอื่น ให้กำหนดค่าบริการ TURN ที่สามารถเข้าถึงได้อย่างถูกต้อง และตรวจสอบ Listener, Shared Secret, การแมป NAT และพอร์ต Relay หากการโทรเชื่อมต่อได้แต่คุณภาพไม่ดี ให้วัดโหลดของเครือข่ายไคลเอ็นต์และปลายทางก่อน เนื่องจาก TURN อาจเพิ่มความหน่วงแทนที่จะลดความหน่วง หากปัญหานี้เพิ่มขึ้นตามจำนวนผู้เข้าร่วม การแก้ไขปัญหาที่เหมาะสมกว่ามักจะเป็น High Performance Backend โดยคง TURN ไว้เป็นทางออกสำหรับเครือข่ายที่มีข้อจำกัด