อินเทอร์เน็ตเร็ว แต่โทรศัพท์เสียงขาด เพราะอะไร?

1. Speed Test ดูดี แต่ทำไมลูกค้ายังถามว่า “เมื่อกี้พูดว่าอะไรนะ?”

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

นี่คือตัวอย่างสมมติ ไม่ใช่กรณีศึกษาลูกค้าของ SIPPER คำถามคือ ผลทดสอบความเร็วบอกสิ่งที่การสนทนาต้องการครบหรือไม่

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

บทความนี้พูดถึง VoIP (Voice over Internet Protocol) หรือการส่งเสียงผ่านเครือข่าย IP เช่น IP phone และ softphone รวมถึงระบบโทรศัพท์คลาวด์ ก่อนเปลี่ยนบริการ จึงควรถามว่า “เสียงสะดุดที่ส่วนไหน?”

ภาพที่ 01 · Fast Internet. Choppy Calls? ความเร็วรับส่งข้อมูลเป็นเพียงส่วนหนึ่งของคุณภาพการโทร ต้องพิจารณาการส่งเสียงให้ทันเวลาและสม่ำเสมอด้วย

2. Bandwidth กับคุณภาพเสียงโทรศัพท์ ไม่ใช่เรื่องเดียวกัน

ความจุของการเชื่อมต่อ กับผลที่วัดได้

Bandwidth คือความจุในการรับส่งข้อมูล ส่วน throughput คืออัตรารับส่งที่ทำได้จริงขณะวัด การประเมินคุณภาพเครือข่ายของ Cloudflare เองก็ใช้ข้อมูลมากกว่าความเร็วรับส่ง [14]

ตัวชี้วัดที่เกี่ยวข้องกับการสนทนา

เสียงหน่วงกับเสียงขาดไม่ใช่อาการเดียวกัน Latency สูงทำให้การโต้ตอบล่าช้าเป็นหลัก ไม่ได้แปลว่าเสียงต้องขาดเสมอ ส่วน jitter และ packet loss ต้องดูวิธีรับมือของระบบเสียงร่วมด้วย [1] [2] [3]

ทำไมเสียงสนทนาจึงรอไม่ได้เหมือนไฟล์ดาวน์โหลด

ฝั่งรับมี jitter buffer หรือพื้นที่พักแพ็กเก็ตสั้น ๆ เพื่อจัดจังหวะก่อนเล่นเสียง แต่รับมือได้จำกัด แพ็กเก็ตที่มาช้าเกินไปอาจถูกทิ้ง และการเพิ่มเวลาพักก็เพิ่มความหน่วงตามไปด้วย [2]

ถึงอย่างนั้น bandwidth ก็ยังสำคัญ การวางแผนต้องรวม codec ระยะเสียงต่อแพ็กเก็ต ข้อมูลส่วนหัวของโปรโตคอล และจำนวนสายที่โทรพร้อมกัน ไม่ใช่นับเฉพาะข้อมูลเสียงอย่างเดียว [4]

ภาพที่ 02 · Speed vs Voice Quality ความจุและคุณภาพการส่งถึงปลายทางต้องพิจารณาร่วมกัน ไม่ใช่เลือกดูอย่างใดอย่างหนึ่ง

3. จุดที่ควรตรวจเมื่อเสียงขาด แม้ความเร็วอินเทอร์เน็ตยังเหลือ

ความแออัดและ bufferbloat

เมื่อข้อมูลเข้าจุดคอขวดเร็วกว่าที่ส่งออกได้ แพ็กเก็ตต้องรอคิว งานอัปโหลด สำรองข้อมูล CCTV ขึ้นคลาวด์ หรือวิดีโอสตรีมจึงควรอยู่ในรายการตรวจเมื่อใช้งานหนัก ส่วน bufferbloat คือการพักข้อมูลมากเกินไปจนเกิดความหน่วง ไม่ใช่ชื่อเรียกรวมของอินเทอร์เน็ตช้าทุกกรณี [5] [6]

Wi-Fi และเครือข่ายภายใน

ควรดูทั้งความครอบคลุม การรบกวน การแย่งใช้ช่องสัญญาณ และตำแหน่ง access point หรือ AP สัญลักษณ์เชื่อมต่อหรือขีดสัญญาณเต็มไม่ได้ยืนยันคุณภาพสำหรับเสียงแบบ real-time เครือข่าย Wi-Fi ที่ออกแบบเหมาะสมใช้โทรได้ แต่ควรมีผลทดสอบผ่านสาย LAN ไว้เปรียบเทียบ [7]

Router, firewall, NAT และ routing

อย่าดูแค่ความเร็วพอร์ตของ router ให้ตรวจภาระงานและคิวด้วย เพราะอุปกรณ์อาจรับงานจริงไม่ไหวแม้พอร์ตรองรับความเร็วสูง [14]

NAT ทำหน้าที่แปลงที่อยู่เครือข่าย ส่วน firewall ควบคุมการเชื่อมต่อ ทั้งสองต้องรองรับเส้นทางตั้งสายและเส้นทางเสียงที่ใช้งานจริง ปัญหาเข้าถึงปลายทางไม่ได้จึงอาจต้องตรวจคนละแบบกับเสียงสะดุดเป็นช่วง [8]

SIP ALG คือฟังก์ชันที่เข้าใจและอาจปรับข้อมูลการสื่อสาร SIP ตัวช่วยลักษณะนี้อาจรบกวนกลไกผ่าน NAT ของระบบอื่น จึงควรตรวจตามสถาปัตยกรรมและคำแนะนำผู้ผลิต ไม่เปลี่ยนค่าโดยเดา [9]

Codec และการเชื่อมต่อระหว่างระบบ

Codec คือวิธีเข้ารหัสและถอดรหัสเสียง ระบบต้องตกลงรูปแบบที่รองรับร่วมกันได้ หากการเจรจาแบบ SDP offer/answer ไม่มีรูปแบบร่วมกัน อาจปฏิเสธสตรีมเสียงหรือการเชื่อมต่อ ไม่ใช่แค่เสียงกระตุก [10]

ส่วน transcoding คือการแปลงระหว่างรูปแบบเสียง ซึ่งอาจจำเป็นต่อการเชื่อมต่อ ไม่ใช่ข้อผิดพลาดในตัวเอง ควรระบุว่าการแปลงเกิดตรงไหน แล้วตรวจความสามารถและการตั้งค่าของจุดนั้น [11]

อุปกรณ์และโปรแกรมของผู้ใช้

Headset ไมโครโฟน IP phone โปรแกรม softphone รุ่นซอฟต์แวร์ และไดรเวอร์เสียง ล้วนควรอยู่ในรายการตรวจ [12] สำหรับคอมพิวเตอร์ ให้เทียบช่วงมีและไม่มีงานหนัก ดูภาระ CPU ควบคู่กับอาการ ไม่สรุปว่าเป็นเครือข่ายทั้งหมด

เครือข่ายภายนอกและ cloud path

เส้นทางหลังออกจากสำนักงานก็สำคัญ แนวทาง Microsoft 365 เน้นการเชื่อมต่อเข้าบริการอย่างมีประสิทธิภาพ แทนการอ้อมผ่านจุดรวมโดยไม่จำเป็น [13] จึงควรเปรียบเทียบเส้นทางสาขา VPN และเครือข่ายของคู่สนทนาด้วย โดยยังไม่ชี้ว่าผู้ให้บริการรายใดเป็นต้นเหตุ

ภาพที่ 03 · What Affects Call Quality? การตรวจคุณภาพเสียงควรครอบคลุมเครือข่าย อุปกรณ์ และการเชื่อมต่อระบบโทรศัพท์ ไม่สรุปจากความเร็วอินเทอร์เน็ตเพียงอย่างเดียว

4. ทำไมการดูผล Speed Test อย่างเดียวจึงยังไม่พอ?

ดูมากกว่าตัวเลขที่ใหญ่ที่สุด

Speed Test มีประโยชน์ และบางเครื่องมือ เช่น Cloudflare แสดง latency, jitter และ packet loss ด้วย ปัญหาคือการดูเฉพาะ Download/Upload แล้วใช้ตัดสินว่าเส้นทางเสียงไม่มีปัญหา [15]

เปรียบเทียบตอนเครือข่ายว่างกับตอนมีโหลด

Loaded latency คือความหน่วงที่วัดระหว่างมี traffic ใช้งาน ช่วยให้ถามได้ว่า “ตอนรับส่งข้อมูลหนัก เครือข่ายยังตอบสนองดีอยู่ไหม?” ซึ่งต่างจากการถามว่ารับส่งได้เร็วที่สุดเท่าไร [14]

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

วัดให้สัมพันธ์กับสายที่มีปัญหา

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

5. เสียงหนึ่งสายต้องผ่านอะไรบ้าง?

ตัวอย่างเส้นทางแบบย่อคือ:

IP phone / softphone ↔ LAN / Wi-Fi ↔ router/firewall ↔ อินเทอร์เน็ต ↔ แพลตฟอร์มเสียงหรือจุดรับส่งสื่อ ↔ เครือข่ายปลายทาง ↔ คู่สนทนา

นี่คือภาพรวมแนวคิด ไม่ใช่แบบติดตั้งสำหรับทุกองค์กร ตำแหน่ง PBX หรือ Session Border Controller (SBC) อาจต่างกัน และเสียงอาจวิ่งตรง ผ่านตัวกลางส่งต่อ หรือผ่านระบบประมวลผลตามการออกแบบ [8] [16]

Signaling ใช้ตั้งสายและควบคุมการโทร ส่วน media คือข้อมูลเสียง ในระบบ SIP มักใช้ RTP ส่งสื่อ และใช้ SRTP เมื่อมีการตกลงส่งสื่อแบบปลอดภัย เส้นทางทั้งสองไม่จำเป็นต้องเหมือนกัน ส่วน Teams client ก็ไม่ควรอธิบายเหมือน SIP phone ทั่วไป เพราะ Microsoft แยกวิธี signaling ของ client กับการใช้ SIP ในบางการเชื่อมต่อ [16]

จึงต้องแยกตรวจว่า “ตั้งสายสำเร็จหรือไม่” กับ “เสียงเดินทางได้ถูกต้องทั้งสองทิศทางหรือไม่”

ภาพที่ 04 · A Typical Voice Path ตัวอย่างแบบย่อ ตำแหน่ง PBX/SBC และเส้นทาง media จริงขึ้นกับสถาปัตยกรรม และอาจต่างจากเส้นทาง signaling

6. สถานการณ์ตัวอย่างในองค์กร: อาการคล้ายกัน แต่จุดตรวจอาจต่างกัน

ตัวอย่างต่อไปนี้เป็นสมมติฐานเพื่อเลือกการทดสอบ ไม่ใช่คำวินิจฉัย

ควรเปลี่ยนทีละตัวแปร การเปลี่ยน headset ย้ายไป LAN และเปลี่ยนผู้ให้บริการพร้อมกัน ไม่ช่วยระบุว่าอะไรแก้ปัญหาได้จริง แนวทางนี้อิงปัจจัยด้านเครือข่าย อุปกรณ์ และคิว [5] [7] [12]

7. Checklist ตรวจเบื้องต้นก่อนซื้ออุปกรณ์หรือเพิ่มแพ็กเกจอินเทอร์เน็ต

ระบุขอบเขตและทิศทางของปัญหา

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

“โทรออก” บอกว่าใครเริ่มสาย ไม่ได้บอกว่าเสียงทิศทางใดเสีย ต้องตรวจสตรีมขาส่งและขารับแยกกัน [12]

เปรียบเทียบเครือข่ายและช่วงใช้งาน

• ทดสอบเครื่องเดิมผ่าน LAN และ Wi-Fi เทียบช่วงมีปัญหากับช่วงปกติ
• ตรวจการใช้งานขารับ/ขาส่ง error หรือ drop ของพอร์ต คิว และภาระ router/firewall ระหว่างเกิดเหตุ
• วัด latency, jitter, packet loss และตรวจว่า QoS จัดประเภทและให้ความสำคัญกับ traffic ที่ต้องการจริงหรือไม่

ระบุให้ชัดว่าเป็นความหน่วงขาเดียวหรือ RTT (round-trip time) ซึ่งวัดไปและกลับ ไม่ควรถือว่าหาร RTT ด้วยสองแล้วได้ค่าขาเดียวที่แม่นยำเสมอ และไม่ใช้เกณฑ์ผ่าน/ไม่ผ่านชุดเดียวกับทุกระบบโดยไม่ระบุวิธีวัด

ตรวจอุปกรณ์และข้อมูลของสาย

• สลับ headset หรือเครื่องทดสอบ ตรวจรุ่นโปรแกรม ไดรเวอร์ และภาระ CPU
• ตรวจ codec และเส้นทาง SIP/RTP หรือ media ของแพลตฟอร์ม รวมถึง NAT, firewall, routing และ SIP ALG
• เก็บหมายเลขอ้างอิงสายและสถิติเสียงที่มี RTCP ซึ่งเป็นโปรโตคอลรายงานประกอบ RTP สามารถให้ข้อมูลการรับ เช่น packet loss และ interarrival jitter ได้ [17]

ผู้ดูแล Teams ใช้หน้าตรวจการประชุมและการโทรใน admin center ตามสิทธิ์และข้อมูลที่มีได้ โดยรายละเอียดขึ้นกับชนิดเซสชันและอุปกรณ์ [18] ควรดูการสูญหายเป็นช่วงและแพ็กเก็ตที่ถูกทิ้งเพราะมาช้า ไม่ดูแต่ค่าเฉลี่ย แพ็กเก็ตที่นับว่ามาถึงแล้วอาจยังช้าเกินจะเล่นเสียงทัน [3]

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

ภาพที่ 05 · Troubleshooting Checklist เริ่มจากระบุอาการและขอบเขต เปรียบเทียบทีละตัวแปร แล้ววัดผลก่อนและหลังปรับปรุง

8. ปรับปรุงอย่างไรให้ตรงจุด ไม่ใช่แค่เพิ่มความเร็ว?

เริ่มจากสิ่งที่เปรียบเทียบได้

จุดรับสายประจำที่สำคัญควรทดลองสาย LAN ก่อนตัดสินใจเปลี่ยนระบบใหญ่ ส่วนผู้ใช้ที่ต้องเคลื่อนที่ควรประเมินความครอบคลุมและความจุ Wi-Fi ไม่ใช่สรุปว่าต้องเลิกใช้ทั้งหมด [7]

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

ใช้ QoS และการจัดคิวอย่างมีเป้าหมาย

QoS (Quality of Service) คือการให้ความสำคัญกับ traffic บางประเภทในเครือข่ายที่ใช้นโยบายนั้น ไม่ได้เพิ่มความจุหรือรับประกันว่าอินเทอร์เน็ตสาธารณะจะจัดการแพ็กเก็ตแบบเดียวกัน ต้องตรวจการจำแนก ทำเครื่องหมาย และคิวในเครือข่ายที่บริหารได้ โดยดู media ไม่ใช่เฉพาะข้อความตั้งสาย [1]

การแยก voice VLAN ช่วยจัดระบบและนโยบาย แต่ไม่ได้จอง bandwidth ให้อัตโนมัติ ส่วน traffic shaping และ AQM (Active Queue Management) หรือการจัดการคิวเชิงรุก อาจช่วยเมื่อพบคอขวดที่เกี่ยวข้อง ต้องเลือกให้เหมาะกับอุปกรณ์และวัดผล ไม่ตั้งเพดานกับเสียงทุกสายโดยเดา นโยบายคิวข้อมูลทั่วไปอาจต่างจากคิวเสียงที่ออกแบบให้มีลำดับความสำคัญ [5] [6] [19]

สำหรับ Teams และบริการคลาวด์อื่น ควรทำตามแนวทาง media path ของแพลตฟอร์ม ไม่เพิ่มอุปกรณ์ตรวจหรือจำกัด traffic กลางทางโดยไม่จำเป็น [16]

ตรวจการเชื่อมต่อและวัดผลซ้ำ

ทบทวน codec จุดแปลงเสียง และการตั้งค่า trunk ร่วมกับผู้เกี่ยวข้อง หากสงสัย SIP ALG ให้ทดสอบเปิด/ปิดเฉพาะขอบเขตตามคำแนะนำผู้ผลิตและมีแผนย้อนกลับ ไม่ปิด firewall หรือเปิด PBX กว้างสู่ภายนอกเพื่อทดลองแบบลัดขั้นตอน

เพิ่ม bandwidth เมื่อข้อมูลชี้ว่าความจุไม่พอจริง โดยคิดจำนวนสายพร้อมกัน ทั้งสองทิศทาง overhead แอปอื่น และความจุเผื่อใช้งาน ไม่คำนวณจากสายเดียวในสภาพอุดมคติ [4]

หลังปรับปรุงให้ทดสอบเงื่อนไขใกล้เคียงเดิม เก็บค่าฐานเพื่อติดตามต่อ ความสำเร็จคือผู้ใช้พบปัญหาน้อยลงและหลักฐานรายสายดีขึ้น ไม่ใช่แค่ผล Speed Test สูงขึ้น

9. SIPPER ช่วยให้องค์กรมองระบบโทรศัพท์ทั้งภาพได้อย่างไร?

SIPPER ให้บริการ SIP Trunk และ DID ในประเทศไทย การหารือเรื่องคุณภาพเสียงควรดูว่าเครือข่าย อุปกรณ์ PBX (ระบบตู้สาขาโทรศัพท์) และ trunk ทำงานร่วมกันอย่างไร ไม่ตั้งต้นว่าเปลี่ยน trunk แล้วทุกอาการจะหาย

องค์กรสามารถติดต่อ SIPPER เพื่อหารือระบบที่ใช้อยู่ ความพร้อมเครือข่าย การเชื่อมต่อ PBX/SIP Trunk และขอบเขตการประเมินหรือปรับปรุงที่เหมาะสม โดยเตรียมตัวอย่างสายที่มีปัญหา พร้อมข้อมูลสาขาและอุปกรณ์

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

10. สรุป: อย่าดูแค่ว่าเน็ตเร็วแค่ไหน ให้ดูว่าเสียงเดินทางได้ดีเพียงใด

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

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

องค์กรพบปัญหาเสียงขาดบ่อย? ติดต่อ SIPPER เพื่อหารือระบบโทรศัพท์องค์กร และแนวทางประเมินที่เหมาะกับสภาพแวดล้อมของคุณ

แหล่งอ้างอิง

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

1. Microsoft Learn - Implement Quality of Service (QoS) in Microsoft Teams
2. Cisco - Understanding Jitter in Packet Voice Networks
3. IETF / RFC Editor - RFC 3611 - RTP Control Protocol Extended Reports (RTCP XR), sections 4.7.1–4.7.2
4. Cisco - Modify Bandwidth Consumption Calculation for Voice Calls
5. IETF / RFC Editor - RFC 7567 - IETF Recommendations Regarding Active Queue Management
6. IETF / RFC Editor - RFC 8290 - The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm
7. Microsoft Learn - Prepare your organization’s network for Microsoft Teams
8. IETF / RFC Editor - RFC 6314 - NAT Traversal Practices for Client-Server SIP
9. IETF / RFC Editor - RFC 4787 - Network Address Translation (NAT) Behavioral Requirements for Unicast UDP, section 7
10. IETF / RFC Editor - RFC 3264 - An Offer/Answer Model with the Session Description Protocol (SDP), section 6.1
11. IETF / RFC Editor - RFC 7667 - RTP Topologies, section 3.2.1.3
12. Microsoft Learn - Use CQD to manage call and meeting quality in Microsoft Teams
13. Microsoft Learn - Microsoft 365 network connectivity principles
14. Cloudflare - Aggregated Internet Measurement (AIM)
15. Cloudflare - Internet Speed Test - Measure Network Performance
16. Microsoft Learn - Microsoft Teams call flows
17. IETF / RFC Editor - RFC 3550 - RTP: A Transport Protocol for Real-Time Applications, section 6.4.1
18. Microsoft Learn - Monitor and troubleshoot Teams meetings and calls from the Teams admin center
19. IETF / RFC Editor - RFC 4594 - Configuration Guidelines for DiffServ Service Classes, sections 4.1–4.2