Error in xml when routing MM7 to operators MMSC

Error in xml when routing MM7 to operators MMSC SearchSearch
Author Message
Shimon
New member
Username: Daffy

Post Number: 3
Registered: 06-2004
Posted on Friday, July 16, 2004 - 11:08 am:   

Hi.

The operators MMSC will not accept my MM7 message and I belive that it is becase of an extra space in the body (<Content href="cid:mms_cid" /> between the second " and /) of the xml that is sent (see log).

Regards
Shimon Kupersmidt

--LOG-----------------------------------

16:14:29:644 [7] InetServerConnect: Connected to xxx.yyy.se (1.1.1.1:8090)
16:14:29:644 [7] ThreadProcessVASPQ: POST /mm7 HTTP/1.0
Host: xxx.yyy.se:8090
SOAPAction: ""
Content-Length: 1336
Content-Type: multipart/related; boundary="---mime-boundary-F032A15B.98A2DA1C---"; type="text/xml"; start="<mm7_msg>"
Connection: close


16:14:29:644 [7] ThreadProcessVASPQ: -----mime-boundary-F032A15B.98A2DA1C---
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-2" env:mustUnderstand="1">
20040715/11/D32E025B@172.16.92.22
</mm7:TransactionID>
</env:Header>
<env:Body>
<SubmitReq xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2">
<MM7Version>5.3.0</MM7Version>
<SenderIdentification>
<VASPID>INFOSYS</VASPID>
<VASID>INFOSYS</VASID>
</SenderIdentification>
<Recipients>
<To>
<Number>46701111111</Number>
</To>
</Recipients>
<DeliveryReport>False</DeliveryReport>
<Subject>subj</Subject>
<Content href="cid:mms_cid" />
</SubmitReq>
</env:Body>
</env:Envelope>

-----mime-boundary-F032A15B.98A2DA1C---
Content-Type: multipart/mixed; boundary="---mime-boundary-C97CAD9D.029FABDE---"
Content-ID: <mms_cid>

-----mime-boundary-C97CAD9D.029FABDE---
Content-Type: text/plain
Content-ID: <40F64F99.txt>
Content-location: 40F64F99.txt

test
-----mime-boundary-C97CAD9D.029FABDE-----

-----mime-boundary-F032A15B.98A2DA1C-----

16:14:29:674 [7] ThreadProcessVASPQ: mm7 - got unknown response
16:14:29:674 [7] ThreadProcessVASPQ: HTTP/1.1 500 Could not decode soap operation.
Date: Thu, 15 Jul 2004 16:13:28 +0200
Content-Type: text/plain
Connection: Close
Server: Nobill/R3
Content-Length: 32

Could not decode soap operation.
16:14:29:674 [7] ThreadProcessVASPQ: Outbound route Symsoft: setting retry for D32E025B.MMS
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 3066
Registered: 10-2002
Posted on Friday, July 16, 2004 - 03:33 pm:   

Hi Shimon,

Granted, I have seen stranger issues ... but I'd be very surprised if that extra space character made a difference as it is perfectly legal XML.

Before we make any changes to this, let's try a test of manually submitting this message. Cut & paste the MM7 data and put it into Notepad.

Remove the extra "16:14:29:644 [7] ThreadProcessVASPQ:" debug info that appears in the log.

--------
POST /mm7 HTTP/1.0
Host: xxx.yyy.se:8090
SOAPAction: ""
Content-Length: 1336
Content-Type: multipart/related; boundary="---mime-boundary-F032A15B.98A2DA1C---"; type="text/xml"; start="<mm7_msg>"
Connection: close

-----mime-boundary-F032A15B.98A2DA1C---
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-2" env:mustUnderstand="1">
20040715/11/D32E025B@172.16.92.22
</mm7:TransactionID>
</env:Header>
<env:Body>
<SubmitReq xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2">
<MM7Version>5.3.0</MM7Version>
<SenderIdentification>
<VASPID>INFOSYS</VASPID>
<VASID>INFOSYS</VASID>
</SenderIdentification>
<Recipients>
<To>
<Number>46701111111</Number>
</To>
</Recipients>
<DeliveryReport>False</DeliveryReport>
<Subject>subj</Subject>
<Content href="cid:mms_cid" />
</SubmitReq>
</env:Body>
</env:Envelope>

-----mime-boundary-F032A15B.98A2DA1C---
Content-Type: multipart/mixed; boundary="---mime-boundary-C97CAD9D.029FABDE---"
Content-ID: <mms_cid>

-----mime-boundary-C97CAD9D.029FABDE---
Content-Type: text/plain
Content-ID: <40F64F99.txt>
Content-location: 40F64F99.txt

test
-----mime-boundary-C97CAD9D.029FABDE-----

-----mime-boundary-F032A15B.98A2DA1C-----

--------

As different editors can sometimes cause a few extra spaces to be added or removed, change the Content-Length to increase it by a few bytes ... say 1350. Also, remove that extra space that you think is the problem.

Now, go into TELNET. Open a connection to the server.

Cut and paste the MM7 data from Notepad into TELNET.

As the "Content-Length:" may tell the server to expect some more data ... after you paste, hit the space bar a few times until the server comes back with a response.

Did the server come back with this "500" error again?

If the server didn't come back with the "500", then let us know, and we'll go ahead and remove the space character that you suspected to be a problem.

If the server still comes back with the "500", then there is something else that this service does not like.

My first guess would be that it wants to be a sender address. Try applying a default sender address to the outbound route definition in NowSMS, and see if that makes a difference.

It is also possible that the service wants a different version of the MM7 schema. We do have a way to change that ... but I'd suggest getting advice from the provider before you attempt this. (The following thread has info on this: http://support.nowsms.com/discus/messages/485/3417.html)

Ask your provider for any docs that they have. I can't say that I've seen this particular server before ... and there is no documentation on the vendor's web site. So if you do get any documentation, I'd appreciate it if you forward it to me.

-bn
Shimon Kupersmidt
New member
Username: Daffy

Post Number: 4
Registered: 06-2004
Posted on Friday, July 16, 2004 - 04:27 pm:   

Hi.

I did the test as you suggested and by removing the extra space in <Content href="cid:mms_cid" /> it accepted and it got through. Got an error which says "message format corrupt" instead. Does it have anything to do how it was submitted when I tested with telnet?

According to the MMSC vendor also the <?xml version='1.0' ?> header is not right and should have double quotes instead of single quotes; <?xml version="1.0" ?>. The single quotes however are accepted by the server so its not an issue. Just wanted to inform.

Thanks,
Shimon

---LOG---

POST /mm7 HTTP/1.1
Host: xxx.yyy.se:8090
SOAPAction: ""
Content-Length: 1345
Content-Type: multipart/related; boundary="---mime-boundary-DFF6D736.6BB48237---"; type="text/xml"; start="<mm7_msg>"
Connection: close

-----mime-boundary-DFF6D736.6BB48237---
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-2" env:mustUnderstand="1">
20040716120915-B07766F5@172.16.92.22 </mm7:TransactionID>
</env:Header>
<env:Body>
<SubmitReq xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2">
<MM7Version>5.3.0</MM7Version>
<SenderIdentification>
<VASPID>INFOSYS</VASPID>
<VASID>INFOSYS</VASID>
</SenderIdentification>
<Recipients>
<To>
<Number>46701111111</Number>
</To>
</Recipients>
<DeliveryReport>False</DeliveryReport>
<Subject>subj</Subject>
<Content href="cid:mms_cid"/>
</SubmitReq>
</env:Body>
</env:Envelope>

-----mime-boundary-DFF6D736.6BB48237---
Content-Type: multipart/mixed; boundary="---mime-boundary-B147F7F8.E394C879---"
Content-ID: <mms_cid>

-----mime-boundary-B147F7F8.E394C879---
Content-Type: text/plain
Content-ID: <40F7A901.txt>
Content-location: 40F7A901.txt

text
-----mime-boundary-B147F7F8.E394C879-----

-----mime-boundary-DFF6D736.6BB48237-----
--> 7
SOAP MESSAGE IND
Envelope
Header
Block
Name : TransactionID
Value : 20040716120915-B07766F5@172.16.92.22
Attribute : env:mustUnderstand = "1"
Attribute : xmlns:mm7 = "http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2"
Must understand : true
Body
Block
Name : SubmitReq
Attribute : xmlns = "http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2"
Name : MM7Version
Value : 5.3.0
Name : SenderIdentification
Name : VASPID
Value : INFOSYS
Name : VASID
Value : INFOSYS
Name : Recipients
Name : To
Name : Number
Value : 46701111111
Name : DeliveryReport
Value : False
Name : Subject
Value : subj
Name : Content
Attribute : href = "cid:mms_cid"
Attachment
178 octets
--> 7
Mm7 message recieved
--> 9
MM7 SUBMIT REQUEST IND
Transaction Id
20040716120915-B07766F5@172.16.92.22
Mms Version
5.3.0
To
+46701111111 : PLMN
Message Content
41 octets
Vasp Id
INFOSYS
Vas Id
INFOSYS
Delivery Report
No
Subject
subj
--> 10
MM7, Mm7SubmitRequestInd, vasId: INFOSYS
Got stop reason: 0 in state: 0
<-- 10
MM7 SUBMIT RESPONSE REQ
Transaction Id
20040716120915-B07766F5@172.16.92.22
Mms Version
5.3.0
Request Status
Message format corrupt
Message Id
hSY2TOnFcPRT5
<-- 14
SOAP MESSAGE REQ
Envelope
Header
Block
Name : TransactionID
Value : 20040716120915-B07766F5@172.16.92.22
Attribute : soapenv:mustUnderstand = "1"
Attribute : xmlns:mm7 = "http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-4"
Must understand : true
Body
Block
Name : SubmitRsp
Attribute : xmlns:mm7 = "http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-4"
Name : MM7Version
Value : 5.3.0
Name : MessageID
Value : hSY2TOnFcPRT5
Name : Status
Name : StatusCode
Value : 2007
Name : StatusText
Value : Message format corrupt
<-- 16
HTTP/1.1 200 OK
Message-Id: <32963152.1089989471990.JavaMail.root@mums2>
Date: Fri, 16 Jul 2004 16:51:11 +0200
Mime-Version: 1.0
Content-Type: text/xml; charset="utf-8"
Content-Transfer-Encoding: 7bit
SOAPAction: ""
Connection: Close
Server: Nobill/R3
Content-Length: 739


<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<mm7:TransactionID soapenv:mustUnderstand="1" xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-4">20040716120915-B07766F5@172.16.92.22</mm7:TransactionID>
</soapenv:Header>
<soapenv:Body>
<mm7:SubmitRsp xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-4">
<MM7Version>5.3.0</MM7Version>
<MessageID>hSY2TOnFcPRT5</MessageID>
<Status>
<StatusCode>2007</StatusCode>
<StatusText>Message format corrupt</StatusText>
</Status>
</mm7:SubmitRsp>
</soapenv:Body>
</soapenv:Envelope>

--> 16
Got success() from Mm7
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 3069
Registered: 10-2002
Posted on Friday, July 16, 2004 - 07:13 pm:   

Hmm ...

The issue of ' vs. " shouldn't be significant. You're supposed to be able to use either in XML. However, it is inconsistent for us to use ' in the header, then " subsequently. So we will change that.

As it seems to make a difference for this particular service, we'll also remove that extra space.

I've uploaded a quick update to address those issues, it can be downloaded as http://www.nowsms.com/download/shimon.zip

Now, the tougher problem ... why is the server reporting that the message format is corrupt?

I'd suggest trying the following variations with the update:

1.) Submit a message with multiple content parts instead of just a single text file. (It is possible that the server does not like a "multipart/mixed" wrapper around a single piece of content.)

2.) Try including a sender address in the message, as I indicated above.

3.) Try including a SMIL file in with your message submission. It is possible that the server expects there to be a SMIL file (even though the specs don't require one). If a SMIL file is present, we use "multipart/related" in the submission instead of "multipart/mixed".

-bn
Shimon Kupersmidt
New member
Username: Daffy

Post Number: 5
Registered: 06-2004
Posted on Monday, July 19, 2004 - 02:42 pm:   

Hi.

With your updated version it is working now. I don't even get the "Message format corrupt" anymore, as when testing through telnet.

Thanks,
Shimon