I have a question. How do you send 1 long message to Kannel via
multiple-part messages ?

I'm using sqlbox setup. If I do split a long message in multiple and insert
them into send_sms, kannel should send separate messages, not the long one,
right?


On Mar 7, 2012 6:45 PM, "Rene Kluwen" <rene.klu...@chimit.nl> wrote:
>
> One possible solution is not to let Kannel handle multiple-part messages
> but do it yourself.
>
> So instead of passing one long message to Kannel, you split the message up
> in multiple parts and send the different parts to Kannel (including UDH).
>
> Each with a different DLR url.
>
> This way, you will get a failure message per message part.
>
>
>
> == Rene
>
>
>
>
>
> *From:* users-boun...@kannel.org [mailto:users-boun...@kannel.org] *On
> Behalf Of *Alexander Malysh
> *Sent:* Wednesday, 07 March, 2012 13:51
> *To:* Ashish Agarwal
> *Cc:* users@kannel.org
> *Subject:* Re: NACK reporting help
>
>
>
> Hi,
>
>
>
> this is not easy to fix because you send only one but long message and
> awaiting only one DLR.
>
> BUT kannel splits message into peaces for you and receive two DLRs. How
> would you put both reason
>
> codes into one DLR? In you case that would be easy because they both equal
> but what do you do if not?
>
>
>
> Thanks,
>
> Alex
>
>
>
> Am 06.03.2012 um 12:20 schrieb Ashish Agarwal:
>
>
>
> Hello All,
>
>
>
> Any update on the below query.
>
>
>
> On Wed, Feb 22, 2012 at 5:59 PM, Ashish Agarwal <ashisha...@gmail.com>
> wrote:
>
> Hello,
>
>
>
> I have been using kannel for over 2 years now and I am currently using the
> latest 1.5 version of kannel. I have come across an issue with NACK reports
> generated for messages that fails or are rejected by the smsc.
>
>
>
> I have the following problem:-
>
>
>
> As per the PDU user receives the *command_status: 1153 = 0x00000481* from
> the smsc but the kannel esme does not interpret it correctly.
>
>
>
> e.g.
>
>
>
> 2012-02-22 17:24:31 FAILED Send SMS [SMSC:XXXX] [SVC:XXXX] [ACT:XXX]
> [BINF:] [FID:] [META:] [from:XXX] [to:XXXXXXX] [flags:-1:0:-1:-1:19] [msg:
> *185*:1..Create a basic account (Pictorial Representation)..Create a FREE
> basic account on kareeredge.com and start searching and applying for jobs
> through your personal dashboard right away.] [udh:0:]
>
>
>
> 2012-02-22 17:24:31 Receive DLR [SMSC:XXX] [SVC:XXXX] [ACT:] [BINF:]
> [FID:] [META:] [from:XXXX] [to:XXXXXXX] [flags:-1:-1:-1:-1:16] [msg:5:*
> NACK/*] [udh:0:]
>
>
>
>
>
>
>
> As you see NACK/ should contain NACK/*0x00000481. *I have tried this
> with multiple cases and have found out that when esme submits more than 160
> characters of message and the message is rejected by the smppbox we do not
> receive the NACK report correctly whereas when message text is less than
> 160 characters esme receive the report correctly as below:-
>
>
>
>
>
> 2012-02-22 17:23:10 FAILED Send SMS [SMSC:XXXX] [SVC:XXXX] [ACT:XXX]
> [BINF:] [FID:] [META:] [from:XXXX] [to:XXXX] [flags:-1:0:-1:-1:19] [msg:*
> 75*:Dear This is remind to u that,Please sms to 56767 to get more
> products Free] [udh:0:]
>
> 2012-02-22 17:23:10 Receive DLR [SMSC:SIP11] [SVC:smssip1] [ACT:] [BINF:]
> [FID:] [META:] [from:INFINI] [to:919900000147] [flags:-1:-1:-1:-1:16]
> [msg:73:*NACK/0x00000481/Vendor-specific error, please refer to your SMPP
> provider*] [udh:0:]
>
>
>
> Also %A value in dlr-url gives the same output as mentioned above, because
> of which we are not able to trace the exact reason for the sms failure in
> case of sms text more than 160 characters.
>
>
>
> For supporting also find the pdu dump of the message text of 185
> characters:-
>
>
>
> 2012-02-22 17:24:31 [6329] [15] DEBUG: boxc_receiver: sms received
>
> 2012-02-22 17:24:31 [6329] [15] DEBUG: new split_parts created
> 0x2aaab4135f70
>
> 2012-02-22 17:24:31 [6329] [15] DEBUG: send_msg: sending msg to boxc:
> <sqlbox>
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (0.00,0.00)
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: Sending PDU:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   type_name: submit_sm
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   command_id: 4 = 0x00000004
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   command_status: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   sequence_number: 192708 =
> 0x0002f0c4
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   service_type: NULL
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   source_addr_ton: 5 = 0x00000005
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   source_addr_npi: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   source_addr: "XXX"
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   dest_addr_ton: 2 = 0x00000002
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   dest_addr_npi: 1 = 0x00000001
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   destination_addr: "XXXXXXXXXX"
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   esm_class: 67 = 0x00000043
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   protocol_id: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   priority_flag: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   schedule_delivery_time: NULL
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   validity_period: NULL
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   registered_delivery: 1 = 0x00000001
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   replace_if_present_flag: 0 =
> 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   data_coding: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   sm_default_msg_id: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   sm_length: 159 = 0x0000009f
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   short_message:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:    Octet string at 0x2aaab4172160:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      len:  159
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      size: 1024
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      immutable: 0
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 05 00 03 90 02 01 31 2e
> 3f 43 72 65 61 74 65 20   ......1.?Create
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 61 20 62 61 73 69 63 20
> 61 63 63 6f 75 6e 74 20   a basic account
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 28 50 69 63 74 6f 72 69
> 61 6c 20 52 65 70 72 65   (Pictorial Repre
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 73 65 6e 74 61 74 69 6f
> 6e 29 0d 0a 43 72 65 61   sentation)..Crea
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 74 65 20 61 20 46 52 45
> 45 20 62 61 73 69 63 20   te a FREE basic
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 61 63 63 6f 75 6e 74 20
> 6f 6e 20 6b 61 72 65 65   account on karee
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 72 65 64 67 65 2e 63 6f
> 6d 20 61 6e 64 20 73 74   redge.com and st
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 61 72 74 20 73 65 61 72
> 63 68 69 6e 67 20 61 6e   art searching an
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 64 20 61 70 70 6c 79 69
> 6e 67 20 66 6f 72 20 6a   d applying for j
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 6f 62 73 20 74 68 72 6f
> 75 67 68 20 79 6f 75      obs through you
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:    Octet string dump ends.
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   more_messages_to_send: 1 =
> 0x00000001
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU dump ends.
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (1.00,0.00)
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: Sending PDU:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   type_name: submit_sm
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   command_id: 4 = 0x00000004
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   command_status: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   sequence_number: 192709 =
> 0x0002f0c5
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   service_type: NULL
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   source_addr_ton: 5 = 0x00000005
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   source_addr_npi: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   source_addr: "XXX"
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   dest_addr_ton: 2 = 0x00000002
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   dest_addr_npi: 1 = 0x00000001
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   destination_addr: "XXXXXXXXXX"
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   esm_class: 67 = 0x00000043
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   protocol_id: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   priority_flag: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   schedule_delivery_time: NULL
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   validity_period: NULL
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   registered_delivery: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   replace_if_present_flag: 0 =
> 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   data_coding: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   sm_default_msg_id: 0 = 0x00000000
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   sm_length: 38 = 0x00000026
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   short_message:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:    Octet string at 0x2aaab4139270:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      len:  38
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      size: 1024
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      immutable: 0
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 05 00 03 90 02 02 72 20
> 70 65 72 73 6f 6e 61 6c   ......r personal
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 20 64 61 73 68 62 6f 61
> 72 64 20 72 69 67 68 74    dashboard right
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:      data: 20 61 77 61 79 2e
>                          away.
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:    Octet string dump ends.
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU dump ends.
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (2.00,0.00)
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (2.00,0.00)
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: Got PDU:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   type_name: submit_sm_resp
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   command_id: 2147483652 = 0x80000004
>
> *2012-02-22 17:24:31 [6329] [8] DEBUG:   command_status: 1153 = 0x00000481
> *
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   sequence_number: 192708 =
> 0x0002f0c4
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   message_id: NULL
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU dump ends.
>
> *2012-02-22 17:24:31 [6329] [8] ERROR: SMPP[XXXX]: SMSC returned error
> code 0x00000481 (Vendor-specific error, please refer to your SMPP provider)
> in response to submit_sm.*
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: Set split msg status to 3
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (2.00,0.00)
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (2.00,0.00)
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: Got PDU:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump:
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   type_name: submit_sm_resp
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   command_id: 2147483652 = 0x80000004
>
> *2012-02-22 17:24:31 [6329] [8] DEBUG:   command_status: 1153 = 0x00000481
> *
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   sequence_number: 192709 =
> 0x0002f0c5
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG:   message_id: NULL
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU dump ends.
>
> *2012-02-22 17:24:31 [6329] [8] ERROR: SMPP[XXXX]: SMSC returned error
> code 0x00000481 (Vendor-specific error, please refer to your SMPP provider)
> in response to submit_sm.*
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: Set split msg status to 3
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: Parts of concatenated message failed.
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMSC[XXXX]: creating DLR message
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMSC[XXXX]: DLR =
> http://XX.XX.XX.XX/apps/report1/dlr.php?status=%A&type=%d&id=27-1&smscid=%i
>
> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (2.00,0.00)
>
> 2012-02-22 17:24:31 [6329] [18] DEBUG: send_msg: sending msg to boxc:
> <smsbox>
>
> 2012-02-22 17:24:31 [6329] [18] DEBUG: boxc_sender: sent message to
> <127.0.0.1>
>
> 2012-02-22 17:24:31 [6329] [17] DEBUG: boxc_receiver: got ack
>
> 2012-02-22 17:24:34 [6329] [17] DEBUG: boxc_receiver: heartbeat with load
> value 0 received
>
>
>
>
>
> I think it is a bug with smsbox. Please help.
>
>
>
>
>
> --
> Regards,
>
> Ashish
>
>
>
>
>
> --
> Regards,
>
> Ashish Agarwal
>
>
>

Reply via email to