IOSOR ความรู้

การแปลง E.164 ก่อนผูก DID: เครื่องหมายบวก ศูนย์ และช่องว่าง

เรียนรู้ว่าการแปลงรูปแบบ E.164 ที่เข้มงวดช่วยป้องกันความล้มเหลวในการจัดเส้นทางเมื่อผูกเบอร์โทรศัพท์เข้ากับแอปพลิเคชันในระบบนิเวศ white-label CPaaS ของคุณ

ทำไมการป้อนข้อมูลเบอร์ดิบจึงทำให้เส้นทางล้มเหลว

การรับข้อมูลเบอร์โทรศัพท์ดิบจากผู้ใช้โดยไม่มีการทำความสะอาดเป็นสาเหตุหลักของการหลุดของเส้นทางแบบเงียบๆ เมื่อผู้เช่าวางเบอร์ที่มีเลขศูนย์เบิ้ลนำหน้า เครื่องหมายบวกที่ขาดหายไป ขีดคั่น หรือช่องว่าง ระบบจะไม่สามารถจับคู่กับโปรไฟล์ปลายทางได้ ในโมเดล prepaid CPaaS ของเรา การจัดสรรแบบ JIT หมายความว่าเบอร์จะถูกร้องขอแบบไดนามิกและผูกทันที หากรูปแบบขาเข้าแตกต่างจากมาตรฐาน E.164 อย่างเคร่งครัด ตัวจัดการ webhook จะไม่สามารถลงทะเบียนการผูกได้.

กฎการแปลงรูปแบบสำหรับรูปแบบระหว่างประเทศ

การแปลงรูปแบบที่เข้มงวดกำหนดให้ต้องแปลงสตริงตัวเลขขาเข้าทั้งหมดให้เป็นมาตรฐาน E.164 ก่อนทำการค้นหาฐานข้อมูลหรือพยายามผูก กระบวนการนี้จะตัดอักขระจัดรูปแบบทั้งหมดออก รวมถึงช่องว่าง วงเล็บ จุด และขีดกลาง โดยจะแทนที่คำนำหน้าโทรระหว่างประเทศในท้องถิ่นเช่น '011' หรือ '00' ด้วยเครื่องหมาย '+' มาตรฐาน และใส่รหัสประเทศที่ถูกต้องไว้ข้างหน้าหากละไว้ตามภาษาท้องถิ่นเริ่มต้นของผู้เช่า ตัวอย่างเช่น ข้อมูลนำเข้าเช่น «+1 (555) 019-2834» จะต้องถูกจัดเก็บเป็น «+15550192834».

การจัดการกรณีขอบในพอร์ทัลผู้เช่า

พอร์ทัลผู้เช่ามักจะนำความผิดปกติที่ซ่อนอยู่มาด้วย เช่น ช่องว่างความกว้างศูนย์ การขึ้นบรรทัดใหม่ต่อท้าย หรือรหัสออกระหว่างประเทศนำหน้าจากระบบ PBX เดิม การตรวจสอบฝั่งหน้าบ้านของคุณต้องขัดขวางความผิดปกติเหล่านี้ก่อนที่เพย์โหลดจะถึงเกรดเวย์ API เมื่อมีการดำเนินการแบบกลุ่ม สตริงสกปรกมักจะข้ามการตรวจสอบฟิลด์เดียว ผู้ปฏิบัติงานควรใช้โปรโตคอลสุขอนามัย CSV ที่เข้มงวดคล้ายกับที่กล่าวไว้ใน /learn/lookup/bulk-lookup-campaign-csv-hygiene เพื่อให้แน่ใจว่าข้อมูลมีความสมบูรณ์.

การป้องกันการไม่ตรงกันของการผูกและการหลุดแบบเงียบ

เมื่อคำขอผูกเบอร์ล้มเหลวเนื่องจากความแตกต่างของรูปแบบ แพลตฟอร์มอาจส่งคืนข้อผิดพลาดทั่วไป หรือที่แย่กว่านั้นคือประมวลผลการจับคู่บางส่วนที่กำหนดเส้นทางจราจรไม่ถูกต้อง ผู้เช่าที่ติดตามเมตริกแคมเปญจะสังเกตเห็น DLR ที่หายไปและ webhook ที่ไม่ตอบสนอง การรักษาการแปลงรูปแบบที่เข้มงวดช่วยป้องกันการไม่ตรงกันแบบเงียบๆ เหล่านี้ หากคำสั่งซื้อพบข้อผิดพลาดในการจัดสรร ให้ตรวจสอบขั้นตอนมาตรฐานที่ระบุไว้ใน /learn/numbers/did-order-fail-refund-swap-status.

การตรวจสอบหลังการมอบหมายและขั้นตอนนำร่อง

เมื่อการแปลง E.164 สำเร็จและผูกเบอร์ได้สำเร็จ วงจรชีวิตการดำเนินงานจะเปลี่ยนไปสู่การตรวจสอบเชิงรุก ในระหว่างการเปิดตัวครั้งแรก ผู้เช่าควรติดตามอัตราการส่งมอบและสัญญาณ HB อย่างใกล้ชิด เพื่อทำความเข้าใจวิธีการประเมินประสิทธิภาพในช่วงสัปดาห์แรกของการปรับใช้ โปรดอ้างอิงแนวทางปฏิบัติใน /learn/numbers/did-pilot-week-after-first-assign.

เริ่มต้นกับ IOSOR

ผูก DID หนึ่งเบอร์หลังเขียนเป็น E.164 เท่านั้น เครื่องบวกนำหน้า รหัสประเทศ ไม่มีช่องว่าง ไม่มีศูนย์ trunk เก็บค่าดิบข้างรูปมาตรฐานในไฟล์ส่งออกการมอบหมาย ถ้าช่อง bind ยังมี 00 ท้องถิ่นหรือตัวเลขเว้นวรรค ให้ปฏิเสธการผูก อย่าสัญญาว่าจะล้างหลังมีทราฟฟิก นี่คือประตูรูปแบบก่อนกรรมสิทธิ์ ไม่ใช่การเขียน STOP ลงรายการ และไม่ใช่การหาผู้เช่าด้วย webhook.

บทความ: Caller ID เทียบกับ messaging From: เสียงใช้งานได้ไม่ได้หมายความว่า SMS ใช้งานได้ MO ขาเข้าสู่การระงับ: STOP บน DID ช่วยปกป้องชื่อเสียง การกันยอดเติมเงินก่อนการหักครั้งแรก.

สรุป IOSOR

การผูกที่เก็บรูปแบบท้องถิ่นคือคำโกหกเส้นทาง ตารางมอบหมายเก็บ E.164 หรือไม่มี bind.

ทำ: ทำให้เป็นมาตรฐาน แล้วผูก แล้วส่งออกทั้งสองรูป อย่า: ผูกก่อนแล้วค่อยเก็บ หรือมองบวก ศูนย์ และช่องว่างเป็นเครื่องสำอาง.

คู่มือนี้มีประโยชน์ไหม?

คู่มือที่เกี่ยวข้อง