Dual Message IDs in Delivery Reports

Dual Message IDs in Delivery Reports SearchSearch

SMS & MMS Technical Forum » NowSMS Support - SMS Issues (Product Support Only) » Dual Message IDs in Delivery Reports « Previous || Next »
Author Message
Kishore
New member
Username: Kishore37

Post Number: 8
Registered: 03-2012
Posted on Tuesday, July 21, 2020 - 10:42 am:   

Hi Team,

We have a recent issue with some Customers unable to process SMPP delivery reports from NowSMS. We believe the issue is due to 2 Message IDs being populated in the delivery report (SMSCReceiptMsgID & SMSCReceiptMsgID) - see example as follows;

2020-07-21 12:30:03,123456789,SMPP - XXX.XXX.XXX.XXX#2:5000,Text="id:8E5168DB 137535576 sub:001 dlvrd:000 submit date:2007211229 done date:2007211230 stat:DELIVRD err:000";SMSCRouteName=ROUTE-001;Recip=XXX XXX;SMSCReceiptMsgId=8E5168DB;SMSCReceiptMsgIdOrig=137535576 (SMSIN)

2020-07-21 12:30:03,8E5168ED,,XXX XXX,OK -- LocalUser:xxx,SubmitUser=SMPP - XXX.XXX.XXX.XXX#2:5000;Sender=123456789;Text="id:8E5168DB 137535576 sub:001 dlvrd:000 submit date:2007211229 done date:2007211230 stat:DELIVRD err:000" (SMSOUT)

Is it possible to remove the SMSCReceiptMsgIdOrig in the DLR being returned back to certain Customers?

Kind regards,

Kishore
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 8345
Registered: 10-2002
Posted on Tuesday, July 21, 2020 - 01:32 pm:   

Hi Kishore,

The reporting of the two message IDs (SMSCReceiptMsgId and SMSCReceiptMsgIdOrig) occurs only in the SMSIN log file.

The customer will only see the value reported in the log as SMSCReceiptMsgId. The other ID (assigned by an upstreeam) is recorded to assist in troubleshooting, or to correlate billing records.

If you were to look at a Wireshark trace of the SMPP connection with the customer, you would see that the SMSCReceiptMsgId value is the only ID present in the receipted_message_id parameter.

That said, I do find it very odd that the other ID appears in the text of the DLR:

id:8E5168DB 137535576 sub:001 dlvrd:000 submit date:2007211229 done date:2007211230 stat:DELIVRD err:000

This would suggest the DLR that is arriving from the provider has this text with an extra space between "id:" and the actual ID:

id: 137535576 sub:001 dlvrd:000 submit date:2007211229 done date:2007211230 stat:DELIVRD err:000

Instead of:

id:137535576 sub:001 dlvrd:000 submit date:2007211229 done date:2007211230 stat:DELIVRD err:000



Do you see this behavior consistently, where both IDs appear in the text part of the message?

Some applications (especially those that convert SMPP to HTTP) may try to parse the receipt message ID from the text of the message, and I guess an app that assumes everything between "id:" and "sub:" is part of the message ID.
That is a very bad assumption, but that is my guess for how this might be a problem.

So, let me ask 2 questions:

1. Do you see this behavior consistently, where both IDs appear in the text part of the message?

2. What version of NowSMS?
Kishore
New member
Username: Kishore37

Post Number: 9
Registered: 03-2012
Posted on Tuesday, July 21, 2020 - 05:41 pm:   

Hi Bryce,

Thanks for the reply.

1. We see this behaviour consistently.
2. Version of NowSMS is v2017.04.07.

I have pcap traces for the following scenario tests;

1. Test SMPP client <-> NowSMS
2. Test SMPP client <-> Upstream provider

We see that the issue appears to be with NowSMS. The pcap traces show dual Message IDs being returned from NowSMS DLRs but not the upstream provider DLRs.

Is their a way I can privately send the pcap traces?

Kishore
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 8346
Registered: 10-2002
Posted on Tuesday, July 21, 2020 - 08:32 pm:   

Hi Kishore,

Please send the trace to nowsmstech@nowsms.com and include Attention: Bryce in the subject line of the email.

My theory is that the provider has an extra space in the DLR sent to NowSMS. For example:

id: 137535576 sub:001 dlvrd:000 submit date:2007211229 done date:2007211230 stat:DELIVRD err:000

Instead of:

id:137535576 sub:001 dlvrd:000 submit date:2007211229 done date:2007211230 stat:DELIVRD err:000

When NowSMS processes the message, it replaces the ID ... but the extra space breaks this process.

Without the extra space:

id:137535576 sub:001 dlvrd:000 submit date:2007211229 done date:2007211230 stat:DELIVRD err:000

becomes:

id:8E5168DB sub:001 dlvrd:000 submit date:2007211229 done date:2007211230 stat:DELIVRD err:000

With the extra space:

id: 137535576 sub:001 dlvrd:000 submit date:2007211229 done date:2007211230 stat:DELIVRD err:000

becomes:

id:8E5168DB 137535576 sub:001 dlvrd:000 submit date:2007211229 done date:2007211230 stat:DELIVRD err:000

In either case, the SMPP receipted_message_id parameter would contain only 8E5168DB.
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 8347
Registered: 10-2002
Posted on Tuesday, July 21, 2020 - 09:27 pm:   

Hi Kishore,

The traces confirm my assumptions. Most importantly, the SMPP receipted_message_id parameter is formatted correctly, which is the official SMPP method of accessing this ID.

The format of the text in a delivery report is not necessarily standard, and is described in he specification with this pretext:


quote:

The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC vendor specific but following is a typical example of Delivery Receipt report.




That said, it is very common practice to follow this format...and many people process the DLR after the message is converted to HTTP, so they rely on the format of the text.

From the NowSMS side, our normal behavior is that if we process a message that identifies as a DLR, but the message text does not start with "id:", we replace the text of the DLR formatted consistent with the typical format. If the message text starts with "id:", we keep he text, but replace the message ID that immediately follows "id:".

We are updating NowSMS to do a bit more analysis to detect formatting problems such as what you are experiencing, so that in this case, NowSMS will replace the message text completely to avoid problems with DLR format expectations. We will have an interim update available shortly. This will be part of the 2020 version series, and depending on your license, may require purchasing n upgrade.

Regards,


Bryce Norwood
NowSMS Support
Kishore
New member
Username: Kishore37

Post Number: 10
Registered: 03-2012
Posted on Tuesday, July 21, 2020 - 09:37 pm:   

Hi Bryce,

Many thanks for the update.

Do keep us informed when the update is available.

I will contact your Sales team with regards to an upgrade licence.

Kind regards,

Kishore
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 8348
Registered: 10-2002
Posted on Thursday, July 23, 2020 - 02:50 pm:   

Hi Kishore,

We've posted an update at https://www.nowsms.com/download/nowsms20200722.zip which includes this change.

Historically, NowSMS behavior is that if a message identifies as a DLR, but the message text does not start with "id:", NowSMS replaces the text of the DLR formatted consistent with the typical format.

If the message text starts with "id:", NowSMS keeps the text, but replaces the message ID that immediately follows "id:", as needed. NowSMS has been updated to detect additional formatting problems (such as white space between "id:" and the actual message ID, or missing headers such as "stat:", "dlvrd:" or "err:"), and will replace the message text completely to avoid problems with DLR format expectations.

DLR text replacement can be disabled by adding FixSMPPReceipts=No under the [SMSGW] header in SMSGW.INI.

Regards,

Bryce Norwood
NowSMS Support

Add Your Message Here, or click here to create a new discussion topic.
Post:
Bold text Italics Underline Create a hyperlink Insert a clipart image
Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Click here to create an account.
Username:
Password:
Options: Automatically activate URLs in message
Action:

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