>> 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
<alejandro.guerri...@gmail.com> 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 <zer...@zerkms.ru>
> 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
>> <alejandro.guerri...@gmail.com> 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 <zer...@zerkms.ru> 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
>> >> <rene.klu...@chimit.nl>
>> >> 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: users-boun...@kannel.org [mailto:users-boun...@kannel.org]
>> >>> On
>> >>> Behalf
>> >>> Of Ivan Kurnosov
>> >>> Sent: Wednesday, 15 September, 2010 23:58
>> >>> To: Alejandro Guerrieri; users@kannel.org
>> >>> 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
>> >>> <alejandro.guerri...@gmail.com> 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
>> >>>> <zer...@zerkms.ru>
>> >>>> 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 <nbalka...@gmail.com>:
>> >>>>>> 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"
>> >>>>>> <zer...@zerkms.ru>
>> >>>>>> To: <users@kannel.org>
>> >>>>>> 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
