Thanks, but it doesn't mater. It is probably the result that after copying I've manually edited the statement to make it more clear: to show that the dlr_url is non-url unique string.
And your note is a little bit off-topic. The subject is that no DLR's records appears in the sent_sms table. > You have a quote mismatch in that INSERT statement. > > -----Original Message----- > From: dorian [mailto:doria...@o2.pl] > Sent: Thursday, 07 October, 2010 08:32 > To: Rene Kluwen > Cc: 'Alejandro Guerrieri'; users@kannel.org > Subject: Re: sms - dlr bounding > > Rene, > Thanks a lot a lot for the advice. > Recently I've found some time to test your idea. > At the first glance it looked like great solution. > > I've used the following INSERT statement (php syntax) > INSERT INTO send_sms (momt, sender, receiver, msgdata, sms_type, > dlr_mask, dlr_url) VALUES ( 'MT', '8765', '".$phone_nr."', '".$txt."', > 2, 31,'".$id); > > where $id contained unique id (but not url). > > For a moment it worked as expected. But now no DLRs are registered in > the sms_sent table although I see the it is sent back from smsc. > Any idea? > I do not understand why for the first trials the DLRs has been stored > into the table but now they are not. > > Dorian > >> The thing that you might be looking for: >> >> If -instead of using smsbox- you use sqlbox to send messages, then you can >> set dlr-url to whatever you want. It doesn't necessarily have to be a http >> url. >> After that, you get your DLR's in the sent_sms table with the value you >> passed as drl-url. >> >> But since sqlbox doesn't call any http requests, as opposed to smsbox it >> just stays there in the table with boxc_id the same as you defined as >> sqlbox-id. >> >> Judging from your emails, I think this is what you want. >> >> == Rene >> >> -----Original Message----- >> From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf >> Of dorian >> Sent: Friday, 17 September, 2010 11:33 >> To: Alejandro Guerrieri >> Cc: users@kannel.org >> Subject: Re: sms - dlr bounding >> >> Well. I know the difference between fork and pthread_create. >> >> Anyway the http client work (even if it is thread not a process) is >> waste of time for me. >> Additionally I am forced to have working http server also which also do >> a silly work for me (taking CPU time and RAM). >> >> I am trying to find out the way to have dlr report but not to be forced >> to run http server since dlr reply is handled with sqlbox and it is >> enough for me. >> (on condition that I am able to bound sms with dlr) >> >> >> >>> Dorian, >>> >>> Kannel uses threads. It doesn't fork. >>> >>> There's a _huge_ difference in terms of cost between a thread and fork. >>> >>> Using "exec" is a very bad idea in terms of performance and security. >>> >>> Regards, >>> >>> Alex >>> >>> On Fri, Sep 17, 2010 at 10:59 AM, dorian <doria...@o2.pl >>> <mailto:doria...@o2.pl>> wrote: >>> >>> 1. See DEBUG line. Even if it is thread it takes time and RAM to >>> create, >>> the thread running take time preparing http request, my http server >>> waste time to handle the request etc. >>> 2. I need dlr feedback >>> > On Fri, 2010-09-17 at 09:26, dorian wrote: >>> > >>> >> Right. >>> >> But for http connection the kannel's clients is forked (at least it >>> >> looks like according to the logs: 'DEBUG: HTTP: Creating >>> HTTPClient'). >>> >> Such fork is almost the same as exec'ing external process. >>> >> >>> > >>> > How do you know it is fork? >>> > It could be thread or even simple function call. >>> > >>> > >>> >> So I prefer exec my script rather than kannel's http client. >>> This way >>> >> the are no resources consumed by http server and the time >>> needed for >>> >> http request compose and parse is saved. >>> >> >>> >> In case of sms reception I have a chance to do that - there is >>> "exec" >>> >> config keyword. >>> >> But dlr has to be handled via http. >>> >> >>> >> What is more - since sqlbox do "the database registration" >>> without my >>> >> intervention I do not need any drl handler. >>> >> But not to have errors in kannel log I am forced to use http >>> server. >>> >> >>> >> And having similar "exec" config parameter against dlr-url I >>> could try >>> >> to use dummy script like "/bin/false" or something like this >>> which for >>> >> sure would be faster. >>> >> >>> > >>> > Better solution could be not to request delivery report when sending >>> > message and then there is no need for dlr handling at all. >>> > >>> > >>> >>> Hi, >>> >>> >>> >>> The "exec" script is another process started each time and is more >>> >>> expensive than attempting to fetch a dlr-url. The http server, >>> >>> initially takes up some resources (memory) but it remains >>> constant and >>> >>> CPU utilization is overall lower. >>> >>> >>> >>> That's the whole purpose of the dlr-url. To get your dlrs in a >>> databse >>> >>> in the format that you want. >>> >>> >>> >>> BR, >>> >>> Nikos >>> >>> ----- Original Message ----- From: "dorian" <doria...@o2.pl >>> <mailto:doria...@o2.pl>> >>> >>> To: "Alvaro Cornejo" <cornejo.alv...@gmail.com >>> <mailto:cornejo.alv...@gmail.com>> >>> >>> Cc: <users@kannel.org <mailto:users@kannel.org>> >>> >>> Sent: Friday, September 17, 2010 1:06 AM >>> >>> Subject: Re: sms - dlr bounding >>> >>> >>> >>> >>> >>> There is nothing magical in sqlbox. >>> >>> It sits between bearerbox and smsbox and it just records data >>> in the >>> >>> database. >>> >>> Each message = 1 record in the table independetly if the >>> message is >>> >>> outgoing sms (MT) , incoming sms (MO) or delivery report. >>> >>> It is nice and simple way to have a full history of communication. >>> >>> >>> >>> So I do not need any extra dlr message handling - a record in the >>> >>> database if enough for me. >>> >>> But only on condition that it would be possible to recognize >>> which dlr >>> >>> record corresponds to the record describing sent sms. >>> >>> >>> >>> On the other hand the method with dlr-url _requires_ the >>> existence of >>> >>> the url if I want to avoid stupid log entries. >>> >>> >>> >>> What is more kannel unnecessarily runs the http client to make >>> dlr-url >>> >>> fetch. It is waste of CPU time RAM usage etc. >>> >>> >>> >>> In case of sms receiving there is a "exec" entry (sms-service) >>> which >>> >>> allows me to forget about http protocol and get all data >>> directly with >>> >>> my shell script. >>> >>> This way I would not need any working http server (which takes >>> next >>> >>> resourses) but dlr-url requires such server. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> How it works is, once kannel receives a dlr, it matches >>> against its >>> >>>> dlr database, if got a macth, it then calls your own dlr-url to >>> >>>> trigger your own application so you can reccord the status and do >>> >>>> whatever you want with it. If the dlr is for a final status, the >>> >>>> kannel deletes that dlr reccord. >>> >>>> >>> >>>> With sqlbox, I don't know how dlrs exactly works. Have you >>> tried to >>> >>>> put in your dlr-url your own id only? does kannel complains >>> that it is >>> >>>> not a valid url ? >>> >>>> >>> >>>> Regards >>> >>>> >>> >>> |-----------------------------------------------------------------------------------------------------------------| >>> >>>> >>> >>>> Envνe y Reciba Datos y mensajes de Texto (SMS) hacia y desde >>> cualquier >>> >>>> celular y Nextel >>> >>>> en el Perϊ, Mιxico y en mas de 180 paises. Use aplicaciones 2 >>> vias via >>> >>>> SMS y GPRS online >>> >>>> Visitenos en www.perusms.NET >>> <http://www.perusms.NET> www.smsglobal.com.mx >>> <http://www.smsglobal.com.mx> y >>> >>>> www.pravcom.com <http://www.pravcom.com> >>> >>>> >>> >>>> >>> >>>> >>> >>>> 2010/9/16 dorian <doria...@o2.pl <mailto:doria...@o2.pl>>: >>> >>>> >>> >>>> >>> >>>>> Thanks a lot for reply. >>> >>>>> >>> >>>>> Using the sqlbox I see now the MT and DLR record in the >>> database which >>> >>>>> has the same 'dlr_url' field with my id and it looks like the >>> >>>>> problem is >>> >>>>> solved. >>> >>>>> >>> >>>>> Anyway is it the only solution? >>> >>>>> >>> >>>>> The 'dlr_url' field contains the whole http link which for me is >>> >>>>> completely useless and is needlessly long as the only sms id is >>> >>>>> interesting. >>> >>>>> >>> >>>>> Next subject is that having database I do not need to fire >>> up any http >>> >>>>> url when delivery report is sent back. It waste of CPU time >>> only. >>> >>>>> So I am looking for something which could give me >>> same/similar results >>> >>>>> in database without necessity of creating dlr http site Such >>> site is >>> >>>>> completely useless for me. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>>> you need to add your own different id to each of your >>> messages in the >>> >>>>>> dlr-url you send with the message. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>> |-----------------------------------------------------------------------------------------------------------------| >>> >>>>>> >>> >>>>>> Envνe y Reciba Datos y mensajes de Texto (SMS) hacia y >>> desde cualquier >>> >>>>>> celular y Nextel >>> >>>>>> en el Perϊ, Mιxico y en mas de 180 paises. Use aplicaciones >>> 2 vias via >>> >>>>>> SMS y GPRS online >>> >>>>>> Visitenos en www.perusms.NET >>> <http://www.perusms.NET> www.smsglobal.com.mx >>> <http://www.smsglobal.com.mx> y >>> >>>>>> www.pravcom.com <http://www.pravcom.com> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> 2010/9/16 dorian <doria...@o2.pl <mailto:doria...@o2.pl>>: >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>>> Let's assume that I am sending 3 sms'es (MTs) to switched off >>> >>>>>>> terminal. >>> >>>>>>> Next the terminal is switched on. >>> >>>>>>> Let's assume the only 2 of them are delivered. >>> >>>>>>> >>> >>>>>>> The (maybe stupid) question is: >>> >>>>>>> how to find out which dlr report refers to which sms sent? >>> >>>>>>> >>> >>>>>>> I cannot find a "key" which could be used to "bind" dlr report >>> >>>>>>> with sms >>> >>>>>>> as a result I don't know how to detect which sms has been >>> discarded. >>> >>>>>>> >>> >>>>>>> I am using bearerbox-sqlbox-smsbox with CIMD2 smsc. >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> Regards >>> >>>>>>> Dorian >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>> >>> >>> >>> >>> >>> >> >>> >> >>> > >>> > >>> >>> >>> >>> >>> >> >> >> >> >> > > > > >
