Trouble adding X-Mms-Aux-Applic-Info header field

Trouble adding X-Mms-Aux-Applic-Info header field SearchSearch

SMS & MMS Technical Forum » MMS & SMS Technical Discussions (unsupported) » Trouble adding X-Mms-Aux-Applic-Info header field « Previous || Next »
Author Message
aaron huttner
New member
Username: Double_a

Post Number: 1
Registered: 12-2011
Posted on Monday, December 12, 2011 - 04:17 pm:   

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
Posted on Monday, December 12, 2011 - 05:34 pm:   

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
Posted on Tuesday, December 13, 2011 - 08:24 pm:   

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
Posted on Wednesday, December 14, 2011 - 09:52 pm:   

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
Posted on Thursday, December 15, 2011 - 02:44 pm:   

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
Posted on Thursday, December 15, 2011 - 07:52 pm:   

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
Posted on Thursday, December 15, 2011 - 10:11 pm:   

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
Posted on Friday, December 16, 2011 - 03:40 pm:   

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
Posted on Monday, December 19, 2011 - 03:35 pm:   

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
Posted on Wednesday, February 15, 2012 - 09:41 pm:   

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
Posted on Friday, February 17, 2012 - 02:24 pm:   

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
Posted on Sunday, February 19, 2012 - 01:21 am:   

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

Add Your Message Here, or click here to create a new discussion topic.
Post:
Bold text Italics Underline Create a hyperlink Insert a clipart image
Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Click here to create an account.
Username:
Password:
Options: Automatically activate URLs in message
Action:

Login Login / Register Logout Logout Search Last 30 Days Topics Topics