MM1 to MM4 routing config

Author

Message

Robert Barretto
New member
Username: Barretto

Post Number: 9
Registered: 09-2019

Posted on Friday, September 27, 2019 - 05:02 pm:

Hello,
I'm trying to test an MMS origination (via MM1) out to a MMS carrier (via MM4). Right now, I see the MM1 come in with the required X-MSISDN header. I see the MMSC add the user to the MMSC Users automatically (if not there). After the incoming MM1 request is processed at the MMSC, I see the MMS[m-send-conf] response go back. The next thing I see is a WAP push go back out to my SMSC connection route, but I'm wanting the MMS to go out the MM4 link to the carrier MMS provider.

I'm sure it's some really simply thing I'm missing, but I don't know what it is. Unfortunately, I don't know which information to provide to help debug this.

I'll go by tabs, and hopefully something with pop out:

Tab SMSC Connections:
o one connection defined:
o da1-emg-smsc
o server host name: 37.x.x.x
o server port: 2778
o SMPP version: 3.4
o User Name: xxxxxx
o Password: xxxxxx
o Allowed Sender Address Override is grayed out but checked.
o Routing: Support any outboud message traffic is checked but no preferred connections listed.

Web Tab:
o port: 8800
o all check boxes checked (I assume these were defaults, I don't remember changing any of these, but I guess it's possible)

2-Way tab:
o Process Received SMS Messages is checked.

E-mail tab:
o Function as an SMTP Mail server is checked
o Enable SMTP Smart Mailer is checked

MMSC tab:
o Activate MMSC Service is checked
o HTTP Port Number: 80
o SMTP Port Number: 25
o Enable MMS Delivery Receipts is checked
o Enabled Dynamic Image + Audio Conversion is checked, Screen Size scale radio button is selected

MMSC Users tab:
o contains my originating subscriber as both MSISDN and +MSISDN

MMSC VASP tab:
o Three of these. The carrier MMS has two inbound MM4 links, so one for each of those. The only difference is IP address restrition IP and name of the VASP:
o Account Name: xxxx DFW MMS
o IP address restrictions: x.x.x.x
o Accept Connections via: MM4 checked
o Allow Sender Address Override is checked
o MM4 Ack Routing: (Default)
o MM7 Schema: Rel-5-MM7-1-2
o 3GPP MMS Version: 5.3.0
o MMSC Routing for Received Mesages: Force via Defined Route: Direct Delivery
o The last VASP is my mobile network, don't know if this is right:
o Account Name: mobile
o IP addresss restrictions: 37.x.x.*
o Accept Connections via: MM1 (EAIF)
o Allow Sender Address Overrid is checked
o MM4 Ack Routing: Grayed out but set to (Default)
o MM7 Schema: Rel-5-MM7-1-2
o 3GPP MMS Version: 5.3.0
o MMSC Routing for Received Mesages: Receive to MMS-IN Directory

MMSC Routing tab:
o Default Route is set to one of my two "Additional Routes"
o Route 1:
o Account Name: origs-provider mm4
o Default Sender Address: Tango
o Allow Sender Address Override is checked
o Route messages using MM4(SMTP)
o Server Address: x.x.x.x
o E-Mail Domain: mms-dfw.x.x
o Message Format: MM4
o Request MM4 Ack: Yes
o 3GPP MMS Version: 6.10.0
o Max Connections: 1
o Max Receipients per Message: (default)
o Route 2:
o Account Name: terms-emg-smsc
o Default Sender Address: 37.x.x.x:2778
o Route messages to this account for receipient phone number(s): *
o WAP Push with Web Link

That's all I have. In the MMSC debug logs, prior to having the MSISDNHeader and MSISDNHeaderGateways in the MMSC.INI file, I would see the following log when attempting an origination:

2019-09-27 07:18:36:600,MMSIN,37.x.x.x,,,User Not Defined,FAILED

After I configured the MMSC to look for X-MSISDN, I now see the message at least not get rejected:

2019-09-27 07:37:55:172,MMSIN,37.x.x.x,+146955xxxxx,+146955xxxxx,20190927-07-202C4130@37.x.x.x,0919316F.REQ,25390

My network is set up and flows I want look like:

Termination flow (PSTN->Mobile):
[Carrier MMS Provider]--MM4-->[NowSMS MMSC]--SMPP-->[MSG Router]--SMPP-->[Mobile Network]--MAP-->[Mobile Device]

Mobile device auto connects directly to the NowSMS to download MMS contents and all message content automatically shows in the native message app on the phone.

Desired Origination Flow (Mobile->PSTN):
[Mobile Device]--MM1-->[MMS Proxy]--MM1-->[NowSMS MMSC]--MM4-->[Carrier MMS Provider]--MMx-->[Terminating Network]

What I'm seeing for origination flow is:
[Mobile Device]--MM1-->[MMS Proxy]--MM1-->[NowSMS MMSC]--SMMP[WAP push]-->[MSG Router]--SMMP-->[Mobile Network]

Message is then dropped by the [Mobile Network] because the terminating number isn't owned by this network.

If I do Mobile->Mobile the above flow is the same except that the WAP Push does make it to the terminating mobile device. The push message shows as a regular SMS message with a download link hosted on the NowSMS web server. This isn't as good a user experience, because the MMS content is only fully visible by going to the web page view link on the NowSMS, not in the phone native messaging application.

Hopefully this all makes sense. I can provide any other information that I might have inadvertantly omitted.

Thanks!
//Robert

Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6053
Registered: 08-2008

Posted on Monday, September 30, 2019 - 07:19 pm:

Hi Robert,

In most likelihood, you are going to want to implement a routing callback...EVENTUALLY...it is not necessary right now. But without it, subscriber MMS will not be routed properly until they send an MMS or are manually provisioned to "MMSC Users".

When you send the MMS, I see that you are sending from +146955xxxxx to +146955xxxxx.

I'm assuming these are not the same number. If they were, the MMSC is going to see the number is local (added to MMSC Users) and is going to process it locally.

It seems that you are saying that the message gets converted to a WAP Push with a web link.

This setting under route 2 is why:

Route messages to this account for receipient phone number(s): *

This means use it as a default route. Remove the *

Ultimately, you're going to want to do implement a routing callback, where the MMSC sends an HTTP request to a small app that you provide which returns the route that should be used (or rejects with an error). See https://www.nowsms.com/doc/mmsc-messaging-server/operator-mmsc-considerations/mo bile-number-portability-mnp-considerations

--
Des
NowSMS Support

Robert Barretto
New member
Username: Barretto

Post Number: 10
Registered: 09-2019

Posted on Monday, September 30, 2019 - 08:55 pm:

Hi Bryce,

Thanks for the reply. Yes, the two numbers are different. I did a poor job of anonymizing the real numbers and made them look like the same number. Definitely not trying to message myself. Sorry for the confusion on that. Thanks for the link, I'll look into routing callback.

I removed the * from the terms-emg-smsc route and that prevents the looping back, and I see that it picked the orig-provider mm4 to send it out.

2019-09-30 12:30:40:405,MMSIN,37.x.x.x,+146963xxxxx,+121472xxxxx,20190930-12-07A99057@37.x.x.x,VASP:origs-provider mm4,16942

2019-09-30 12:30:40:673,MMSOUT,VASP:origs-provider mm4,+146963xxxxx,+121472xxxxx,OK,20190930-12-07A99057@37.x.x.x,23827

According to SMTP messaging, I see the message going out via MM4:
...
.
250 Successfully received, id <7b0651a3-c18d-49d7-8b2d-8e02a5d599d2>
RSET
250 State and buffers reseted
421 Connection timeout, closing transmission channel
QUIT
...

although the message never arrives on my terminating phone. Could be an error on the provider side for this.

Only thing I notice that could be an issue is that the MMS message data arrives (via MM1) over many 1500 byte TCP packets, when the NowSMS sends the MM4 message out, it sends it as two giants fragments (14,654 byte packet, followed by a 9,281 byte packete). Both of these are way passed the MTU of 1,500 bytes. Do you think this could be an issue? I'm assuming since the far end SMTP server sent back "250 Successfully received" that wouldn't be an issue, although the "421 Connecttion timeout, closing transmission channel" is a little disconcerting. Although that might be perfectly acceptable.

Thanks!
//Robert

Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6054
Registered: 08-2008

Posted on Monday, September 30, 2019 - 09:17 pm:

Hi Robert,

The MTU sizes are generally handled by the TCP stack. I'm not sure about MM4, but I know with MM1 we pass more than 1500 bytes at a time to the TCP stack.

The "421 connection timeout" error is because by default we keep the MM4 connection open for some period of time, and reuse the connection if there are more messages. It looks like the default timeout is 90 seconds. If the timeout passes with no more messages, we try to send QUIT.

There is a config file in VASPOUT/name/VASP.INI that allows tuning. UseKeepAlive=No will force a disconnect after each message. KeepAliveTimeout=## will adjust the timeout in seconds. 90 is arguably to high, and 5 to 10 is more realistic.

I'm more concerned that the message is not getting delivered. That probably needs a discussion with your provider.

--
Des
NowSMS Support

Robert Barretto
New member
Username: Barretto

Post Number: 11
Registered: 09-2019

Posted on Friday, October 04, 2019 - 10:35 pm:

Hi Des,

I opened a ticket with our MMS provider to look into the problem, and they're still investigating it on their end. My trial license is going to expire this weekend. Is there a way to get another 30 days trial period while I'm waiting for them to address the issue on their end?

On the serial tab I have an installation reference code of: B9E03FB8

Thanks!
//Robert