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 >
