| MM7 Variations |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ |
◄ ► |
| Author | Message | |||
| Chris Henn New member Username: Chrishenn Post Number: 18 Registered: 09-2017 |
Is there any documentation that would share all the possible formats for the MM7 boundries or a way to standardize the MM7 format when it sends out from the MMSC? We're seeing MM4 come in with different variables and then those variables are going out in the MM7 with different headers. For instance we've now seen in the text section including "Content-location:" which hasn't been included until recently in some messages. I'm trying to find a way to standardize our outbound to either include all possible variations or not include the variations and standardize it to the basic headers for Text and MMS files. Example portions below. EX01 <text src="text000001.txt" region="Text" /> </par> </body> </smil> -----mime-boundary-EDCBD3A7.1AD2BD68 Content-Type: text/plain; charset="utf-8"; name="text000001.txt" Content-ID: <text000001> Content-location: text000001.txt Testing Android 319 pm -----mime-boundary-EDCBD3A7.1AD2BD68-- -----mime-boundary-B3B201E9.BED9312A-- EX02 <text src="text000001.txt" region="Text" /> </par> </body> </smil> -----mime-boundary-D7BB8BF4.38E13175 Content-Type: text/plain; charset="utf-8"; name="text000001.txt" Content-ID: <text000001> Test 1 -----mime-boundary-D7BB8BF4.38E13175-- -----mime-boundary-386181B6.2D880CB7-- | |||
| Robert Barretto Frequent Contributor Username: Barretto Post Number: 73 Registered: 09-2019 |
The format of the MM7 is defined by spec. You can select which MM7 schema a VASP account uses, as well as the 3GPP MMS Version. On my system we use REL-5-MM7-1-2 on 3GPP MMS Version 5.3.0. You can get that schema here: https://www.3gpp.org/ftp/specs/archive/23_series/23.140/schema/REL-5-MM7-1-2.xsd The definition of the boundaries (I assume you're talking about the mime-boundary) is defined in RFC1341. Here's the relevant section: https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html A mime boundary is basically just any old string. The boundary would start with -- and then the string defined as boundary=xxxxxxxxxxx in the Content-Type header that will hold the multipart mime content body. The last piece of a multipart would have an trailing -- on the end of it, signifying no more parts. An incoming MM7 HTTP POST has two parts: Part 1: SOAP Envelope Part 2: MMS content and Part 2 is also divided into it's own parts: Part 2a: smil layout data Part 2b: image data Part 2c: text data (There could be more parts, for example if there were two images.) An example would look something like this: Content-Type: multi-part/related; bound="--outerBoundary"; type="text/xml"; start="<mm7_msg>" ----outerBoundary // Part 1: SOAP Envelope Content-Type: text/xml; charset=utf-8 <xml body encoding an MM7 DeliverReq> ----outerBoundary // Part 2: MMS message Content-Type: multipart/related; start="<smil>"; type="application/smil"; boundary="--someOtherBoundary" ----someOtherBoundary // Part 2a: (smil markup) Content-Type: application/smil; name="smil.xml" <smil xml body for formatting of mms layout> ----someOtherBoundary // Part 2b: (image data) Content-Type: image/png; name="image000000.png" Content-Transfer-Encoding: base64 <the image data encoded in base64> ----someOtherBoundary // Part 2c: (text data) Content-Type: text/plain; name="text000002.txt"; charset="utf-8" <the text of the mms> ----someOtherBoundary-- ----outerBoundary-- Note: the // Part xx: are just my comments, these are not actually in the message. In your example 1 the outer boundary is ---mime-boundary-B3B201E9.BED9312A-- and your inner boundary is ---mime-boundary-EDCBD3A7.1AD2BD68. Your first example looks good, and looks like pretty much every MM7 request I get from the NowSMS MMSC Gateway. Assuming the extra blank lines aren't a copy paste error, the second exmple isn't formatted correctly. There is a blank line that separates the "headers" portion from the content body portion, of any given mime sub-part. So for your second example the content body of the "text000001.txt" message would actually by: Content-ID: <text000001> Test 1 But I think your text00001.txt file is actually just: Test 1 Cheers, //Robert | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8610 Registered: 10-2002 |
Hi Chris, Are you experiencing an underlying problem or issue, or are you just looking for consistency? I agree with Robert's comments about the blank lines/extra line breaks being problematic if they are not a copy/paste error. Regards, Bryce | |||
| Chris Henn New member Username: Chrishenn Post Number: 19 Registered: 09-2017 |
Bryce, We are not experiencing an issue, just trying to standardize the format for our customers. They wrote code to expect what we normally see without the location header and now have to change for the location header. We're just trying to find all possible variables so we don't have to constantly adapt. The blank lines/extra line breaks were just pasting errors. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8611 Registered: 10-2002 |
Content-Location is a regularly used header. I would expect that most clients generate this header. Technically, it is how a SMIL file "src=" reference is resolved, although the Content-ID header id used by some clients. | |||
