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 <[email protected]>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 > [email protected] > > > > 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 < > [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> >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >>> >> >> > > >
