Alternative to no DR

Alternative to no DR SearchSearch

SMS & MMS Technical Forum » NowSMS Support - SMS Issues (Product Support Only) » Archive through August 22, 2012 » Alternative to no DR « Previous || Next »
Author Message
Blair
New member
Username: Bcotnam

Post Number: 12
Registered: 07-2011
Posted on Monday, October 17, 2011 - 06:32 pm:   

Hello Support,

I have a quick question. We have clients sending messages to us via SMPP connection then we have GSM modems setup as our SMSC for sending the messages to the recipient. Curretly we have delivery reports setup and seems to work well, which will send the DR back to the smpp client for acknowledgement.

The question i have is, some operators in some countries (for example Brazil) don't send Delivery Reports, but we have a smpp client asking if there is any way to send an acknoledgement back to the smpp user that the message has been successfully sent from the nowsms gateway if the operator doesn't support delivery reports?

Is there anyway to send an acknowledgement back to the smpp client when the message has left the nowsms platform if the operator doesn't send/support any DR.

This is just to substitute if the carrier doesn't support any delivery reports.

Thanks for your help.
ZIM CORP
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3543
Registered: 08-2008
Posted on Tuesday, October 18, 2011 - 07:38 pm:   

Hi Blair,

We don't have such an option, but I discussed it with one of our engineers today.

There is a concept of an in-transit (enroute) receipt, which some platforms generate in this instance.

Right now, when an SMS message fails (receives a permanent error) delivery to an upstream SMSC connection, NowSMS generates a non-delivery receipt back to the sender.

In a similar way, it would be relatively easy for us to generate an in-transit/enroute receipt back to the sender when a message is accepted by an upstream SMSC connection (or modem).

Our concern would be ... under what conditions should such an in-transit/enroute receipt be generated.

Here are my thoughts ... but we would want more feedback before implementing such an option.

a.) An in-transit/enroute delivery receipt should only be generated if the submitting client requested a delivery receipt. (Or if configuration parameters are set in NowSMS to request one even if the client did not.)

b.) In-transit/enroute delivery receipts should be enabled on a per SMSC connection, meaning that they will be enabled only for specific SMSC connections that are known not to generate delivery receipts.

c.) In-transit/enroute delivery receipts should be generated if the submitting SMPP client set the "intermediate notification" bit of the registered_delivery parameter, regardless of whether or not the upstream SMSC has a configuration option set (b) to enable in-transit/enroute delivery receipts.

It seems fairly straight-forward to me ... at least as far as (a) and (b). I'm a bit hesitant on (c). I don't have any real world knowledge as to how frequently real world clients set this interim notification bit. Clients might inadvertently set this bit (because the purpose is not explicitly clear in the SMPP spec), and most systems ignore it ... but if we start using it as a signal to generate in-transit/enroute delivery reports, we may generate unnecessary and excess traffic.

Thoughts?

--
Des
NowSMS Support
Blair
New member
Username: Bcotnam

Post Number: 13
Registered: 07-2011
Posted on Thursday, October 20, 2011 - 12:53 pm:   

Hello Des,

Thanks for the inforamtion, very informative. We also received an email from Bryce explaining the situation. option a+b would be a good option/solution and would be very useful for us. Regarding our modems crashing, it could happen becasue its trying to receive a delivery report while sending out a message as bryce mentioned.

Before we go ahead and implement option a/b what we would like to do is disable delivery reports in nowsms to see if we notice a performace difference and if the modems stop crashing.

Is there any easy way to disable sending delivery reports in nowsms as our clients are submitting with 'registered_delivery=1'? We would like to completely disable DR to see if we notice any difference and if we do, then probably a good solution to implement option a+b as you suggest above.

Thanks,
Blair
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3549
Registered: 08-2008
Posted on Friday, October 21, 2011 - 02:08 pm:   

Hi Blair,

We are currently working on implementing options for the described solution.

It will also have the option where if interim delivery reports are being generated for a connection, requests for upstream delivery reports for that connection can be suppressed. (It is hard to explain, but when the new configuration settings are described it will make more sense.)

To answer your most recent question, there does not seem to be an existing setting that will do this. There is a setting that will turn on registered_delivery if it was not set, but not one that will turn it off. We will add that, in addition to the other settings.



--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3550
Registered: 08-2008
Posted on Friday, October 21, 2011 - 02:14 pm:   

Correction ... Bryce just reminded me that there is already a configuration setting that will disable delivery receipt requests, it just works from a different perspective.

For any outbound SMSC connection, under the SMSC specific section header (e.g., [Modem - xxxx]) of SMSGW.INI, you can add:

DisableDeliveryReceipt=Yes

This will suppress the delivery receipt request for all message submitted via that particular connection.

--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3631
Registered: 08-2008
Posted on Tuesday, November 29, 2011 - 03:16 pm:   

Follow-up.

An update is available that adds the ability to generate in-transit delivery reports. With this setting, if the client requested a delivery report, an in-transit/interim delivery report is generated as soon as the SMS is accepted by a modem.

To enable this setting in version 2011.11.14 and later, add DeliveryReportEnroute=Yes to the SMSC specific section of SMSGW.INI for any SMSC or modem connection for which this behaviour is desired.

This can be combined with the DisableDeliveryReceipt=Yes setting mentioned previously.

If DisableDeliveryReceipt=Yes and DeliveryReportEnroute=Yes are set for a connection, and a message requests a delivery report, an in-transit delivery report will be generated when the message is successfully dispatched to the modem (DeliveryReportEnroute=Yes). The message sent via the modem will NOT request further delivery reports (DisableDeliveryReceipt=Yes).

The update with support for this additional configuration setting is at http://www.nowsms.com/download/nowsms20111114.zip.

--
Des
NowSMS Support
Blair
New member
Username: Bcotnam

Post Number: 14
Registered: 07-2011
Posted on Tuesday, November 29, 2011 - 04:02 pm:   

Thanks for the update. We will give this version a try. I just have a few questions regarding the DeliveryReportEnroute option.

If we have DeliveryReportEnroute=Yes and DisableDeliveryReceipt=NO (we want to keep original DR on from operator) and the operator sends us a delivery report, will nowsms still send a DeliveryReportEnroute? As this will duplicate the delivery report?

Also, if we DisableDeliveryReceipt=Yes and DeliveryReportEnroute=yes, then nowsms will only send Delivery Reports, no Delivery Reports will be sent by the operator?

Also, can we run the new installer to update our current version? Or is it better to unistall and reinstall the new build?

Thanks,
Blair
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3632
Registered: 08-2008
Posted on Tuesday, November 29, 2011 - 05:17 pm:   


quote:

If we have DeliveryReportEnroute=Yes and DisableDeliveryReceipt=NO (we want to keep original DR on from operator) and the operator sends us a delivery report, will nowsms still send a DeliveryReportEnroute? As this will duplicate the delivery report?




Correct.


quote:

Also, if we DisableDeliveryReceipt=Yes and DeliveryReportEnroute=yes, then nowsms will only send Delivery Reports, no Delivery Reports will be sent by the operator?




Correct.


quote:

Also, can we run the new installer to update our current version? Or is it better to unistall and reinstall the new build?




Our recommended practice is to run the new installer to update the current version.


--
Des
NowSMS Support
Blair
New member
Username: Bcotnam

Post Number: 25
Registered: 07-2011
Posted on Monday, March 05, 2012 - 11:55 am:   

Hello Support,

We have been using the in-transit delivery reports generated by nowsms using this build to generate DR to our SMPP clients instead of the operator DR as it was severly slowing down the platform when incoming and outgoing messages for large volumes using gsm modems

Everything has been working well. With the in-transit delivery reports when the smpp clients receives the DR, they are receiving with status code: ENROUTE. Is there any way we can change the status code to: DELIVERED instead of ENROUTE?

Lots of our custoemrs are complaining that even though the message is delivered, the status code for the DR never gets updated from ENROUTE to DELIVERED. So, in turn they think the message is failed. Since we are using nowsms to generate the DR instead of the operator, we can't update the status code of the DR once its delivered.

So, is it possible to change the status code of the in-transit delivery reports generated by nowsms to: DELIVERED instead of ENROUTE?

Thanks,
Blair
Blair
New member
Username: Bcotnam

Post Number: 26
Registered: 07-2011
Posted on Tuesday, March 06, 2012 - 01:04 pm:   

Any updates on our last question to change the status code of the in-transit DR generated by nowsms to: DELIVERED -- instead of ENROUTE??

Thanks..
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3829
Registered: 08-2008
Posted on Tuesday, March 06, 2012 - 04:21 pm:   

Hi Blair,

We are discussing it. There's been a bit of concern being voiced that to say the message has been delivered at this stage is not accurate.

There is a good argument that a status of ACCEPTD may be preferable to ENROUTE.

So ... we are going to allow the "stat:" text to be configurable for receipts generated because of this setting. If you want to set it to DELIVRD, that is your choice.

The text value should use one of the common SMPP values, because we do use this text to produce the numeric message_state value for SMPP clients.

Unfortunately, I don't have a good estimate of when this will be available, as we are currently testing some more complex changes for a future update (completely unrelated to any of this, the changes are focused on HTTP SMSC connectivity). I'm expecting 2 weeks, but it could be less ... could also be a little longer.

--
Des
NowSMS Support
Blair
New member
Username: Bcotnam

Post Number: 27
Registered: 07-2011
Posted on Thursday, March 08, 2012 - 02:45 am:   

Hi Des,

That sounds great. This will help the process.

Is there any chance we could get a quick build in the mean time with just the change of ENROUTE to DELIVRD?

I'm not sure if this would be a quick change, but my manager was asking if we would get a quick build in the mean time. Because when we send back the DR, since it stays in the state of 'ENROUTE' our clients think the messages are failing when they are not.

Thanks,
Blair
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3832
Registered: 08-2008
Posted on Thursday, March 08, 2012 - 02:12 pm:   

Hi Blair,

I'm a bit hesitant to do this.

But the majority of changes being worked on at the moment pertain to HTTP SMSC connections, which I believe that you do not use.

As long as you are not using those capabilities, this build should be stable. 2-way SMS, HTTP accounting callbacks are all unchanged. It is only the outbound HTTP SMSC interface that has seen numerous changes, and is still being tested and extended.

The setting to configure what you want is DeliveryReportEnrouteStat=DELIVRD

This setting goes into the modem specific setting area, and requires DeliveryReportEnroute=Yes

The update is at http://www.nowsms.com/download/nowsms4blair.zip

--
Des
NowSMS Support
Blair
New member
Username: Bcotnam

Post Number: 28
Registered: 07-2011
Posted on Friday, March 16, 2012 - 01:34 pm:   

Hi Des,

Thanks for this pre-build. Everything worked as far as smsc smpp connections, http callbacks.

When we tried to send a batch of messages (25000) through the web interface, we noticed it was really really slow at sending the messages (unbarably slow), compared to our last build. We reverted back to the previous build doing the same test and message were being sent very fast compared to the new build.

So, i am assuming there is work being done to the web interface submissions in this build or soemthing is broke. This is fine, we have just reverted back to our previous build for now.

If you can let us know when the new build is complete with the configurable "stat:" text that would be great.

Also, we appreciate the help you have given us thus far.

Thanks,
Blair
Blair
New member
Username: Bcotnam

Post Number: 30
Registered: 07-2011
Posted on Wednesday, March 21, 2012 - 11:20 am:   

Hello,

Do you have any ideas when this new build will be ready? Its been over 2 weeks, just curious.

Thanks,
Blair
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3852
Registered: 08-2008
Posted on Wednesday, March 21, 2012 - 09:14 pm:   

Hi Blair,

Unfortunately the new capabilities are taking longer than expected, so we are performing system tests of the new builds with thie new capabilities disabled?

Thus far, we have not found any performance problems of the nature that you describe.

Are you using accounting callbacks?

I understand from one of my colleagues that you believe the performance problems you are experiencing are related to HTTP submissions that post to a large distribution list. I ran a variety of performance tests earlier today and can see no problems with this type of scenario.

I think we'd need to see some debug logs in order to understand the performance problems that you have described in that other thread.

--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3853
Registered: 08-2008
Posted on Wednesday, March 21, 2012 - 09:16 pm:   

To cross reference the other thread to which I am referring (it also explains the logs we'd like to see): http://support.nowsms.com/discus/messages/1/70928.html
Blair
New member
Username: Bcotnam

Post Number: 32
Registered: 07-2011
Posted on Friday, March 23, 2012 - 11:13 am:   

Hello Des,

Thanks for the update. Just let us know when the new build is ready.

Yes, we are using accounting callbacks. I have sent you the log files from our other thread for investigation.
Blair
New member
Username: Bcotnam

Post Number: 36
Registered: 07-2011
Posted on Wednesday, April 04, 2012 - 10:57 am:   

Hello Des,

Any updates on this release? Do you have an expected ETA for this build?

Thanks,
Blair
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3889
Registered: 08-2008
Posted on Wednesday, April 04, 2012 - 06:19 pm:   

Hi Blair,

It could be as early as Friday...but it shouldn't be any later than next Wednesday.

--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3891
Registered: 08-2008
Posted on Monday, April 09, 2012 - 11:05 am:   

Hi Blair,

A follow-up ... the update has been posted at http://www.nowsms.com/download/nowsms20120404.zip.

--
Des
NowSMS Support
Blair
New member
Username: Bcotnam

Post Number: 37
Registered: 07-2011
Posted on Monday, April 09, 2012 - 01:02 pm:   

Thanks for updating me.

Regards,
Blair
Blair
New member
Username: Bcotnam

Post Number: 38
Registered: 07-2011
Posted on Friday, April 20, 2012 - 05:38 pm:   

Hello Des,

We have installed the new build (v2012.04.04)and works fine, but we are still experiencing slow sending speed to our remote locations of nowsms.

I'll just refresh our setup.

We have a main installation of nowsms where all our customers send messages to. Then we have 2 remote locations of nowsms acting as a SMSC gateway and we send messages to these remote locations via prefix routing.

I'll send you the logs of the tests we did today. We sent 25388 messages to the main installation of nowsms via smpp. Then the main installation of nowsms is sending these messages to both remote locations with prefix routing.

The messages being submitted to the main installation of nowsms is working well, about 40msg/sec being submitted to nowsms. Nowsms is sending those messages slow to the remote locatons (about 4-6msg/sec to each site on average so, around 9-14msg/sec between the two sites which is very slow).

When i first submitted the messages, nowsms was sending the messages to the remote locatons at a good rate, about 30msg/sec between the two sites, then it really slows down to about 9-14 messages a second which is very weird.

I started sending the messages at 1:22pm. we are looking at sending between 30-40msg/sec between 3 remote sites, but we are no where near that.

Below is some examples of tests we did last week:
1. First test with 1 remote site:
Remote Site #1 - 17msg/sec (5000messages)

2. Second test with 2 remote sites
Remote Site #1 - 14msg/sec
Remote Site #2 - 14msg/Sec (5000messages)

3. Third test with 3 remote sites
Remote Site #1 - 8msg/sec
Remote Site #2 - 9msg/Sec
Remote Site #3 - 7msg/sec (5000messages)

4. Fourth test with 3 remote sites
Remote Site #1 - 2msg/sec
Remote Site #2 - 2msg/sec
Remote Site #3 - 2msg/sec (25000messages)

As you can see the more messages we submit the slow the sending is to remote sites. Those are just example, i don't have the log files for these tests.

We submitted the messages from user Claudino and all the messages were sent to +90 prefix. Text =Test 01.

Let me know if you need any further information and i will email you our logs.

Thanks,
Blair
Blair
New member
Username: Bcotnam

Post Number: 39
Registered: 07-2011
Posted on Friday, April 20, 2012 - 05:42 pm:   

Sorry, i posted this in the wrong thread. I will repost in the correct thread.

Please ignore or delete my last post.

THanks,
Blair
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3916
Registered: 08-2008
Posted on Friday, April 20, 2012 - 06:45 pm:   

Follow-up posted in http://support.nowsms.com/discus/messages/1/70928.html

Login Login / Register Logout Logout Search Last 30 Days Topics Topics