Re: [PATCH] preliminary confirmed sendsms

Well, I've just patched my 1.3.2 with this and so far it seems to work ok.

I've checked trying to send messages without defining an smsc and I've got:

"Not routable. Do not try again."

What I'm missing is the capability to detect wrong numbers, ie. if I
try to send a message to "12345678" or "0000000" I've got an "0:
Accepted for delivery", but I think I need DLR's for that isn't it?

Isn't there any way to detect that kind of errors without DLR's?

My provider won't give me DLR's because they are running out of
bandwith (!!??), but this kind of errors whould be easily detected
since they arise during the submit_sm o deliver_sm and on normal
conditions that happens not far away in time. I can live without the
message receive confirmation but any hints about how to detect wrong
numbers is welcome.

Regards,




> On Fri, 08 Oct 2004 09:46:41 +0300, Kalle Marjola <[email protected]> wrote:
> > On Thu, 2004-10-07 at 23:36, Alan McNatty wrote:
> > > Hi Kalle,
> > >
> >
> > > It would be good to understand more the impact on doing this (as you
> > > note). Please consider the following scenario ...
> > >
> > > Often connections to SMSC are bandwidth limited (we have some SMPP links
> > > over limited FR for example). What this can mean is (under load) that
> > > there is not as much traffic inbound as out.
> > >
> > Please note that this patch does NOT wait that message is handled by
> > SMSC driver (which would take time if there are queues), but instead
> > gets an immediate response as soon as bearerbox replies. Thus the
> > delay is milliseconds when compared to old one.
> >
> > The idea of waiting for SMSC ack/nack is in my plan. However, as
> > this could be delayed even seconds, THAT feature would only be used if
> > so configured/requested as it cannot be used with heavy traffic.
> > (that feature would be based on current DLR implementation and there
> > would be a list of possible problematic scenarios)
> >
> > > Also if load balancing with internal queues - in the event one SMSC link
> > > is dropped the message queues are effectively shuffled. What would
> > > happen if we're waiting to hear back from SMSC about message and the
> > > link is dropped, etc? We would need to cope with these scenarios.
> > >
> > See above. This current reply is based on what bearerbox _immediately_
> > replies when it receives SMS from smsbox (and which was previously just
> > discarded by smsbox). So, in exchange for some milliseconds, the caller
> > gets information if there is some basic problems.. (no SMSCes connected,
> > bad configuration,...)
> >
> > If you check out the original code (bb_boxc.c, line 253 and smsbox.c,
> > line 191-196) these messages are already flying around (in fact, have
> > been there for over 4 years...). They were just not used... (blame me =)
> >
> >
> >
> >
> > --
> > &Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
> >
> >
> 
> 
> --
> Alejandro Guerrieri
> Magicom
> http://www.magicom-bcn.net/
> 


-- 
Alejandro Guerrieri
Magicom
http://www.magicom-bcn.net/