| MMS trials, getting insane trying to decode pdu's! |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through September 15, 2003 ⬆ |
◄ ► |
| Author | Message | |||
| Bas |
Hi all, hopefully someone can point me in the right direction. I'm trying to get a grip on MMS and I'm kinda lost on the encoding. As an example, I configured my t68i to use my own webserver as it's message center so the M-Send.req issued by my phone ends up in my script. I'm just dumping the POST data to a file to decode it (by hand for now  ), and it's not making sense when I look at the WAP specs ;( I'm looking at WAP-209-MMSEncapsulation-20020105-a.pdf and my hex dump. As an example, I'm looking for the 'Message-Type' field (0x0c according to section 7.3) which should be equal to 'm-send-req' (0x80, according to section 7.2.14.). I would expect to find a sequence of 0x0c 0x80 but it's not there. What am I missing? Is there (yet) another encoding going on that I'm forgetting about? Here's the start of my hex dump: [MMS]0x8c 140 ? [MMS]0x80 128 ? [MMS]0x98 152 ? [MMS]0x31 49 1 [MMS]0x2d 45 - [MMS]0x66 102 f [MMS]0x35 53 5 [MMS]0x36 54 6 [MMS]0x36 54 6 [MMS]00 0 [MMS]0x8d 141 ? [MMS]0x90 144 ? [MMS]0x85 133 ? [MMS]0x04 4 [MMS]0x3e 62 > [MMS]0x88 136 ? [MMS]0xaa 170 ? [MMS]0xf9 249 ? [MMS]0x89 137 ? [MMS]0x01 1 [MMS]0x81 129 ? [MMS]0x97 151 ? [MMS]0x30 48 0 [MMS]0x36 54 6 [MMS]0x35 53 5 [MMS]0x31 49 1 [MMS]0x34 52 4 [MMS]0x30 48 0 [MMS]0x38 56 8 [MMS]0x30 48 0 (snip) I'd be eternally gracefull if someone can point me in the right direction as to how to go about in parsing this! I can't even explain where the initial 0x8c is doing there! Regards, Bas. | |||
| Bryce Norwood - NowSMS Support |
You really need to get into the WAP WSP spec to understand. The binary value for the header "X-MMS-Message-Type" is indeed 0x0C, but the rules for encoding are that well known header values get or'd with 0x80. In WSP binary encoding, if a a field name or value starts with a value between 0x00 and 0x1E, then that is interpreted as a length field that indicates that this number of bytes follow. If the value starts with 0x1F, then the next byte starts a uintvar that indicates the number of bytes that follow. If the value starts with a value between 0x20 and 0x7F, then it is interpreted as a null terminated text string. If the value starts with a value between 0x80 and 0xFF, then it is a well known binary value. -bn | |||
| bas |
OK, I will study WSP spec. BAS | |||
| xingkelvin |
Does anyone can give me a DLL it can convert SMIL File(include gif,mid...) to MMS file(*.mms like nowsms). Thanks xing_kelvin@yahoo.com | |||
| Bryce Norwood - NowSMS Support |
The MMSCOMP.EXE file included with the Now SMS/MMS Gateway does this as a stand-alone EXE. Nokia also has some Java libraries for doing this. (They try to steer you to a newer SDK which is more bloated and confusing, but last time I was at forum.nokia.com, they still had a download for the Java libraries along with advice that new developers should download the SDK instead. Ignore the advice and try the MMS Java libraries, assuming they are still on the site.) A word of warning about the Nokia Java libraries, however ... they create MMS PDUs in "m-send-req" format. This is the format that an MMS client would use to submit an MMS message to an MMSC. When you send an MMS notification, the phone expects to retrieve an MMS PDU in "m-retrieve-conf" format. The formats of the PDUs are pretty much the same ... just the first two bytes of the file that specify the MMS PDU type are different. 8C 80 is the signature for the "m-send-req" format, and 8C 84 is the signature for the "m-retrieve-conf" format. -bn | |||
