Incoming MM1 origination getting -131 error from MMSC?

Incoming MM1 origination getting -131 error from MMSC? SearchSearch
Author Message
Robert Barretto
New member
Username: Barretto

Post Number: 29
Registered: 09-2019
Posted on Monday, July 27, 2020 - 04:08 pm:   

Hi all,

He all I'm having an issue originating an MMS (incoming MM1 to outgoing MM4 on the NowSMS MMSC). The node sending in the HTTP-enriched MM1 message to the MMSC is receiving an error info="-131" from the MMSC. I'm trying to test a new load on that node, and when I try the new load I get the "-131" and when I revert back the previous load, the MM1 message is accepted and delivered through the NowSMS MMSC. Unfortunately, the MMSCDEBUG logs rolled out before I had a chance to grab them, so all I have are some limited connector logs from the originating node. I was working with them to see if there's a problem with the MM1 request, but they're saying their message looks fine on their side and according to the OMA specification it means
"Error-message-format-corrupt = <Octet 131> (obsolete)", which isn't
super informative.

I've anonymized the logs (numbers/IPs) but here's what a good exchange looks like (excuse the bold, don't know why that's highlighting). The values are what are coming back from the NowSMS MMSC. (I can't see what the original request was though):

2020-07-24 04:21:59.531408 (0) CONNECT OK (info="0 37.18.18.18")
2020-07-24 04:22:00.283087 (0) SEND OK 001:714727 002:14695552345 008:2147275273 018:604800 025:7 027:1 028:0 034:37.37.37.37 059:dc1-mm1-proxy 061:8 064:20200723-23-AA3312E6@mms.blahblah.com 093:1595564519 094:528 095:1595564520 096:282 118:3 133:1 220:43626 026:128 137:1595564517 128:1 145:2145551234/TYPE=PLMN 129:1 219:582d4d534953444e3a202b31343639353535323334350a582d5741502d334750502d5347534e2d4d43432d4d4e433a203331303431300a582d5741502d334750502d494d53493a20323334353637 3839313233343536370a
2020-07-24 04:22:05.298231 (0) DISCONNECT OK

and here's another origination, but this time it fails:

2020-07-24 04:16:34.299197 (6) CONNECT OK (info="0 37.18.18.18")
2020-07-24 04:16:34.660905 (6) SEND ERR (info="-131") 001:714718 002:14695552345 008:2145551234 018:604800 025:7 027:1 028:0 034:37.37.37.37 059:dc1-mm1-proxy 061:8 093:1595564194 094:295 095:1595564194 096:660 118:3 133:1 220:43558 026:128 137:1595564192 128:1 145:2145551234/TYPE=PLMN 129:1
219:582d4d534953444e3a202b31343639353535323334350a582d5741502d334750502d5347534e2d4d43432d4d4e433a203331303431300a582d5741502d334750502d494d53493a20323334353637 3839313233343536370a
2020-07-24 04:16:40.661261 (6) DISCONNECT OK

Currently, the only place I can re-create the issue is in our production environment, so I have to get a maintenance window scheduled before I can try again. Are there specific logs (besides MMSCDEBUG.log) which could be useful? I'll try to take a wireshark trace to see if I can see anything there as well.

Trying to figure out the best way to debug this to find out what's going on, and when it's going wrong.

Thanks,
//Robert
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 8349
Registered: 10-2002
Posted on Tuesday, July 28, 2020 - 01:57 am:   

Hi Robert,

I'm not familiar with the packet format in your logs...it appears to be some intermediary encoding. Wireshark would help to show the final encoding. MMSCDEBUG.LOG would probably also help, although it is probably just going to report a corrupt message.

In MMS 1.0, error 131 was mms_response_status_error_message_format_corrupt. And, our MMSC only returns this error if the client request is MMS 1.0, or the version cannot be determined. If the request uses a later version, error codes are appropriate to the version.

The only thing that comes to mind is that the issue may be something to do with HTTP keep-alive sockets and stray data that is causing HTTP requests and responses to get out of sync. Wireshark would likely be very helpful.

Regards,

Bryce
Robert Barretto
New member
Username: Barretto

Post Number: 30
Registered: 09-2019
Posted on Tuesday, July 28, 2020 - 02:56 pm:   

Hi Bryce,

Understood. I'm getting a maintenance window scheduled so I can get a full set of logs, including Wireshark traces so I can tell what's on the wire. Hopefully with a complete set of logs we can get a better view of what's actually going on. I know I was reaching with just a partial set of logs that may or may not show all the necessary data.
Robert Barretto
New member
Username: Barretto

Post Number: 31
Registered: 09-2019
Posted on Thursday, July 30, 2020 - 10:55 pm:   

Hi Bryce,

Just to follow up. I was able to get a pcap trace of a working and non-working MMSE origination. There was an encoding error that cause the To party element to be mangled, which then caused the Content-Type element to be not seen by the MMSC. This was resulting in a "missing content-type header" log in the MMSCDEBUG file:

22:03:14:369 [72] ThreadProcessConnection: Got application/vnd.wap.mms-message
22:03:14:369 [72] ThreadProcessConnection: Got m-send-req
22:03:14:369 [72] ThreadProcessConnection: Message missing content-type header

The content-type header is in the message and is encoded correctly, it was the previous corrupted header before it that was gumming up the works.

I have received a new load from the MM1 gateway and will be trying that out in a maintenance window tonight.

Thanks!
//Robert
Robert Barretto
New member
Username: Barretto

Post Number: 32
Registered: 09-2019
Posted on Monday, August 03, 2020 - 08:57 pm:   

Hi Bryce,

So I'm a little closer, but it's still not working. The visible parsing error is gone from the MMSCDEBUG log, but now it's saying "invalid recipient", and then "No valid recipients".

In the MMSCDEBUG log I see the following:

22:05:46:189 [72] ThreadProcessConnection: Processing connection from 37.xx.xx.xx...
22:05:48:132 [72] ThreadProcessConnection: Got application/vnd.wap.mms-message
22:05:48:132 [72] ThreadProcessConnection: Got m-send-req
22:05:48:133 [72] ThreadProcessConnection: msisdnHeader auth for user +14695551111
22:05:48:133 [72] ThreadProcessConnection: TO: "214551234/TYPE=PLMN
22:05:48:133 [72] ThreadProcessConnection: Invalid Recip: TO: "2145551234/TYPE=PLMN
22:05:48:133 [72] ParseMMSContentClass: body part #1 Content-Type = application/smil
22:05:48:133 [72] ParseMMSContentClass: body part #2 Content-Type = image/png
22:05:48:133 [72] ParseMMSContentClass: body part #3 Content-Type = text/plain
22:05:48:133 [72] ParseMMSContentClass: got image
22:05:48:133 [72] ThreadProcessConnection: No valid recipients!

From my tcpdump capture, the To address data is:

97178422323134353535313233342f545950453d504c4d4e00

97 - to
17 - length
8422 - not sure about this. It's suppose to be indicating Latin-1, if that helps
3231... - 2145551234/TYPE=PLMN

I think the issue is with the charset bytes before the number portion in the To address, but I don't know what's valid and what isn't. The charset is suppose to be Latin-1 which is (1003d or 0x03EB or 0011 1110 1011). If that gets OR'ed with 0x80 (1000 0000), it should just be 0011 1110 1011 (or 0x03EB), not 0x8422.

So I think the above byte stream should be:

971703EB323134353535313233342f545950453d504c4d4e00

I know if the message was using UTF-8 (106d or 0x6A or 0110 1010) that would be (0x80 | 0x6A) which would get you 1110 1010 (0xEA) and the to address data would show as:

9716EA323134353535313233342f545950453d504c4d4e00

Does that sound correct? Just trying to figure out what to say back to our MM1 proxy developer, so I word the problem correctly.

Thanks,
//Robert
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 8350
Registered: 10-2002
Posted on Monday, August 03, 2020 - 11:25 pm:   

Hi Robert,

There's definitely a problem with the encoding...but I am not sure exactly where to point you in the specs.

I can't spot a reference for how the "Char-set" is encoded in the MMS Encapsulation protocol.

But my assumption is that it is encoded as a WSP format integer value, as the MMS Encapsulation spec is built on top of the WAP WSP spec, and character set values in WSP are encoded as integer.

For WSP integer encoding, if the value is < 0x7F, it is OR'd with 0x80. Larger values are split into 7-bit blocks, and only the last block has the high bit (0x80) set, to indicate the end of the value.



Digging a little further, isn't Latin-1 equivalent to iso-8859-1? That character set value is 4, so 0x84 would be correct.

That leaves the mystery of the quote (0x22) character, which WSP does define in a particular scenario:



Text-string = [Quote] *TEXT End-of-string 
; If the first character in the TEXT is in the range of 128-255, a Quote character must precede it.
; Otherwise the Quote character must be omitted. The Quote is not part of the contents.


Technically the quote character is only supposed to be present if the first character of the string only if the first character of the string is > 0x7F.

So, technically, your client should not be using a quote character here because the first character of the address string is <= 0x7F.

If all of my interpretations are correct, it could also be argued that our MMSC should automatically remove this quote character if present. However, for an address header field that only supports MSISDN or e-mail addresses, we have not seen an address header encoded like this before.

Regards,

Bryce Norwood
NowSMS Support
Robert Barretto
New member
Username: Barretto

Post Number: 33
Registered: 09-2019
Posted on Tuesday, August 04, 2020 - 08:21 pm:   

Hi Bryce,

Thanks for the info. I'll pass it along to the gateway support person. I'll try to clarify which Latin1 they are using. I totally missed the codepoint 4, which I think is correct and not 1003 which is the unicode Latin1 subset: (https://www.iana.org/assignments/character-sets/character-sets.xhtml

I'd be much happier to have length be 16 and the charset be 84, with no " in there at all. :)

Thanks again!
//Robert
Robert Barretto
New member
Username: Barretto

Post Number: 34
Registered: 09-2019
Posted on Tuesday, August 04, 2020 - 08:47 pm:   

I totally misinterpreted the 8422, duh. The " is the 22. Somehow, in my brain I combined both bytes to be charset instead 84 for Latin1 and 22 as the ". I'm so glad that didn't throw you off. My bad. It's really just the 22 that's in question.

I wish I could said it was late or that alcohol was involved. Sadly, neither was the case. My bad... I promise I'm not normally this ditzy.

Thanks again,
//Robert

Add Your Message Here, or click here to start a new topic.
Post:
Bold text Italics Underline Create a hyperlink Insert a clipart image
Options: Automatically activate URLs in message
Action: