เพิ่มประสิทธิภาพเครือข่ายสำหรับ Voice

ต่อไปนี้คือแนวทางปฏิบัติแนะนำบางส่วนในการตั้งค่าเครือข่ายสำหรับสายที่โทรผ่าน Google Voice

สร้างเครือข่ายที่พร้อมรองรับระบบคลาวด์

โครงสร้างพื้นฐานของเครือข่ายที่พร้อมรองรับระบบคลาวด์จะช่วยให้ระบบรับส่งข้อมูลของ Voice สื่อสารกับโครงสร้างพื้นฐานของ Google ได้อย่างมีประสิทธิภาพ โดยจะสร้างเครือข่ายได้ดังนี้

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

แนวทางปฏิบัติที่ดีที่สุดสำหรับพร็อกซี

ขอแนะนำว่าอย่าใช้พร็อกซีเซิร์ฟเวอร์ในเครือข่ายเพื่อรับส่งข้อมูลของ Voice

  • ในการกำหนดค่าพร็อกซี ให้ใส่การรับส่งข้อมูลของ Voice ไว้ในรายการที่อนุญาต
  • Voice จะไม่เปลี่ยนไปใช้ TCP เหมือนที่ Google Meet ทำ แต่ Voice จะใช้เฉพาะ UDP ในการรับส่งข้อมูลเท่านั้น
  • การรับส่งข้อมูลของพร็อกซีจะเพิ่มเวลาในการตอบสนองและอาจทำให้ Voice ต้องลดคุณภาพของระบบเสียงลงโดยอัตโนมัติ Voice จะทำงานได้ดีที่สุดเมื่อเวลาในการตอบสนองระหว่างไคลเอ็นต์กับระบบแบ็กเอนด์ของ Google ต่ำกว่า 100 มิลลิวินาที
  • ระบบไม่รองรับโปรโตคอลอินเทอร์เน็ต Socket Secure (SOCKS5)

การตรวจสอบแพ็กเก็ตหรือเครื่องมือวิเคราะห์โปรโตคอล

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

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

หากใช้เครื่องมือเหล่านี้ ให้ใส่หมายเลขพอร์ตการรับส่งข้อมูลของ Voice ทั้งหมดในรายการที่อนุญาตเพื่อข้ามเครื่องมือดังกล่าว

แนวทางปฏิบัติที่ดีที่สุดสำหรับ Wi-Fi

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

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

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

ย่านความถี่วิทยุ 2.4 GHz กับ 5 GHz

เราขอแนะนำไม่ให้นำแอปพลิเคชันแบบเรียลไทม์ไปใช้งานบนคลื่นความถี่ 2.4 GHz ในเครือข่ายไร้สาย (ซึ่งมักจะมีการใช้งานอย่างหนาแน่น) คำแนะนำนี้รวมถึงแอปพลิเคชันที่ให้การเชื่อมต่อในสภาพแวดล้อมสำนักงานทั่วไป

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

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

ข้อควรพิจารณาในการออกแบบ/การติดตั้งใช้งาน

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

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

หากมี SSID ของเครือข่ายไร้สายอยู่ในทั้ง 2 ย่านความถี่ (2.4 GHz และ 5 GHz) เครือข่ายควรใช้การบังคับย่านความถี่อย่างเข้มงวดเพื่อบังคับให้ไคลเอ็นต์จับกับย่านความถี่ 5 GHz

  • จำนวนที่เหมาะสมคือไม่เกิน 10 เครื่องต่อ AP 1 ตัว จำนวนที่มากกว่านี้อาจทำให้ผู้ใช้ได้รับประสบการณ์ที่คาดเดาไม่ได้
  • ทีมที่มีการใช้งานหนาแน่น/มีการโทรด้วยเสียงจำนวนมาก เช่น ตัวแทนหรือทีมสนับสนุน ไม่ควรใช้โทรศัพท์ตั้งโต๊ะที่เชื่อมต่อแบบไร้สาย เช่น เว็บไซต์ GOVO หรือศูนย์บริการทางโทรศัพท์ที่ให้บริการทุกวันตลอด 24 ชั่วโมง
  • อาจมีเสียงขาดหายเป็นช่วงสั้นๆ ไม่เกิน 10 วินาที และไม่สามารถกำจัดได้ในระดับเครือข่ายสำหรับโทรศัพท์ตั้งโต๊ะที่เชื่อมต่อแบบไร้สาย เราไม่แนะนำให้ใช้เครือข่ายไร้สายสำหรับการโทรที่มีความสำคัญสูง เช่น การประชุม การแถลงข่าว หรือการโทรของผู้บริหาร
  • แม้ว่ากฎในแต่ละประเทศ/ภูมิภาคจะแตกต่างกันไป แต่ข้อกำหนดโดยทั่วไปของอุปกรณ์ Wi-Fi ที่ใช้ช่องสัญญาณ DFS จะเหมือนกัน เช่น ต้องไม่รบกวนเรดาร์ของระบบพยากรณ์อากาศในท้องถิ่น ดังนั้น AP ที่มีการรบกวนเรดาร์จะทำให้สัญญาณหลุด และไคลเอ็นต์ทั้งหมดจะต้องเชื่อมต่อใหม่กับ AP คนละตัวที่ใช้ช่องสัญญาณที่แตกต่างกัน

หากต้องการใช้งานฟีเจอร์ขั้นสูง เช่น การโรมมิ่งอย่างไม่ติดขัดระหว่าง AP ต่างๆ และการจัดการคลื่น RF ให้เหมาะสม เครือข่ายไร้สายจะต้องได้รับการจัดการและดำเนินการจากส่วนกลาง ไม่ใช่เครื่องสแตนด์อโลนหลายๆ เครื่องรวมกัน

และสุดท้ายให้สำรวจเครือข่ายไร้สายหลังจากที่มีการปรับใช้แล้ว เพื่อให้แน่ใจว่ามีสัญญาณครอบคลุมทั่วพื้นที่ที่มีมักมีการใช้งาน Voice

ช่วงที่อยู่ IP ของ Voice

การรับส่งข้อมูลของ Voice มีการรักษาความปลอดภัยและเข้ารหัสไว้ คุณจึงไม่ต้องจำกัดการรับส่งข้อมูลไปยังที่อยู่ IP ของ Google

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

  • IPv4: 74.125.39.0/24
  • IPv6: 2001:4860:4864:2::0/64

ช่วงพอร์ตเสียง

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

  • พอร์ต UDP ขาออก 19302 ถึง 19309
  • TCP ขาออกในพอร์ต 443

หมายเหตุ: ช่วงพอร์ตของ Voice ตั้งแต่ 19302 ถึง 19309 จะใช้การตั้งค่าพอร์ต UDP ของ Chrome WebRTC โปรดดูข้อมูลเพิ่มเติมที่หัวข้อตั้งค่านโยบาย Chrome สำหรับผู้ใช้หรือเบราว์เซอร์