| MMS log files |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through April 21, 2010 ⬆ |
◄ ► |
| Author | Message | |||
| Kumara New member Username: Dial12345 Post Number: 7 Registered: 07-2009 |
Hello, First of all I must thank you for the quick responses received for my earlier questions. Currently I have following problems with MMS logs. 1.in MMSC-YYYYMMDD.log ,two MMSIN records are logged for each MMS submission . please let me know why it is necessary to log 2 records for same transaction 2.Is it possible to log the content type (image , video etc ...)of submtted MMs. Currently there is no option to view the content type. 3. No records are generated for read receipts in MMSC-yyyymmdd.log . is it possible to record read receipts as well ? 4. What is the default timeout value of the HTTP requests used in accounting callbacks . Can we manually configure those values ? 5. I am bit confused with the MMS gateway version numbers . The version number of the application which I currently use is v2008.06.03 . But this version is not mentioned in any of the documents.Please let me know the reason for this. Thanks, Wipula. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1074 Registered: 08-2008 |
Hi Wipula, Generally speaking, we recommend using the accounting callbacks (see http://blog.nowsms.com/2009/05/mmsc-accounting-callbacks-for-billing.html) for billing and charging. The logs can be useful for statistical analysis, but we've put more emphasis over the years on the accounting callbacks. 1.) The reason is because in most configurations, the MMS notification message that goes out over SMS is multipart. There are usually 2 SMS messages that are generated, and this log entry allows you to correlate the MMS with the notifications that go out over SMS, if desired. To filter these duplicates, if the message id and the sender/recipient are the same, then it is the same message. 2.) No. That's a good idea that we could look into in the future. But generally speaking, an MMS message is a multipart message, so it could have multiple images, multiple text parts, multiple video parts, the SMIL presentation part, other content parts, and any mix thereof. It would be interesting if we did log this, even though it would add some extra processing. Something for us to consider for the future. 3.) There should be log entries that say "MMSIN-ReadReport". However, I will say ... not all MMS clients support them. The issue is that read reports were added in MMS 1.2. Earlier version clients can generate read reports, but they look like regular messages. To make things more confusing, the MMSC assumes that clients only support MMS 1.0 until the first time the client sends a message. The MMSC then tracks the MMS version of each of its users this way, so that it doesn't send something to a client that the client won't understand. It is possible to configure the MMSC to assume MMS 1.2 is the default version until a client sends its first message. You can do this by setting DefaultMMSVersion=1.2 under the [MMSC] header of MMSC.INI. Older clients are supposed to ignore what they don't understand. We just believe its safer to assume 1.0 as the base version until we can get confirmation. 4.) No, unfortunately this is not configurable. In most versions, all HTTP request timeouts are hard coded at 120 seconds. (If there is an error reported at the TCP/IP level, the timeout will occur much sooner. This is the timeout waiting for a response over an active connection.) However, we did encounter a problem at one customer that we were troubleshooting last week. When we enabled keep-alive sockets for the accounting callbacks (which are not used in v2008.06.03), they were encountering an occasional problem with re-use of these sockets, where this timeout was too large. In future versions (an update currently installed only at this particular customer), this timeout has been adjusted to 20 seconds. We may make it configurable in the future ... to date we haven't seen it cause a problem until we started using keep-alive sockets for the accounting callbacks. 5.) We release a lot of interim versions to address specific issues, or in some cases to selectively test new features before a general release. v2008.06.03 is a good stable release that was our official release (and download) version, up until the recent release of v2009.07.09. The installer places a readme.txt file in the NowSMS directory, where this file has a detail of changes between releases. This includes information about all interim releases. -- Des NowSMS Support | |||
