| Direct routing v.s. routing callbacks |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through July 28, 2006 ⬆ |
◄ ► |
| Author | Message | |||
| Janek Shein New member Username: Janek Post Number: 3 Registered: 04-2004 |
Hi. I have an issue with numbers that are present in the userlist, but are physicsally outside our network. When i try to send a message to one of such users MMSC does not even try a routing callback and because of that messages get sent to the wrong place. My question would be: how to solve this situation? A temporary workaround would be to flush the user database completely once in a while. Or a more elegant solution - to delete these users from the mmsc via admin interface, but unfortunately this cannot be done at the moment, since nothing is generating such events. What would be really nice is a configuration parameter a'la "allwaysaskroutingcallback=true" or something like that, which puts the routing callback's priority before the local userlist. Is there something like this? Also there is a case with the default routing. When i set it to 'Reject' and then try to override it with a 'Direct' reply from the routing callback it still gets Rejected. Also if i make an Outbound route which leads into 'Direct Delivery' it still gets rejected. Here the idea is to reject the messages that routing backend can't figure ot where to send or just plain crashes. At the moment i just have a DROP Outbound Route which is a 'Reject' target as a workaround. Is this behaviour really meant to be this way? Currently using: NowMMSC 5.51d (20050809) Thanks in advance. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5727 Registered: 10-2002 |
Hi Janek, On the first issue, try editing MMSC.INI, and under the [MMSC] header, add DisableMMSDirectDelivery=Yes. This recommendation definitely may sound illogical based upon the parameter name, but I've done a lot of checking with regard to what this parameter actually does. The parameter was added for configurations where people were using NowSMS as the e-mail to MMS gateway. To enable e-mail to MMS for a particular recipient, you can add them to the "MMSC Users" list. But when you do this, NowSMS then assumes that they are a local user for the MMSC and that NowSMS should always act as an MMSC for that account. The "DisableMMSDirectDelivery=Yes" setting was added to address this type of configuration. However, behind the scenes, what this setting actually does is disable the internal check during the message delivery process to determine if a message recipient is a local user to the MMSC. In your configuration, this would cause the MMSRoutingCallback to always be called, even if the recipient is registered as an MMSC user. In other words, it would have the same effect as the "alwaysaskroutingcallback=true" setting that you have suggested. I don't have as good of an answer for your 2nd question. There's definitely a problem here. The "Reject/BlockMessage" route as a default appears to take precedence over the callback. We will have to investigate this issue further. In the meantime, the drop route appears to be a good work-around. -bn | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5729 Registered: 10-2002 |
Hello again Janek, I've done some more testing on the second issue. Basically, the routing callback does not properly co-exist with the "Default Route" setting. If you are using an MMS routing callback, then you should set the "Default Route" to "Direct Delivery (internal MMSC)". In this configuration, the MMS routing callback should always determine the routing. You should not attempt to use a mix of the routing callback and any routing instructions in the MMSC. The problem that you are experiencing is that if the routing callback returns "Direct", the MMSC then will later perform a second check based upon the routing configuration in the MMSC. (If the routing callback returns any other value than "Direct", this second check is not performed.) I hope that explanation makes sense. If not, please feel free to ask any questions that might help clarify. We are currently doing tests to verify that for future versions, we can safely remove this secondary routing check and avoid this confusion. -bn | |||
| Dziugas Baltrunas New member Username: Menulis Post Number: 4 Registered: 02-2006 |
I have a similar issue with MMS routing callbacks. What Route=?? should I return in case of recipient is invalid, i.e. +666 or something like that? Janek was mentioning a workaround to create "Reject" rule, however, are there any other solutions? I also want to figure out, what will hapen in case MMS has multiple recipients and only for one of them MMS routing callback will return some kind of "Reject"? How many PreAuth callbacks there gonna be? Thanks, Dziugas | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5732 Registered: 10-2002 |
Hi Dziugas, The simple answer is that you can return "Route=BlockMessage". This does not require that any additional route be defined. It is also possible to define a route with a routing of "Block/Reject Message" and return Route=routename for this defined route, which is what I believe Janek did. Either approach will have the same effect. The problem that can occur is that if you use routing callbacks, confusion can occur if you also define "Default route", or define any of the routes with recipient phone numbers to route via the route. If your callback returns "Direct" (or a route that is defined as "Direct Delivery (internal MMSC)", then after the callback, the MMSC will also perform its own route check which could override the callback. My advice, if you are using the routing callback is to have the callback ALWAYS return the routing information. Leave "Default Route" as "Direct Delivery (internal MMSC)", and do not define any recipient phone number masks in any of the defined routings.
There will be multiple routing callbacks, but only one PreAuth with a comma delimited list of recipients in the "To=" parameter. (Except for a message received via an MM4 connection. This is slightly different because the protocol is different. Here, there is one PreAuth for each recipient.) -bn | |||
| Janek Shein New member Username: Janek Post Number: 4 Registered: 04-2004 |
No, this explanation is perfectly clear. Thanks. I think I will revert to Route=BlockMessage instead. I have no reason to have a route duplicating existing functionality. | |||
