MM4 Connecting to Bandwidth.com

MM4 Connecting to Bandwidth.com SearchSearch
Author Message
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 1
Registered: 02-2020
Posted on Tuesday, February 18, 2020 - 03:41 pm:   

Hi Team,

I am attempting to connect the NOWSMS SMS/MMS Gateway to our provider Bandwidth, but I am not having much luck with configuring this connection.

Has anyone else set-up Bandwidth as a VASP and able to configure under MMSC Routing?

When I attempt to set this up, I get the following error.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6098
Registered: 08-2008
Posted on Tuesday, February 18, 2020 - 05:44 pm:   

Hi Bradley,

What error do you see?

I know we have a few customers that have connections via Bandwidth. I recall one customer having a TLS problem connecting with them last year...but it did not present as an error during configuration.

--
Des
NowSMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 2
Registered: 02-2020
Posted on Tuesday, February 18, 2020 - 05:54 pm:   

Hi Des,

Thank you for the fast reply. I am getting an error that says "Unable to connect to server 67.231.1.16:25"

https://imgur.com/N7hgXpj

I do have my IP whitelisted at the BW side for both origination and termination MM4.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6099
Registered: 08-2008
Posted on Tuesday, February 18, 2020 - 06:15 pm:   

Hi Bradley,

I suspect its a whitelist issue on the BW side. Double check that your outbound IP is as expected, and that Bandwidth has the correct IP for you.

This error message indicates a basic TCP/IP connection failure, so it would seem like a firewall type of issue.

Looking through our support archives, I see another customer connecting to the same IP, so that would seem to be correct.

--
Des
NowSMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 3
Registered: 02-2020
Posted on Tuesday, February 18, 2020 - 06:19 pm:   

Hi Des,

I am using the same IP for SMPP and MM4, I have full visibility to their dashboard where these are whitelisted. I am showing everything correct as far as matching what I have for SMPP which is working as intended. I will do more double-checking.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6101
Registered: 08-2008
Posted on Tuesday, February 18, 2020 - 06:50 pm:   

Hi Bradley,

As a sanity test, you might want to try using telnet to connect to port 25 on that IP. It should respond with an SMTP welcome banner.

Another thought...and this is kind of an odd one...

In the interest of spam prevention, a lot of ISPs block all outbound SMTP connections ... essentially blocking SMTP port 25 completely.

This type of block usually only exists for "residential" accounts...not business accounts. But, considering that no one really hosts their own e-mail servers any more...it might not be a surprise to see a business account with the SMTP port blocked.

I'm not sure if BW supports an alternate port, but it may be worth trying a server address 67.231.1.16:587

--
Des
NowSMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 4
Registered: 02-2020
Posted on Tuesday, February 18, 2020 - 07:30 pm:   

Hi Des,

So another update which I think is in the right direction.

Bandwidth 587 is for TLS, so I did enable this, and the route can now be built, but now I am not able to send/receive any MMS.

Still playing around.
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 5
Registered: 02-2020
Posted on Tuesday, February 18, 2020 - 07:31 pm:   

Also, I do have a message stuck in Queue. When I try to delete, it will not remove, even after refresh it just hangs there.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6102
Registered: 08-2008
Posted on Tuesday, February 18, 2020 - 10:19 pm:   


quote:

Also, I do have a message stuck in Queue. When I try to delete, it will not remove, even after refresh it just hangs there.



This suggests it is locked because it is actively being processed. Assuming the transmission is failing, there will be increased delay between retries, and the message will not be locked.

The UI leaves a lot to be desired...but normally it would not take a long time to process such a message. So it is better to focus on getting the messages flowing.


quote:

but now I am not able to send/receive any MMS.




I don't know anything about the rest of your configuration. Are you setting up an MMSC with local phone subscribers as a mobile operator? Or creating some type of gateway?

MM4 can be a pain to initially configure, but I'd start with sending...which is the direction configured in the MMSC Routing definition.

If MM4 is not the default route for sending, add a destination number to be used for testing in "Route messages to..."

Make sure the "E-Mail Domain" in the MMSC Routing is set to whatever Bandwidth expects. mms-dfw.bandwidthclec.com ?

Also make sure the MM4 domain that they expect you to be using is configured as the MMS domain name in the MMSC settings.

Note that sending a test message with a blank sender will often fail and cause problems. Always set a phone number for the sender when submitting test messages...or set a number as the default sender in the MMS route definition.

For troubleshooting, enable the MMSCDEBUG.LOG and use it to review the MM4/SMTP dialog.

--
Des
NowSMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 6
Registered: 02-2020
Posted on Wednesday, February 19, 2020 - 06:07 pm:   

Hi Des,

Thanks again for the update.

I am setting up with local phone subscribers, just a test number.

The settings appear to be correct. Here is my dialog for a message that just sits in the queue.

18:05:06:041 [17] InitSMTPConnection:
18:05:06:041 [17] WaitForSocketClose: WinSock reported ioctlsocket complete
18:05:06:203 [23] ThreadProcessVASPQ: E9164796.MMS
18:05:06:203 [23] ThreadProcessVASPQ: Message size = 3621
18:05:06:203 [23] ParseMMSContentClass: body part #1 Content-Type = application/smil
18:05:06:203 [23] ParseMMSContentClass: body part #2 Content-Type = image/png
18:05:06:203 [23] ParseMMSContentClass: body part #3 Content-Type = text/plain
18:05:06:203 [23] ParseMMSContentClass: got image
18:05:06:203 [23] ThreadProcessVASPQ: recipArray count = 1
18:05:06:203 [23] ReportOverThreshold: Debug
18:05:06:203 [23] WSPDecodeFile: fileBufferLen=3513
18:05:06:203 [23] WSPDecodeFile: currHeaderLen=38, currBodyLen=3472
18:05:06:203 [23] WSPDecodeFile: application/vnd.wap.multipart.related; start="<2F37586B.smil>"; type="application/smil"
18:05:06:203 [23] WSPDecodeFile: Debug mutlipart - 3 parts
18:05:06:203 [23] WSPDecodeFile: decoding part 1
18:05:06:203 [23] WSPDecodeFile: fileBufferLen=382
18:05:06:203 [23] WSPDecodeFile: currHeaderLen=69, currBodyLen=310
18:05:06:203 [23] WSPDecodeFile: application/smil; name="2F37586B.smil"; charset="utf-8"
18:05:06:203 [23] WSPDecodeFile: Content-ID: <2F37586B.smil>

18:05:06:203 [23] WSPDecodeFile: Content-location: 2F37586B.smil

18:05:06:203 [23] WSPDecodeFile: Test Encoding
18:05:06:204 [23] WSPDecodeFile: decoding part 2
18:05:06:204 [23] WSPDecodeFile: fileBufferLen=3043
18:05:06:204 [23] WSPDecodeFile: currHeaderLen=34, currBodyLen=3006
18:05:06:204 [23] WSPDecodeFile: image/png
18:05:06:204 [23] WSPDecodeFile: Content-ID: <test imae.PNG>

18:05:06:204 [23] WSPDecodeFile: Content-location: test imae.PNG

18:05:06:204 [23] WSPDecodeFile: Test Encoding
18:05:06:204 [23] TestMimeEncode: 8bit
18:05:06:204 [23] TestMimeEncode: 8bit
18:05:06:204 [23] TestMimeEncode: NULL
18:05:06:204 [23] WSPDecodeFile: Content-Transfer-Encoding: base64

18:05:06:204 [23] WSPDecodeFile: Before Encode
18:05:06:204 [23] WSPDecodeFile: After Encode
18:05:06:204 [23] WSPDecodeFile: decoding part 3
18:05:06:204 [23] WSPDecodeFile: fileBufferLen=46
18:05:06:204 [23] WSPDecodeFile: currHeaderLen=32, currBodyLen=12
18:05:06:204 [23] WSPDecodeFile: text/plain
18:05:06:204 [23] WSPDecodeFile: Content-ID: <2F37586B.txt>

18:05:06:204 [23] WSPDecodeFile: Content-location: 2F37586B.txt

18:05:06:204 [23] WSPDecodeFile: Test Encoding
18:05:06:204 [23] WSPDecodeFile: headerLen = 62, contentTypeLen = 55, bodyLen = 310
18:05:06:204 [23] WSPDecodeFile: Content-Type: application/smil; name="2F37586B.smil"; charset="utf-8"
18:05:06:204 [23] WSPDecodeFile: headerLen = 97, contentTypeLen = 9, bodyLen = 4110
18:05:06:204 [23] WSPDecodeFile: Content-Type: image/png
18:05:06:204 [23] WSPDecodeFile: headerLen = 60, contentTypeLen = 10, bodyLen = 12
18:05:06:204 [23] WSPDecodeFile: Content-Type: text/plain
18:05:06:241 [23] InetServerConnect: Connected to 67.231.1.16 (67.231.1.16:587)
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6103
Registered: 08-2008
Posted on Wednesday, February 19, 2020 - 06:38 pm:   

Hi Bradley,

What happens next?

I'm guessing a timeout.

And I'm thinking the fact that we have to use port 587 might be the issue.

Normally, port 587 is used for STARTTLS....the SMTP dialog starts off in plain text...and the client sends a STLS command to negotiate an encrypted TLS session.

Can you TELNET to port 587 and see what happens when you connect manually? There should be an SMTP welcome message...but I am guessing there is not.

--
Des
NowSMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 7
Registered: 02-2020
Posted on Thursday, February 20, 2020 - 03:20 pm:   

Hi Des,

So I have got 25 unblocked, so no longer trying to use TLS. I see the conneciton take place, but just hangs out.

0:19:50:681 [29] InitSMTPConnection: STARTTLS
10:19:50:719 [29] InitSMTPConnection: 220 Ready to start TLS

10:19:50:862 [29] InitSMTPConnection: SSL Connection failed for SMTP server (SSL_connect: Error 14094418 making SSL connection)
10:19:50:862 [29] WaitForSocketClose: WinSock reported ioctlsocket complete
10:19:50:972 [33] ThreadProcessVASPQ: 064D7DEB.MMS
10:19:50:972 [33] ThreadProcessVASPQ: Message size = 3615
10:19:50:972 [33] ParseMMSContentClass: body part #1 Content-Type = application/smil
10:19:50:972 [33] ParseMMSContentClass: body part #2 Content-Type = image/png
10:19:50:972 [33] ParseMMSContentClass: body part #3 Content-Type = text/plain
10:19:50:972 [33] ParseMMSContentClass: got image
10:19:50:972 [33] ThreadProcessVASPQ: recipArray count = 1
10:19:50:972 [33] WSPDecodeFile: fileBufferLen=3505
10:19:50:972 [33] WSPDecodeFile: currHeaderLen=38, currBodyLen=3464
10:19:50:972 [33] WSPDecodeFile: application/vnd.wap.multipart.related; start="<064D7DEB.smil>"; type="application/smil"
10:19:50:972 [33] WSPDecodeFile: Debug mutlipart - 3 parts
10:19:50:972 [33] WSPDecodeFile: decoding part 1
10:19:50:972 [33] WSPDecodeFile: fileBufferLen=382
10:19:50:972 [33] WSPDecodeFile: currHeaderLen=69, currBodyLen=310
10:19:50:972 [33] WSPDecodeFile: application/smil; name="064D7DEB.smil"; charset="utf-8"
10:19:50:972 [33] WSPDecodeFile: Content-ID: <064D7DEB.smil>

10:19:50:973 [33] WSPDecodeFile: Content-location: 064D7DEB.smil

10:19:50:973 [33] WSPDecodeFile: Test Encoding
10:19:50:973 [33] WSPDecodeFile: decoding part 2
10:19:50:973 [33] WSPDecodeFile: fileBufferLen=3043
10:19:50:973 [33] WSPDecodeFile: currHeaderLen=34, currBodyLen=3006
10:19:50:973 [33] WSPDecodeFile: image/png
10:19:50:973 [33] WSPDecodeFile: Content-ID: <test imae.PNG>

10:19:50:973 [33] WSPDecodeFile: Content-location: test imae.PNG

10:19:50:973 [33] WSPDecodeFile: Test Encoding
10:19:50:973 [33] TestMimeEncode: 8bit
10:19:50:973 [33] TestMimeEncode: 8bit
10:19:50:973 [33] TestMimeEncode: NULL
10:19:50:973 [33] WSPDecodeFile: Content-Transfer-Encoding: base64

10:19:50:973 [33] WSPDecodeFile: Before Encode
10:19:50:973 [33] WSPDecodeFile: After Encode
10:19:50:973 [33] WSPDecodeFile: decoding part 3
10:19:50:973 [33] WSPDecodeFile: fileBufferLen=38
10:19:50:973 [33] WSPDecodeFile: currHeaderLen=32, currBodyLen=4
10:19:50:973 [33] WSPDecodeFile: text/plain
10:19:50:973 [33] WSPDecodeFile: Content-ID: <064D7DEB.txt>

10:19:50:973 [33] WSPDecodeFile: Content-location: 064D7DEB.txt

10:19:50:973 [33] WSPDecodeFile: Test Encoding
10:19:50:973 [33] WSPDecodeFile: headerLen = 62, contentTypeLen = 55, bodyLen = 310
10:19:50:973 [33] WSPDecodeFile: Content-Type: application/smil; name="064D7DEB.smil"; charset="utf-8"
10:19:50:973 [33] WSPDecodeFile: headerLen = 97, contentTypeLen = 9, bodyLen = 4110
10:19:50:973 [33] WSPDecodeFile: Content-Type: image/png
10:19:50:973 [33] WSPDecodeFile: headerLen = 60, contentTypeLen = 10, bodyLen = 4
10:19:50:973 [33] WSPDecodeFile: Content-Type: text/plain
10:19:51:010 [33] InetServerConnect: Connected to 67.231.1.16 (67.231.1.16:25)
10:19:51:047 [33] InitSMTPConnection: 220 mms-dfw.bandwidthclec.com Server ready

10:19:51:047 [33] InitSMTPConnection: EHLO 18.232.70.251
10:19:51:083 [33] InitSMTPConnection: 250-mms-dfw.bandwidthclec.com
250-SIZE 5242880
250-STARTTLS
250 Ok

10:19:51:083 [33] InitSMTPConnection: STARTTLS
10:19:51:119 [33] InitSMTPConnection: 220 Ready to start TLS

10:19:51:263 [33] InitSMTPConnection: SSL Connection failed for SMTP server (SSL_connect: Error 0 making SSL connection)
10:19:51:263 [33] WaitForSocketClose: WinSock reported ioctlsocket complete
10:19:51:274 [30] ThreadProcessVASPQ: 064D7DEB.MMS
10:19:51:274 [30] ThreadProcessVASPQ: Message size = 3615
10:19:51:274 [30] ParseMMSContentClass: body part #1 Content-Type = application/smil
10:19:51:274 [30] ParseMMSContentClass: body part #2 Content-Type = image/png
10:19:51:274 [30] ParseMMSContentClass: body part #3 Content-Type = text/plain
10:19:51:274 [30] ParseMMSContentClass: got image
10:19:51:274 [30] ThreadProcessVASPQ: recipArray count = 1
10:19:51:274 [30] WSPDecodeFile: fileBufferLen=3505
10:19:51:274 [30] WSPDecodeFile: currHeaderLen=38, currBodyLen=3464
10:19:51:274 [30] WSPDecodeFile: application/vnd.wap.multipart.related; start="<064D7DEB.smil>"; type="application/smil"
10:19:51:274 [30] WSPDecodeFile: Debug mutlipart - 3 parts
10:19:51:274 [30] WSPDecodeFile: decoding part 1
10:19:51:274 [30] WSPDecodeFile: fileBufferLen=382
10:19:51:274 [30] WSPDecodeFile: currHeaderLen=69, currBodyLen=310
10:19:51:274 [30] WSPDecodeFile: application/smil; name="064D7DEB.smil"; charset="utf-8"
10:19:51:274 [30] WSPDecodeFile: Content-ID: <064D7DEB.smil>

10:19:51:274 [30] WSPDecodeFile: Content-location: 064D7DEB.smil

10:19:51:274 [30] WSPDecodeFile: Test Encoding
10:19:51:274 [30] WSPDecodeFile: decoding part 2
10:19:51:274 [30] WSPDecodeFile: fileBufferLen=3043
10:19:51:274 [30] WSPDecodeFile: currHeaderLen=34, currBodyLen=3006
10:19:51:274 [30] WSPDecodeFile: image/png
10:19:51:274 [30] WSPDecodeFile: Content-ID: <test imae.PNG>

10:19:51:274 [30] WSPDecodeFile: Content-location: test imae.PNG

10:19:51:274 [30] WSPDecodeFile: Test Encoding
10:19:51:274 [30] TestMimeEncode: 8bit
10:19:51:274 [30] TestMimeEncode: 8bit
10:19:51:274 [30] TestMimeEncode: NULL
10:19:51:274 [30] WSPDecodeFile: Content-Transfer-Encoding: base64

10:19:51:275 [30] WSPDecodeFile: Before Encode
10:19:51:275 [30] WSPDecodeFile: After Encode
10:19:51:275 [30] WSPDecodeFile: decoding part 3
10:19:51:275 [30] WSPDecodeFile: fileBufferLen=38
10:19:51:275 [30] WSPDecodeFile: currHeaderLen=32, currBodyLen=4
10:19:51:275 [30] WSPDecodeFile: text/plain
10:19:51:275 [30] WSPDecodeFile: Content-ID: <064D7DEB.txt>

10:19:51:275 [30] WSPDecodeFile: Content-location: 064D7DEB.txt

10:19:51:275 [30] WSPDecodeFile: Test Encoding
10:19:51:275 [30] WSPDecodeFile: headerLen = 62, contentTypeLen = 55, bodyLen = 310
10:19:51:275 [30] WSPDecodeFile: Content-Type: application/smil; name="064D7DEB.smil"; charset="utf-8"
10:19:51:275 [30] WSPDecodeFile: headerLen = 97, contentTypeLen = 9, bodyLen = 4110
10:19:51:275 [30] WSPDecodeFile: Content-Type: image/png
10:19:51:275 [30] WSPDecodeFile: headerLen = 60, contentTypeLen = 10, bodyLen = 4
10:19:51:275 [30] WSPDecodeFile: Content-Type: text/plain
10:19:51:312 [30] InetServerConnect: Connected to 67.231.1.16 (67.231.1.16:25)
10:19:51:348 [30] InitSMTPConnection: 220 mms-dfw.bandwidthclec.com Server ready

10:19:51:348 [30] InitSMTPConnection: EHLO 18.232.70.251
10:19:51:385 [30] InitSMTPConnection: 250-mms-dfw.bandwidthclec.com
250-SIZE 5242880
250-STARTTLS
250 Ok

10:19:51:385 [30] InitSMTPConnection: STARTTLS
10:19:51:428 [30] InitSMTPConnection: 220 Ready to start TLS

10:19:51:572 [30] InitSMTPConnection: SSL Connection failed for SMTP server (SSL_connect: Error 14094418 making SSL connection)
10:19:51:572 [30] WaitForSocketClose: WinSock reported ioctlsocket complete
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6104
Registered: 08-2008
Posted on Thursday, February 20, 2020 - 08:02 pm:   

Hi Bradley,

I'm investigating what the SSL/TLS error means.

In the meantime, edit MMSC.INI and add: SMTPUseStartTLS=No under the [MMSC] header.

--
Des
NowSMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 8
Registered: 02-2020
Posted on Thursday, February 20, 2020 - 10:12 pm:   

Hi Des,

Closer, I am seeing this now. Nothing at the term side yet, but much closer.

6:22:22:753 [26] InternalProcessConnection: Thread started
16:22:22:753 [26] ThreadProcessConnection: Processing connection from 127.0.0.1...
16:22:22:754 [26] ThreadProcessConnection: Got application/vnd.wap.mms-message
16:22:22:754 [26] ThreadProcessConnection: Got m-send-req
16:22:22:754 [26] ThreadProcessConnection: SubmitUser=bshackleford
16:22:22:754 [26] ThreadProcessConnection: TO: 19198668354/TYPE=PLMN
16:22:22:754 [26] ParseMMSContentClass: body part #1 Content-Type = application/smil
16:22:22:754 [26] ParseMMSContentClass: body part #2 Content-Type = image/jpeg
16:22:22:754 [26] ParseMMSContentClass: body part #3 Content-Type = text/plain
16:22:22:754 [26] ParseMMSContentClass: got image
16:22:22:754 [26] CheckLawfulIntercept: C:\PROGRA~2\NowSMS\LawfulIntercept.INI
16:22:22:754 [26] CheckLawfulIntercept: 19198668354
16:22:22:754 [26] MMSRoutingCallback: 19198668354/TYPE=PLMN
16:22:22:754 [26] CheckBlackList: 19198668354
16:22:22:754 [26] CheckBlackListSender:
16:22:22:755 [26] MMSRoutingCallback: 19198668354/TYPE=VASP:Bandwidth DFW
16:22:22:756 [26] DeliverMMSMessage: TO: 19198668354/TYPE=VASP:Bandwidth DFW
16:22:22:756 [26] ParseMMSContentClass: body part #1 Content-Type = application/smil
16:22:22:756 [26] ParseMMSContentClass: body part #2 Content-Type = image/jpeg
16:22:22:756 [26] ParseMMSContentClass: body part #3 Content-Type = text/plain
16:22:22:756 [26] ParseMMSContentClass: got image
16:22:22:756 [26] DeliverMMSMessage: Before MMSLocalIDAdd
16:22:22:759 [26] DeliverMMSMessage: After MMSLocalIDAdd
16:22:22:759 [26] DeliverMMSMessage: TO: 19198668354/TYPE=VASP:Bandwidth DFW
16:22:22:759 [26] DeliverMMSMessage: Found VASP Recip - Bandwidth DFW
16:22:22:759 [26] DeliverMMSMessage-VASP: TO: 19198668354/TYPE=VASP:Bandwidth DFW
16:22:22:760 [26] DeliverMMSMessage-VASP: 19198668354
16:22:22:760 [26] DeliverMMSMessage-VASP: Closing Queued Message Files
16:22:22:761 [23] Debug: Signaled
16:22:22:764 [26] DeliverMMSMessage-VASP: Complete
16:22:22:764 [26] ThreadProcessConnection: Processing Complete
16:22:22:764 [26] WaitForSocketClose: WinSock reported ioctlsocket complete
16:22:22:764 [26] InternalProcessConnection: Thread ended
16:22:22:891 [23] ThreadProcessVASPQ: 4C79509D.MMS
16:22:22:891 [23] ThreadProcessVASPQ: Message size = 69190
16:22:22:891 [23] ParseMMSContentClass: body part #1 Content-Type = application/smil
16:22:22:891 [23] ParseMMSContentClass: body part #2 Content-Type = image/jpeg
16:22:22:891 [23] ParseMMSContentClass: body part #3 Content-Type = text/plain
16:22:22:891 [23] ParseMMSContentClass: got image
16:22:22:892 [23] ThreadProcessVASPQ: recipArray count = 1
16:22:22:892 [23] ReportOverThreshold: Debug
16:22:22:892 [23] WSPDecodeFile: fileBufferLen=69081
16:22:22:892 [23] WSPDecodeFile: currHeaderLen=38, currBodyLen=69039
16:22:22:892 [23] WSPDecodeFile: application/vnd.wap.multipart.related; start="<CC5067DB.smil>"; type="application/smil"
16:22:22:892 [23] WSPDecodeFile: Debug mutlipart - 3 parts
16:22:22:892 [23] WSPDecodeFile: decoding part 1
16:22:22:892 [23] WSPDecodeFile: fileBufferLen=383
16:22:22:892 [23] WSPDecodeFile: currHeaderLen=69, currBodyLen=311
16:22:22:892 [23] WSPDecodeFile: application/smil; name="CC5067DB.smil"; charset="utf-8"
16:22:22:892 [23] WSPDecodeFile: Content-ID: <CC5067DB.smil>

16:22:22:892 [23] WSPDecodeFile: Content-location: CC5067DB.smil

16:22:22:892 [23] WSPDecodeFile: Test Encoding
16:22:22:892 [23] WSPDecodeFile: decoding part 2
16:22:22:892 [23] WSPDecodeFile: fileBufferLen=68611
16:22:22:892 [23] WSPDecodeFile: currHeaderLen=36, currBodyLen=68571
16:22:22:892 [23] WSPDecodeFile: image/jpeg
16:22:22:892 [23] WSPDecodeFile: Content-ID: <Ben-Logo-5.jpg>

16:22:22:892 [23] WSPDecodeFile: Content-location: Ben-Logo-5.jpg

16:22:22:892 [23] WSPDecodeFile: Test Encoding
16:22:22:892 [23] TestMimeEncode: 8bit
16:22:22:892 [23] TestMimeEncode: 8bit
16:22:22:892 [23] TestMimeEncode: 8bit
16:22:22:892 [23] TestMimeEncode: 8bit
16:22:22:892 [23] TestMimeEncode: NULL
16:22:22:892 [23] WSPDecodeFile: Content-Transfer-Encoding: base64

16:22:22:892 [23] WSPDecodeFile: Before Encode
16:22:22:892 [23] WSPDecodeFile: After Encode
16:22:22:895 [23] WSPDecodeFile: decoding part 3
16:22:22:895 [23] WSPDecodeFile: fileBufferLen=44
16:22:22:895 [23] WSPDecodeFile: currHeaderLen=32, currBodyLen=10
16:22:22:895 [23] WSPDecodeFile: text/plain
16:22:22:895 [23] WSPDecodeFile: Content-ID: <CC5067DB.txt>

16:22:22:895 [23] WSPDecodeFile: Content-location: CC5067DB.txt

16:22:22:895 [23] WSPDecodeFile: Test Encoding
16:22:22:895 [23] WSPDecodeFile: headerLen = 62, contentTypeLen = 55, bodyLen = 311
16:22:22:895 [23] WSPDecodeFile: Content-Type: application/smil; name="CC5067DB.smil"; charset="utf-8"
16:22:22:895 [23] WSPDecodeFile: headerLen = 99, contentTypeLen = 10, bodyLen = 93714
16:22:22:895 [23] WSPDecodeFile: Content-Type: image/jpeg
16:22:22:895 [23] WSPDecodeFile: headerLen = 60, contentTypeLen = 10, bodyLen = 10
16:22:22:895 [23] WSPDecodeFile: Content-Type: text/plain
16:22:22:933 [23] InetServerConnect: Connected to 67.231.1.16 (67.231.1.16:25)
16:22:22:972 [23] InitSMTPConnection: 220 mms-dfw.bandwidthclec.com Server ready

16:22:22:972 [23] InitSMTPConnection: EHLO 18.232.70.251
16:22:23:013 [23] InitSMTPConnection: 250-mms-dfw.bandwidthclec.com
250-SIZE 5242880
250-STARTTLS
250 Ok

16:22:23:013 [23] ThreadProcessVASPQ: MAIL FROM:<19196947515/TYPE=PLMN@mms-dfw.bandwidthclec.com>
16:22:23:051 [23] ThreadProcessVASPQ: 250 OK

16:22:23:051 [23] ThreadProcessVASPQ: RCPT TO:<19198668354/TYPE=PLMN@mms-dfw.bandwidthclec.com>
16:22:23:092 [23] ThreadProcessVASPQ: 250 OK

16:22:23:092 [23] ThreadProcessVASPQ: DATA
16:22:23:129 [23] ThreadProcessVASPQ: 354 Start mail input; end with <CRLF>.<CRLF>

16:22:23:283 [23] ThreadProcessVASPQ: 250 Successfully received, id <7e17e2fc-d9c4-4f92-aa32-f5ff1130f3d8>

16:22:23:283 [23] ThreadProcessVASPQ: RSET
16:22:23:321 [23] ThreadProcessVASPQ: 250 State and buffers reseted

16:22:23:321 [23] SaveIniData:
16:22:23:321 [23] ThreadProcessVASPQ: Delete: C:\PROGRA~2\NowSMS\VASPQ\4C79509D.MMS
16:23:54:380 [23] ThreadProcessVASPQ: QUIT
16:23:54:380 [23] ThreadProcessVASPQ: 421 Connection timeout, closing transmission channel

16:23:54:380 [23] WaitForSocketClose: WinSock reported ioctlsocket complete
16:23:54:380 [23] ThreadProcessVASPQ: closing keep-alive connection
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 9
Registered: 02-2020
Posted on Thursday, February 20, 2020 - 10:13 pm:   

Hi Des,

So good news, I think it was an issue with the term provider. My messages are routing to other devices fine.

Now to inbound MM4.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6106
Registered: 08-2008
Posted on Monday, February 24, 2020 - 03:53 pm:   

Hi Bradley,

Any progress on the inbound?

I should have referenced this before, but there is an overview of the settings starting on slide 16 here:

https://www.nowsms.com/techsupport/training/mmsc-interconnection-protocol-mm4

--
Des
NowSMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 11
Registered: 02-2020
Posted on Monday, February 24, 2020 - 08:56 pm:   

Hi Des,

I should have everything good to go per the PowerPoint, but where should these received MMS messages be viewed at? I am looking at received messages via the web portal, but do not see anything.
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 8340
Registered: 10-2002
Posted on Tuesday, February 25, 2020 - 06:02 pm:   

Hi Bradley,

The short answer is that it depends.

The normal message routing for inbound MM4 on an MMSC would be to convert the message to MM1 format and send an MMS notification message using SMS over SMPP.

I'm glad Des referenced that PowerPoint, as slides 31 & 32 provide some explanation of this routing.

In the usual MMSC scenario, you would see the message only as references in the log files.

This is not the only option for how inbound MM4 MMS messages can be routed. Routing options can quickly become overwhelming...but keeping it somewhat simple, each inbound MMS route (MMSC VASP account) has an "MMSC Routing for Received Messages". This allows you to override the standard MMSC processing...converting to another MMS protocol, or "Receive to MMS-IN Directory" stores them in a viewable format that also maps to the 2-way SMS processing.

-bn

Bryce Norwood
Now SMS/MMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 12
Registered: 02-2020
Posted on Thursday, October 29, 2020 - 08:22 pm:   

Hey Team,

I wanted to follow-up on this post as we have "finally", and I say that because this took over a year for our team to purchase out of trial.

I have everything configured for SMS inbound/outbound; however, now, I have outbound MMS over MM4 working, but having trouble setting up inbound.

I feel like I have everything configured correctly; however, I am not having any luck. Is there a way to view inbound MMS via the GUI? When an inbound MM4 message is received, where does it go within NOWSMS?
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 8364
Registered: 10-2002
Posted on Monday, November 02, 2020 - 02:21 pm:   

HI Bradley,

MM4 uses SMTP as a transport protocol.

The other party needs to connect to the MM4/SMTP port configured in NowSMS. Port 25 is the default SMTP port, which is often blocked by default by service providers in an effort to limit email spam.

This document has some good background info on MM4: https://www.nowsms.com/techsupport/training/mmsc-interconnection-protocol-mm4

For troubleshooting MM4 on your side, I'd start by looking at the MMSC-yyyymmdd.LOG for any evidence of connection attempts. These would be either MMSIN or SMTPIN records. An SMTPIN record would most likely indicate a connection from an unexpected IP address, as almost all MM4 connections authenticate by IP address.

The typical setup is multiple "MMSC VASP" inbound account definitions and one outbound. Each inbound needs to have its "MM4 Ack Route" pointing to the outbound route.

Regards,

Bryce Norwood
NowSMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 13
Registered: 02-2020
Posted on Friday, November 06, 2020 - 02:36 pm:   

Hey,

I do have some logs, this is what I am seeing on a recent test:

2020-11-06 09:28:42:781,SMTPIN,67.XXX.XX.XX,mms-lax.bandwidthclec.com,+19199808614,REJECTED,REJECTED-550 Recipient unknown or not local

Does this mean a user is not defined or a route is not correct?
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 15
Registered: 02-2020
Posted on Friday, November 06, 2020 - 02:51 pm:   

After reviewing the slideshow mentiond aboved, I configured per that, and now I am seeing this:

2020-11-06 09:46:51:140,SMTPIN,67.xxx.x.xx,+19198668354/TYPE=PLMN@mms-lax.bandwidthclec.com,+19199808614,REJECTED,REJECTED-550 Recipient unknown or not local
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6191
Registered: 08-2008
Posted on Monday, November 09, 2020 - 07:39 pm:   

Hi Bradley,

That is a very good sign.

You need to have an MMSC VASP account named 67.xxx.x.xx.

It is confusing, but for any IP addresses used by the partner, there must be an MMSC VASP (Inbound) with that IP address as the account name. Once you define this account, these messages should begin to be processed as MMS.

--
Des
NowSMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 16
Registered: 02-2020
Posted on Monday, November 09, 2020 - 08:17 pm:   

Hey Des,

Thanks for the follow-up! This is where I am getting confused is because I feel like I do have it defined accordingly. Since the connection with Bandwidth, no need to redact their IPs any longer as they are made public anyways. But my set-up is like below, and a recent test shows the same error.

2020-11-09 15:12:09:457,SMTPIN,67.231.5.30,+19198668354/TYPE=PLMN@mms-lax.bandwidthclec.com,+19199808614,REJECTED,REJECTED-550 Recipient unknown or not local

https://imgur.com/1aKts8H
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6194
Registered: 08-2008
Posted on Monday, November 09, 2020 - 09:08 pm:   

Hi Bradley,

Those settings do appear to be correct.

And I see the problem now...

Normally in MM4, you have an SMTP domain name that is associated with your subscribers. The MMSC is rejecting the messages because mms-lax.bandwidthclec.com is not the expected domain name.

(As a side note, I'm not sure why the MMSC is picky about this, and I am requesting that our team consider removing this requirement in an update.)

It is very easy to work-around this issue. Edit MMSC.INI and under the [MMSC] header add:

DomainNameAlias1=mms-lax.bandwidthclec.com
DomainNameAlias2=mms-dfw.bandwidthclec.com

--
Des
NowSMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 19
Registered: 02-2020
Posted on Monday, November 09, 2020 - 09:18 pm:   

Hey Des,

I was super hopeful, but still the same thing.

Recent Error:
2020-11-09 16:15:49:398,SMTPIN,67.231.5.30,+19198668354/TYPE=PLMN@mms-lax.bandwidthclec.com,+19199808614,REJECTED,REJECTED-550 Recipient unknown or not local

Here is my MMSC.INI content:

[MMSC]
DomainNameAlias1=mms-lax.bandwidthclec.com
DomainNameAlias2=mms-dfw.bandwidthclec.com
SMTPUseStartTLS=No
SMTPPort=25
RelayHost=
SMSEMail=No
SMSDomainName=
SMSPerEMail=1
SMSEMailSender=
WebPort=8080
HostName=REDACTED
DomainName=mms-lax.bandwidthclec.com
SMTPRequireAuth=No
EnableDeliveryNotification=Yes
ConvertImages=Yes
ConvertScaleToScreen=Yes
Debug=Yes
DefaultOutboundRoute=Bandwidth DFW
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6196
Registered: 08-2008
Posted on Monday, November 09, 2020 - 09:43 pm:   

Hi Bradley,

I'm going to get Bryce to investigate this as he has more experience on the MMS side. He's probably not going to be able to get back to you until tomorrow.

Regards,

Des
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 6197
Registered: 08-2008
Posted on Monday, November 09, 2020 - 10:10 pm:   

And I'm back ...

I ran a few tests and noticed something. The log entry that we have been looking at does not show the complete picture.

+19199808614 is the to address. For some reason, the log entry does not contain the associated domain name ... even when the reason for rejection is an unexpected domain name.

To see what is going on, you need to enable the MMSCDEBUG.LOG. Look for the RCPT TO: command, where I expect that you will see +19199808614/TYPE=PLMN@mms.domain.name

This "mms.domain.name" needs to be configured either in the DomainName or DomainNameAlias# settings.

Most likely, you will just use the DomainName setting and there is no need for the alias settings.

--
Des
NowSMS Support
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 8367
Registered: 10-2002
Posted on Tuesday, November 10, 2020 - 04:52 pm:   

Hi Bradley,

Did the most recent reply from Des help resolve this? I'm fairly confident that this domain name is the issue.

Regards,

Bryce Norwood
NowSMS Support
Bradley Shackleford
New member
Username: Bshackleford

Post Number: 21
Registered: 02-2020
Posted on Tuesday, November 10, 2020 - 05:16 pm:   

Hey Team,

All is working now!

Got the inbound working!

2020-11-10 12:14:18:400,MMSIN,67.231.5.30,VASP:67.231.5.30,+19199808614,0FD9F74367A60000AB500002~sun5x1035034,cd3aaa31.HDR,972147

Here is where the RCPT was too:
RCPT TO:<+19199808614/TYPE=PLMN@mm4.inphomatch.com>

From MMSC.INI
[MMSC]
DomainNameAlias1=mms-lax.bandwidthclec.com
DomainNameAlias2=mms-dfw.bandwidthclec.com
DomainNameAlias3=mm4.inphomatch.com
SMTPUseStartTLS=No
SMTPPort=25
RelayHost=
SMSEMail=No
SMSDomainName=
SMSPerEMail=1
SMSEMailSender=
WebPort=8080
HostName=184.72.118.25
DomainName=mms-lax.bandwidthclec.com
SMTPRequireAuth=No
EnableDeliveryNotification=Yes
ConvertImages=Yes
ConvertScaleToScreen=Yes
Debug=Yes
DefaultOutboundRoute=Bandwidth DFW
Robert Barretto
New member
Username: Barretto

Post Number: 39
Registered: 09-2019
Posted on Friday, December 11, 2020 - 05:04 pm:   

Hi Bradley,

I noticed you have a space character in your DefaultOutboundRoute. You should remove that if you ever plan on using the MMSRoutingURL callback, as the space character can trip up that parser. There's an older thread on here about that where Des and I discussed that ( MM4 Route selection via MM1 parameter? ).

I have integrated Bandwidth to the NowSMS MMSC as well (from both LAX and DFW connectors as well). You don't need the DomainNameAliasX lines, the problem is that your DomainName isn't correct. It's working for you because the last alias3 you added is what's fixing the issue.

You should be able to replace the following MMSC.INI lines:

DomainNameAlias1=mms-lax.bandwidthclec.com
DomainNameAlias2=mms-dfw.bandwidthclec.com
DomainNameAlias3=mm4.inphomatch.com
DomainName=mms-lax.bandwidthclec.com

with just:

DomainName=mm4.inphomatch.com

I have EnableDeliveryNotification=No since the delivery report Bandwidth will return is not the delivery to the end user but rather the successful delivery into the Bandwidth core network. That's not useful for my requirements, so I've disabled those.

I have two VASP accounts defined: BW-DFW-MMS and BW-LAX-MMS. The only difference between the two is the "IP Address Restrictions" field which I assigned to the specific Bandwidth IP for the specific MM4 connector.

IP Address Restrictions: 67.231.1.16 (or 67.231.5.30)
Acception Connections via: MM4 (SMTP)
Allow Sender Address Override is ticked
MM4 Ack Routing: (Default)
MM7 Schema: REL-5-MM7-1-2
3GPP MMS Version: 5.3.0
MMSC Routing for Received Messages: Local MMS Recipients Only


I have two origination MMSC Routing routes defined: origs-bw-mm4-lax and origs-bw-mm4-dfw. The only differences between the two routing definitions is the Server Address IP, which I assigned to the specific LAX/DFW IP, and the E-Mail Doman, which I set to the specific LAX/DFW domain (what you used for DomainNameAlias1 and 2, respectively).

Allow Sender Address Override is ticked
Route message using: MM4 (SMTP)
Server Address: 67.231.1.16 (or 67.231.5.30)
E-Mail Domain: mms-dfw.bandwidthclec.com (or mms-lax.bandwidthclec.com)
Message Format: MM4
Request MM4 Ack: No
3GPP MMS Version 6.10.0
Max Connections: 10
Max Recipients per Message: (default)


There was also an issue with the way Bandwidth was formatting phone numbers in the incoming MM4. They're format is not to spec compliant (they're adding domain in the MMS Address field, which is incorrect). Des' team created a new MMSC load for me to get around this (20190925) since Bandwidth would not change on their end. Since you're getting passed that, I'm assuming you're on a newer NowSMS MMSC load already. There's an old thread on here about that a well ( MM4 to SMPP notification source addr manipulation? ).

Cheers,
//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: