Thanks for your answer again. which opensmppbox are you using ? I just checked the svn repository, it looks some dlr source code is now inside the opensmppbox, perhaps there is a good way to make correction inside direclty ?
I'm not sure to understand "kannel will be past memory", do you quit the telecom world or kannel is going to die ? Best regards -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Niel Envoyé : vendredi 15 juin 2012 13:58 À : [email protected] Objet : RE: OpenSMPP+Kannel: DLR: (dst & src) are expected INVETED in the deliver_sm (but remains as in submit_sm) Hi, This is intended for swapping the src and dest for delivery report for clients connected using opensmppbox. If you are using the same bearerbox for other purposes, such as http smsc and/or proxy, the delivery reports src and dest will also be swapped around. You might need to swap the fields in the get-url or via script. Personally I use a different bearerbox for each gateway, and a separate one for opensmppbox, due to smsbox not being able to deal with any form of real load. Each bearerbox has it's own mysql dlr table, and I only apply the trigger to the ones using opensmppbox. Luckily, soon kannel will be past memory; a horror story to tell my kids around the campfire :) Regards, info.ubichip wrote: > > Thanks a lot, I will try it very soon. > > one more question : does it change the way the dlr are coming back to > the originator of the request through SMPP ? > > -----Message d'origine----- > De : [email protected] [mailto:[email protected]] De la > part de Niel Envoyé : vendredi 15 juin 2012 13:25 À : [email protected] > Objet : RE: OpenSMPP+Kannel: DLR: (dst & src) are expected INVETED in > the deliver_sm (but remains as in submit_sm) > > > Yes, that is where the trigger should be. My kannel config has been > set to use the table kannel.dlr, and columns dest and src. > > The MySQL command would look something like this: > > delimiter $ > CREATE TRIGGER `kannel`.`dlr_src_dest_swap_trigger` > BEFORE INSERT ON `kannel`.`dlr` > FOR EACH ROW > BEGIN > DECLARE temp VARCHAR(100); > SET temp = NEW.src; > SET NEW.src = NEW.dest; > SET NEW.dest = temp; > END > $ > > Other useful commands: > > SHOW TRIGGERS; > DROP TRIGGER `dlr_src_dest_swap_trigger`; SHOW CREATE TRIGGER > `dlr_src_dest_swap_trigger`; > > Regards, > > > > info.ubichip wrote: >> >> Hello, >> >> is it possible to have your "mysql trigger" on the DLR table ? >> >> thanks in advance >> >> -----Message d'origine----- >> De : [email protected] [mailto:[email protected]] De la >> part de Niel Envoyé : mardi 20 mars 2012 07:54 À : [email protected] >> Objet : Re: OpenSMPP+Kannel: DLR: (dst & src) are expected INVETED in >> the deliver_sm (but remains as in submit_sm) >> >> >> Hi, >> >> I know this is old, but, this issue still exists in the latest SVN. >> >> My brearbox is set to use mysql storage for DLRs. As workaround I >> added a mysql trigger on the DLR table before insert that swaps the >> src and dest values. >> >> Regards, >> >> >> >> Dídac Royo wrote: >>> >>> Hi Users, >>> >>> I need your help. >>> >>> We have a problem in our Kannel + openSMPPbox. The values of >>> parameters: >>> dst & src are expected INVETED in the deliver_sm, I'm I correct? >>> >>> >>> In the logs *source_addr* & *destination_addr* have the same in both >>> * >>> submit_sm* and *deliver_sm* operations (when we expect them inverted >>> in the >>> deliver_sm) >>> >>> >>>>>This is our log for the submit_sm: >>> >>> >>> *2011-03-01 16:50:00 [634] [6] DEBUG: SMPP[ISMSAD]: Got PDU: >>> 2011-03-01 16:50:00 [634] [6] DEBUG: SMPP PDU 0x73b700 dump: >>> 2011-03-01 16:50:00 [634] [6] DEBUG: type_name: submit_sm >>> 2011-03-01 16:50:00 [634] [6] DEBUG: command_id: 4 = 0x00000004 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: command_status: 0 = 0x00000000 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: sequence_number: 1404 = >>> 0x0000057c >>> 2011-03-01 16:50:00 [634] [6] DEBUG: service_type: NULL >>> 2011-03-01 16:50:00 [634] [6] DEBUG: source_addr_ton: 5 = 0x00000005 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: source_addr_npi: 0 = 0x00000000 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: source_addr: "Info" >>> 2011-03-01 16:50:00 [634] [6] DEBUG: dest_addr_ton: 1 = 0x00000001 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: dest_addr_npi: 1 = 0x00000001 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: destination_addr: "34695839615" >>> 2011-03-01 16:50:00 [634] [6] DEBUG: esm_class: 3 = 0x00000003 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: protocol_id: 0 = 0x00000000 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: priority_flag: 0 = 0x00000000 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: schedule_delivery_time: NULL >>> 2011-03-01 16:50:00 [634] [6] DEBUG: validity_period: NULL >>> 2011-03-01 16:50:00 [634] [6] DEBUG: registered_delivery: 1 = >>> 0x00000001 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: replace_if_present_flag: 0 = >>> 0x00000000 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: data_coding: 0 = 0x00000000 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000 >>> 2011-03-01 16:50:00 [634] [6] DEBUG: sm_length: 10 = 0x0000000a >>> 2011-03-01 16:50:00 [634] [6] DEBUG: short_message: "test 16:48" >>> 2011-03-01 16:50:00 [634] [6] DEBUG: SMPP PDU dump ends.* >>> >>> >>>>>and this is our log for the deiver_sm: >>> >>> >>> *2011-03-01 16:50:04 [634] [5] DEBUG: SMPP[ISMSAD]: Sending PDU: >>> 2011-03-01 16:50:04 [634] [5] DEBUG: SMPP PDU 0x73fd30 dump: >>> 2011-03-01 16:50:04 [634] [5] DEBUG: type_name: deliver_sm >>> 2011-03-01 16:50:04 [634] [5] DEBUG: command_id: 5 = 0x00000005 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: command_status: 0 = 0x00000000 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: sequence_number: 1 = 0x00000001 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: service_type: NULL >>> 2011-03-01 16:50:04 [634] [5] DEBUG: source_addr_ton: 2 = 0x00000002 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: source_addr_npi: 1 = 0x00000001 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: source_addr: "Info" >>> 2011-03-01 16:50:04 [634] [5] DEBUG: dest_addr_ton: 1 = 0x00000001 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: dest_addr_npi: 1 = 0x00000001 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: destination_addr: "34695839615" >>> 2011-03-01 16:50:04 [634] [5] DEBUG: esm_class: 4 = 0x00000004 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: protocol_id: 0 = 0x00000000 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: priority_flag: 0 = 0x00000000 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: schedule_delivery_time: NULL >>> 2011-03-01 16:50:04 [634] [5] DEBUG: validity_period: NULL >>> 2011-03-01 16:50:04 [634] [5] DEBUG: registered_delivery: 0 = >>> 0x00000000 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: replace_if_present_flag: 0 = >>> 0x00000000 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: data_coding: 0 = 0x00000000 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: sm_default_msg_id: 0 = 0x00000000 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: sm_length: 0 = 0x00000000 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: short_message: >>> 2011-03-01 16:50:04 [634] [5] DEBUG: Octet string at 0x73a350: >>> 2011-03-01 16:50:04 [634] [5] DEBUG: len: 112 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: size: 1024 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: immutable: 0 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: data: 69 64 3a 33 30 37 32 30 >>> 66 >>> 30 36 20 73 75 62 3a id:30720f06 sub: >>> 2011-03-01 16:50:04 [634] [5] DEBUG: data: 30 30 31 20 64 6c 76 72 >>> 64 >>> 3a 30 30 31 20 73 75 001 dlvrd:001 su >>> 2011-03-01 16:50:04 [634] [5] DEBUG: data: 62 6d 69 74 20 64 61 74 >>> 65 >>> 3a 31 31 30 33 30 31 bmit date:110301 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: data: 31 36 35 30 20 64 6f 6e >>> 65 >>> 20 64 61 74 65 3a 31 1650 done date:1 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: data: 31 30 33 30 31 31 36 35 >>> 30 >>> 20 73 74 61 74 3a 44 103011650 stat:D >>> 2011-03-01 16:50:04 [634] [5] DEBUG: data: 45 4c 49 56 52 44 20 65 >>> 72 >>> 72 3a 30 30 30 20 74 ELIVRD err:000 t >>> 2011-03-01 16:50:04 [634] [5] DEBUG: data: 65 78 74 3a 20 20 20 20 >>> 20 >>> 20 20 20 20 20 20 20 ext: >>> 2011-03-01 16:50:04 [634] [5] DEBUG: Octet string dump ends. >>> 2011-03-01 16:50:04 [634] [5] DEBUG: message_state: 2 = 0x00000002 >>> 2011-03-01 16:50:04 [634] [5] DEBUG: receipted_message_id: "30720f06" >>> 2011-03-01 16:50:04 [634] [5] DEBUG: dlr_err: "000" >>> 2011-03-01 16:50:04 [634] [5] DEBUG: SMPP PDU dump ends. >>> 2011-03-01 16:50:04 [634] [5] ERROR: SMPP: Unknown TLV `dlr_err', >>> don't >>> send.* >>> >>> and looking at bearerbox.access... >>> >>> *2011-03-01 16:50:00 Sent SMS [SMSC:GMS] [SVC:ismsad] [ACT:] [BINF:] >>> [FID:110301S00d1a44c] [META:?smpp?] [from:Info] [to:+34695839615] >>> [flags:-1:0:**-1:0:19] [msg:10:test 16:48] [udh:0:]* >>> *2011-03-01 16:50:04 Receive DLR [SMSC:GMS] [SVC:ismsad] [ACT:sit2] >>> [BINF:] [FID:110301S00d1a44c] [META:?smpp?dlr_err=000&] [from:Info] >>> [to:+34695839615] [flags:-1:-1:-1:-1:1] [msg:111:id:110301S00d1a44c >>> sub:000 dlvrd:000 submit >>> date:1103011650 done date:1103011650 stat:DELIVRD err:000 text: ] >>> [udh:0:]* >>> >>> What I'm doing wrong? >>> is there any known issue? >>> >>> Any help is appreciated! please help! >>> >>> Thanks guys! >>> >>> Didac >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/OpenSMPP%2BKannel%3A-DLR%3A-%28dst---src%29-are >> - >> expected-INVETED-in-the-deliver_sm-%28but-remains-as-in-submit_sm%29- >> t p31042793p33536778.html Sent from the Kannel - User mailing list >> archive at Nabble.com. >> >> >> >> >> >> > > -- > View this message in context: > http://old.nabble.com/OpenSMPP%2BKannel%3A-DLR%3A-%28dst---src%29-are- > expected-INVETED-in-the-deliver_sm-%28but-remains-as-in-submit_sm%29-t > p31042793p34017505.html Sent from the Kannel - User mailing list > archive at Nabble.com. > > > > > > -- View this message in context: http://old.nabble.com/OpenSMPP%2BKannel%3A-DLR%3A-%28dst---src%29-are-expected-INVETED-in-the-deliver_sm-%28but-remains-as-in-submit_sm%29-tp31042793p34017627.html Sent from the Kannel - User mailing list archive at Nabble.com.
