A workaround for the issue rised by Alex might be to use a sort of virtual smsc_id for long messages in order to force long messages --or, if you do the split by yourself-- each sms part to use only that specific smsc.
I mean send long sms or its parts using "...&smsc=smsc_long_sms..." and add to only one of your smsc's config: allowed-smsc = ..., smsc_long_sms, ... This way all sms/sms parts set to this smsc will go only through this specific smsc. All other sms will continue to go through the smsc you normally use and will load balance as usual. Regards Alvaro On 3/9/12, Rene Kluwen <rene.klu...@chimit.nl> wrote: > Please also note the answer of Alex Malysh. > > It is just a matter of trying and see if it will work for you. > > If you have multiple connections to the same smsc, it might (possibly) work. > > But for the same matter it doesn't, for the reasons that Alex stated. So see > if it works or not. > > > > =+= Rene > > > > From: Ashish Agarwal [mailto:ashisha...@gmail.com] > Sent: Thursday, 08 March, 2012 05:22 > To: Alexander Malysh > Cc: users@kannel.org; Rene Kluwen > Subject: Re: NACK reporting help > > > > Hi, > > Please help me how can this be achieved. > > On Mar 8, 2012 2:00 AM, "Alexander Malysh" <amal...@kannel.org> wrote: > > Hi Rene, > > > > this will not work, because multipart message, means each part, have to go > via the same SMSC, otherwise handset may reject it. > > > > Alex > > > > Am 07.03.2012 um 15:57 schrieb Rene Kluwen: > > > > > > That shouldn't be a problem if the dlr-url your pass is also generic. > > > > From: Ashish Agarwal [mailto:ashisha...@gmail.com] > Sent: Wednesday, 07 March, 2012 15:36 > To: Rene Kluwen > Cc: Alexander Malysh; users@kannel.org > Subject: RE: NACK reporting help > > > > I agree with you Rene, but the problem here is that if I have multiple smsc > and if I am using a generic smsc name for all smsc, determing the right smsc > from where the 1st or the 2nd part was sent will be difficult and troubling. > > 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 <http://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 <http://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 > <http://XX.XX.XX.XX/apps/report1/dlr.php?status=%25A&type=%25d&id=27-1&smsci > d=%25i> &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 > > > > > > -- |-----------------------------------------------------------------------------------------------------------------| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com
