Actually you just misread my mail. As mentioned, we are in complete agreement. 
I didn't mean different dlr-url locations, but 3 different dlr-url attempts, 
one for each part. Don't jump the gun over nothing.

BR,
Nikos
  ----- Original Message ----- 
  From: Alejandro Guerrieri 
  To: Nikos Balkanas 
  Cc: Rene Kluwen ; Ivan Kurnosov ; [email protected] 
  Sent: Wednesday, September 15, 2010 7:21 PM
  Subject: Re: registered_delivery and multi-parts message


  You're wrong. When you queue the message, you specify the dlr-url to use.


  If kannel splits the message into 3 segments, and you modify kannel to ask 
for DLR's on the 3 of them, you'll get the same dlr-url called 3 times.


  If you set dlr-url=http://my.host.com/dlr.php?id=1234, it will be called 3 
TIMES with "1234".


  Only"dynamic" elements like the timestamp or any other thing that could 
change between parts would change, but your "id" would continue to be 1234. 
Good luck dealing with it on your DLR handling application...


  Regards,


  Alex


  2010/9/15 Nikos Balkanas <[email protected]>

    Actually, it won't complain. Each received submit_sm_resp will generate a 
separate dlr_entry, one for each part. When the respective DLRs arrive they 
will be correctly matched and call a different dlr_url in smsbox one for each 
part, as correctly pointed out by Alex.

    smpp->sent_msgs is matched since it is filled after sms is split by 
bearerbox.

    BR,
    Nikos
    ----- Original Message ----- From: "Rene Kluwen" <[email protected]>
    To: "'Ivan Kurnosov'" <[email protected]>; "'Nikos Balkanas'" 
<[email protected]>; <[email protected]>
    Sent: Wednesday, September 15, 2010 3:35 PM
    Subject: RE: registered_delivery and multi-parts message



      True, it's a Kannel thing, not an smpp spec issue.
      What you did probably won't break Kannel... but... you might get some log
      messages where Kannel complains about not being able to find DLR or not
      interested in it.

      == Rene

      -----Original Message-----
      From: [email protected] [mailto:[email protected]] On Behalf
      Of Ivan Kurnosov
      Sent: Wednesday, 15 September, 2010 14:08
      To: Nikos Balkanas; [email protected]

      Subject: Re: registered_delivery and multi-parts message

      How they can broke it? It is just removing registered_delivery from
      other messages than 1st

      2010/9/15 Nikos Balkanas <[email protected]>:

        That's a kannel, not a spec limitation. And these 3 lines of code you
        changed propably have broken your kannel.

        BR,
        Nikos
        ----- Original Message ----- From: "Ivan Kurnosov" <[email protected]>
        To: "Nikos Balkanas" <[email protected]>; <[email protected]>
        Sent: Wednesday, September 15, 2010 2:24 PM
        Subject: Re: registered_delivery and multi-parts message


        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








Reply via email to