ทำไมการโทร SIP จึงลงทะเบียนผ่าน VPN ได้แต่ไม่ส่งเสียง
การลงทะเบียนและเสียงเดินคนละเส้นทาง ติดตามสายเดียวผ่านอุโมงค์เพื่อดูว่า PBX ใช้ที่อยู่ใดได้บ้างและ RTP หยุดจริงที่ตรงไหน
การลงทะเบียนสำเร็จแทบไม่ได้บอกอะไรเกี่ยวกับเสียง โทรศัพท์ซอฟต์แวร์สามารถคงการผูกที่ถูกต้องกับ PBX ของสำนักงานได้หลายชั่วโมงและยังส่งความเงียบออกไป อุโมงค์บรรทุกเฉพาะแพ็กเก็ตที่ใครบางคนตั้งใจส่งเข้าไป และการโทรใช้เส้นทางแยกกันสามเส้น: การผูก การตั้งบทสนทนา และสตรีม RTP เมื่อแยกออกจากกัน ความล้มเหลวจะตกอยู่ที่เส้นทางใดเส้นทางหนึ่ง ไม่ใช่ที่คำว่า VPN
ลองนึกภาพแล็ปท็อปบน Wi-Fi ที่บ้านหมุนหมายเลขภายในสำนักงานผ่านอุโมงค์ที่ได้รับอนุมัติ PBX ตรวจสอบผู้ใช้ ยอมรับ REGISTER และหมายเลขภายในปรากฏว่าใช้งานได้ แต่การโทรเชื่อมต่อด้วยความเงียบสนิทในทิศทางเดียว
การลงทะเบียนผูกผู้ติดต่อ ไม่ใช่เส้นทางสื่อ
คำขอ REGISTER ขอให้ตัวลงทะเบียนเก็บการแมประหว่างที่อยู่บันทึกกับ URI ผู้ติดต่อหนึ่งรายการหรือมากกว่า การแมปนั้นตอบคำถามแคบ ๆ ว่าบทสนทนาใหม่ควรส่งไปที่ใดตอนนี้ ไม่ได้บอกอะไรเกี่ยวกับตำแหน่งของสื่อ และการลงทะเบียนที่ได้รับการยอมรับไม่ได้พิสูจน์ว่า INVITE ในภายหลังจะมีที่อยู่สื่อที่เข้าถึงได้ การลงทะเบียนยังหมดอายุตามตัวจับเวลา ดังนั้นโทรศัพท์ที่หยุดต่ออายุจะสูญเสียสายที่เข้ามาในขณะที่อุโมงค์ยังดูปกติ ติดตามการหมดอายุของผู้ติดต่อแทนสถานะของอุโมงค์
เมื่อโทรศัพท์ซอฟต์แวร์อยู่หลังอุโมงค์ หัวข้อผู้ติดต่ออาจมีที่อยู่ส่วนตัว PBX ที่ส่งต่อไปยังปลายทางอื่นจะสร้างบทสนทนาที่มุ่งไปยังเครือข่ายที่ผู้รับสายเข้าถึงไม่ได้ การตั้งค่า rewrite_contact=yes ที่ปลายทาง PJSIP ทำให้ PBX แทนที่ที่อยู่ต้นทางที่สังเกตเห็น ซึ่งมักเป็นความแตกต่างระหว่างเสียงกริ่งกับการหมดเวลา
INVITE เสนออะไรและใครใช้ได้บ้าง
INVITE ที่มีเนื้อหา SDP เสนอว่าผู้เรียกต้องการรับสื่อที่ใด: ที่อยู่ พอร์ต และรายการโคเดก ผู้รับสายตอบด้วยที่อยู่และพอร์ตของตนเอง จากนั้นแต่ละฝ่ายส่ง RTP ไปยังสิ่งที่อีกฝ่ายเสนอ หากผู้เรียกเสนอที่อยู่ 192.168.x.x ที่มีอยู่เฉพาะในเครือข่ายที่บ้าน ผู้รับสายก็ไม่มีที่ให้ส่งเสียง ไม่ว่าการส่งสัญญาณจะสะอาดเพียงใด การปกปิดที่อยู่เขียนหัวข้อ IP ใหม่เมื่อแพ็กเก็ตออกจากเราเตอร์ แต่ไม่เคยเขียนข้อความภายในเนื้อหา SDP ใหม่
ช่องว่างนี้อธิบายการโทรทิศทางเดียวแบบคลาสสิก: การส่งสัญญาณทำงานเพราะปลายทั้งสองเข้าถึง PBX และเสียงล้มเหลวเพราะปลายหนึ่งถูกบอกให้ส่งไปยังที่อยู่ที่มีอยู่เฉพาะหลัง NAT อีกตัว
| Path | Who picks the address | Typical failure |
|---|---|---|
| REGISTER | Softphone, rewritten by the registrar if configured | Binding expires or points at a private address |
| INVITE and SDP | Each endpoint in its own offer or answer | Offer names a media address nobody can route to |
| RTP | PBX relay policy or the two endpoints | Port range blocked, or no return path |
ใครเป็นผู้บรรทุกเสียงคือการเลือกการกำหนดค่า
การส่งสัญญาณและสื่อเป็นบทบาทแยกกัน พร็อกซีสามารถอยู่บนเส้นทางการส่งสัญญาณตลอดการโทรและไม่แตะแพ็กเก็ต RTP แม้แต่แพ็กเก็ตเดียว การที่ PBX จะกลายเป็นตัวถ่ายทอดสื่อขึ้นอยู่กับการกำหนดค่า ไม่ใช่การมีอยู่ของอุโมงค์
เมื่อใช้สื่อโดยตรง ปลายทั้งสองแลกเปลี่ยน RTP กันเอง ซึ่งทำงานได้ดีใน LAN เดียวและแย่เมื่อฝ่ายหนึ่งอยู่หลังช่วงพอร์ตแคบ ๆ
การตั้งค่า direct_media=no บังคับให้ PBX เข้าสู่เส้นทางสื่อเพื่อให้ขาทั้งสองสิ้นสุดที่ที่อยู่ที่ควบคุมได้ แลกแบนด์วิดท์และซีพียูกับการกำหนดที่อยู่ที่คาดเดาได้ เมื่อถ่ายทอด PBX ยังต้องประกาศที่อยู่ที่เข้าถึงได้ บนโฮสต์หลายเครือข่าย external_media_address และ external_signaling_address ใน pjsip.conf กำหนดสิ่งที่จะปรากฏใน SDP และในหัวข้อ Via หากปล่อยไว้โดยไม่ตั้งค่า PBX อาจเสนอที่อยู่ LAN ของตนให้ผู้เรียกที่มีเส้นทางเดียวคืออีกฟากของอุโมงค์
ติดตามแต่ละทิศทางก่อนแตะการตั้งค่า
เริ่มจากตารางซ็อกเก็ตบน PBX ขณะมีการโทรอยู่: ss -uanp | grep -E '5060|10000' แสดงว่าพอร์ต RTP ถูกผูกไว้หรือไม่และใช้ที่อยู่ภายในใด จากนั้นบันทึกที่ฝั่งโทรศัพท์ซอฟต์แวร์ด้วย tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap แพ็กเก็ตขาออกที่ไม่มีแพ็กเก็ตขาเข้าทำให้ปัญหาจำกัดอยู่ที่เส้นทางขากลับหรือที่อยู่ที่ฝ่ายไกลถูกบอกให้ใช้ และการบันทึกที่ว่างเปล่าหมายความว่าสื่อไม่เคยไปถึงอินเทอร์เฟซของอุโมงค์เลย การบันทึกการส่งสัญญาณด้วย sngrep ตอบอีกครึ่งหนึ่งโดยแสดงบรรทัดการเชื่อมต่อ SDP ตามที่ส่งออกไป
เปรียบเทียบที่อยู่ในบรรทัดการเชื่อมต่อนั้นกับที่อยู่ที่ฝ่ายไกลสามารถกำหนดเส้นทางไปถึงได้จริง การเปรียบเทียบครั้งเดียวนั้นแก้ปัญหารายงานเสียงทิศทางเดียวส่วนใหญ่ได้เร็วกว่าการทบทวนการกำหนดค่าใด ๆ
การเข้ารหัสหยุดที่ขอบอุโมงค์
SIP บน TLS ปกป้องฮอปการส่งสัญญาณที่กำหนดไว้ SRTP ปกป้องสื่อเมื่อปลายทั้งสองเจรจากัน และอุโมงค์ปกป้องทราฟฟิกระหว่างปลายของตัวเอง ไม่มีสิ่งใดให้สิ่งอื่น การโทรที่เข้ารหัสภายในอุโมงค์อาจออกจากเกตเวย์เป็นข้อความธรรมดาไปยัง PBX และนั่นเป็นการตัดสินใจออกแบบ ไม่ใช่ข้อบกพร่อง
ก่อนปิดตั๋ว ให้ยืนยันสามสิ่งตามลำดับ: การลงทะเบียนใหม่ ที่อยู่ SDP เข้าถึงได้จากฝ่ายไกล และแพ็กเก็ตไหลทั้งสองทิศทางบนพอร์ตสื่อ หากข้อใดเป็นเท็จ อุโมงค์ไม่ใช่ที่อยู่ของปัญหา แก้ไขเส้นทางที่ล้มเหลว แล้วรันการบันทึกเดิมซ้ำเพื่อยืนยันการเปลี่ยนแปลง การเก็บการบันทึกก่อนและหลังทำให้รายงานทิศทางเดียวครั้งถัดไปเป็นการตรวจห้านาทีแทนที่จะเป็นทั้งบ่าย