| Unsupported MM7 Transaction (4003) Error Where there should not be ... |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through February 20, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Khwezi Mngoma New member Username: Nexus Post Number: 2 Registered: 11-2003 |
Greetings, I submited this SOAP envelope to the MMSC: Note: I took this directly from the 3GPP manual... <?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-3" env:mustUnderstand="1"> vas00324-dlvr </mm7:TransactionID> </env:Header> <env:Body> <!-- Example of MM7_deliverReq --> <DeliverReq xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-3"> <MM7Version>5.6.0</MM7Version> <MMSRelayServerID>240.110.75.34</MMSRelayServerID> <LinkedID>wthr8391</LinkedID> <Sender> <RFC2822Address>97254265781@OMMS.com</RFC2822Address> </Sender> <TimeStamp>2002-04-15T14:35:21-05:00</TimeStamp> <Priority>Normal</Priority> <Subject>Weather Forecast</Subject> <Content href="cid:forecast-location200102-86453"/> </DeliverReq> </env:Body> </env:Envelope> and this is what I got back: <?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"> vas00324-dlvr </mm7:TransactionID> </env:Header> <env:Body> <mm7:RSErrorRsp xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0"> <MM7Version>5.3.0</MM7Version> <Status> <StatusCode>4003</StatusCode> <StatusText>Unsupported Operation</StatusText> <Details>Unsupported MM7 transaction</Details> </Status> </mm7:RSErrorRsp> </env:Body> </env:Envelope> I fidn it confusing why it should give me this error message time and time again when I am following what I am told. What could possibly be going wrong? HELP. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1415 Registered: 10-2002 |
Did you include any content, or just the envelope? The error that you mention could occur if the content-type of the POST is not multipart. (The only MM7 transaction supported that is not multipart, i.e., has no content associated with it, is a DeliveryReportReq.) See the following link, which includes a complete POST (not just the envelope): http://www.nowsms.com/documentation/ProductDocumentation/mms_notifications_and_c ontent/Submitting_MMS_Messages_MM7.htm | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1418 Registered: 10-2002 |
This reply was received via e-mail, so I am posting it here to maintain the thread: Thanks for the reply, I was performing a number of tests and my first one was to set the content type to "text/xml" and the payload only being the SOAP envelope containing the relevant information for the delivery request. I decided to take an MMS dump of another program along with its headers and the same thing occurred. When I took an MMS delivery request dump from your help system, it sent it fine. I then took the very same data and sent it through my operator's domain, it told something about a corrupt part definition. I though all MMSC and MM7 protocols are supposed to be standardized, I am severely confused now. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1419 Registered: 10-2002 |
Without any payload, the request is corrupt. We could probably give a more detailed error message than just "Unsupported MM7 Transaction", but that is why you would receive such an error.
These are early days for the MM7 and MM4 protocols. MM1 is pretty solid because it is widely implemented across a large number of handsets. But MM7 and MM4 are still quite young (we've made quite a few tweaks to our implementation of both in patches since the v5.0 release.) The example on our web page was adapted from the 3GPP MMS specification, so it should be a good example. The only thing that jumps out at me is the "start=" parameter on the "Content-type:" field is a continuation of the previous header, and that is not obvious from the way things are word-wrapped in our example page. -bn | |||
