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