Intercarrier MMS

Intercarrier MMS SearchSearch
Author Message
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 9
Registered: 12-2012
Posted on Friday, March 29, 2013 - 08:54 pm:   

We have a phone number that ported in, and ported out from our network within a few month. We now have a complaint that this number cannot recieve MMS from our subscribers.

I've checked the MMS users tab to make sure those that number is not in the MMS users table, and we have double checked the systems that handle the porting process, but I think it's still being routed as one of our subscribers. What do I need to do to fix this, and what further information do you need?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4346
Registered: 08-2008
Posted on Saturday, March 30, 2013 - 04:33 pm:   

Hi Jeremy,

Where I would start is by determining whether the issue is routing related on your end or at the interconnect routing messages to you that it should not.

We'll start on your end. From a device connected to your MMSC, send an MMS to the problematic number.

Now search the MMSC-yyyymmdd.LOG for references to that number.

There will be one or two MMSIN records. If the second to last parameter ends in ".req", then that is a good indication that the message is being routed locally instead of to the interconnect. I'm going to assume that is what you see. If that is NOT what you see, then what references do you see to that number in the log?

Continuing with my assumption...

Why would the message be routed locally?

If the recipient number is not in your MMSC Users list, then the procedure is this:

If a routing callback is defined, the MMSC is going to issue an HTTP request to the callback. (For more info on how this works, see http://www.nowsms.com/doc/mmsc-messaging-server/operator-mmsc-considerations/mob ile-number-portability-mnp-considerations)

The following assumes you are using routing callbacks...

We need to check to see whether that callback is returning correct information.

To do this, enable debug mode temporarily for the MMSC. This is done by editing MMSC.INI, and under the [MMSC] header, adding Debug=Yes. After saving MMSC.INI, wait about 60 seconds for debug mode to be enabled. Then send another MMS message to the problem number. Search MMSCDEBUG.LOG for that number, looking for an HTTP request that references this number. The log should show the request and response. If the response is blank or Route=Direct, then this is an indication that the callback is telling the MMSC to handle the message locally ... and you need to investigate why the callback is returning incorrect routing and fix it.

If you do not see a routing callback for this number, send a message to another known remote number. If you see a callback for this other number, but not the problem number, this indicates that the MMSC thinks the number is in the "MMSC Users" list. In this case, under the [MMSC] header or MMSC.INI, add the parameter ForceRoutingCallback=Yes. This setting will cause the routing lookup to always occur, and the "MMSC Users" list to be ignored for routing purposes.

I'm making a lot of assumptions about likely scenarios, so if you follow this path, and something doesn't follow my assumption, explain what you see.

--
Des
NowSMS Support
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 10
Registered: 12-2012
Posted on Monday, April 01, 2013 - 05:13 pm:   

I'm still going through those debug steps.

Another question: Once I get out of debug mode (by deleting the "Debug=Yes" line in the MMSC.ini file. I'm trying to delete the log (it grows in size super fast), but I'm told that the file is still opened in mmsc.exe. How do I get the MMS gateway to release it?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4354
Registered: 08-2008
Posted on Monday, April 01, 2013 - 05:23 pm:   

Yes, it can grow very fast. Remove Debug=Yes to stop it.

That will not release it, however. But the MMSC should have it open in a non-exclusive mode. For example, the COPY command works fine. Or if you need a good file browser, I like to use V from fileviewer.com.
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 11
Registered: 12-2012
Posted on Monday, April 01, 2013 - 05:42 pm:   

Here's what I have for this number (3075553326 is the sender, 3075556178 is the recipient that cannot get messages from our subscribers).
Line 3455838 - 09:33:26:516 [10] ThreadProcessConnection: TO: <3075556178>/TYPE=PLMN
Line 3455840 - 09:33:26:516 [10] NormalizePhoneNumber: Normalized <3075556178>/TYPE=PLMN to +13075556178/TYPE=PLMN
Line 3455840 - 09:33:26:516 [10] NormalizePhoneNumber: Normalized 3075556178/TYPE=PLMN to +1<3075556178>/TYPE=PLMN
Line 3455842 - 09:33:26:517 [10] MMSRoutingCallback: +1<3075556178>/TYPE=PLMN
Line 3455846 - 09:33:26:517 [10] RetrieveURL: Retrieving http://localhost:9800/Accounting/Default.aspx?Type=MMSRouteCheck&From=%2B1307555 3326&To=%2B1<3075556178>&Size=122463
Line 3455850 - 09:33:26:517 [10] RetrieveURL: Retrieving Accounting/Default.aspx?Type=MMSRouteCheck&From=%2B13075553326&To=%2B1<307555617 8>&Size=122463
Line 3455852 - 09:33:26:517 [10] RetrieveURL: GET /Accounting/Default.aspx?Type=MMSRouteCheck&From=%2B13075553326&To=%2B1<30755561 78>&Size=122463 HTTP/1.1
Line 3455910 - 09:33:26:519 [10] MMSRoutingCallback: +1<3075556178>/TYPE=PLMN
Line 3455946 - 09:33:26:521 [10] RetrieveURL: Retrieving http://localhost:9800/Accounting/Default.aspx?PreAuth=Yes&Type=MMSSend&From=%2B1 3075553326&To=%2B1<3075556178>&MsgCount=1&Size=122463
Line 3455950 - 09:33:26:521 [10] RetrieveURL: Retrieving Accounting/Default.aspx?PreAuth=Yes&Type=MMSSend&From=%2B13075553326&To=%2B1<307 5556178>&MsgCount=1&Size=122463
Line 3455952 - 09:33:26:522 [10] RetrieveURL: GET /Accounting/Default.aspx?PreAuth=Yes&Type=MMSSend&From=%2B13075553326&To=%2B1<30 75556178>&MsgCount=1&Size=122463 HTTP/1.1
Line 3456121 - 09:33:26:530 [10] DeliverMMSMessage: TO: +1<3075556178>/TYPE=PLMN
Line 3456323 - 09:33:26:540 [10] RetrieveURL: Retrieving http://localhost:9800/Accounting/Default.aspx?Type=MMSSend&From=%2B13075553326&T o=%2B1<3075556178>&MessageID=20130401/09/8E93DEDC&Size=122463
Line 3456327 - 09:33:26:540 [10] RetrieveURL: Retrieving Accounting/Default.aspx?Type=MMSSend&From=%2B13075553326&To=%2B1<3075556178>&Mes sageID=20130401/09/8E93DEDC&Size=122463
Line 3456329 - 09:33:26:540 [10] RetrieveURL: GET /Accounting/Default.aspx?Type=MMSSend&From=%2B13075553326&To=%2B1<3075556178>&Me ssageID=20130401/09/8E93DEDC&Size=122463 HTTP/1.1


I see an "MMSRoutingCallback: +1<3075556178>/TYPE=PLMN". Is that what I should be seeing?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4355
Registered: 08-2008
Posted on Monday, April 01, 2013 - 06:35 pm:   

Hi Jeremy,

That is bizarre and unexpected.

The message appears to be addressed to <3075556178>/TYPE=PLMN

The angle brackets (less than/greater than symbols) are not valid in an MMS recipient address, so it is unclear where they are coming from.

If you look above that area of the debug log, in the hex dump of the MMS message submission, does it also show these angle brackets around the recipient phone number?

Assuming the angle brackets are present there in the hex dump (because I don't know where else they could be coming from), that would indicate that the MMS client is putting them there, like there is an error in the client address book.

Technically we should be rejecting the message as having a malformed MMS address. However, it looks like we are trying to work with it. That is confusing the routing callback.

And I assume that eventually we remove the angle brackets to try to deliver the message, but after the routing callback has occurred.

Are you seeing this behaviour with other senders to this number?

If you want to send a more complete log to me, send it to nowsms@nowsms.com, but put Attention: Des in the subject line.

I'm going to run some tests to try to better understand what happens if a message is submitted to a recipient address that includes angle brackets. But can you confirm that these angle brackets are present in the raw MMS submission?

--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4356
Registered: 08-2008
Posted on Monday, April 01, 2013 - 07:47 pm:   

Hello again Jeremy,

I am guessing that these angle brackets are not actually a factor and that they are being added by the program that is being used to search the text. So they don't actually exist.

Assuming that is the case, I was under an incorrect assumption that the MMSCDEBUG.LOG would show the response received from the routing callback. It does not. It shows the request, but not the response.

This is the request that is being made in the routing callback.

http://localhost:9800/Accounting/Default.aspx?Type=MMSRouteCheck&From=%2B1307555 3326&To=%2B13075556178&Size=122463

Open a web browser on the MMSC, and cut and paste the routing callback request into the browser. (Remove any embedded spaces or line breaks, as this discussion board software adds spaces into extremely long strings.)

Try changing the To= to reference other recipient numbers as well for comparison.

I think that is where the routing is becoming incorrect. Hopefully some manual URL checks can confirm this.

--
Des
NowSMS Support
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 12
Registered: 12-2012
Posted on Monday, April 01, 2013 - 09:04 pm:   

The route says "Direct". I'm guessing it should be one of the route listed in the MMSC Routing tab of the MMSC. Now what?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4357
Registered: 08-2008
Posted on Monday, April 01, 2013 - 09:15 pm:   

Yes, that would be the reason.

One of your colleagues would have had to put that script together (it is not something that we would have supplied). It's basically a script that does a lookup against your MNP database to determine how to route the message.

For some reason the script is returning back an indication that the subscriber is local.

Your setup appears to be to route all external MMS messages to an interconnect service. So this script is probably checking one of your internal databases to see if the subscriber belongs to you, and the subscriber still exists in that database. I'd suggest taking a look at the script file on that server (looks like IIS web server) and try to determine what database it is checking against so that it can be updated.

--
Des
NowSMS Support
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 13
Registered: 12-2012
Posted on Tuesday, April 02, 2013 - 04:56 pm:   

I think we found what's causing this. It appears we have a reference to an old inter-carrier service in that script file. We'll try to update that in a maintenance window.

Des, thank you again for all your help in troubleshooting this!