| Trouble with a reading report |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ |
◄ ► |
| Author | Message | |||
| marc bazimon Frequent Contributor Username: Marc_orange Post Number: 85 Registered: 01-2007 |
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)  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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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. | |||
