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.
ทำ: ทำให้เป็นมาตรฐาน แล้วผูก แล้วส่งออกทั้งสองรูป อย่า: ผูกก่อนแล้วค่อยเก็บ หรือมองบวก ศูนย์ และช่องว่างเป็นเครื่องสำอาง.
คู่มือนี้มีประโยชน์ไหม?
คู่มือที่เกี่ยวข้อง
- การส่งมอบ DID เจ้าของคนที่สอง: ใครสามารถกำหนดและปล่อยหมายเลขได้
ควบคุมขอบเขตการดำเนินงาน การจัดสรร JIT และเกณฑ์ทางการเงินแบบเติมเงินระหว่างการส่งมอบ DID เจ้าของคนที่สอง
- ขีดจำกัดการใช้จ่ายต่อ DID: ค่าเช่าและการใช้งานขาออกในเบอร์เดียว
ควบคุมความเสี่ยงต่อเบอร์ใน CPaaS ป้ายขาวของคุณด้วยขีดจำกัดการใช้จ่ายรวมสำหรับค่าบริการรายเดือนและทราฟฟิกขาออก
- การกำหนดเส้นทางเว็บโฮขาเข้าบน DID: MO โดยไม่มีเจ้าของจะสูญเสียคำสั่ง STOP
กำหนดเส้นทางเว็บโฮขาเข้าไปยังบัญชีเจ้าของอย่างปลอดภัย ป้องกันเหตุการณ์ MO ที่ไม่มีเจ้าของและการยกเลิกการรับข่าวสารที่พลาดไปใน white-label prepaid CPaaS