| Number portability management |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through April 05, 2007 ⬆ |
◄ ► |
| Author | Message | |||
| Xavier Berger New member Username: Xberger Post Number: 1 Registered: 10-2006 |
The question is: How do we configure the MMSC to handle users with a number which has been moved from one operator to an other? Here are 2 scenarios with a proposal of configuration and associated questions: Situation: OP1 phone number begin with +44123 – This is the operator where MMSC is implemented OP2 phone number begin with +44987 Use case 1: A customer from OP2 comes to OP1 and keeps his mobile phone (+44987654321). If we provision the phone number in the database, it will be able to receive MMS from OP1 users and send MMS from his handset. For other users with OP2 MSISDN, we will create a route to OP2 MMSC with the filter +44987* Questions: - Is this use case OK? - If yes, could you confirm that we can set filter for OP2 to +44* ? ( It will be useful for second use case) Use case 2: A customer from OP1 goes to OP2 and keeps his mobile phone (+44123456789). We remove this user from the database. So the default rule will be applied on this MSISDN: The +44* route and the MMS will be redirected to OP2 MMSC. Questions: - Is this use case OK? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6646 Registered: 10-2002 |
Hi Xavier, For maximum flexibility in these types of scenarios, you would need to implement the MMSRouting callback. This may or may not be required for your specific use cases above. I'll work through them shortly in this reply ... and then I'll describe the MMSRouting callback. Use case 1: If you add "+44987654321" to the "MMSC Users" list, then a message to this phone number will get routed via MMS direct delivery. No other routing logic will be applied. So if you have a route defined with a filter of "+44987*" or "+44*", it would not be applied because the user is registered with the MMSC locally. Use case 2: Technically, this would work. But it may have unintended consequences. Here are consequences that you should consider (there may be more, but these are what come to mind): 1.) You need to ensure that all of your users are registered with the MMSC, otherwise messages will get routed to the other MMSC. 2.) Any messages addressed to an invalid recipient will be routed to the other MMSC. MMSRouting Callback This callback is designed to support configurations in environments with number portability, where number portability queries can be resolved by querying an external database or service. The MMSRouting callback is an HTTP-based routing callback for dynamic routing of MMS messages. When the MMSC receives a message, it will connect to a configurable customer-provided 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. The MMS routing callback URL is defined in the MMSC.INI file, under the [MMSC] section header: MMSRoutingURL=http://server.name/path 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 address VASPIN=VASPname (present if the message was received via a specific account defined in the "MMSC VASP" list) To=RecipientPhoneNumber Example: http://server.name/path?Type=MMSRouteCheck&From=%2B1234567&VASPIN=test&To=%2B999 9999999 (Note: The "%2B" in the above examples is 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: Route=xxxxxxx "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 "BlockMessage" to indicate that the message should be rejected ("Unsupported recipient" error returned to the sending device). 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: Route=xxxxxxx:yyyyyy:zzzzzz In this case, the message could be routed through any of the listed routes. Important: There is a bug in releases prior to 2006.04.26, where if the callback returns "Direct", the MMSC will still apply its default routing logic ... so the "Direct" response from the callback does not override a routing definition based upon a filter. This bug was fixed in releases dated 2006.04.26 and later. -bn | |||
