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> >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >>> >> >> >
