| MMSCOMP |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through September 15, 2003 ⬆ |
◄ ► |
| Author | Message | |||
| MARTINENT Jerome |
Hi, I'm currently using developing a connector to adapt Nokia EAIF application to use your MMSC. To do this I use the HTTP or SMTP interfaces to send an MMS created using MMSCOMP. However, I got a problem as I have to automate the using of MMSCOMP from a java program. Could you tell me what is exactly doing MMSCOMP to reproduce its behaviour in java ? Is it just an encoder ? Regards, Jerome | |||
| Bryce Norwood - NowSMS Support (Bryce) |
Hi Jerome, MMSCOMP takes individual message components and builds a compiled MMS file (MIME type application/vnd.wap.mms-message). I think Nokia has some Java tools to build this type of file, which you could use as well. One idea ... however ... you don't have to build the pre-compiled MMS file to submit a message to our server. You can submit a MIME message with the individual file components, and we'll build the compiled file automatically. So if you're connecting via HTTP (POST in the multipart/form-data format with one or more MMSFile variables containing file upload content), or SMTP (use SMTP AUTH to login to the server), you can include multiple files, and we'll compile them before sending them out to the device. -bn | |||
| Jerome |
I need to send through NowSMS MMSC the same MMS as I received as I'm developping a kind of adaptation layer. I cannot loose informations contained in the headers, this explaining why I wanted to use MMSCOMP (I build the header file using informations read from the received MMS using Nokia Library functions). I tested it and it's working well, however I'm MMSCOMP dependant and using it from Java is not trivial... I'm going to compare in details the results from MMSCOMP and from the encoding functions of the MMSLibrary... which I already tried... without results :-( Regards, | |||
| Jerome |
Well I found the solution. The Nokia library encoding function was not working last time but this time it's working. In fact, it is dessassambling the MMS to reassemble it in a different order. However, if I send the encoded MMS to the SMTP interface I see on the phone the email of the sender whereas if I send the same email to my smtp relay, which is relaying it to the MMSC, I see the same result as if I had posted the MMS via http !!! Strange, isn't it ? | |||
| Bryce Norwood - NowSMS Support (Bryce) |
That is very odd. I can't explain why there would be a difference. We do build an MMS From header in the notification message based upon the "From:" address in the SMTP header. Maybe there is some difference in the raw SMTP header when it passes through the relay? | |||
| Jerome |
Well, I found the tip... When I send an HTTP post in java (using the url class and by-hand built content, the first field of the multipart mime message is dropped. In my case that was the MSISDN, this explaining why I received mms from the email address and not from the mms pdu content. One field is always dropped, and I chosed to drop the subject, which in my case is not very useful as it is already contained in the mms pdu. I compared the smtp messages content (sniffed) in both SMTP from the relay and directly to the MMSC and it was only working in the case of the relay usage | |||
