ก่อนเริ่มต้น
โปรดตรวจสอบว่าคุณมีสิ่งต่อไปนี้เมื่อต้องการแก้ปัญหาเกี่ยวกับ SIP Link
- การดักจับแพ็กเก็ตใน SBC
- การบันทึกแพ็กเก็ตบนไฟร์วอลล์ของคุณ
- เครื่องมือสำหรับดูแพ็กเก็ตแคปเจอร์
- เข้าถึงบันทึก SBC
หมายเหตุ: หากต้องการความช่วยเหลือเพิ่มเติมเกี่ยวกับการแก้ปัญหา โปรดติดต่อตัวแทนจำหน่ายหรือผู้ให้บริการ SBC
ยืนยันการเชื่อมต่อสัญญาณด้วย SIP Link
การส่งสัญญาณสำหรับ SIP Link ใช้ Transport Layer Security (TLS) TLS ประกอบด้วยแพ็กเกจใบรับรองที่สร้างโดย Public Certificate Authorities (CA) คุณสามารถตรวจสอบสถานะการเชื่อมต่อ TLS ได้จากแผงควบคุมของผู้ดูแลระบบในหน้า Landing Page ของ SIP Link
- ยืนยันว่าใบรับรอง TLS มาจาก CA ต่อไปนี้
- DigiCert
- Entrust DataCard
- GlobalSign
- GoDaddy
- Sectigo
- เริ่มต้นแฮนด์เชคชุดโปรโตคอลสำหรับควบคุมการรับส่งข้อมูล (TCP) แบบ 3 ทาง ตามด้วยแฮนด์เชค TLS
เมื่อมีการแลกเปลี่ยนใบรับรอง Voice จะส่งใบรับรองตามด้วยใบรับรองของ SBC
- เมื่อการแลกเปลี่ยนข้อมูลเริ่มขึ้นแล้ว Voice กับ SBC ของคุณจะแลกเปลี่ยนข้อมูลแอปพลิเคชันกันได้
แก้ปัญหาคุณภาพการโทร
หากเกิดปัญหาเกี่ยวกับคุณภาพการโทร ให้ตรวจสอบว่าเวลาในการตอบสนองของเครือข่ายมีความสม่ำเสมอและอยู่ในระดับต่ำ คุณภาพการโทรจะดีที่สุดเมื่อการรับส่งข้อมูลของ Voice ใช้เส้นทางที่สั้นที่สุดระหว่าง Voice กับ SBC เป้าหมายสำหรับเวลาในการตอบสนองไป-กลับควรอยู่ที่ 100 มิลลิวินาทีหรือน้อยกว่านั้น
วิธีทดสอบเวลาในการตอบสนองของเครือข่าย
- ใช้คำสั่ง ping กับเซิร์ฟเวอร์ส่วนหน้าของสื่อ Voice จากอินเทอร์เฟซภายนอกของ SBC
- เชื่อมต่อ Voice ไว้อย่างน้อย 4 ชั่วโมง
- ตรวจสอบว่าเวลาในการตอบสนองนั้นสม่ำเสมออยู่ที่ไม่เกิน 100 มิลลิวินาที อย่าคำนวณค่าเฉลี่ยของเวลาในการตอบสนอง และให้ตรวจสอบช่วงที่เพิ่มขึ้นอย่างผิดปกติของเวลาในการตอบสนองเป็นครั้งคราว
- หากเวลาในการตอบสนองมากกว่า 100 มิลลิวินาที ให้ใช้ยูทิลิตี traceroute เพื่อพิมพ์เส้นทางเครือข่ายจาก SBC หรือเครื่องไคลเอ็นต์ไปยังฟรอนท์เอนด์ของสื่อ Voice โดยเส้นทางนี้ควรสั้นที่สุดดังตัวอย่างต่อไปนี้
- สำหรับเดสก์ท็อป ให้ใช้ > traceroute lens.voice.google.com
- สําหรับ Chromebook ให้ใช้ > tracepath lens.voice.google.com
- สำหรับ SBC ให้ใช้ traceroute siplink.telephony.goog หรือ traceroute lens.voice.google.com
แก้ปัญหาการเชื่อมต่อสัญญาณที่พบบ่อย
สร้างเซสชัน TCP ระหว่าง SBC และ Voice ไม่ได้
หากเซสชัน TCP ไม่เริ่มต้น อาจเป็นเพราะปัญหาของไฟร์วอลล์หรือการเชื่อมต่อเครือข่าย SBC อาจส่งข้อความ SYN แต่ไม่ได้รับการตอบกลับ
วิธีแก้ปัญหามีดังนี้
- ใช้คำสั่ง ping siplink.telephony.google เพื่อให้แน่ใจว่าการเชื่อมต่อเครือข่ายพร้อมใช้งาน
- เปิดใช้พอร์ตปลายทาง 5672 สําหรับ Voice
- ยืนยันว่า DNS ทํางานได้กับความละเอียด siplink.telephony.goog
- ตรวจสอบว่าไฟร์วอลล์ของคุณอนุญาตให้มีการรับส่งจาก SBC และพอร์ต siplink.telephony.goog:5672 เปิดอยู่
สร้างเซสชัน TLS ระหว่าง SBC และ Voice ไม่ได้
หากเซสชัน TLS ไม่เริ่มต้น อาจเป็นเพราะปัญหาการรับรอง PCA คุณอาจได้รับการแจ้งเตือนที่ร้ายแรงว่าไม่รู้จักใบรับรอง
วิธีแก้ปัญหามีดังนี้
- ตรวจสอบว่าได้อัปโหลดใบรับรองรูทและใบรับรองกลางที่เชื่อมโยงกับ PCA ไว้ในคีย์สโตร์ที่เชื่อมโยงกับโปรไฟล์ TLS สําหรับ SIP Link แล้ว เมื่อสร้าง CSR สําหรับใบรับรองของ SBC โปรดทำตามหลักเกณฑ์ในเอกสารการทำงานร่วมกันสำหรับผู้ให้บริการ SBC ที่เกี่ยวข้อง
- ตรวจสอบว่าใบรับรอง SBC เป็นไปตามหลักเกณฑ์ต่อไปนี้
- ขนาดคีย์ 2,048
- การเข้ารหัส RSA หรือ ECDSA
- ชื่อทั่วไป (CN) ตรงกับชื่อโฮสต์ที่สร้างขึ้นสำหรับ SIP Link
- โดเมนของ CN ในใบรับรองตรงกับโดเมน Workspace
- เปิดใช้การตรวจสอบสิทธิ์ร่วมกัน
- เปิดใช้การตรวจสอบสิทธิ์เซิร์ฟเวอร์และไคลเอ็นต์
- ไม่รองรับใบรับรองไวลด์การ์ด
- ตรวจสอบว่าใบรับรอง GTSR1 ของ Google ที่พบใน pki.goog นั้นได้รับการอัปโหลดไปยังคีย์สโตร์สําหรับโปรไฟล์ TLS ของ SIP Link ที่เกี่ยวข้องด้วยเช่นกัน
- ตรวจสอบว่าใบรับรองจาก SBC ไปยัง Google หมดอายุหรือไม่
การตอบสนอง "404 or 604 Not Found" ระหว่างคำเชิญ SBC
หากได้รับการตอบกลับ "404 or 604 Not Found" ระหว่างคำเชิญจาก SBC แสดงว่าคุณอาจจะยังไม่ได้กําหนดหมายเลข SBC ให้กับ Voice
วิธีแก้ปัญหามีดังนี้
- ตรวจสอบว่ามีการกำหนดหมายเลขโทรศัพท์สำหรับ SBC ให้กับผู้ใช้ การต่อสายอัตโนมัติ หรือกลุ่มผู้ใช้ที่เป็นผู้รับสายใน Voice แล้ว
- ยืนยันว่าหมายเลขโทรศัพท์อยู่ในรูปแบบ E 164 ในส่วนหัว PAI
การตอบสนอง "400 Bad Request" ระหว่างคำเชิญ SBC
หากได้รับการตอบสนอง "400 Bad Request" ระหว่างคำเชิญจาก SBC แสดงว่าคุณอาจไม่ได้ใช้คีย์ลับที่ถูกต้อง
วิธีแก้ปัญหามีดังนี้
- ตรวจสอบข้อความคำเชิญว่ามีส่วนหัว SIP X-Google-Pbx-Trunk-Secret-Key ที่มีค่าที่ถูกต้องหรือไม่ โดยคีย์นี้จะสร้างขึ้นเมื่อคุณตั้งค่า SIP Link
- ยืนยันว่าหมายเลขโทรศัพท์อยู่ในรูปแบบ E 164 ในส่วนหัว P-Asserted-Identity
การตอบสนอง "403 Forbidden" จาก Voice
หากคุณได้รับการตอบกลับ "403 Forbidden" แสดงว่า URI คำขอ (RURI) ของคุณในคำเชิญจาก SBC ถึง Voice อาจไม่ถูกต้อง ยืนยันว่าโฮสต์ของ RURI คือ trunk.sip.voice.google.com
แก้ปัญหาการเชื่อมต่อสื่อทั่วไป
ก่อนที่จะเริ่มแก้ปัญหาเกี่ยวกับการเชื่อมต่อสื่อ โปรดตรวจสอบว่าเครือข่ายมีคุณสมบัติตรงตามเงื่อนไขต่อไปนี้
- เครือข่ายใช้การเข้ารหัส Datagram Transport Layer Security (DTLS) หรือการเข้ารหัส Session Description Protocol Security Description for Media Streams (SDES) อย่างใดอย่างหนึ่ง
- คุณไม่ได้ใช้ข้อเสนอ SDP ที่ไม่ได้เข้ารหัส การโทรด้วยวิธีนี้จะสิ้นสุดโดยอัตโนมัติ
- ต้องปิดใช้งาน MKI หรือ Crypto Lifetime
- หากใช้ DTLS อยู่ ระบบจะใช้ใบรับรองแบบ Self-signed ใน SBC โดยใบรับรองนี้ไม่จําเป็นต้องเป็นใบรับรองที่ลงชื่อโดย CA
- ตรวจสอบว่าได้กำหนดค่าตัวแปลงรหัสที่รองรับในโปรไฟล์ Voice ของ SBC, G711 mulaw (PCMU), G711 alaw (PCMA), Opus หรือ G722 แล้ว
- ระบบความถี่สูง 2 โทน (DTMF) อยู่ในกิจกรรมโทรศัพท์
- กําหนด IP สาธารณะเฉพาะสําหรับอินเทอร์เฟซภายนอกของ SBC
- กําหนดค่า NAT ต้นทางและปลายทางสําหรับไฟร์วอลล์ของคุณ
การเจรจาใบรับรอง (DTLS) ล้มเหลว
หากคุณได้รับข้อความแจ้งเตือน (ระดับ: ร้ายแรง คําอธิบาย: CA ที่ไม่รู้จัก) แสดงว่าใบรับรองที่ใช้สําหรับ DTLS อาจไม่ผ่านการรับรอง
การเจรจา DTLS จะเริ่มด้วยแฮนด์เชคใบรับรองระหว่างปลายทางสื่อที่ระบุไว้ในข้อเสนอและระบุคำตอบในช่องการเชื่อมต่อ SDP เมื่อดําเนินการเสร็จแล้ว ระบบจะส่งสื่อไปมาระหว่าง SBC และ Google Voice ผ่านการเชื่อมต่อที่เข้ารหัส
หากต้องการแก้ไขปัญหา โปรดตรวจสอบว่าใบรับรองนั้นมีใบรับรองแบบ Self-signed จาก SBC อย่าใช้ใบรับรองที่ลงชื่อโดย CA สาธารณะ เนื่องจากจะทําให้เกิดการกระจัดกระจายใน UDP ซึ่งก่อให้เกิดปัญหา
ข้อความ "Client Hello" จาก SBC ไปยัง Voice ที่ไม่มีการตอบกลับ (DTLS)
คุณอาจได้รับข้อความ Hello ที่ส่งจาก SBC ไปยัง Voice หลายข้อความที่ไม่มีการตอบกลับเมื่อใช้การเข้ารหัส DTLS
วิธีแก้ไขปัญหา
- ตรวจสอบพอร์ตไฟร์วอลล์เพื่อให้แน่ใจว่า SBC มีการรับส่งสื่อแบบ 2 ทิศทางไปยังพอร์ตซับเน็ต IP (74.125.39.0/24) 19305 หรือ 26500 ของสื่อ Voice
- สำหรับ พอร์ต SBC Public IP:media <> 74.125.39.0/24:(19302-19308, 26500) ดูข้อมูลเพิ่มเติมได้ที่ส่วนพอร์ตไฟร์วอลล์สำหรับ SIP Link
- IP ของ Google Voice Media สามารถเข้าถึงได้ด้วยคําสั่ง ping และสามารถทดสอบการเข้าถึงจาก SBC ได้ด้วยวิธีนี้
ฉันไม่ได้รับการตอบสนองใดๆ สำหรับ UDP จาก SBC ไปยัง Voice
วิธีแก้ไขปัญหา
- ตรวจสอบพอร์ตไฟร์วอลล์เพื่อให้แน่ใจว่า SBC มีการรับส่งสื่อแบบ 2 ทิศทางไปยังพอร์ตซับเน็ต IP (74.125.39.0/24) 19305 หรือ 26500 ของสื่อ Voice
- สำหรับ พอร์ต SBC Public IP:media <> 74.125.39.0/24:(19302-19308, 26500) ดูข้อมูลเพิ่มเติมได้ที่ส่วนพอร์ตไฟร์วอลล์สําหรับ SIP Link
- IP ของ Google Voice Media สามารถเข้าถึงได้ด้วยคําสั่ง ping และสามารถทดสอบการเข้าถึงจาก SBC ได้ด้วยวิธีนี้
- เมื่อดําเนินการเปลี่ยนค่าที่อยู่เครือข่าย (NAT) ไฟร์วอลล์ไม่ควรแก้ไขพอร์ตที่ SBC ส่ง ซึ่งจะทําให้ Voice ทิ้งแพ็กเก็ตสื่อที่ส่งจาก SBC เนื่องจากระบบจะเห็นแหล่งที่มาในรูปแบบ IP สาธารณะของ SBC แต่เป็นพอร์ตที่แตกต่างจากข้อเสนอและคําตอบ SDP ที่แลกเปลี่ยนข้อมูลกันไว้
การรับส่งแพ็กเก็ตแบบ 2 ทิศทาง แต่ไม่มีเสียงระหว่างคุย
โปรดตรวจสอบคริปโตการเข้ารหัสที่ใช้สําหรับสื่อเพื่อแก้ไขปัญหานี้ ซึ่งควรอยู่ในรูปแบบ AES_CM_128_HMAC_SHA1_80
Google ตอบกลับคำเชิญด้วย 486 (SDES)
โปรดตรวจสอบคริปโตการเข้ารหัสที่ใช้สําหรับสื่อเพื่อแก้ไขปัญหานี้
หากคําเชิญมี MKI ซึ่ง SIP Link ไม่รองรับ ให้ปิดใช้ MKI
หัวข้อที่เกี่ยวข้อง
Google, Google Workspace รวมถึงเครื่องหมายและโลโก้ที่เกี่ยวข้องเป็นเครื่องหมายการค้าของ Google LLC ชื่อบริษัทและชื่อผลิตภัณฑ์อื่นๆ ทั้งหมดเป็นเครื่องหมายการค้าของบริษัทที่เกี่ยวข้อง