| Routing by service_type Parameter |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through December 23, 2009 ⬆ |
◄ ► |
| Author | Message | |||
| ashot shahbazian Frequent Contributor Username: Animatele Post Number: 67 Registered: 06-2004 |
Hi Des, Bryce We've tried testing routing by service_type. The current task is quite simple: There are two SMSC uplinks, SMSC1 and SMSC2. Both have dest_address routing via Routexxx=+yyy*, but no RoutePrefOnly=Yes setting, which means that the message matching the longer prefix in the list routes through the respective uplink, but if a match is not found messages load-share across two uplinks. We need messages with a specific service_type, SMSC2, to route via SMSC2 uplink only, while all other messages irrespective of the service_type field or its absense should route as before - by longer prefixes, or load-share if there's no prefix or service_type match. Surprisingly, we could not acheve this. Tests have been carried out on a test machine with no dest_address routing: - if we set Route1=service_type=SMSC2 in the SMSC2 uplink definition, messages with service_type=SMSC1 only would route via that uplink, and no other messages would route through it, despite no RoutePrefOnly=yes is set for that uplink - if we set Route1=!service_type=SMSC2 in the SMSC1 definition and set no service_type parameter in the SMSC2 link definition, the messages with any service_type field or without it would submit over SMSC2 uplink only and no messages regardless of the service_type field or an absence thereof would submit on an SMSC1 uplink, as if Route1=!service_type=SMSC2 works as a complete block. - if we set for SMSC2: Route1=service_type=SMSC2 Route2=service_type=* and for SMSC1 uplink: Route1=service_type=SMSC1 Route2=service_type=* messages with either SMSC2 or SMSC1 or any other service_type field would load-share across two uplinks. It is not trying to find a longer match, as it would have with dest prefix routing. Could it be we've misunderstood and are doing it wrong? If not, can you please redo the logic consistent with that for Dest_addr routing? -if there's RoutePrefOnly=yes - route ONLY by exact (with wildcards) matches and exact (with wildcards) exclusions in the lists - if there is no RoutePrefOnly=yes - route by uplinks for matching (with wildcards) parameters but ignore the rule for messages where no matching fields are found. - regardless if it is with or without RoutePrefOnly=yes, or whether it's an inclusion or an exclusion rule - match by the longer matching string. Kind regards, Ashot | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1570 Registered: 08-2008 |
Hi Ashot, I'm trying to understand, but it is challenging. I can confirm that the preferred service type matching looks for any match, not just a best match. We should be able to change this to look for a best (longest pattern) match. I'm just concerned if this has any ramifications to a situation where both service_type and destination number matching is being used. It shouldn't, but I'm not sure 100% how this logic is applied ... or how it should be applied ... so we'll have to look at it more closely. Hopefully it's a simple adjustment. -- Des NowSMS Support | |||
| ashot shahbazian Frequent Contributor Username: Animatele Post Number: 68 Registered: 06-2004 |
Hi Des, I can't see it conflicting with dest_addr routing (as I remember, your approach was to route if dest_addr AND service_type are matching, if both are present.) What's important is not only that you try to find the best (longest) match for the service_type value, but also that the rule should work similarly to dest_addr rule. In other words, in absense of RoutePrefOnly=Yes, routing of messages with non-matching service_type values, or with no service_type value should be allowed via that uplink, and that with a match (or a best match, if other matches are found in other uplinks) would route ONLY though it. WITH the RoutePrefOnly=yes, it should be the opposite: no match - no routing. Also, the "!" option should not prevent routing through the uplink altogether as it does now, but only for messages with a matching value for routing exclusion in service_type. This is what we view as logical and consistent with dest_addr routing in NowSMS. If your view and the implementation is different, it'd be good to know how exactly it works, when it's done and tested. Kind regards, Ashot | |||
