I'm using SVN dated about 4 months ago (not an option to update due to the risk of breaking something else - the devil you know...)
I've started a project, guess you might call it a "smpp proxy server" of sorts, replacing kannel completely. Regards, info.ubichip wrote: > > 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. > > > > > > -- 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-tp31042793p34018513.html Sent from the Kannel - User mailing list archive at Nabble.com.
