Smil MMS messages incorrectly formatted? | Search |
NowSMS Support Forums ⬆ NowSMS Lite Support ⬆ Archive through September 20, 2012 ⬆ |
◄ ► |
Author | Message | |||
Neil Stamps New member Username: Nstamps Post Number: 1 Registered: 11-2011 |
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 |
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 |
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 |
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 |
Des yes - it came directly from an option modem. | |||
Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3584 Registered: 08-2008 |
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:
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 |