Overview
Un messaggio che rimane "in coda" – senza mai raggiungere DELIVRD o UNDELIV – di solito significa che è stato accettato dal gateway ma non ancora consegnato dall'operatore di destinazione: comunemente perché è programmato per un secondo momento, limitato dal tuo limite di TPS, in attesa di un periodo di validità con un telefono spento o fuori copertura, oppure bloccato su una tratta congestionata. Controlla schtime, il tuo limite di throughput e il DLR: un messaggio esce dalla coda solo quando l'operatore restituisce una conferma finale.
È previsto per più tardi
Se imposti schtime (con gmt), il gateway trattiene deliberatamente il messaggio fino a quel momento, quindi rimane in coda fino all'arrivo dell'orario programmato. Verifica schtime/gmt che hai inviato: un offset GMT errato o una data futura sono la causa più semplice per cui un batch "non viene inviato". Ometti schtime per inviare immediatamente; l'API REST restituisce uno ScheduleId quando un invio è programmato.
- schtime (yyyyMMddhhmm) + gmt mantiene il messaggio fino a quell'ora.
- Un offset GMT errato può causare uno slittamento delle ore di invio.
- Ometti schtime per inviare ora.
- Un batch programmato restituisce un ScheduleId, non la consegna immediata.
Viene limitato al limite del tuo TPS
Un batch di grandi dimensioni consuma la quantità di dati consentita dal tuo account (messaggi al secondo), quindi i messaggi successivi rimangono in coda mentre quelli precedenti vengono inviati: questo è un normale consumo di dati, non un errore. Se un volume di messaggi costante è importante, richiedi un TPS (messaggi al secondo) più elevato. Gli invii molto grandi è meglio caricarli come file di destinatari sull'endpoint di invio in blocco /sms/sendbulk piuttosto che come un'unica richiesta di grandi dimensioni.
- Grandi quantitativi vengono consumati fino al limite massimo del TPS: i quantitativi successivi attendono.
- Questo è il ritmo previsto, non un errore.
- Richiedi una maggiore capacità di elaborazione per volumi costanti.
- Per elenchi molto lunghi, utilizzare /sms/sendbulk.
Il telefono risulta irraggiungibile entro il periodo di validità.
Se il telefono del destinatario è spento o fuori copertura, l'SMSC dell'operatore memorizza il messaggio e lo ritrasmette finché il dispositivo non torna disponibile o non scade il periodo di validità. Durante tale intervallo, il messaggio viene legittimamente messo in coda. Quando la validità scade senza che il messaggio sia stato consegnato, il DLR passa allo stato UNDELIV/expired, quindi un messaggio rimasto a lungo in coda spesso si risolve da solo una volta che il dispositivo torna online.
- La funzione store-and-forward dell'SMSC tenta di ricontattare un telefono irraggiungibile.
- Il messaggio rimane in coda fino alla consegna o alla scadenza della validità.
- Alla scadenza, DLR diventa UNDELIV/scaduto.
- Spesso il problema si risolve quando il telefono torna ad avere copertura.
Verifica crediti, percorso e stato reale
Se non si verifica alcun movimento, verificare il saldo (l'invio può fallire con HTTP18, crediti insufficienti) e che l'ID del mittente e il percorso siano approvati per la destinazione. Non dedurre lo stato dall'assenza di un webhook: recuperare direttamente lo stato di ciascun messaggio (tramite l'API HTTP legacy: /websmpp/websmsstatus con l'ID di risposta).
- Nessun movimento? Controlla i crediti: HTTP18 indica un saldo insufficiente.
- Conferma che l'ID del mittente e il percorso siano approvati per il paese.
- Leggi lo stato reale recuperandolo direttamente (API HTTP legacy: /websmpp/websmsstatus).
- Non dare nulla per scontato in caso di webhook mancante: controlla lo stato.