Yes, you're understanding it correctly. So you can use "bind-a" as smsc-id for all the binds, and then use allowed-smsc-id like "bind-b", "bind-c", "bind-d", etc on each and use those as smsc parameter for sending the MTs.
DLRs will all use "bind-a". Regards. On Sat, Apr 26, 2014 at 11:40 AM, Jeff Thorn <j...@thorntechnologies.com>wrote: > 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 > >>>>> > >>>>> > >>>> > >>> > >> > > >
