| Read report |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through July 07, 2009 ⬆ |
◄ ► |
| Author | Message | |||
| Michael New member Username: Michael123 Post Number: 10 Registered: 02-2007 |
Hi Bryce, We have Now SMS/MSM v2008.06.03 and MM4 connection with another MMSC. When our subscribers has enabled read report, in MMSCDEBUG.LOG I see MM4_read_reply_report.REQ, but I can't find any MM4_read_reply_report.RES. Of course by this reason another MMSC is spamming our subscribers with read reports. Do we need to make some changes on our side? Regards, Michael | |||
| Michael New member Username: Michael123 Post Number: 11 Registered: 02-2007 |
Hi Bryce, Can you help to resolve this problem? Regards, Michael | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 17 Registered: 08-2008 |
Hi Michael, Bryce has been involved in too many projects that are taking time away from his being able to fully participate in the discussion board. Could you provide me with some more details from the MMSCDEBUG.LOG so that I can understand the logic of the message flow? If an MM4_forward.REQ message is received from this partner, I assume that NowSMS correctly generates an MM4_forward.RES back to the partner? Does the MM4_read_reply_report.REQ message come in from the same IP address as the MM4_forward.REQ that works? (How do you identify the partner, is it with an "MMSC VASP" account with the IP address as the name? I am wondering if there is some reason that the partner is not being identified the same way in the read reply case.) Is the "X-Mms-Ack-Request: Yes" header present in the MM4_read_reply_report.REQ message? NowSMS will only send an acknowledgment (.RES) message back if this header is present requesting one. The relevant specification says:
The way to request this acknowledgment is with the "X-Mms-Ack-Request: Yes". Maybe that parameters is not present? Let's take a closer look at the messsage ... -- Des NowSMS Support | |||
| Michael New member Username: Michael123 Post Number: 12 Registered: 02-2007 |
Hi Des, Thank you for your reply. With MM4_forward.REQ there is no problem. IP is the same. "X-Mms-Ack-Request: Yes" header presents in the MM4_read_reply_report.REQ message. Regards, Michael | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7657 Registered: 10-2002 |
Hi Michael, Can you e-mail an MMSCDEBUG.LOG to nowsms@now.co.uk with "Attention: Bryce" in the subject line of the message. We'd like to take a closer look at this. In particular, I'd like to get a full look at the headers. In addition to "X-Mms-Ack-Request: Yes", there should be an "X-Mms-Originator-System:" header that tells us where to send the report back to. If that header is not present, that would cause a problem, because we don't know what address to direct the report back to. -bn | |||
| Michael New member Username: Michael123 Post Number: 13 Registered: 02-2007 |
Hi Bryce, I sent MMSCDEBUG.LOG. "X-Mms-Originator-System:" presents in header, but I found that it has not valid host. So our partners will need to fix it. Thanks again, Michael | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 50 Registered: 08-2008 |
Hi Michael, We took at the log, and while the complete MM4 message header is not included in the debug log, it appears that there is no "X-Mms-Originator-System" header. When we parse the received MM4 message header, if the "X-Mms-Originator-System" header is present, it will be logged. If your partner is not able to quickly fix this problem ... there is a temporary fix whereby you can disable all requests for read receipts. Note, however, that this will affect all messages sent on your system (including local users). Under the [MMSC] header of MMSC.INI, you can add: EnableReadReceipt=No When this setting is present, if the MMSC processes any messages where a read receipt is requested, it turns it off. -- Des NowSMS Support | |||
| Michael New member Username: Michael123 Post Number: 14 Registered: 02-2007 |
Hi Des, Thanks for temporary solution. You are right, X-Mms-Originator-System is exists only in MM4_forward.REQ and it has not valid value. But we have no problem with MM4_forward.REQ. Is it normal? Regards | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 54 Registered: 08-2008 |
Hi Michael, When you configure the "MMSC VASP" side of the connection, you configure an "MM4 Ack Route" which indicates the corresponding outbound routing that should be used for the ".RES" messages. So the ".RES" message is automatically routed back to that connection. The message recipient for the ".RES" message is the original "X-Mms-Originator-System" value from the corresponding ".REQ" message. It doesn't matter if this address is invalid, as long as the other MMSC accepts it. The problem is, if there is no "X-Mms-Originator-System" value in the ".REQ" message, we don't have any address to which to direct the ".RES". Even though we know which route to send the ".RES" back to, the SMTP protocol upon which MM4 is based requires that we specify a recipient. Because we don't have a recipient value, this prevents NowSMS from sending back the ".RES". The 3GPP TS 23.140 spec seems pretty clear that "X-Mms-Originator-System" is required. But that said, I did a little more checking, and if "X-Mms-Originator-System" is not present, we'll also check for a "Sender" header, and will direct the ".RES" back to that, as that resolved a similar problem with another MMSC that was not generating this header. (Unfortunately, we can't send it back to the "From:" as this could cause confusion, as it is the address of the MMS message sender, not a system address.) -- Des NowSMS Support | |||
| Michael New member Username: Michael123 Post Number: 15 Registered: 02-2007 |
Hi Des, We got answer from partner's MMSC vendor (Telenity). They told that "X-Mms-Originator-System is not required in MM4_Read_Reply_Report.Req and it's optional parameter". So looks like they are not going to fix it. Is "Sender" header mandatory in MM4_Read_Reply_Report.Req? Maybe they'll fix it. One more question: can we disable read report for only this partner? As I understand adding EnableReadReceipt=No in MMSC.INI will disable read reports for all messages. Can we add this line in VASP.INI? Thanks, | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 61 Registered: 08-2008 |
Hi Michael, I have to admit that my first reaction was to curse profanities at them ... and when I first read your message ... unfortunately I cursed them out loud.  One of my colleagues heard me (probably they all did) ... but he calmed me down to read the spec. And I am man enough to admit that I was wrong ... at least partially wrong. They are correct about "X-Mms-Originator-System:" not being required in MM4_Read_Reply_Report.REQ (or MM4_Delivery_Report.REQ for that matter). That particular header is defined only for MM4_forward.REQ. However ... the issue still remains ... that some information is required in order to tell the receiving system where to send the corresponding ".RES" response. That information would seem to be the "Sender:" header. Section 8.4.4.6 of 3GPP TS 23.140 defines the "MM4_Read_Reply_Report.REQ" header mappings, and it says this:
So, if they are requesting an acknowledgment, but they are not setting the "Sender:" header, then they have failed to specify the system address to which the "MM4_Read_reply_report.RES" is to be sent. That, of course, is a problem, as they are not going to receive this response as they have not specified where it should be directed to. Similar text exists in Section 8.4.4.4 of 3GPP TS 23.140, which describes the "MM4_Delivery_report.REQ" transaction. And as I look through the MMSCDEBUG.LOG that you sent to Bryce, I can see that they do include a "Sender:" header in their "MM4_Delivery_report.REQ" transactions, but not in "MM4_Read_Reply_report.REQ". --- All this said, I'm still a bit worried that they won't be very quick to come up with a fix for this problem. I've studied your log file, and I've noticed that the system address that should be present in the "Sender:" header is present in the "MAIL FROM:" command that is part of the SMTP transport level envelope. We could make a change to allow that as an alternative. While the 3GPP TS 23.140 says that the MM4_Read_Reply_report.RES should be sent back to the "Sender:" of the MM4_Read_Reply_report.REQ ... it also indicates that the MMS system address in the MM4_Read_Reply_report.REQ transaction should be encoded as both the "Sender:" header and the "MAIL FROM:" command ... so that would seem to indicate that it would be safe for us to use this as a backup. I've already conferred with engineering, and they indicate that this is a very simple modification. However, they have a couple of other modifications in the queue, so this will probably take a week to get completed and tested. -- Des NowSMS Support | |||
| Michael New member Username: Michael123 Post Number: 16 Registered: 02-2007 |
Hi Des, Thank you. I'll wait for one week One maybe stupid question: why MM4_Read_Reply_report.RES is not automatically routed to default route defined in "MMSC VASP"? It will be much easier. Regards, Michael | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 62 Registered: 08-2008 |
Hi Michael, Even though there is a route defined, it still needs to be addressed to someone or something. Since MM4 uses SMTP as a transport protocol, when the response acknowledgment is routed back to the sending system over SMTP, there needs to be a "RCPT TO" header to specify where the message is to be routed. Without this, the SMTP protocol is broken. Technically, they should definitely be putting a "Sender:" header in, because that is how the 3GPP TS 23.140 specification says that the receiving MMSC should send the response acknowledgment back to the address specified in the "Sender:" header. Of course, we will use the defined "ack route" to determine how to route the response ... but we need a "RCPT TO" header. We can make a simple change to use the original "MAIL FROM" if the "Sender:" is not present, and that should work for this scenario. But the sending system is still doing something wrong by not including this "Sender:" header. The update has been made, and it seems simple enough, but it still needs to go through some testing. I'll post an update when it is ready for download. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 76 Registered: 08-2008 |
Hi Michael, The update has been made available at the following link: http://www.nowsms.com/download/nowsmsupdate.zip Basically, like I described, if the "Sender:" header is not present in any MM4 "REQ" message where an acknowledgement is requested, it will use the address specified as the "MAIL FROM" command as the destination for the corresponding "RES" message. -- Des NowSMS Support | |||
| Michael New member Username: Michael123 Post Number: 17 Registered: 02-2007 |
Hi Des, Looks like something wrong with this update. I install it and after we were not able to send messages via MM4 at all. So we moved to old version. I need few days to install it again and get MMSCDEBUG.LOG. I'll come back with our problem on next week. Regards, Michael | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7658 Registered: 10-2002 |
Hi Michael, I suppose you haven't had the opportunity of time to try the update again (which is understandable). So in the meantime ... I've been reviewing all of the MM4 related changes since v2008.06.03, and I can't see anything that would cause message blockage. But there was a minor change related to the MMSRoutingURL callback. And maybe that could be a culprit. We had someone complain that when the MMSRoutingURL callback was called for delivery notifications and read receipts, the "From" field was not always present in the callback. The changes made should only affect delivery notifications and read receipts. But maybe there is a subtle change in this callback, where if you are using it, your callback script might be rejecting messages destined for the MM4 connection after this change? In my own tests, I haven't noticed any difference, but maybe I'm missing something. -bn | |||
| Michael New member Username: Michael123 Post Number: 18 Registered: 02-2007 |
Hi Bryce, Sorry for delay. Reason is that currently partner company is updating their MMSC (btw they put "FROM" field in MM4_Read_Reply_report.REQ), so problems we see periodically should be by this reason. I think it will be better to let them finishing their job and after (if something will be still wrong) I'll contact you. Thank again, Michael | |||
| TaunT New member Username: Taunt Post Number: 2 Registered: 12-2008 |
thanks for information --- | |||
