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
