Hi Juan, That is an interesting approach. Are you saying that if a bind has an smsc-id of "bind-a" but I add allowed-smsc-id with a value of "bind-b" then only messages that have the "smsc=bind-b" in the sendsms URL will get routed to that bind? It doesn't seem like that should work. Am I understanding your suggestion properly?
Thanks! Jeff On Apr 26, 2014 10:26 AM, "Juan Nin" <jua...@gmail.com> wrote: > > Use the same smsc-id on all of them, but different allowed-smsc-id on each. > That way the DLRs will all use the smsc-id, but you use the allowed-smsc-id to route your MTs. > > Also use smsc-admin-id so that you can start/stop/whatever each bind individually > > Regards > > > On Thu, Apr 24, 2014 at 10:49 AM, Jeff Thorn <j...@thorntechnologies.com> wrote: >> >> Thanks for the response spamden. That is very unfortunate. We have a legitimate need to have different smsc-ids but have only one account. How feasible would it be to use meta data or some other way to match the sending smsc-id instead of the receiving smsc-id? If all else fails, what is the risk of matching the DLR on destination and timestamp alone? >> >> The reason we need multiple smsc-id is because we are routing interactive messages to binds that are less active since many of our other binds may have several thousand messages queued at any given time. If using multiple smsc-ids is not a valid approach, is there some other way to accomplish what we are trying to do. Perhaps the "priority" field is what we need? How does the priority field affect MT messages on a bind that already has several thousand messages queued for sending by kannel? >> >> Thanks! >> >> Jeff >> >> >> >> >> On Thu, Apr 24, 2014 at 3:23 AM, spameden <spame...@gmail.com> wrote: >>> >>> >>> >>> >>> 2014-04-24 1:20 GMT+04:00 Jeff Thorn <j...@thorntechnologies.com>: >>> >>>> I've searched the user groups for this issue and everyone says to use the same smsc-id. We specifically need different smsc-ids so our interactive messages can be delivered in real time and not get queued with our bulk messages. >>> >>> >>> Only if you use same bind server and same login you need to use same smsc-id parameter. Because remote server doesn't know through which connection it should send DLR report. >>>> >>>> >>>> Is there anyway to ensure that Delivery Reports come back on the same smsc-id that the message was sent from? Otherwise, I don't understand why there is an option to specify different smsc-ids. >>> >>> >>> It's always the same from which it was sent, just make sure you don't have same credentials / same server specified more than once. >>>> >>>> >>>> Thanks! >>>> >>>> >>>> On Wed, Apr 23, 2014 at 4:45 PM, Jeff Thorn <j...@thorntechnologies.com> wrote: >>>>> >>>>> We are seeing an increased number of error messages like the following: >>>>> >>>>> ERROR: SMPP[bind-b]: got DLR but could not find message or was not interested in it id<xxxxxx> dst<xxxxxxx>, type<1> >>>>> >>>>> We have a number of binds setup to handle bulk messaging (which may queue in kannel) or interactive messaging (which is less frequent). >>>>> >>>>> I've noticed these errors occur when we receive the Delivery Report on one bind (bind-b), but the original MT was sent from a different bind (bind-a). In the DLR database table, the message with the same id and dst exists, but the smsc value is different (bind-a vs bind-b). >>>>> >>>>> Is there anyway to ensure that Delivery Reports come back on the same smsc-id that the message was sent from? >>>>> >>>>> Thanks! >>>>> >>>>> Jeff >>>>> >>>>> >>>> >>> >> >
