Re: [PATCH] fix bug #529 (sms-resend-* ignored for concatenated messages)

You're using separate MO/MT binds, so yes, that's possible. But on some scenarios, you might need the binds to appear as a single bind to your application.

e.g., if you're using transceiver binds (or single TX/RX binds for MO/MT) and your application can't handle different smsc names for the same carrier, then having this flexibility turns to be very useful.

Regards,

Alex
--
Alejandro Guerrieri
[email protected]



On 19/03/2010, at 13:05, Konstantin Vayner wrote:

> hm.. thats weird
> 
> i have several smscs in my config named smsc_carriername_mt1 , smsc_carriername_mt2 , ...
> and i put allowed-smsc-id=smsc_carriername_mt in their config, then submit messages with smsc=smsc_carriername_mt (without numbers) and kannel does load balance between them... or at least so it looks (messages go out from all of them)
> 
> 
> On Fri, Mar 19, 2010 at 1:57 PM, Alejandro Guerrieri <[email protected]> wrote:
> smsc-id's can't be unique. That would ruin load-balancing for example.
> 
> smsc-admin-id's could be unique though... (imho, they _should_ be unique, otherwise it's pointless to use it).
> 
> Regards,
> 
> Alex
> --
> Alejandro Guerrieri
> [email protected]
> 
> 
> 
> On 19/03/2010, at 12:51, Konstantin Vayner wrote:
> 
>> Actually, now that i'm rereading this conversation again...
>> 
>> > You have to remember SMSC pointer not only SMSC-name/id and then teach all routing parts
>> > to respect it...
>> 
>> What if kannel gets shut down and then starts up again?
>> Obviousely, smsc pointers are different... 
>> 
>> I say lets make smsc-id's a must and unique, that'll make things better ;)
>> 
>> On Thu, Mar 18, 2010 at 11:00 AM, Alexander Malysh <[email protected]> wrote:
>> Hi,
>> 
>> the possibility for endless loop is equal for each part. So this will not help... We need real fix...
>> 
>> Thanks,
>> Alexander Malysh
>> 
>> Am 17.03.2010 um 18:04 schrieb Michael Zervakis:
>> 
>> > Dear Alex,
>> >
>> >   From my experience endless loops from temporary errors usually occur before ever transmitting the first message part. It's a very rare occurence to transmit first part and then enter in an endless loop with left parts. A partial fix could be to keep two counters in split_parts struct, parts_left and parts_len, to make it possible to determine which part we are transmitting. So if temp error occurs and we are sending first part we can safely put the whole message into resend queue without the drawback of sending extra SMS parts to receiver. I know this is not a real fix, but I believe it will hanlde most of the endless loop cases.
>> >
>> >
>> > Am 17.12.2009 um 11:28 schrieb Konstantin Vayner:
>> >
>> >
>> >
>> > why remembering smsc-id in sms.smsc_id is not enough?
>> >
>> >
>> > due to accepted-smsc in smsc config group and because SMSCs may have the same names (or even no names defines)...
>> >
>> >
>> >
>> > how does smsbox remember routing when i submit a message with predefined smsc id from http (sendsms) ?
>> >
>> > On Thu, Dec 17, 2009 at 12:10 PM, Alexander Malysh <[email protected] <mailto:[email protected]>> wrote:
>> >
>> >
>> > Am 17.12.2009 um 10:43 schrieb Konstantin Vayner:
>> >
>> >
>> >
>> > so the best option would be to requeue the part via same smsc, right ?
>> >
>> >
>> > yes, but it's not easy todo. You have to remember SMSC pointer not only SMSC-name/id and then teach all routing parts
>> >
>> > to respect it...
>> >
>> >
>> >
>> > cause requeueing all parts may also get extra messages to the handset despite it not being able to reconstruct (not to mention the extra money ;) )
>> >
>> > On Thu, Dec 17, 2009 at 11:33 AM, Alexander Malysh <[email protected] <mailto:[email protected]>> wrote:
>> >
>> > Hi,
>> >
>> >
>> > unfortunately this will not work as expected (the rule is: _all_ parts if multipart message have to be send via the same SMSC)...
>> >
>> >
>> > example:
>> >
>> >
>> >           SMSC-A -> splits (2 parts) -> 1 part sent OK -> 2 part get temp. error -> you put it into global queue for resend -> 2 part sent via SMSC-B -> handset rejects it
>> >
>> >
>> > We have only two possibility here:
>> >
>> > 1) if temp error occurs put the _whole_ message into resend queue and resend then _all_ parts (very easy todo)
>> >
>> > 2) remember smsc which was used for first parts and resend it via the same smsc (complicated but save money :) )
>> >
>> >
>> > Thanks,
>> >
>> > Alexander Malysh
>> >
>> >
>> > Am 16.12.2009 um 18:17 schrieb Konstantin Vayner:
>> >
>> >
>> >
>> > Bug report: http://redmine.kannel.org/issues/show/529
>> >
>> > Quote from gw/bb_smscconn.c :
>> >
>> > static void handle_split(SMSCConn *conn, Msg *msg, long reason)
>> > {
>> >   struct split_parts *split = msg->sms.split_parts;
>> >
>> >   /*
>> >    * If temporarely failed, try again immediately but only if connection active.
>> >    * Because if connection is not active we will loop for ever here consuming 100% CPU
>> >    * time due to internal queue cleanup in smsc module that call bb_smscconn_failed.
>> >    */
>> >   if (reason == SMSCCONN_FAILED_TEMPORARILY && smscconn_status(conn) == SMSCCONN_ACTIVE &&
>> >       smscconn_send(conn, msg) == 0) {
>> >       /* destroy this message because it will be duplicated in smsc module */
>> >       msg_destroy(msg);
>> >       return;
>> >   }
>> >
>> > (end quote)
>> >
>> > So, if an smsc is alive and throws temporary error every time you try to submit such a message, we enter endless loop of attempting to resend it....
>> >
>> >
>> > Suggested patch follows (also attached).
>> > Sorry its not cvs diff - having firewall issues accessing pserver now so i ran diff vs snapshot generated yesterday
>> > I will be able to produce a normal cvs diff tomorrow morning if it is needed
>> >
>> >
>> > --- kannel-snapshot/gw/bb_smscconn.c    2009-11-15 16:12:28.000000000 +0200
>> > +++ gateway-cvs/gw/bb_smscconn.c        2009-12-16 19:47:32.000000000 +0200
>> > @@ -203,18 +203,6 @@
>> >    struct split_parts *split = msg->sms.split_parts;
>> >       /*
>> > -     * If temporarely failed, try again immediately but only if connection active.
>> > -     * Because if connection is not active we will loop for ever here consuming 100% CPU
>> > -     * time due to internal queue cleanup in smsc module that call bb_smscconn_failed.
>> > -     */
>> > -    if (reason == SMSCCONN_FAILED_TEMPORARILY && smscconn_status(conn) == SMSCCONN_ACTIVE &&
>> > -        smscconn_send(conn, msg) == 0) {
>> > -        /* destroy this message because it will be duplicated in smsc module */
>> > -        msg_destroy(msg);
>> > -        return;
>> > -    }
>> > -   -    /*
>> >     * if the reason is not a success and status is still success
>> >     * then set status of a split to the reason.
>> >     * Note: reason 'malformed','discarded' or 'rejected' has higher priority!
>> > @@ -303,7 +291,7 @@
>> > void bb_smscconn_send_failed(SMSCConn *conn, Msg *sms, int reason, Octstr *reply)
>> > {
>> > -    if (sms->sms.split_parts != NULL) {
>> > +    if (reason != SMSCCONN_FAILED_TEMPORARILY && sms->sms.split_parts != NULL) {
>> >        handle_split(conn, sms, reason);
>> >        octstr_destroy(reply);
>> >        return;
>> >
>> >
>> >
>> >
>> >
>> > <bb_smscconn.diff>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> 
>> 
> 
>