Trouble with a reading report

Trouble with a reading report SearchSearch

SMS & MMS Technical Forum » NowSMS Support - MMS & Advanced Issues (Product Support Only) » Trouble with a reading report « Previous || Next »
Author Message
marc bazimon
Frequent Contributor
Username: Marc_orange

Post Number: 85
Registered: 01-2007
Posted on Wednesday, September 11, 2019 - 12:31 pm:   

Hi
ME again ^^ sorry for spamming the forum,
by doing check , we notice a unusual traffic , after trouble shooting , we found that all the traffic ( around 2000 retry for only yesterday ) was only for three read report that are on the system since long time ago ( since 2017 to be precise)
read report graph for one MMS
the graph show the delivery of the read report for only one message. It seems that the read report is stuck into a loop since Two year^^
despite the obvious question , how it is possible , is it a way to discard these kind of MMS ?
Thanks beforehand for your help
br
Marc
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6046
Registered: 08-2008
Posted on Wednesday, September 11, 2019 - 07:20 pm:   

Hi Marc,

Where is/was this had report stuck? Was it being retried or replicated?

I'm confused because there appears to be a reference to "MMSIN-ReadReport" which is a log entry of a read report being received by the MMSC, which then needs to forward it.

A .REQ file is referenced, which suggests the MMSC is delivering the read report to a local subscriber over SMS.

So, I need to understand what is being retried, or if the message is being received and processed repeatedly (the latter case would see repeated MMSIN-ReadReport entries).

--
Des
NowSMS Support
marc bazimon
Frequent Contributor
Username: Marc_orange

Post Number: 86
Registered: 01-2007
Posted on Thursday, September 12, 2019 - 05:13 am:   

Hi Des ,
I am not fully sure that the message is stuck into MMSC , but this seems weird that the mobile from the customer do a reply since 2017.
The example , i took for the graph is an extraction of the mmsc.log ( grafana , elesticsearch and kibana ).
2019-09-12 04:18:17,MMSIN-ReadReport,10.76.xxx.xxx,+2626922xxxx,+262692xxxxx,20170228-14-1FAF9456@mms.orange.re,7B0E7856.REQ,72
The initial requests take place since 28 feb 2017 , so on my point of view could be that the message is stuck somewhere into the MMSC.
Note that the count in the graph are the number of MMSIN-readreport. This number is quite high.
After that , it may come from the mobile , but the strange thing is that there's no try to send the readreport ( no MMSOUT-readreport )
Br
Marc
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6047
Registered: 08-2008
Posted on Thursday, September 12, 2019 - 12:27 pm:   

Hi Marc,

Is the IP address (10.76.xxx.xxx) in that log entry associated with the IP address range of phones on your network? (I’m assuming that it is, but. I want to make sure.)


Des
NowSMS Support
marc bazimon
Frequent Contributor
Username: Marc_orange

Post Number: 87
Registered: 01-2007
Posted on Friday, September 13, 2019 - 10:35 am:   

Hi Des ,
Sorry or the delay , i thought i had respond ^^
Yes the IP belong to the IP pool from the MMS APN on our core network .
Br
Marc
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6048
Registered: 08-2008
Posted on Friday, September 13, 2019 - 02:15 pm:   

Hi Marc,

This suggests the MMS client in question is repeatedly generating a red receipt, which is extremely unusual.

Are there are three clients doing this? How often?

Let's try to get more info...I wonder if there is something common about these phones. Can you enable the MMSCDEBUG.LOG? Under the [MMSC] header of MMSC.INI, add DebugFull=Yes to make sure we have all the debug info...and let's try to capture these transactions.

I'm trying to think of potential ways to stop the storm. At present, if we receive a read report, we unconditionally forward it.

There is a setting to disable read reports, but its action is to block asking for them...so it would have no effect on old messages.

I'm puzzled why a client would keep sending a read report. Clients are supposed to ignore the response from the MMSC when submitting a read report, but I am guessing these clients don't like the response from the MMSC, and are retrying. We could experiment with updates that change this response. What do you think?

--
Des
NowSMS Support
marc bazimon
Frequent Contributor
Username: Marc_orange

Post Number: 88
Registered: 01-2007
Posted on Tuesday, September 17, 2019 - 11:20 am:   

Hi Des
I did an extract using our statistics tools, On One week we have got 22 124 MMSIN-ReadReport ( but only 610 MMSOUT-ReadReport )

Now focusing on the MSISDN itself, we have got several client that request

As 100 % represent 22 124 MMSIN-ReadReport , the first MSISDN do 52 % of the request , then 2.8 % , 2.6 %, 1.2 % then 1% .

Now in order to troubleshoot , the handset of the first who do lot of request has got a Huawei-ane-lx1, and do the request since feb 2017.

I had enable debug when i discover the point , i will send it into an email if you don't mind. it may be a trouble of route , but i don't know why , the styrange thing is that there's no MMSOU-ReadReport for tall this message.

Br
Marc
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6049
Registered: 08-2008
Posted on Wednesday, September 18, 2019 - 10:03 pm:   

Hi Marc,

My suspicion is that some clients do not like the response from the MMSC when submitting the read report, which is causing them to retry.

The specification does not define any response to the submission of a read report, and indicates the client should ignore the response from the MMSC.

10+ years ago, we used to respond:

HTTP/1.1 204 No Content
Connection: Keep-Alive

204 is an HTTP status code indicating the response is OK, but there is no content to return. This caused problems with another vendor's WAP gateway, which did not know how to process the 204 response code.

So, at the time, we changed the response to this:

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Type: application/vnd.wap.mms-message
Content-Length: 0

This indicates the response is OK, but we have 0 bytes of content in the response.

Our guess is that this client sees the MMS content type in the response, and is trying to interpret it, but can't, because it is 0 bytes.

At the end of the day, it would seem to be a bug in the MMS client, which should be ignoring the response. But, obviously, that is outside of our control.

So our thought is that the only way to address this is with an update.

We believe that the "204 No Content" response is the most correct response in this situation. But, our plan is to produce an update that has options for different responses:

a) Default
b) 204 No Content
c) 200 OK with 0 byte content application/octet-stream

Unfortunately, I don't see any way to address this short of an update.

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

Post Number: 6050
Registered: 08-2008
Posted on Wednesday, September 18, 2019 - 10:06 pm:   

P.S. - There is no MMSOUT-ReadReport because it is a locally generated SMS.

Also, the "Report route unavailable" just means that the read report does not need to be routed externally.

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