| Mm7_deliver.REQ? |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through February 20, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Anonymous |
I wonder if your MMS-C supports mm7_deliver.REQ and if it does, where I can find more info about how to set it up. | |||
| Bryce Norwood - NowSMS Support |
Hi Mikael, A lot depends on your configuration ... that is, how you send/receive MMS messages external to your system. I'm going to make an assumption that you're sending and receiving MMS messages through a GSM/GPRS modem (or through some sort of direct MMS delivery, as opposed to via another MMSC). On the "MMSC VASP" configuration dialog, you define the accounts that can submit messages inbound to NowSMS. So if you wanted to use MM7 to submit a message to NowSMS, you would define an account here. On the "MMSC Routing" configuration dialog, you define external connections that NowSMS will initiate to send (or deliver) messages. So if you want to use MM7 to receive messages from NowSMS, you would define a link to your MM7 application here. In some ways, it might make more sense if we combined these configuration dialogs, but having them separate allows a great deal of flexibility for how messages are routed. There are two ways to route MMS messages to your MM7 application. When you define an entry on the "MMSC Routing" page, there is an option "Route messages to this account for recipient phone number(s)". This option is normally used when you are performing outbound MMS message delivery via an MMSC. You can specify a phone number mask (e.g., +44*), and if during the course of normal MMS message routing, the MMSC encounters a recipient address that matches this mask, it will route it to this connection. (If this is an MM7 connection, the MM7 application would receive an MM7 SubmitReq.) The other way, which is more related to your question, is when an MMS message has been received by the gateway, such as over the GSM/GPRS modem ... where the recipient destination for the message is the gateway itself. Here, we've added some new settings in v5.0. On the "SMSC" page, if you select "Properties", there is an "MMS Settings" dialog that tells NowSMS how to fetch MMS messages from the operator MMSC. This dialog also has an option "MMSC Routing for Received Messages", where the "Route via MM7" option can be used to specify that received MMS messages should be routed to a particular MM7 application defined on the "MMSC Routing" dialog. So, if you setup a link to your MM7 application on the "MMSC Routing" page of the dialog ... then define the "MMS Settings" under the "Properties" for the appropriate modem connection, you'll receive the MM7 DeliverReq messages for any MMS messages received over the modem. | |||
| Mikael Unregistered guest |
Hi again and thanks a lot, I was initially intending to send MMS to NowSMS using a cell phone, but since I have read that it is not advised to use a cell-phone for modem (I am using an Ericsson T39) when receiving MMS, I would like to try the same when incoming MMS come from a VASP mm7-client. How should I configure NowSMS to produce a forward an mm7_deliver.REQ upon receving an mms from a VASP. When I setup my VASP-account in NowSMS the MM7-routing option is grayed out? And, if I were to try to use my T39 for receiving MMS to NowSMS...how would I address the recipient (the NowSMS MMS-C)? Best regards, Mikael | |||
| Mikael Unregistered guest |
just wanted to add this... Just as you described in your answer, I get NowSMS to produce an mm7_submit.REQ when I add the modem's phone number to the field: "Route messages to this account for recipient phone number(s)" using my Ericsson T39 phone. According to your info, removing recipient phone number in that field should cause an mm7_deliver.REQ right? I don't get anything... /Mikael | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 931 Registered: 10-2002 |
Hi Mikael, Currently, NowSMS is only going to generate an MM7_submit.REQ in that type of configuration. It will only generate an MM7_deliver.REQ if it receives an MMS that is being delivered in to the gateway (instead of being submitted to the gateway) ... such as a message being received over a phone being received over MM1 via GSM/GPRS modem. We are looking at adding a configuration option in a future release to remap submit to deliver for the type of setup that you describe. (This issue was recently discussed here: http://support.nowsms.com/discus/messages/12/858.html.)
You address it to the phone number of the phone/modem. (Just note that if the modem is a phone, the MMS client intercepts the message, and it is never routed over the modem interface.) | |||
| Mikael Unregistered guest |
So, if I buy a dedicated gsm/gprs modem, such as Siemens MC-35, I will be able to send MMS to NowSMS, which then can be routed as mm7_deliver.REQs to my mm7-VASP? I am not sure I understand the difference between "being delivered in to the gateway instead of being submitted to the gateway..". Do I need to involve another live operator MMS-C to "deliver in to the gateway.."? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 974 Registered: 10-2002 |
Mikael, Yes ... however, hopefully you would be doing more than sending messages to yourself. Basically, with a GSM/GPRS modem connection, you could submit messages via MM7 ... which would get routed out over the GSM/GPRS modem for delivery. Any delivery reports or messages addressed to the SIM card on the modem could get routed back in as "deliver" messages to your MM7 application. The issue at present is that there does need to be a connection to a live MMSC in order for any messages to be routed to an MM7 connection in "deliver" format instead of "submit". For a future version, I think we're going to have to add an option to the MM7 configuration which specifies whether to use "submit" or "deliver" format for a particular connection. -bn | |||
| Mikael Unregistered guest |
Hi! I have now bought a dedicated modem (Siemens MC35) and I have gotten NowSMS to produce and route an mm7_deliver.REQ to my mm7-vasp application  . However, when my VASP receives the mm7_deliver.REQ I get the error "soap end tag mismatch" or "cannot parse content type". The mm7-deliver.REQ produced by NowSMS is attached below. I wonder if there is any problem in the <env:Body> with <Content href="cid:mms_cid"/>, or anything else you might see which could cause the error. ************************************************* 604600 [Thread-6] INFO com.openwave.mms.mm7.Listener - MM7Receiver got a conne ction 604600 [Thread-7] INFO com.openwave.mms.mm7.Listener - MM7Receiver listening f or connections on port 35356 612621 [Thread-6] DEBUG com.openwave.mms.mm7.Listener - [Begin Incoming Request From Relay] 612621 [Thread-6] DEBUG com.openwave.mms.mm7.Listener - POST / HTTP/1.0 Authorization: Basic dHdpbmZhY3Rvcjp0d2luZmFjdG9y Host: 213.212.54.120:35356 SOAPAction: "" Content-length: 1909 Content-type: multipart/related; boundary="---mime-boundary-41068C60.B41ABAE1--- " Connection: close -----mime-boundary-41068C60.B41ABAE1--- Content-type: text/xml; charset=utf-8 <?xml version='1.0' ?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header> <mm7:TransactionID xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series /23.140/schema/REL-5-MM7-1-0" env:mustUnderstand="1"> BFB606E4.998D4065@mms.softhouse.se </mm7:TransactionID> </env:Header> <env:Body> <mm7:DeliverReq xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23 .140/schema/REL-5-MM7-1-0"> <MM7Version>5.3.0</MM7Version> <Recipients> <To><Number>+46706699092</Number></To> </Recipients> <Priority>Normal</Priority> <Subject>Multimedia Message</Subject> <Content href="cid:mms_cid" /> </mm7:DeliverReq> </env:Body> </env:Envelope> -----mime-boundary-41068C60.B41ABAE1--- Content-type: multipart/related; type=application/smil; start=<AAAA>; boundary=" ---mime-boundary-ED4A5422.3BF0E823---" Content-ID: <mms_cid> -----mime-boundary-ED4A5422.3BF0E823--- Content-type: text/plain; name="mms.txt"; charset=utf-8 Content-ID: <mms.txt> Content-location: mms.txt Munk -----mime-boundary-ED4A5422.3BF0E823--- Content-type: application/smil; name="mms.smil"; charset=utf-8 Content-ID: <AAAA> Content-transfer-encoding: quoted-printable <smil><head><layout><root-layout background-color=3D"#FFFFFF" backgroundColor=3D "#F= FFFFF" height=3D"240px" width=3D"160px"/> <region id=3D"Image" top=3D"0" left=3D"0" height=3D"50%" width=3D"100%" fit=3D"m eet"/> <region id=3D"Text" top=3D"50%" left=3D"0" height=3D"50%" width=3D"100%" fit=3D" meet"/> </layout> </head> <body><par dur=3D"2000ms"><text src=3D"mms.txt" region=3D"Text"><param name=3D"f oregrou= nd-color" value=3D"#000000"/> </text> </par> </body> </smil> -----mime-boundary-ED4A5422.3BF0E823----- -----mime-boundary-41068C60.B41ABAE1----- 612631 [Thread-6] DEBUG com.openwave.mms.mm7.Listener - [End Incoming Request F rom Relay] 612631 [Thread-6] WARN com.openwave.mms.mm7.Listener - cannot-parse-content-ty pe ************************************** Best regards, Mikael | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1026 Registered: 10-2002 |
Mikael, Based upon the error message that you're seeing, I'm guessing that the client is having a problem parsing the top level content type header. I suspect it wants a "start" parameter to point it to the XML document. I've sent you an e-mail with something to try. -bn | |||
| Mikael Unregistered guest |
Hi again and thanks! I have installed your patch and I can see that a "start"-parameter is now included. This seems to help a bit...but unfortunately there is still some parsing problem. I have attached the log below containing the mm7_deliver.REQ from NowSMS and the fault raised from the Openwave API("<StatusText>MessagingException retrieving mime body parts from message</StatusText>"). ps. Hope you had a good vacation! Regards, Mikael ************************************************* 411912 [Thread-3] DEBUG com.openwave.mms.mm7.Listener - [Begin Incoming Request From Relay] 411912 [Thread-3] DEBUG com.openwave.mms.mm7.Listener - POST / HTTP/1.0 Authorization: Basic dHdpbmZhY3Rvcjp0d2luZmFjdG9y Host: 213.212.54.120:35356 SOAPAction: "" Content-Length: 1943 Content-Type: multipart/related; boundary="---mime-boundary-96C6913C.5100FCBD--- "; type=text/xml; start="<mm7_msg>" Connection: close -----mime-boundary-96C6913C.5100FCBD--- Content-Type: text/xml; charset=utf-8 Content-ID: <mm7_msg> <?xml version='1.0' ?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header> <mm7:TransactionID xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series /23.140/schema/REL-5-MM7-1-0" env:mustUnderstand="1"> 0EAD7FC0.A9C9F641@mms.softhouse.se </mm7:TransactionID> </env:Header> <env:Body> <mm7:DeliverReq xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23 .140/schema/REL-5-MM7-1-0"> <MM7Version>5.3.0</MM7Version> <Recipients> <To><Number>+46706699092</Number></To> </Recipients> <Priority>Normal</Priority> <Subject>Multimedia Message</Subject> <Content href="cid:mms_cid" /> </mm7:DeliverReq> </env:Body> </env:Envelope> -----mime-boundary-96C6913C.5100FCBD--- Content-Type: multipart/related; type="application/smil"; start="<AAAA>"; bounda ry="---mime-boundary-55E692FE.1E22E3FF---" Content-ID: <mms_cid> -----mime-boundary-55E692FE.1E22E3FF--- Content-Type: text/plain; name="mms.txt"; charset=utf-8 Content-ID: <mms.txt> Content-location: mms.txt Hello world -----mime-boundary-55E692FE.1E22E3FF--- Content-Type: application/smil; name="mms.smil"; charset=utf-8 Content-ID: <AAAA> Content-Transfer-Encoding: quoted-printable <smil><head><layout><root-layout background-color=3D"#FFFFFF" backgroundColor=3D "#F= FFFFF" height=3D"240px" width=3D"160px"/> <region id=3D"Image" top=3D"0" left=3D"0" height=3D"50%" width=3D"100%" fit=3D"m eet"/> <region id=3D"Text" top=3D"50%" left=3D"0" height=3D"50%" width=3D"100%" fit=3D" meet"/> </layout> </head> <body><par dur=3D"2000ms"><text src=3D"mms.txt" region=3D"Text"><param name=3D"f oregrou= nd-color" value=3D"#000000"/> </text> </par> </body> </smil> -----mime-boundary-55E692FE.1E22E3FF----- -----mime-boundary-96C6913C.5100FCBD----- 411922 [Thread-3] DEBUG com.openwave.mms.mm7.Listener - [End Incoming Request F rom Relay] 411922 [Thread-3] WARN com.openwave.mms.mm7.Listener - MessagingException retr ieving mime body parts from message 411922 [Thread-3] DEBUG com.openwave.mms.mm7.Listener - [Begin Outgoing Respons e To Relay] 411922 [Thread-3] DEBUG com.openwave.mms.mm7.Listener - HTTP/1.0 200 OK 411922 [Thread-3] DEBUG com.openwave.mms.mm7.Listener - Content-Type: text/xml 411922 [Thread-3] DEBUG com.openwave.mms.mm7.Response - Content-length: 594 411922 [Thread-3] DEBUG com.openwave.mms.mm7.Response - <?xml version='1.0' ?>< env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mm7="ht tp://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0"><env: Body><Fault xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema /REL-5-MM7-1-0"><faultstring>Unknown Server Error</faultstring><faultcode>Server </faultcode><detail><VASPErrorRsp><MM7Version>5.3.0</MM7Version><Status><StatusT ext>MessagingException retrieving mime body parts from message</StatusText><Stat usCode>2000</StatusCode></Status></VASPErrorRsp></detail></Fault></env:Body></en v:Envelope> 411932 [Thread-3] DEBUG com.openwave.mms.mm7.Listener - [End Outgoing Response To Relay] ************************************************** | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1099 Registered: 10-2002 |
Hi Mikael, Have you made any progress on this? I've spent a good part of the day today fighting the Openwave MMS SDK. The odd thing is that at this point, I can't get their MM7MessageSender to generate an MM7 message that their MM7MessageReceiver will accept! I'm getting a different error message back ... "soap end tag mismatch". After a bit of frustration, I finally realised that MM7MessageReceiver expects MM7_Deliver.REQ format, whereas MM7MessageSender uses MM7_Submit.REQ. Reformatting the message that MM7MessageSender submits, but as a DeliverReq instead of a SubmitReq, I get the same "MessagingException retrieving mime body parts from message" error message that you have been receiving. Finally, I decided to try the sample MM7_deliver.REQ that appears in the 3GPP spec (after section 8.7.9.4). And the OpenWave MM7MessageReceiver also chokes on this simple example with the same error message. I'm at a loss to explain what is going on. I would certainly expect at least the example from the 3GPP specification to work. I checked the Openwave developer discussion board where someone else is asking similar questions, and the Openwave stock answer seems to be that it has only been tested against their MMSC and should only be used with a test account on their developer MMSC. So it sounds like the libraries aren't quite ready for prime time yet. I don't really have the time to work out getting a test account on their developer MMSC ... but if you want to do that, and post the format for the message that comes in from their MMSC, we could take a look at it and see what differences there might be. -bn | |||
