Please help with this mms header

Please help with this mms header SearchSearch
Author Message
Anonymous
 
Posted on Thursday, February 12, 2004 - 01:10 pm:   

Hi,

Sometimes when I receive an MMS (standard MMS with JPEG image) via NowSMS gateway i get this header:

Message-type: m-retrieve-conf
Transaction-id: QCtxlcCo4MQAAA6MAAAABgAAQGgAAAAA
MMS-version: 1.1
To: 07977000077/TYPE=PLMN
From: +447973214524/TYPE=PLMN
Date: Thu, 12 Feb 2004 12:29:45 GMT
Message-class: Personal
Message-size: 10240
Content-type: application/vnd.wap.multipart.mixed
X-NowMMS-Content-Location: 402B7189\unk1.txt

In the MMS-IN dir I get a folder called 402B7189 and unk1.txt is inside this folder. Whats gone wrong here?. Is it something to do with an incomplete download of the MMS?. If so where has the failure occured and does NowSMS retry to donload the content?

Thanks in advance.

Mark Little
Anonymous
 
Posted on Thursday, February 12, 2004 - 01:11 pm:   

Sorry forgot to mention im recieving MMS's via a Nokia 30 GSM modem.

Mark Little
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 1874
Registered: 10-2002
Posted on Thursday, February 12, 2004 - 03:32 pm:   

Mark,

Do you have a scenario where you can recreate this every time, or is it sporadic?

Assuming that you can recreate it, I'd like to see a debug log. It certainly would appear that there is a problem parsing the received message. (NowSMS is not going to retry the download, because it thinks it got the entire download.)

If the problem is sporadic, just enable the SMSDEBUG.LOG. (Manually edit SMSGW.INI, and under the [SMSGW] section header, add Debug=Yes. Then restart the SMS service.) After you notice this happening, e-mail the SMSDEBUG.LOG to nowsms@now.co.uk (or post in reply here), and advise as to the contents of the MMS-IN file, so that we know approximately what time to look for in the log.

If this happens consistently in a particular situation, then I'd like to see a more detailed log, which can be enabled by creating a file named MMSWAP.INI with the following content:

[MMSWAP]
Debug=Yes

Restart the NowSMS services after creating this file. Repeat the problem attempt, and then you will have an MMSWAPDEBUG.LOG that can be sent to us.

(Delete this MMSWAP.INI file when you no longer need this debug level, as this file can get VERY large.)

-bn
Anonymous
 
Posted on Thursday, February 12, 2004 - 04:26 pm:   

Hi Bryce,

It is sporadic but it happens enough for me to be a able to recreate it!. Heres another "corrupt" header:

Message-type: m-retrieve-conf
Transaction-id: QCukqsCo4MMAAHOZAAAAAgAAKM4AAAAA
MMS-version: 1.1
To: xxxx/TYPE=PLMN
From: +xxxx/TYPE=PLMN
Date: Thu, 12 Feb 2004 16:07:06 GMT
Delivery-report: No
Message-class: Personal
Message-id: 6171707@pm.t-mobile.co.uk
Message-size: 10240
Priority: normal
Content-type: application/vnd.wap.multipart.related; type=application/smil; start=<start>
X-NowMMS-Content-Location: 402B71AB\unk1.smil

Now the .smil file is in the MMS-IN file. I also noticed in the .smil file that the it was referencing an image file that was not in the MMS-IN dir.

Mark
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 1875
Registered: 10-2002
Posted on Thursday, February 12, 2004 - 05:21 pm:   

Mark,

Ok. Let's try to collect the relevant debug logs from such an exchange. Then we can see what is happening over the wire.

-bn
Anonymous
 
Posted on Friday, February 13, 2004 - 10:52 am:   

Bryce,

I've attached sections of mmsdebug.log and smsdebug.log when failed messages were received. They were both sent from the same phone. Its intresting to note that failed messages were later received correctly when we put the SIM into a nokia 7650. But when we tried to view the MMS a warning message appeared on the screen saying we had to "view object". Hope this helps

Mark Little
application/octet-streamMMSdebug
mmsdebug-nowsms.log (60.5 k)
application/octet-streamsmsdebug
smsdebug-nowsms.log (193.3 k)
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 1879
Registered: 10-2002
Posted on Friday, February 13, 2004 - 05:28 pm:   

Hi Mark,

The logs appear to be from different time periods. I don't see the same transaction in both logs, which I would really like to see.

I see a strange filename being displayed for the decoded JPG in the SMSDEBUG.LOG (something odd in the way the MMSC has used MIME quoteable printed string to encode the filename ... which I'm sure we can deal with easily enough).

But I'd like to see the transaction where a JPEG is missing, with both of these logs covering the same time period.

-bn
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 1880
Registered: 10-2002
Posted on Friday, February 13, 2004 - 05:43 pm:   

Mark,

Ok. It just hit me what is going on. There's no need to send any additional logs.

We're parsing the MMS message just fine. But the MMS message indicates that the file name for the JPEG component is:

=?UTF-8?B?Um9iaW4gJiBKdWxpZS5qcGc=?=

That appears to be a MIME header encoding. And this type of encoding should not be used within a binary MMS message (it might be used in a text representation, but not a binary representation).

NowSMS uses this filename as the name that it gives to the file when it receives it. Because the filename contains the "?" character, which is a wildcard, Windows will not allow the file to be created, and therefore we skip it.

I've got an update, where we check the filename for invalid characters like this, and skip the reference if it is invalid. And that should take care of your problem.

I'd e-mail this to you, but I don't have your e-mail address. So please e-mail me at nowsms@now.co.uk to request this patch update.

Note that the MMSC is definitely doing something wrong here. Because of this corruption of the name, that is why the Nokia 7650 is telling you that you have to use "view objects". It cannot find the file referenced in the SMIL because the filename has been corrupted.

-bn
Anonymous
 
Posted on Saturday, February 14, 2004 - 04:01 pm:   

Bryce,

Thats excellent news.

Thank you


Mark Little