this will not help to solve our resend issue. The steps I think of to fix it: 1) We have to remember pointer to SMSC via we sent other parts. 2) By restart of bearerbox we need to resend all parts because we don't remember in store which part was already sent and via which SMSC.
Thanks, Alexander Malysh Am 19.03.2010 um 15:47 schrieb Alejandro Guerrieri: > I kind of agree into making smsc-admin-id mandatory and unique, though it > would probably mean breaking many people's configuration files. > > Note: If you don't specify an smsc-admin-id, it gets loaded with the smsc-id > value, so you'd only need to specify it if you're using duplicated smsc-id's. > > Thoughts? Alex? > > Regards, > -- > Alejandro Guerrieri > aguerri...@kannel.org > > > > On 19/03/2010, at 15:33, Konstantin Vayner wrote: > >> Ok, so in this case we may as well just remember the admin-smsc-id , and not >> the current pointer, that would be still precise (if of course the >> admin-smsc-id will be obligatory). >> >> And thanks for the tip about the DLRs, i was banging my head against the >> wall trying to find out why the dlrs keep failing to find the message >> randomly ;-) (i do have same user-pass smscs) >> >> On Fri, Mar 19, 2010 at 2:17 PM, Alejandro Guerrieri <aguerri...@kannel.org> >> wrote: >> Yes, that also! :) >> >> That's why we added the smsc-admin-id parameter to be able to manage the >> binds independently from the administration interface: to avoid having to >> sacrifice the non-uniqueness of smsc-id. >> >> Regards, >> >> Alex >> -- >> Alejandro Guerrieri >> aguerri...@kannel.org >> >> >> >> On 19/03/2010, at 13:11, Alexander Malysh wrote: >> >>> >>> Am 19.03.2010 um 13:05 schrieb Konstantin Vayner: >>> >>>> 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) >>> >>> try this setup for e.g. SMPP with the same username/pass and you will get >>> issues with DLRs because DLRs will arrive on every >>> connection. >>> >>> And to the question about shutdown: yes you will lose pointer to SMSC >>> struct and there would be only one possibility to go for sure, retransmit >>> all parts. >>> >>> >>>> >>>> >>>> On Fri, Mar 19, 2010 at 1:57 PM, Alejandro Guerrieri >>>> <aguerri...@kannel.org> 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 >>>> aguerri...@kannel.org >>>> >>>> >>>> >>>> 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 <amal...@kannel.org> >>>>> 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 <amal...@kannel.org >>>>> > <mailto:amal...@kannel.org>> 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 <amal...@kannel.org >>>>> > <mailto:amal...@kannel.org>> 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> >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>> >>>> >>> >> >> >
