| MM4 Route selection via MM1 parameter? |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ |
◄ ► |
| Author | Message | |||
| Robert Barretto New member Username: Barretto Post Number: 13 Registered: 09-2019 |
Hi, From the link that Bryce gave me (Mobile Number Portability (MNP) Considerations) I see there's an MMS Routing callback function that uses MMSRoutingURL=http://server.name/path to get a route name to use for the outbound side. However, is there a way to have outgoing route selection information alrady in the incoming MM1 message via a Route/MMSCRoute header (or some other equivalent header)? The reason I ask is because my MMS proxy node that is sending the MM1 request to the NowSMS MMS Gateway can provide this information alraedy. It seems unnecessary for that box to send the MM1 request to the NowSMS MMS Gateway only for the NowSMS MMS Gateway to turn around and have to query another server to determine the route selection via the MMSRoutingURL, when that information could have been provided in the original MM1 request. I saw this older thread related to outgoing MMS route selection (Select MMS Route when sending MMS) but it looks more these are HTTP specific requests for generating an outgoing MMS. My incoming MM1 message, is HTTP but it doesn't include all the fields listed in the code samples from that thread (e.g., there's no MMSSubject, MMSFile, MMSFrom, etc headers in the MM1 message). The only HTTP headers I see in the MM1 message are: Accept: */*, application/vnd.wap.mms-message, application/vnd.wap.sic Accept-Language: en-GB, en-US User-Agent: g013c x-wap-profile: http://www.gstatic.com/android/sms/G013C.xml Content-Type: application/vnd.wap.mms-message Content-Length: 16989 Host: 37.x.x.x Connection: Keep-Alive X-MSISDN: +1214555xxxx X-WAP-3GPP-SGSN-MCC-MNC: 310xxx Accept-Encoding: gzip ... Is it as simple as adding "MMSCRoute: some-mm4-routename" to this request and this can work? Thanks, //Robert | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 6059 Registered: 08-2008 |
Hi Robert, There is no support for routing to be included in the MM1 request. -- Des NowSMS Support | |||
| Robert Barretto New member Username: Barretto Post Number: 14 Registered: 09-2019 |
Bummer. So I should just set up the MMSRoutingURL in the MMSC.INI file to point to the location of a server that can respond with 200OK with Route=xxxxxxx in the message body? Two follow up questions. 1. Can the NowSMS MMS Gateway do any sort of number manipulation/replacement for destination digits? For example, stripping off prefixes? 2. Does the MMSRoutingURL get executed for all incoming messages, regardless of the interface and whether or not the MMS User is known? Scenarios: 1. MMS termination (i.e., VASP MM4[MMS_forward.REQ] in -> SMPP[MMS m-notification-ind] out) to a known MMSC User. Does the MMSRoutingURL still get run, since the gateway knows the subscriber, does it just go out the SMSC connection? 2. MMS termination (i.e., VASP MM4 in -> SMSC out) to an unknown MMSC User. The Now SMS MMS Gateway executes the MMSRoutingURL to get the route to use (the remote script will return the same SMSC route name as scenario 1). 3. MMS origination (i.e., MM1[m-send-request] in -> MM4[MMS_forward.REQ] from a known MMSC User (i.e., X-MSISDN header in MM1 has subscriber number). The MMSRoutingURL runs to pick the correct outbound VASP MM4 link. The reason I ask this second one, is because I really don't have a routing decision to make for terminations, anything coming in from any VASP MM4 interface just needs to route out the one and only SMSC interface defined on the NowSMS MMS Gateway. So, implementing the MMSRoutingURL script to just return the SMSC connection name would be trivial. However, for MMS originations (i.e., coming in via HTTP-enriched MM1 request), these may have to select a specific VASP MM4 provider. It looks like there's only one MMSRoutingURL hook, so it seems like that means the same backend script has to known orig vs termination, which can be determined by the VASPIN parameter? Does this make sense? Thanks! //Robert | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 6060 Registered: 08-2008 |
Hi Robert, A1. - Yes, but limited. Search on MSISDNRecipientPrefixConvert for examples. A2. - If ForceRoutingCallback=Yes is set, yes. Otherwise the callback is skipped for known users. B1. - If ForceRoutingCallback=Yes, callback still occurs. B2+B3. - Correct. Yes, your logic will in many cases be dependent on the VASPIN parameter. For example, if VASPIN is set, and the recipient does not belong to you, you will want to respond with Route=BlockMessage. But if VASPIN is not set, you want to route the message via MM4. (That said, if you don't block in this scenario, circular routing should be detected to reject the message. For that matter, there is also a VASP account setting "local MMS recipients only" which prevents any messages received inbound from this connection from getting routed to any external connection.) I fear my explanation is making this seem even more complicated...so let me take a step back to explain the central issue. Are you going to provision your subscribers in the MMSC? If yes, there is no need for a routing callback. There is an HTTP API that can be used to add/delete accounts as necessary. There is also the ability to provision on first send (which still leaves the scenario of what happens if a number is ported away from your service). In most cases, you do not want to maintain this extra provisioning, and this is where the routing callbacks are needed. At a minimum, the callback should return Route=Direct for your numbers, Route=BlockMessage for anything you want to block (international?), and Route=MM4RouteName for externally routed. This assumes "local MMS recipients only" is set for the inbound MM4 connection. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 6061 Registered: 08-2008 |
P.S. - Please avoid space characters in route names, as there is an issue parsing the callback response for these routes. | |||
| Robert Barretto New member Username: Barretto Post Number: 15 Registered: 09-2019 |
Hi Des, I'll search on MSISDNRecipientPrefixConvert for more info. I have updated my route names to not have spaces in them. Thanks for the that heads up. Is the same thing needed for the VASP names? I have spaces in those too. Only place I see those are in the log files "VASP: xxxx", so it looks like those Account Names aren't an issue. As far as adding subscribers... I'm not manually adding subscribers in the MMSC. In the MMSC.INI file I have MSISDNHeader=X-MSISDN, and for MMS originations my MMS proxy has added the necessary X-MSISDN header in the HTTP POST[MM1], and the NowSMS MMS Gateway automatically adds that number into the MMSC subscriber database and allows the message to go out the MM4 VASP route. This doesn't help for the case where we're receiving an MMS termination for a subscriber that has never originated an MMS (which means they aren't a known user on the MMSC yet). Although, if there is an API to add/remove users, we do have a centralized provisioning interface that could call that API to add the user number on intitial onboarding of a subscriber, and then remove that user number on deleting of the subscriber. That can't be added immediately, so it would be a longer term activity on our end, but is definitely worth looking at. However, it looks like your recommending, don't add users at all, and just use the callback routing hook to return Direct/BlockMessage/<some-mm4-route-name>. One final thing. I have two VASP inbound MM4 accounts defined (they're for the same MMS provider, just from different IPs as they have two MM4 servers that can deliver inbound messages to us). Both of those have "MMSC Routing for Received Messages" set to "Force vid Defined Route: Direct Delivery". Is this incorrect? My full set up is in another thread (MM1 to MM4 routing config). Have I configure anything improperly, or against best practices? Cheers, //Robert | |||
| Robert Barretto New member Username: Barretto Post Number: 16 Registered: 09-2019 |
Hi Des, Is there a specific was to make sure the MMSC sees updates to the MMSC.INI file? I've been going to the Service tab, then clicking 'Stop' for both SMS and MMSC services. Then I close the GUI by clicking "OK". It then prompts me that "Service it not active, do you wish to activate the service?" I select no. Then I re-start the GUI by double-clicking the Now SMS Gateway icon, and then click 'Start' for SMS Gateway Service, and "Run as a service" for MMSC Service, and that gets everything back in the "Service is Active, All Connections OK" state. I'm asking because I added: ForceRoutingCallback=Yes MMSRoutingURL=http://37.x.x.x/tango but I didn't see my hook getting called in either direction. I'm just assuming I've done something dumb. :) Cheers, //Robert | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 6062 Registered: 08-2008 |
Hi Robert, With very few exceptions, any changes should be activated within a minute or two. Make sure the settings are under the [MMSC] section header in MMSC.INI. (And make sure you're editing MMSC.INI, not SMSGW.INI, as that's usually where I make a mistake.) If everything looks correct and you don't see an obvious problem, we have occasionally encountered strange directory/file security issues where Windows creates a user-specific copy of the configuration file. When you edit the file, it edits a "virtual store" copy. To rule this out, open a command prompt window, cd , to go to the root, and then use the command dir /s mmsc.ini to scan for files with this name. In the case of this particular problem, the copies will be under a directory named VirtualStore. -- Des NowSMS Support | |||
| Robert Barretto New member Username: Barretto Post Number: 17 Registered: 09-2019 |
Hi Des, So you're sayiiing I don't need to stop/start the MMSC to see changes to the MMSC.INI file? I just neeeed to edit the file and wait a few minutes for the change to be seen? I was definitely in the MMSC.INI file in the [MMSC]. I put my lines at the end of the section, but before the [Outbound MMS Routing] section (which is empty). I did the dir /s command and the only file that came back was the one in "C:\Program Files(x86)\NowSMS", so luckily there's no strangeness on that front. I removed the lines the last time I stopped/started the NowSMS MMSC Gateway because I wanted to try a test of an incoming MMS for a unknown subscriber. I was expecting the incoming message to not be delivered, since the "to" digits were not in the MMSC Users list, but it did. The user digits used to be in the system (i.e., I made an MMS origination with X-MSISDN header, and the MMSC added my user to the system) but I went to the MMSC Users tab and deleted that subscriber number. It didn't tell me I had to restart or wait, after I deleted the subscriber, so I assumed it was an immediate change. Perhaps it's routing because my VASP Account is configured as "Force via Defined Route: Direct Delivery" and not "local MMS recipients only"? I actually want to try the billing callback hooks first, since that's higher priority for me right now, but I wanted to make sure I had the correct procedure for activating changes in the MMSC.INI file. Cheers, //Robert | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 6063 Registered: 08-2008 |
Hi Robert,
Yes, that is it. Sorry that I missed that earlier question...I had never thought of using that setting in this way. There is definitely an overuse of the word force here, but this particular force setting is stronger than ForceRoutingCallback=Yes, and takes precedence. | |||
| Robert Barretto New member Username: Barretto Post Number: 18 Registered: 09-2019 |
Ah ok. I was wondering if that might not be the case. Would you recommend that I not have the "Force via Defined Route" option selected (e.g., is that against best common practices?) We actually have another node in the network that will apply routing policy to the incoming message, so always routing inbound MMS messages to our policy engine is totally ok, as oppose to the MMSC pre-checking for known subscribers. I just don't want to go against the standard way of configuring the MMSC, if there is a standard way of doing things, as it looks pretty flexible with all the available options in the GUI. Cheers, //Robert | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8337 Registered: 10-2002 |
Hi Robert, Des asked me to review this. We would not recommend using the "Force via Defined Route" setting in this case. We actually never considered this setting as being potentially useful in this scenario. The setting exists primarily for situations where protocol conversion is the primary application. We'd typically recommend "Local MMS recipients only" (or standard)...and using a routing callback. -bn Bryce Norwood Now SMS/MMS Support | |||
| Robert Barretto New member Username: Barretto Post Number: 21 Registered: 09-2019 |
Hi Bryce, Understood. In our configuration, we are essentially just converting MM4 to SMPP for all incoming MMS terminations, and SMPP to MM4 for all MMS originations. That being said, I'd rather have things configured in your recommend way. I have changed both my MM4 VASPs from "Force via" to "Local MMS recipients only". I've also configured MMSAccountingURL and MMSRoutingURL in the MMSC.INI file. I did not add ForceRoutingCallback=Yes, so for terms it's only calling my routing check for unknown subscribers. Everything is still working great, so I'm glad I was able to migrate to a standard configuration with no issue. Cheers, //Robert | |||
