| M-acknowledge-ind issues |  Search
|
|
NowSMS Support Forums ⬆ MMS & SMS Technical Discussions (unsupported) ⬆ Archive through November 21, 2009 ⬆ |
◄ ► |
| Author | Message | |||
| Greg Lipscomb New member Username: Glipscomb Post Number: 1 Registered: 06-2009 |
Hi, From (section 7.3.1) of the WAP MMS Client Transaction docuement says: "If an acknowledgement is requested, the MMS Client SHALL respond by invoking a WSP/HTTP POST operation with an M-Acknowledge.ind message embedded as the content body. This message is submitted using a URI that addresses the MMS Proxy-Relay that supports the specific MMS Client. The MMS Client SHOULD ignore the associated WSP/HTTP POST response from the MMS Proxy-Relay." By this description and the behaviour I've seen testing a deployment of NowSMS as a direct delivery MMSC I take it to mean that the MMS handset will sent M-acknowledge-ind messages to the mmsc service centre adress rather than the direct download uri (the one the hanset uses in the HTTP GET request) My questions are: 1. Is there anyway to change this behaviour? So that handsets send the M-ackowledge-ind to the same url used to download the message? IE the URL sent in the direct delivery SMS and used by the handset in its HTTP GET request to NowSMS? 2. If there isn't what is it exactly that "requests acknowledgement" The original sending handset? NowSMS? The WAP GW? Is it possible to always have acknowledgments turned off? 3. What could cause "corrupted" m-acknowledge requests? When downloading mms on all handsets other than certain nokia models the packets are not recognized by wireshark. The underlying data seems alright but there is obviousl some subtle difference as it's not classified as MMSE traffic. Any help/insight into these questions would be greatly appreciated. cheers Greg | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 875 Registered: 08-2008 |
Hi Greg, 1.) No, it's not possible to change this behaviour. The MMS protocol design is such that the acknowledgment is always directed back to the MMSC address that is configured in the mobile phone. This is an issue that has frustrated us for quite a few years now. We've learned to live with it. We did do a proof of concept project for a customer several years ago where we did a proxy that could direct m-acknowledge.ind messages to the correct MMSC based upon the message id. In the end, they determined that it wasn't really that important. Their MMSC would ignore acknowledgments that weren't meant for it. And from a NowSMS perspective, if the MMSC sees the GET request, it considers the message delivered. (We know the client received and understood the MMS notification. If the GET fails for some reason, we assume the client will just retry.) If there was a need, we could dust off the old proof of concept. As I recall, it was built into NowWAP, related to the settings where we throttle MM1 transactions. There were INI settings where it didn't have to be a WAP proxy, you could just point to the proxy as the MMSC address. Most transactions would get forwarded to the primary MMSC, but acknowledments and read receipts would get forwarded to different MMSCs based upon message id. 2.) It's just part of the protocol, there's no way to turn them off. The intent in the protocol is that this packet confirms that the message has been received by the handset (the GET response was received and understood). 3.) Are you sure that they're corrupted? Wireshark is very good ... but it's not perfect. If you want to give some examples, we can take a closer look ... either offer some confirmation that everything is ok, or explain what's wrong. ... Are you encountering a problem where an MMSC is having problems with acknowledgments for messages that it did not generate? -- Des NowSMS Support | |||
| Greg Lipscomb New member Username: Glipscomb Post Number: 2 Registered: 06-2009 |
Des, Thanks for the quick reply. The specific issue I'm facing relates to charging for MMS - this implementation is a test implementation for what will eventually be the production mms system for a telcom. The approach we've taken is: 1. handset configured to use mmsc gateway http://mms.domain.com:8990 2. NowSMS server's hostname configured as mmsd.domain.com:8990 3. Both mmsd.domain.com & mms.domain.com are resolved to the (same) ip of the NowSMS server by the wap gateway 4. GPRS charging system is configured to detect and charge traffic to mms.domain.com (and the actual ip) as MO MMS and mmsd.domain.com as MT MMS. 5. When receiving the handset does a GET request to the expected address of mmsd.domain.com but also does POST to mms.domain.com in ack of the GET. This POST (the m-acknowledge-ind) is picked up by the charging system and thus a MT download is charged as if it had been an MO send. As for the message corruption, I'll see if I can find some traces suitable for posting but what I'm seeing... and what has greatly confused my testing... is that the above scenario only happens for a few phones, for the rest of them the charging system doesn't pick up the completed session and charging is fine. In effect the corruption seems to cause problems such that the m-acknowledge isn’t recognized and thus doesn’t cause the charging issue. This seems to correspond to when wireshark also mis-classifies the traffic. (Although honestly I haven’t checked this extensively) I'm actually only seeing the "correct" behaviour with V5+ firmware Nokia phones. I suppose this is a side issue to the above, but it lies at the core of what has been a very confusing debug process. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 882 Registered: 08-2008 |
Hi Greg, I understand. Unfortunately, that m-acknowledge.ind is always going to go to the same address as an MMS message send. For MMS 1.2 handsets, you will also end up with read receipts being POSTed to the MMSC address configured in the mobile phone. Without actually analysing the data (MMS message type in the header), I'm not sure what good options there are. Obviously the POST size is going to be small on an m-acknowledge.ind ... and you might be able to make use of that. But that's far from a perfect solution. We usually recommend using the accounting callbacks for this type of charging interface. Have you looked at them? I just recently posted an explanation of how they work at http://support.nowsms.com/discus/messages/485/25243.html -- Des NowSMS Support | |||
| Greg Lipscomb New member Username: Glipscomb Post Number: 3 Registered: 06-2009 |
Des, One further question, semi-related to all this. On the difference between using direct delivery MMSC routing vs. convert mms to multimedia wap push. When using the multimedia wap push option what I'm receiving to the handset is a "service message" which upon retrieval displays a wap page with links to the image and/or audio content which was sent. These have to be manually downloaded and when they are, are stored in the appropriate folders (gallery, audio) etc. These downloads trigger direct GET requests to the mmsd address and thus don't run afoul of our charging setup. Also on the NowSMS server the raw jpg/midi files are archived. When using direct delivery the full MMS is delivered directly to the MMS inbox of the phone. The full contents of the MMS are downloaded (assuming auto-download is set) before the MMS received notification is poped up and when view the MMS comes up immediatly. The MMS is a "true" MMS and can be forwarded on to others unlike the service message. Further the archive on the NowSMS service contains an encapsulation file of the MMS contents rather than raw media files. As I missing something here? When using a E// GW is there a way for WAP push messages to behave as "real" MMS? Is there a difference to this behaviour if using NowSMS WAP GW instead? | |||
| Greg Lipscomb New member Username: Glipscomb Post Number: 4 Registered: 06-2009 |
P.S. RE. The callbacks. Yes I understand that it's an option but we are trying to avoid having to develop an enhancement to out billing system. I believe the multimedia wap push is also an option but as above am puzzled as to the difference in user experience I'm seeing. Greg | |||
| Greg Lipscomb New member Username: Glipscomb Post Number: 5 Registered: 06-2009 |
Des, Any thoughts on this? cheers Greg | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 890 Registered: 08-2008 |
Hi Greg, I took a look at the log files that you sent me yesterday, and here is what I noticed. The packet from the Samsung phone with an Openwave browser that Wireshark can't identify is an M-NotifyResp.ind packet telling the MMSC that the message has been successfully retrieved. I'm not sure why Wireshark can't decode it. It's possible that Wireshark just doesn't have a filter for this particular packet. This sent me back to the MMS specifications for some heavy reading and re-education to try to determine why a client would use M-NotifyResp.ind instead of M-Acknowledge.ind. And to be honest ... I don't have a good answer. Basically, it's an implementation decision that is at the discretion of the MMS client. The client can acknowledge receipt of the message using either of these packets. Normally, M-NotifyResp.ind would be used only in a "deferred delivery" scenario. The MMS client can acknowledge an MMS notification with M-NotifyResp.ind and tell the MMSC that it will download the message later. However, it is also perfectly legal for the client to use this packet to acknowledge receipt of the notification and receipt of the message content. Now, here's where it gets even more confusing. The specification does allow the MMSC to ask the client to suppress the M-Acknowledge.ind ... which is what you originally were asking about. I forgot about this. But there is actually a setting in the NowSMS MMSC to do this. Under the [MMSC] section of MMSC.INI, you can add DisableTransactionID=Yes. When this setting is present, the MMSC does not include a transaction ID in the MMS message itself. The specification says that the client should use this as a signal to suppress sending M-Acknoweldge.ind. (Beware, as I'm not confident that this behaviour has been tested in all commercially available MMS clients.) HOWEVER ... this setting does NOT suppress M-NotifyResp.ind, and that seems to be the packet that is giving you decoding problems. As I study the specification further, I believe an argument could be made that the Samsung/Openwave client is sending the correct packets, but the Nokia client is not. As I read the specification, the M-NotifyResp.ind transaction is required to acknowledge receipt of the MMS notification. The client has the option of either sending it before the GET, indicating that it will download the message later. Or it can send it after the GET, acknowledging both the MMS notification and successful download of the message content. In the former case (NotifyResp before GET), the M-Acknowledge.ind is still required unless the MMSC has omitted the transaction id from the message content. In the latter case (NotifyResp after GET), the M-Acknowledge.ind is not required at all. In the real world, we tend to see more MMS clients that send the M-Acknowledge.ind and do not use M-NotifyResp.ind except in special scenarios. (Nokia phones have settings to block anonymous messages or advertisements, and in these cases, I have seen those phones send an M-NotifyResp.ind indicating that the message will be downloaded later ... but the phone never performs the download. I assume the M-NotifyResp.ind is just to tell the MMSC not to retry the notification.) So where does all of this leave you? Unfortunately, no closer to a solution for what you're trying to do. It may be possible to suppress the M-Acknowledge.ind being generated by the Nokia phone. (Per the spec, the INI setting I mentioned above should do this. But beware because this is not a scenario that I expect all MMS client vendors have tested.) However, it is not possible to suppress the M-NotifyResp.ind which some of your phones are generating. (As I read the specification, all phones should be generating this packet. However, from experience, I know that not all phones do.) -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 891 Registered: 08-2008 |
P.S. - I forgot to address the WAP Push questions. Multimedia WAP push is an alternative solution for some content providers, but it is not a viable solution for person-to-person MMS. It is not true MMS, it is just an alternate content delivery mechanism. (Real MMS actually uses WAP push. But if you use MMS message format in the WAP push, the MMS client in the receiving device is going to use all of the other protocol components of MMS as well.) | |||
