The NowSMS MMSC implements a dynamic MMS routing callback facility for environments where more advanced MMS routing capabilities are required.
The standard NowSMS MMSC configuration allows for MMS routing based upon phone number prefixes. However, in MNP environments, it may be necessary to query a database to determine how to properly route an MMS message.
Dynamic MMS routing callbacks also allow for MMS routing control based upon who submitted the MMS message. For example, it may be desirable to block MMS sending to international destinations for some or all MMS VASP accounts.
Here’s the text that I usually cut and paste when people ask how to implement the dynamic MMS routing callback:
When the MMS Routing callback is enabled in NowSMS, each time the MMSC receives a message, it will connect to a configurable customer-provided routing callback URL, passing the message recipient to the URL. The customer provided URL can return a response to indicate that the message should be routed via a specific route defined in the “MMSC Routing” page of the NowSMS configuration dialog, or the response can indicate that the message should be rejected.
The MMS routing callback URL is defined in the MMSC.INI file, under the [MMSC] section header:
The variables listed below will be added to the MMSRoutingURL when the URL is executed by the gateway as HTTP GET (CGI-style) parameters.
Type=MMSRouteCheck (Note: Future “Type” values may be added in the future.)
From=SenderPhoneNumber or e-mail addressVASPIN=VASPname (present if the message was received via a specific account defined in the “MMSC VASP” list)
(Note: The “%2B” in the above examples is standard URL escaping for the “+” character.)
To specify which of the routes defined in the “MMSC Routing” list should be used to route this message, the URL must return a standard HTTP 200 OK response, and include the following text somewhere in the response:
“xxxxxxx” should match an “Account Name” defined in the “MMSC Routing” list, or it can use the predefined values of “Direct” (signifying MMSC Direct Delivery), “WAPPush” (signifying “Convert to Multimedia WAP Push”), or “Deny” (signifying the MMSC should reject the message).
If it is possible to route the message via one of several defined routes, multiple routes can be returned in the response, separated by “:”. For example:
In the above case, the message could be routed through any of the listed routes.
Although that explanation is fairly complete, we’re frequently asked for an example.
Examples can be helpful. But we’ve always been hesitant to provide an example because this routing callback script runs on a separate external web server. That means that the script can be written in whatever web development environment the customer is most familiar with. For example, it could be PHP, ASP, Perl, Ruby on Rails, or numerous other environments.
A PHP example routing callback script is avaialble at the following link: http://www.nowsms.com/download/mmsroute-php.txt.
There is an additional consideration for MNP.
In a typical operator MMSC configuration, new MMSC user accounts are automatically provisioned the first time a user sends an MMS message. This configuration is detailed in the section titled NowSMS MMSC Operator Considerations.
A problem scenario develops if a subscriber moves their number from this operator to another operator, after they have already been provisioned on the MMSC. The MMSC will see the user account and attempt to deliver the MMS message directly, without performing a routing lookup.
To address this scenario, an additional MMSC configuration parameter exists. Under the [MMSC] header or MMSC.INI, add the parameter ForceRoutingCallback=Yes. This setting will cause the routing lookup to always occur.
(Note: Prior to the 2009-06-30 release, the setting DisableMMSDirectDelivery=Yes was recommended to address this issue. This setting name sounds contrary to the intended purpose, and was originally added to NowSMS for a different purpose, but it does have the side effect of always forcing the routing callback. We no longer recommend the use of DisableMMSDirectDelivery=Yes for this purpose, and instead recommend the ForceRoutingCallback=Yes setting. This is because DisableMMSDirectDelivery=Yes has an extra side effect of disabling the automatic version tracking of MMS clients. Because the MMS read receipt format was not introduced until OMA MMS v1.2, this can cause some clients to generate read receipts as regular MMS messages instead of using the read receipt format.)