Trouble adding X-Mms-Aux-Applic-Info header field | Search |
NowSMS Support Forums ⬆ MMS & SMS Technical Discussions (unsupported) ⬆ |
◄ ► |
Author | Message | |||
aaron huttner New member Username: Double_a Post Number: 1 Registered: 12-2011 |
OK, so I'm building a nifty encrypted SMS/MMS app for the Android platform and I've got everything working but I'd like to add some application specific information to the MMS header and I'm running into trouble. Basically, I don't get a send-conf back after I add my octet plus text-string and hence the send fails. I'm obviously encoding the field incorrectly. I'm having trouble understanding how to convert the header values I find in the specifications to the octets I should be using to compose the PDU header? For example, the content-type header field has an assigned number of 0x04 in the OMA specs but I know it should be 0x84. I've found a few posts addressing this issue but I'm still at a loss, this one was probably the closest http://support.nowsms.com/discus/messages/1/661.html. Also, does it matter what order I put the headers in? Do I need other application specific headers in order to use the one I want (my guess is no since the OMA specs usually say so if that's the case) ? OMA Specs I've read through: - encapsulation specifications - WAP WSP BTW, feel free to keep tabs on the project, www.gryphn.co (yes, i know it's a picture of an iPhone and I said android, the iPhone version is on it's way). | |||
aaron huttner New member Username: Double_a Post Number: 2 Registered: 12-2011 |
ok, i figured out the encoding portion. the correct encoded value for the aux-applic-info header is 0xB9. I've put that header value in and inserted my custom encoded text value after the header value but I'm still not getting the send-conf? | |||
aaron huttner New member Username: Double_a Post Number: 3 Registered: 12-2011 |
I realized using this header wasn't the appropriate way for me to accomplish what I wanted. Instead I'm using the part name field in the part header, it's a better approach and more importantly the right way to do it. | |||
Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3675 Registered: 08-2008 |
Hi Aaron, I assume you were able to send the MMS ok if this header was not present? To troubleshoot that issue further it would help to see the successful post data and then the unsuccessful data, so that we could help analyze what the issue is. That particular header is an MMS 1.3 header (I think...I don't have the specs in front of me right now), so an MMSC that does not support MMS 1.3 might choke on an unsupported header. (Of course, it should just ignore it, but sometimes unexpected things happen for untested scenarios.) By part header, are you referring to an attribute in a multiparty header? One thing to watch out for is interconnects between the operators. They are not always good about preserving unusual headers or attributes. -- Des NowSMS Support | |||
aaron huttner New member Username: Double_a Post Number: 4 Registered: 12-2011 |
ya, mms sends fine w/o the header. by part header I mean the following Content-Id - <text_666> Content-Location - text_666.txt Part-Data - key exchange Content-type - text/plain P_NAME - KEY_REQUEST.txt P_CHARSET - 106 you can see how I left the header tags the same but just used a custom part name. I wouldn't think operators woul have an issue w/ that, would you? Unfortunately, I can only afford so many phones (two to be exact) so it's difficult to test on multiple carriers, right now they're both Verizon. | |||
Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3676 Registered: 08-2008 |
I would be surprised if those headers survived going across an operator interconnect (specifically the Part-Data header). The reason I say this is because there is a format conversion that occurs when the message is transferred from the originating MMSC to the interconnect, and then again when the receiving MMSC picks up the message from the interconnect. You'd have a better chance of preserving the data if it were in the content of that text file part. -- Des NowSMS Support | |||
aaron huttner New member Username: Double_a Post Number: 5 Registered: 12-2011 |
Is there anyway you can think of that I could test this out without getting my hands on a Sprint or ATT phone? Maybe a public MMSC that routes to an email account (if such a thing exists). | |||
Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3679 Registered: 08-2008 |
Send an e-mail to nowsms@nowsms.com with Attention: Des in the subject line. I'll send you a US phone number that you can send a test message to. I believe it's got a T-Mobile SIM. I should be able to then send you a hex dump of the MMS message it receives. The problem though is that you may experience different changes interconnecting with different operator MMSCs ... but at least this will show you something. -- Des NowSMS Support | |||
aaron huttner New member Username: Double_a Post Number: 6 Registered: 12-2011 |
Hey Des, One of my co-worker has an Android on a Sprint line,I'm gonna try two-way communication via my app w/ him. I do appreciate the offer and still might take you up on it. I'll let you know how the test turns out. | |||
aaron huttner New member Username: Double_a Post Number: 7 Registered: 12-2011 |
wow, i thought i updated you on this a while ago. my bad. anyway, it works on ATT and Verizon, but you were absolutely right on Sprint. I can't even append the encrypted data as attachments. Sprints MMSC server do something to it that make it the wrong length and it won't decrypt. any suggestions? | |||
Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3797 Registered: 08-2008 |
Thanks for the follow-up. Putting the data in an attachment is probably the way to go. But for widest compatibility, I'd suggest keeping it to a text format using something that is safe to character set translations. Think of it as if you were sending something via e-mail. BASE64 encoding or a similar variation to it would probably be the way to go. PGP signed e-mail or S/MIME would probably be good reference points to think in terms of. -- Des NowSMS Support | |||
aaron huttner New member Username: Double_a Post Number: 8 Registered: 12-2011 |
Thanks des, encoding was my first thought, I am fairly certain I'm using base 64 on both ends, but I'll double check. I also thought I was adding it as an attachment, if I post the before and after markup do you think it would help you help me? I'm out of town for the next day butI can post it late tomorrow night |