Portare DID: Testare de fum în direct înainte de volum

Fumul live al unui DID portat vine înainte de volum, nu după insigna complete.

1. Starea Port Complete este un semnal, nu un semafor verde

Când o cerere de portare DID trece la starea completată în panou, înseamnă doar că registrul central a actualizat profilul de rutare. Nu garantează că fiecare operator din aval și-a reîncărcat tabelele LRN sau că webhook-urile SMS de intrare sunt recepționate corect. Activarea traficului de producție pe un număr E.164 portat recent imediat după finalizare duce adesea la OTP-uri pierdute și eșecuri silențioase de livrare. Siguranța operațională necesită tratarea finalizării drept o invitație la test de fum, nu o permisiune de a deschide robinetul de trafic.

2. Pasul 1: Teste de fum pentru intrare și ieșire

Înainte de a ruta traficul de aplicație în direct, rulați teste pe o singură destinație în condiții controlate. Trimiteți SMS-uri de test manuale către numărul portat din rețelele majore de consum și verificați dacă webhook-urile de intrare se declanșează cu payload-uri JSON valide. Verificați dacă răspunsurile de ieșire returnează stări DLR valide fără erori de livrare. Testarea ambelor direcții la volum redus expune anomaliile de rutare, legăturile lipsă ale centrului SMS sau propagarea incompletă înainte ca utilizatorii finali să piardă coduri de verificare.

3. Pasul 2: Livrarea webhook și formatarea E.164

Rutarea de intrare depinde de formatarea JSON precisă și standardizarea strictă E.164. Asigurați-vă că webhook-urile primesc notificări în ferestrele SLA standard. Verificați dacă numerele mențin formatul internațional complet fără prefixe de țară lipsă sau zerouri inițiale. În timpul alocărilor JIT sau activării DID portate, platforma rezervă și atribuie dinamic căile de trafic. Comparați această abordare în ghidul despre portare sau un DID nou. Dacă webhook-urile returnează erori HTTP 5xx sau eșuează la verificările de semnătură în timpul testelor cu rată redusă, corectați imediat punctele finale înainte de a ruta utilizatori reali.

4. Pasul 3: Creșterea treptată a volumului și gestionarea soldului minim

Scalarea traficului pe numerele recent portate trebuie să urmeze o creștere eșalonată: 5%, 25%, 50% și în final 100% în decursul mai multor ore sau zile. Acest lucru vă protejează reputația de livrare și permite monitorizarea soldului în timp real. Rutarea platformei funcționează pe un registru prepaid strict. Mențineți soldul contului peste pragul minim obligatoriu de 20 USD pentru a preveni întreruperea serviciului în timpul vârfurilor de trafic. Pe măsură ce cheltuielile lunare se apropie de pragul de 1.000 USD/lună, parametrii contului sunt evaluați pentru a asigura un debit continuu.

5. Protocoale de verificare și ghiduri operaționale

Pentru a construi o arhitectură de mesagerie de încredere, integrați verificarea portării cu listele de verificare standard de onboarding și strategiile dinamice de alocare a numerelor. Consultați procedurile operaționale detaliate în Săptămâna de lansare OTP: lista de verificare prepaid împotriva pierderilor.

6. Începeți cu IOSOR

Când starea de portaj devine complete, fum întâi — nu deschideți stăvilarul. Trimiteți un inbound și un outbound pe E.164 portat. Confirmați sarcina webhook și un DLR terminal. Apoi 5, 25, 50, 100. Exportați fereastra de fum: volumul nu e ghicitură.

Materiale: Adevărul prepaid: ce nu promite niciodată IOSOR Săptămâna de lansare OTP: lista de verificare prepaid împotriva pierderilor portare sau un DID nou.

Rezumat IOSOR

Complete e invitație la fum, nu semafor verde de volum.

Faceți: fum în ambele sensuri, apoi trepte. Nu faceți: blast în ora în care consola zice complete.