Ok, thanks for discussion. I will try to contact to SMSC admins then. On Thu, Sep 16, 2010 at 8:36 PM, Alejandro Guerrieri <[email protected]> wrote: > Ivan, > Sorry, there seems to be a misunderstanding about the semantics here. The > "dlr-url" remains the same, what changes is the "url" (which is the dlr-url > with the variables replaced). > In short: same dlr-url, different url. > Let me give you an example: > You query a message longer than 160 characters. You set dlr-url to be: > http://localhost/dlr.php?id=1234&fid=%F&status=%d > Under normal circumstances, Kannel would split the message in 2 (or more) > segments and would only request a DLR for the first one. > The first thing you'd get is an "internal" DLR, created by kannel after > receiving the submit_sm_resp > http://localhost/dlr.php?id=1234&fid=abcdef12&status=8 > Afterwards, when the carrier sends a deliver_sm with a DLR, you'll hit that > url again, but with different status: > http://localhost/dlr.php?id=1234&fid=abcdef12&status=1 > If the status is "final" (delivery, failure) kannel deletes the dlr from > it's db and nothing else is done about it. > Now, if you adjust kannel to request dlrs for all fragments, what you'd get > is: > Internal DLR: > http://localhost/dlr.php?id=1234&fid=abcdef12&status=8 > http://localhost/dlr.php?id=1234&fid=fedcba21&status=8 > Smsc DLR: > http://localhost/dlr.php?id=1234&fid=abcdef12&status=1 > http://localhost/dlr.php?id=1234&fid=fedcba21&status=1 > Again, the dlr-url is in all cases: > http://localhost/dlr.php?id=1234&fid=%F&status=%d > What changes is the "fid" and "status". > The problem is, figuring out if messages have been delivered or not from > those request is going to be tricky at best. How could you tell if all parts > were received? You could "predict" how many parts would be required from the > message length, insert the dlr's on a table and group by "id" (probably > filtering by "status"), but it's a long shot at best. > In other words, the %F / foreign_id field is created by the carrier on the > submit_sm_resp, so you don't have it available when you queue the message in > first place. > Regards, > Alex > On Thu, Sep 16, 2010 at 8:46 AM, Ivan Kurnosov <[email protected]> wrote: >> >> >> The way dlr-url works would mean that the same dlr-url would be >> >> accessed 2 or more times, using the same user values you provided on all >> >> of >> >> them. >> Actually - no. With %F it is the different urls >> >> I'm feeling dummy but what is "MO"? Is it the way of manual splitting >> the messages into parts with (1/3, 2/3, etc) in the beginnig? >> >> On Thu, Sep 16, 2010 at 5:32 PM, Alejandro Guerrieri >> <[email protected]> wrote: >> > Let's see: >> > Kannel currently functionality works as follows: >> > When a message longer than 160 chars is queued, Kannel splits it into 2 >> > or >> > more messages. Only on the first one the registered_delivery flag is >> > set. >> > That means that Kannel asks for DLR's only on the first part. >> > You could change Kannel to ask for DLR's on all parts of course, but >> > that's >> > not very useful, because you need some means to be able to relate the 3 >> > parts back together. The way dlr-url works would mean that the same >> > dlr-url >> > would be accessed 2 or more times, using the same user values you >> > provided >> > on all of them. >> > As was discussed yesterday, a possible solution would be to maintain a >> > local >> > queue of pending multi-parts, very similar to what Kannel already does >> > with >> > the multi-part MO: it keeps a queue of parts and only moves the messages >> > to >> > smsbox when all parts were received. As in the MO implementation, this >> > queue >> > should expire messages from time to time (and send the proper DLR to the >> > higher layer). >> > >> > Regards, >> > Alex >> > On Thu, Sep 16, 2010 at 2:54 AM, Ivan Kurnosov <[email protected]> wrote: >> >> >> >> Hmhmhmh, may be I'm understanding wrong, but my task now is: >> >> >> >> To be sure that ALL PARTS of multipart message has been delivered. Is >> >> there any possible way of doing this? >> >> >> >> Another point of view of this issue: If I get only the one dlr message >> >> (for first msg, as kannel does) - can I be sure that all parts has >> >> been delivered? >> >> >> >> And third part: one of SMSC does not send DLR for miltupart if only >> >> one message containg delivery request flag. Whose mistake is this - >> >> kannel's (which does not send delivery request in each message), or >> >> SMSC's (which does not send me delivery message)? >> >> >> >> On Thu, Sep 16, 2010 at 11:38 AM, Alejandro Guerrieri >> >> <[email protected]> wrote: >> >> > Ivan, %F comes loaded with the information from the smsc. While it >> >> > should be unique, you don't know it in advance, so it can't be used >> >> > to match >> >> > back to anything on your side. For the dlrs to be useful, you should >> >> > be able >> >> > to match it against something known on your side, and that's where >> >> > the id I >> >> > mentioned comes into play. >> >> > >> >> > Regards, >> >> > -- >> >> > Alex Guerrieri >> >> > >> >> > On 16/09/2010, at 02:06, Ivan Kurnosov <[email protected]> wrote: >> >> > >> >> >> Hmmmm.... I'm talking about %F which is foreign id and as I said - >> >> >> when it is multipart short message - I get it == 0 at my dlr-url >> >> >> >> >> >> On Thu, Sep 16, 2010 at 10:43 AM, Rene Kluwen >> >> >> <[email protected]> >> >> >> wrote: >> >> >>> You guys are talking about different id's. >> >> >>> >> >> >>> Smsc id (foreign id) is not the same id as you assign in dlr-url. >> >> >>> >> >> >>> == Rene >> >> >>> >> >> >>> -----Original Message----- >> >> >>> From: [email protected] [mailto:[email protected]] On >> >> >>> Behalf >> >> >>> Of Ivan Kurnosov >> >> >>> Sent: Wednesday, 15 September, 2010 23:58 >> >> >>> To: Alejandro Guerrieri; [email protected] >> >> >>> Subject: Re: registered_delivery and multi-parts message >> >> >>> >> >> >>> Not the same id. Each part has its own SMSC message_id >> >> >>> >> >> >>> On Thu, Sep 16, 2010 at 12:36 AM, Alejandro Guerrieri >> >> >>> <[email protected]> wrote: >> >> >>>> Yes. I wouldn't call it a bug, it was a design decision. Of course >> >> >>>> you're >> >> >>>> absolutely entitled to disagree with it and change it on your >> >> >>>> local >> >> >>>> tree, >> >> >>> as >> >> >>>> you already did :) >> >> >>>> Now, the issue is, since you define one dlr-url (probably with a >> >> >>>> unique id >> >> >>>> you created) and Kannel splits the message into 2 or 3 parts, >> >> >>>> you'd >> >> >>>> get 2 >> >> >>> or >> >> >>>> 3 hits on that URL, sharing the same id. Are you sure that that's >> >> >>>> what you >> >> >>>> want? >> >> >>>> Regards, >> >> >>>> Alex >> >> >>>> On Wed, Sep 15, 2010 at 1:24 PM, Ivan Kurnosov <[email protected]> >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> Actually, I can ;-) I already fixed kannel (to be clear - i've >> >> >>>>> just >> >> >>>>> commented 3 lines of code) to send only one DLR msg. So now I get >> >> >>>>> N >> >> >>>>> delivery messages. >> >> >>>>> >> >> >>>>> But I'm very curious - is it just kannel "feature" or some smpp >> >> >>>>> specification mandatory? I've asked this question because one of >> >> >>>>> my >> >> >>>>> SMSC (currently i'm working with 3 different companies) does not >> >> >>>>> send >> >> >>>>> me delivery messages if it is 0x1 just at first and not at second >> >> >>>>> message. So I need to know whether I need to ask their support to >> >> >>>>> reconfigure SMSC or make some tricks to get that info >> >> >>>>> >> >> >>>>> 2010/9/15 Nikos Balkanas <[email protected]>: >> >> >>>>>> Hi, >> >> >>>>>> >> >> >>>>>> This is a known kannel limitation. In a multpart SMS it will >> >> >>>>>> request >> >> >>> DLR >> >> >>>>>> only for the first part. Nothing you can do about it. >> >> >>>>>> >> >> >>>>>> BR, >> >> >>>>>> Nikos >> >> >>>>>> ----- Original Message ----- From: "Ivan Kurnosov" >> >> >>>>>> <[email protected]> >> >> >>>>>> To: <[email protected]> >> >> >>>>>> Sent: Wednesday, September 15, 2010 8:28 AM >> >> >>>>>> Subject: registered_delivery and multi-parts message >> >> >>>>>> >> >> >>>>>> >> >> >>>>>>> Hello there. >> >> >>>>>>> >> >> >>>>>>> Why does >> >> >>>>>>> >> >> >>>>>>> 2010-09-15 16:26:32 [25217] [6] DEBUG: registered_delivery: 0 >> >> >>>>>>> = >> >> >>>>>>> 0x00000000 >> >> >>>>>>> >> >> >>>>>>> for second part even though it was 0x1 for first one? >> >> >>>>>>> >> >> >>>>>>> Is not it a bug? >> >> >>>>>>> >> >> >>>>>>> While reading SMPP v3.4 specification I did not see any >> >> >>>>>>> recommendations about how to set registered_delivery if there >> >> >>>>>>> are >> >> >>>>>>> multiple parts. >> >> >>>>>>> >> >> >>>>>>> -- >> >> >>>>>>> With best regards, Ivan Kurnosov >> >> >>>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> -- >> >> >>>>> With best regards, Ivan Kurnosov >> >> >>>>> >> >> >>>> >> >> >>>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> With best regards, Ivan Kurnosov >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> With best regards, Ivan Kurnosov >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> With best regards, Ivan Kurnosov >> > >> > >> >> >> >> -- >> With best regards, Ivan Kurnosov > >
-- With best regards, Ivan Kurnosov
