Hi,
patch could be produced with cvs diff -Nau.
I don't think it's a good idea to implement max retries only for the
smpp. It's really easy to get it working for all protos if you implement
it at generic layer bb_smscconn.c.
Thanks,
Alex
Josh McAllister schrieb:
I have a patch with some changes we had to make to pass Cingular US's
SMPP integration testing. This is my first time giving a patch back to
an open source project, so could someone let me know how I should
produce the diff, and how I should submit it.
This patch adds:
max-retries = [num retry attempts]
and
retry-delay = [seconds]
config options for SMPP smsc groups.
retry-delay is only the minimum delay... it may be slightly longer
before we actually get around to retrying.
The default (and only AFAIK) behavior is to immediately retry and keep
retrying, very ugly.
Caveat: If your throttle time delay is less than your retry delay,
delayed messages will be retried before new messages in the event you
are throttled... The easy fix... make sure retry-delay is >
throttle-delay by at least 15 - 30 seconds.
NOTE: I do set defaults for max-retries(10), and retry-delay(30) This
changes the current behavior... but IMHO the current behavior is not
sane.
There's also a couple of sm_resp codes added... these were required by
Cingular, US. Not sure if they're standardized... they are:
RX_T_MCFAIL (x45) = Message center reported failure, Cingular says this
is a Temporary Failure.
RX_T_STNA (x410) = Service Type not Available, again a Temp failure.
If I missed some config option(s), that already addresses the temporary
failure behavior for SMPP SMSCs, then please let me know... otherwise
this should be a very useful patch.
Thanks,
Josh McAllister
