Smil MMS messages incorrectly formatted?

Smil MMS messages incorrectly formatted? SearchSearch
Author Message
Neil Stamps
New member
Username: Nstamps

Post Number: 1
Registered: 11-2011
Posted on Thursday, November 03, 2011 - 11:27 am:   

I'm having problems with smil formatted inbound MMS messages - it appears that the start attribute is being incorrectly formatted - I am seeing 0.smil instead of <01.smil> - it looks like it is quoting the content location not the id.

I enclose some trace from our application for reference.



--- INCOMING DATA ---
-----mime-boundary-BF9E9F32.71641F33
Content-Type: text/xml; charset=utf-8
Content-ID: <mm7_msg>

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header>
<TransactionID xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-0" env:mustUnderstand="1">20111102113100-EBEBBFAF@
nowsms</TransactionID>
</env:Header>
<env:Body>
<DeliverReq xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-0">
<MM7Version>6.3.0</MM7Version>
<Sender>
<Number>+447989417659</Number>
</Sender>
<Recipients>
<To>
<Number displayOnly="true">+447583617686</Number>
</To>
<Bcc>
<Number>+07583617686</Number>
</Bcc>
</Recipients>
<Priority>Normal</Priority>
<Subject>Multimedia Message</Subject>
<Content href="cid:mms_cid" />
</DeliverReq>
</env:Body>
</env:Envelope>

-----mime-boundary-BF9E9F32.71641F33

Content-Type: multipart/related; type="application/smil"; start="0.smil"; boundary="---mime-boundary-DD57FF70.C0F919F1"
Content-ID: <mms_cid>

-----mime-boundary-DD57FF70.C0F919F1
Content-Type: application/smil; name="0.smil"
Content-ID: <01.smil>
Content-location: 0.smil

<smil><head><layout><root-layout/>
<region id="Text" top="70%" left="0%" height="30%" width="100%" fit="scroll"/>
<region id="Image" top="0%" left="0%" height="70%" width="100%" fit="meet"/>
</layout>
</head>
<body><par dur="10s"><img src="IMG_79221.jpg" region="Image"/>
</par>
</body>
</smil>

2011-11-02 11:23:48,665 DEBUG [http-0.0.0.0-8080-8] (?:?) - Fetching Message Body part with cid: mms_cid
2011-11-02 11:23:48,665 DEBUG [http-0.0.0.0-8080-8] (?:?) - Incoming message is a SMIL message, start='0.smil'
2011-11-02 11:23:48,670 WARN [http-0.0.0.0-8080-8] (?:?) - Attachment does not contain referenced document with ID '0.smil'.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3576
Registered: 08-2008
Posted on Thursday, November 03, 2011 - 10:01 pm:   

Hi Neil,

My understanding is that if angle brackets are present ... e.g., start="<01.smil>" .... then it is referencing the object by Content-ID value.

If the angle brackets are not present, it is referencing the object by Content-Location or name value.

As you will note, the object in question has different Content-Location and Content-ID values.

How is this message being received by the system? In other words, what is the logic flow through which NowSMS receives and processes this message?

--
Des
NowSMS Support
Neil Stamps
New member
Username: Nstamps

Post Number: 2
Registered: 11-2011
Posted on Friday, November 04, 2011 - 11:58 am:   

Thanks Des

reading the 6.3 MM7 specification, there is no mention of a choice of formatting of this start attribute. All examples are formatted as <> - referencing the content-id.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3577
Registered: 08-2008
Posted on Friday, November 04, 2011 - 03:37 pm:   

Hi Neil,

I'm trying to understand the message flow.

I'm guessing the message is coming in via a modem, and we are transcoding from MM1 to MM7. The MM1 format is a binary encoding of MIME, so I think we are just taking that data and transcoding to the text format.

I'm trying to understand if the message arrived that way via MM1, or we did something to it while processing it.

--
Des
NowSMS Support
Neil Stamps
New member
Username: Nstamps

Post Number: 3
Registered: 11-2011
Posted on Friday, November 04, 2011 - 03:42 pm:   

Des

yes - it came directly from an option modem.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3584
Registered: 08-2008
Posted on Friday, November 04, 2011 - 09:35 pm:   

Ok Neil,

The raw MM1 data should be logged in the SMSDEBUG.LOG when the message is received. I'm assuming that the received message is encoded with the start parameter pointing to the Content-Location instead of the Content-ID.

We're simply converting the WSP MIME multipart encoding to a text MIME multipart encoding. The idea is to try to preserve the original content.

To be honest, I don't think "start=" referring to a Content-location: or "name=" value is valid in MM1 either.

The MM1 encoding uses the "multipart/related" format, which is defined by RFC2387. That specification is very clear in stating:


quote:

The "start" parameter, if given, points, via a content-ID, to the body part that contains the object root.




The dilemma we have is that if it is arriving in MM1 format with the "start=" parameter not pointing to a valid "Content-ID:", then the message is already invalid at this point. I'm not sure that it is NowSMS responsibility to fix it.

Of course, I'm still assuming that NowSMS isn't responsible somehow for mixing up the values, which is why I'd like to see an SMSDEBUG.LOG showing the received MM1 content and the resulting MM7 data from MMSCDEBUG.LOG ... to confirm.

I can tell you that there are other places in MMS (in the SMIL specifically), where you can either reference by name/Content-location or Content-ID. So it is logical to deduce that since the angle brackets are missing for the start parameter value, and there is no match on Content-ID, a tolerant application should look for a match on name/Content-location.

--
Des
NowSMS Support