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