MT couldn't be delivered

MT couldn't be delivered SearchSearch
Author Message
Omar
Frequent Contributor
Username: Kfsmart

Post Number: 62
Registered: 01-2008
Posted on Wednesday, June 27, 2012 - 09:25 am:   

Dear Des,
Hope you are doing well!

I 'm sending SMS through specific connection ,but it returned as :


sub:001 dlvrd:001 stat:EXPIRED err:034


I contacted the provider and it replied with nonhelpful answer:)
"This problem in your software or your mobile not in SMSC system"

I attached SMPPDebug and SMSDebug.

Thanks.
text/plainSMPP Debug
SMPPDebug.txt (14.5 k)
text/plainSMS Debug
SMSDebug.txt (1.9 k)
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4008
Registered: 08-2008
Posted on Wednesday, June 27, 2012 - 07:33 pm:   

Hi Omar,

That message is coming from the provider (or one of the systems that they connect to). It is not generated by NowSMS.

When you see "stat:EXPIRED" in a delivery receipt, this is what it usually means ... well, let me explain some background ...

When you submit an SMS message to a provider, there is the possibility that the recipient phone may be powered off or out of range.

SMS is a store-and-forward system. So when you submit a message to an SMSC, the SMSC will try for some period of time to deliver the message, periodically retrying if necessary.

The SMSC will have a policy for how long to keep retrying before considering a message to be expired. At that point, if the message can not be delivered, it will be discarded, and an expired delivery notification will be generated.

(Historically, a typical expiry policy would be 72 hours, the idea being that it was long enough for a work mobile to be powered off over a weekend. But as message volumes have grown, and SMS messages have been considered more time critical, many providers use lower expiry timeouts.)

So, I'd ask ... how long after the message is generated do you receive this error?

Is it happening for a particular number or numbers or a lot of them? (If it is a lot, then this suggests the provider might be having some other issue, but is returning the wrong error code.)

There is some more discussion of expired status and validity periods in the following thread: http://support.nowsms.com/discus/messages/1/60253.html

In particular, note that SMPP allows you to specify a validity period for how long the message should be attempted to be delivered before it is considered expired. By default, NowSMS does not set this value, so the provider's default validity period policy applies.

However, it is also possible to request a specific validity period. This can either be done via URL parameters when submitting a message to NowSMS, or you can set a default value for a particular connection. The thread that I referenced explains how to set a default value for a particular connection.

Note that SMS providers will typically have a default validity period and a maximum validity period. So even if you request an extra long validity period, that may be ignored by the SMS provider.

--
Des
NowSMS Support
Omar
Frequent Contributor
Username: Kfsmart

Post Number: 63
Registered: 01-2008
Posted on Thursday, June 28, 2012 - 07:12 am:   

Dear Des,
THanks.

this is new connection and I tested on 3 different mobile#(not switched off and not out of coverage) ,same delivery status which is normally received after 4 hours.
submit date:1206270914 done date:1206271326
submit date:1206270914 done date:1206271453
submit date:1206270915 done date:1206271620

The main issue is that their technicals are not helpful at all,so is there some trials I can do?

for example I tried to change the Char-set to Default, GSM,latin?but nothing happened.
I tried also to check encode text messages with 7 bit encoding aslo failed.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4010
Registered: 08-2008
Posted on Thursday, June 28, 2012 - 04:38 pm:   

Hi Omar,

So it does appear that the messages are expiring from the queue of the provider before they can be delivered. And that your provider is using a validity period of approximately 4 hours.

So the question is ... why is your provider unable to deliver these messages, considering that the recipient devices are turned on and prepared to receive messages?

Does your provider have a web interface that allows you to send test messages? If so, I'd suggest trying this. If that also fails, then any solution would have to come from the provider.

If, however, those messages work, then this suggests that there might be an issue with some attribute of the messages that you are submitting. (I say might, because it is also very possible that the provider has made a mistake in how your account is provisioned on their system.)

As far as what message attributes might be a problem, my suspicion would be an issue with sender and/or recipient address formatting being different from what the provider expects. That is the type of problem that could cause their system to be unsure of how to route your messages.

Start with the recipient address. Are your recipient addresses in national number format or international number format? What does your provider expect?

From your logs it appears that you are using international format. Try sending in national format (without the "+" prefix). If that works, you can add configuration settings for NowSMS to change the recipient format as it routes to that connection: http://www.nowsms.com/international-prefix-conversion-for-sms

Normally international format is the way to go, but you do appear to be sending from a short code. Since short codes are country specific, they may be expecting recipients in national number format instead.

Another issue may be with the short code as the sender address. By default, when a short code is specified as the sender address, NowSMS uses a TON (SMPP type of number) code of 3, which means network specific, and is the value normally used to signify short code. Check to see what source TON value your provider recommends using with short codes. If it is not 3, use the SMPP settings in NowSMS to specify a different value. In your testing, you might want to try 0 (unknown / not specified) to see if this makes a difference. For more info on TON, see http://www.nowsms.com/ton-and-npi-settings-for-smpp-and-ucpemi

--
Des
NowSMS Support
Omar
Frequent Contributor
Username: Kfsmart

Post Number: 64
Registered: 01-2008
Posted on Sunday, July 01, 2012 - 09:08 am:   

Dear Des,

Thanks,I tried all possibilities but it also failed.
Please note that I'm receiving the incoming SMS from them as follows:

2012-06-07 18:48:24,+21891xxxxxxx,Binary,062E06270644062F,+77123


Kindly what do you suggest for the format of the mobile and Sender as well as source and destination for the TON and NPI values?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4016
Registered: 08-2008
Posted on Monday, July 02, 2012 - 12:49 pm:   

Hi Omar,

If your source/sender address is a short code, I would only try source TON values of 0 and 3. (3 is the default)

For the recipient TON, I would leave it blank for default. Try sending to recipient numbers using different formats...

1. Include country code, and start with + (NowSMS will use TON=1)

2. Include country code, but do NOT start with + (NowSMS will use TON=0)

3. Use local number format (in many countries the first number is 0 when dialing a local number). (NowSMS will use TON=0)

Try 6 tests...do 1-3 with source TON left blank. Then try 1-3 again with source TON=0.

If all tests fail, my guess would be that your provider account is not provisioned (on the provider end) to support sending from the short code you are using. Your provider would have to tell you what source/sender address you can use.

Did your provider give you any connection instructions besides host address, user/system name and password? It is rare, but there are some providers that require additional settings such as system type or service type. We can't guess at these settings, if they are required, the provider would have to tell you what values they require.

At this point you really have to ask your provider why all of your messages are failing to be sent, and tell them you are getting expired delivery notifications referencing err:034.

The other message you are receiving is in Unicode format. Newer versions of NowSMS log this in more understandable UTF-8 format, but older versions just display hex. To decode, take 4 dIgits at a time. The first character is Unicode 062E, which is Arabic letter Khah.

--
Des
NowSMS Support