Try commenting out completely msg-id-type if it would be the same means its
something you need to settle down with your SMSC operator.


2014-07-19 2:13 GMT+04:00 Mario Noboa <[email protected]>:

> You're right the message id is in short_message but it should be in
> receipted_message_id. It's a bug of the operator, but they told me that
> they can't do any change.
>
> That's why I asked to use the timestamp  :)
>
> Here is my config (it tried msg-id-type = 2 but didn't work):
>
> #Rx SMSC1
> group = smsc
> smsc = smpp
> smsc-id = SMSC1
> host = X.X.X.X
> port = 0
> receive-port = 10000
> smsc-username = esystem
> smsc-password = psystem
> system-type =
> interface-version = 34
> throughput=20
> msg-id-type = 1
> allowed-smsc-id = SMSC1
>
>
> #Tx SMSC1
> group = smsc
> smsc = smpp
> smsc-id = SMSC1
> host = X.X.X.X
> port = 10000
> receive-port = 0
> smsc-username = esystem
> smsc-password = psystem
> system-type =
> interface-version = 34
> throughput=20
> msg-id-type = 1
> log-level = 0
> allowed-smsc-id = SMSC1
>
> Thanks!
>
>
> 2014-07-18 16:35 GMT-05:00 spameden <[email protected]>:
>
> Actually, I've just looked at your logs again:
>>
>> 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: Got PDU:
>> 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU 0x11f4cb80 dump:
>> 2014-07-17 12:45:12 [32271] [36] DEBUG:   type_name: submit_sm_resp
>> 2014-07-17 12:45:12 [32271] [36] DEBUG:   command_id: 2147483652 =
>> 0x80000004
>> 2014-07-17 12:45:12 [32271] [36] DEBUG:   command_status: 0 = 0x00000000
>> 2014-07-17 12:45:12 [32271] [36] DEBUG:   sequence_number: 5579 =
>> 0x000015cb
>> 2014-07-17 12:45:12 [32271] [36] DEBUG:   message_id: "1e13a15"
>> 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU dump ends.
>> 2014-07-17 12:45:12 [32271] [36] DEBUG: DLR[internal]: Adding DLR
>> smsc=SMSC1, ts=31537685, src=30100, dst=XXXXXXXXXXX, mask=31, boxc=
>> 2014-07-17 12:45:12 [32271] [36] DEBUG: SMSC[SMSC1]: creating DLR message
>>
>> Message ID is 31537685 in submit_sm.
>>
>> In deliver_sm it's:
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:   short_message:
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:    Octet string at 0x11f4cf80:
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:      len:  119
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:      size: 120
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:      immutable: 0
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:      data: 69 64 3a 30 30 33 31
>> 35 33 37 36 38 35 20 73 75   id:0031537685 su
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:      data: 62 3a 30 30 31 20 64
>> 6c 76 72 64 3a 30 30 31 20   b:001 dlvrd:001
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:      data: 73 75 62 6d 69 74 20
>> 64 61 74 65 3a 31 34 30 37   submit date:1407
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:      data: 31 37 31 32 34 35 20
>> 64 6f 6e 65 20 64 61 74 65   171245 done date
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:      data: 3a 31 34 30 37 31 37
>> 31 32 34 35 20 73 74 61 74   :1407171245 stat
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:      data: 3a 44 45 4c 49 56 52
>> 44 20 65 72 72 3a 30 30 30   :DELIVRD err:000
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:      data: 20 74 65 78 74 3a 6d
>> 65 6e 73 61 6a 65 20 64 65    text:test messa
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:      data: 20 70 72 75 65 62 61
>>                             ge 000
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:    Octet string dump ends.
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:   message_state: 2 = 0x00000002
>> 2014-07-17 12:45:16 [32271] [35] DEBUG:   receipted_message_id: "2496a396"
>>
>> In msg-log it says:  id:0031537685 so it must be either kannel
>> converting it to hex for some reason or maybe some SMSC bug.
>> I can't seem to be able to get hex number from source id so it must be
>> something either at your operator side or something.
>>
>> What is the kannel version you're using? And show your configuration.
>>
>>
>> 2014-07-19 1:16 GMT+04:00 Mario Noboa <[email protected]>:
>>
>> Thanks your answer Spameden. I thought the same thing, but the message
>>> ids are complete different:
>>>
>>> if you see the log:
>>>
>>> submit_sm_resp: message_id: 31537685   (decimal)
>>> deliver_sm:   ts=613852054   (decimal)
>>>
>>> regards,
>>>
>>>
>>>
>>> 2014-07-18 16:04 GMT-05:00 spameden <[email protected]>:
>>>
>>> err, I meant hex in submit_sm and decimal in deliver_sm packets.
>>>>
>>>>
>>>>  2014-07-19 1:04 GMT+04:00 spameden <[email protected]>:
>>>>
>>>> It looks like your SMSC operator gives hex number in submit_sm packet
>>>>> and hex number in deliver_sm, so you need to add this in smsc group
>>>>> configuration:
>>>>>
>>>>> msg-id-type = 0x02
>>>>>
>>>>>
>>>>>
>>>>> 2014-07-19 0:40 GMT+04:00 Mario Noboa <[email protected]>:
>>>>>
>>>>> Of course Niel, thanks!!!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2014-07-18 15:30 GMT-05:00 Niel Smith <[email protected]>
>>>>>> :
>>>>>>
>>>>>> Hi Mario,
>>>>>>>
>>>>>>> Would it be possible to supply the full submit_sm, submit_sm_resp,
>>>>>>> and deliver_sm PDU dumps?
>>>>>>>
>>>>>>>
>>>>>>> On 18 July 2014 22:12, Mario Noboa <[email protected]> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Hi list,
>>>>>>>>
>>>>>>>> I got a DLR problem with an operator.
>>>>>>>>
>>>>>>>> When sent a "submit_sm", kannel receipt a message id:
>>>>>>>>
>>>>>>>> *message_id: "1e13a15"*
>>>>>>>> *DLR[internal]: Adding DLR smsc=SMSC1, ts=31537685, src=30100,
>>>>>>>> dst=XXXXXXXXXXX, mask=31, boxc=*
>>>>>>>>
>>>>>>>>
>>>>>>>> But its DLR arrives with another id:
>>>>>>>>
>>>>>>>> *2014-07-17 12:45:16 [32271] [35] DEBUG: DLR[internal]: Looking for
>>>>>>>> DLR smsc=SMSC1, ts=613852054, dst=975647918, type=1*
>>>>>>>> *2014-07-17 12:45:16 [32271] [35] WARNING: DLR[internal]: DLR from
>>>>>>>> SMSC<SMSC1> for DST<975647918> not found.*
>>>>>>>> *2014-07-17 12:45:16 [32271] [35] ERROR: SMPP[SMSC1]: got DLR but
>>>>>>>> could not find message or was not interested in it id<613852054>
>>>>>>>> dst<XXXXXXXXX>, type<1>*
>>>>>>>>
>>>>>>>>
>>>>>>>> if you notice both are in decimal and they are different. *31537685
>>>>>>>> and **613852054*
>>>>>>>>
>>>>>>>> I tried to configure version 33 to use Timestamp, but they don't
>>>>>>>> let me connect in that way.  There is any way to use timestamp instead 
>>>>>>>> of
>>>>>>>> message id?
>>>>>>>>
>>>>>>>> Thanks for your answers!
>>>>>>>>
>>>>>>>> Mario
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply via email to