SAR issue

SAR issue SearchSearch
Author Message
Mazen Mazen
New member
Username: Mazenmezo

Post Number: 1
Registered: 04-2015
Posted on Saturday, April 04, 2015 - 11:59 pm:   

Dears,

We are facing a very weird issue with the nowssms version we are using which is 2012.06.28, the thing is; we have been noticing messages queuing with non identical SAR IDs for same message parts, for example below 2 SAR are for same message but as mentioned showing different IDs:

SAR-xxxxxxxxxxx-552217d0-2-1.req
SAR-xxxxxxxxxxx-55221312-2-2.req

I am not sure why this happens or what to do to get it solved, would you please advise what would this be or what to do noting that this happening randomly and not all concatenated messages shows same behavior?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 5252
Registered: 08-2008
Posted on Monday, April 06, 2015 - 05:43 pm:   

That is very odd....how are the messages being submitted to NowSMS?
Mazen Mazen
New member
Username: Mazenmezo

Post Number: 2
Registered: 04-2015
Posted on Wednesday, April 15, 2015 - 10:19 am:   

Hi Des,

Sorry for the late reply, messages are being submitted to NowSMS via SMPP user and NowSMS then forward the messages to our HTTP service, we have noticed that this issue only occurs with concatenated uni-coded messages not with English ones.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 5259
Registered: 08-2008
Posted on Thursday, April 16, 2015 - 02:39 pm:   

Hi Mazen,

I've done some investigation, and we are not aware of any problems in this area. The only reason why the ID would be different is if the SMPP submission included a different sar_msg_ref_num TLV value (or corresponding value in the UDH), or if there is a different sender value...as this is how the message segments are correlated.

I ran tests using both TLV and UDH based segmentation, and the SAR IDs were generated correctly.

I expect that to make any sense of the problem that you are seeing, we would need to see an SMPP trace to confirm why the values are not set as expected. If you can recreate the problem and capture the SMPP transactions in Wireshark or SMPPDEBUG.LOG, this would give us the needed information.

I do see that there is a bug in the version of NowSMS you are running, where under certain circumstances with an outbound HTTP SMSC connection, these messages will get stuck in the outbound queue. The relevant note from our changes log is here:


quote:

2013-05-31:

* HTTP SMSC: If "Send Long Messages without Segmentation" is enabled for a connection, any segmented messages where a part is missing would get stuck in the queue. With this update, any such stuck messages will get released automatically after 3 minutes.




I'd suggest doing the trace, and then send to nowsms@nowsms.com with Attention: Des in the subject line. Please post a follow-up note here as well, in case the email gets stuck in our system, so that I know to look for it.

--
Des
NowSMS Support