sending fake DLRs via fakesmsc?
Hello, Is there a way to send make fakesmsc send a bogus (artificially constructed) DLR to bearerbox? Gerald -- Gerald Timothy Quimpo http://bopolissimus.blogspot.com bopolissimus.li...@gmail.com bopolissi...@gmail.com Even Tom Lane said: Or, if you're worried about actions from functions, use a trigger to do the logging. There are approximately no cases where a rule is really better than a trigger :-(
Re: sending fake DLRs via fakesmsc?
On Thu, Oct 21, 2010 at 12:09 PM, Bopolissimus Platypus Jr bopolissimus.li...@gmail.com wrote: Is there a way to send make fakesmsc send a bogus (artificially constructed) DLR to bearerbox? Never mind. I see in smsc_fake.c creates the DLRs, they're not actually sent from fakesmsc. Gerald -- Gerald Timothy Quimpo http://bopolissimus.blogspot.com bopolissimus.li...@gmail.com bopolissi...@gmail.com Even Tom Lane said: Or, if you're worried about actions from functions, use a trigger to do the logging. There are approximately no cases where a rule is really better than a trigger :-(
Re: concatenated MOs whose parts arrive at different kannels?
Thank you Nikos. We don't have the flexibility of using multiple accounts so we'll just have to do the concatenation on the backend then. Gerald 2010/9/7 Nikos Balkanas nbalka...@gmail.com: No. There are SMScs out there that will recognise sockets (or IPs) and will send each part of a concatenated SMS to the same socket. Some others do (as is in your case). The only thing you can do that works, is to use different accounts to connect from each kannel. BR, Nikos - Original Message - From: Bopolissimus Platypus Jr bopolissimus.li...@gmail.com To: users@kannel.org Sent: Tuesday, September 07, 2010 5:44 AM Subject: concatenated MOs whose parts arrive at different kannels? Hello, We have a setup where we have two separate kannel instances each binding (RX and TX) to the same two SMSCs. Only RX Connections shown below since TX is not relevant. Kannel1 --- SMSC1 | --- SMSC2 Kannel2 --- SMSC1 | --- SMSC2 In previous testing with just one Kannel, different parts of a concatenated SMS can arrive via both SMSCs (setting smsc-id the same for logically equivalent SMSCs allows concatenation to work correctly in this case). This almost certainly extends to having two kannels with this setup (conjecture, not tested since that's a production system).. The parts of a concatenated SMS might arrive via 1 each of the four connections so Kannel1 might end up with parts 1 and 3 and Kannel2 might end up with parts 2 and 4. We have not previously needed to use sms-combine-concatenated-mo since there was previously no concatenated SMS support for this service. However, we are now looking into implementing concatenated message support and therefore are looking into options for automatic SMS combination in the above setup. Apart from turning off sms-combine-concatenated-mo and recombining the parts at the backend, are there any options for supporting combining at the kannels (somehow)? There was a conjecture among my colleagues that sqlbox might be a possibility. However, after looking at the sqlbox userguide and some of the code, I don't see anything like that. Thanks for any pointers, or for showing where we might be going wrogn. Gerald -- Gerald Timothy Quimpo http://bopolissimus.blogspot.com bopolissimus.li...@gmail.com bopolissi...@gmail.com Even Tom Lane said: Or, if you're worried about actions from functions, use a trigger to do the logging. There are approximately no cases where a rule is really better than a trigger :-( -- Gerald Timothy Quimpo http://bopolissimus.blogspot.com bopolissimus.li...@gmail.com bopolissi...@gmail.com Even Tom Lane said: Or, if you're worried about actions from functions, use a trigger to do the logging. There are approximately no cases where a rule is really better than a trigger :-(
concatenated MOs whose parts arrive at different kannels?
Hello, We have a setup where we have two separate kannel instances each binding (RX and TX) to the same two SMSCs. Only RX Connections shown below since TX is not relevant. Kannel1 --- SMSC1 | --- SMSC2 Kannel2 --- SMSC1 | --- SMSC2 In previous testing with just one Kannel, different parts of a concatenated SMS can arrive via both SMSCs (setting smsc-id the same for logically equivalent SMSCs allows concatenation to work correctly in this case). This almost certainly extends to having two kannels with this setup (conjecture, not tested since that's a production system).. The parts of a concatenated SMS might arrive via 1 each of the four connections so Kannel1 might end up with parts 1 and 3 and Kannel2 might end up with parts 2 and 4. We have not previously needed to use sms-combine-concatenated-mo since there was previously no concatenated SMS support for this service. However, we are now looking into implementing concatenated message support and therefore are looking into options for automatic SMS combination in the above setup. Apart from turning off sms-combine-concatenated-mo and recombining the parts at the backend, are there any options for supporting combining at the kannels (somehow)? There was a conjecture among my colleagues that sqlbox might be a possibility. However, after looking at the sqlbox userguide and some of the code, I don't see anything like that. Thanks for any pointers, or for showing where we might be going wrogn. Gerald -- Gerald Timothy Quimpo http://bopolissimus.blogspot.com bopolissimus.li...@gmail.com bopolissi...@gmail.com Even Tom Lane said: Or, if you're worried about actions from functions, use a trigger to do the logging. There are approximately no cases where a rule is really better than a trigger :-(
Re: Strange concatenated MO issue
2010/8/30 Nikos Balkanas nbalka...@gmail.com: What is the corresponding access log entry? I've been clearing the logs, so I don't have the corresponding entries for the previous message. Instead I tested again. Attached are both the relevant PDUs from the bearerbox log and the corresponding access log. I've added a bunch of fields in the access log for debugging. I've also semi-obfuscated some identifying information but nothing that would make analysis go wrong. 2010-08-29 23:23:12 [27180] [10] DEBUG: Optional parameter tag (0x0204) 2010-08-29 23:23:12 [27180] [10] DEBUG: Optional parameter length read as 2 2010-08-29 23:23:12 [27180] [10] DEBUG: SMPP[X-XX]: Got PDU: 2010-08-29 23:23:12 [27180] [10] DEBUG: SMPP PDU 0x8fd460 dump: 2010-08-29 23:23:12 [27180] [10] DEBUG: type_name: deliver_sm 2010-08-29 23:23:12 [27180] [10] DEBUG: command_id: 5 = 0x0005 2010-08-29 23:23:12 [27180] [10] DEBUG: command_status: 0 = 0x 2010-08-29 23:23:12 [27180] [10] DEBUG: sequence_number: 384 = 0x0180 2010-08-29 23:23:12 [27180] [10] DEBUG: service_type: NULL 2010-08-29 23:23:12 [27180] [10] DEBUG: source_addr_ton: 1 = 0x0001 2010-08-29 23:23:12 [27180] [10] DEBUG: source_addr_npi: 1 = 0x0001 2010-08-29 23:23:12 [27180] [10] DEBUG: source_addr: 649 2010-08-29 23:23:12 [27180] [10] DEBUG: dest_addr_ton: 2 = 0x0002 2010-08-29 23:23:12 [27180] [10] DEBUG: dest_addr_npi: 1 = 0x0001 2010-08-29 23:23:12 [27180] [10] DEBUG: destination_addr: 4008 2010-08-29 23:23:12 [27180] [10] DEBUG: esm_class: 64 = 0x0040 2010-08-29 23:23:12 [27180] [10] DEBUG: protocol_id: 0 = 0x 2010-08-29 23:23:12 [27180] [10] DEBUG: priority_flag: 1 = 0x0001 2010-08-29 23:23:12 [27180] [10] DEBUG: schedule_delivery_time: NULL 2010-08-29 23:23:12 [27180] [10] DEBUG: validity_period: NULL 2010-08-29 23:23:12 [27180] [10] DEBUG: registered_delivery: 0 = 0x 2010-08-29 23:23:12 [27180] [10] DEBUG: replace_if_present_flag: 0 = 0x 2010-08-29 23:23:12 [27180] [10] DEBUG: data_coding: 240 = 0x00f0 2010-08-29 23:23:12 [27180] [10] DEBUG: sm_default_msg_id: 0 = 0x 2010-08-29 23:23:12 [27180] [10] DEBUG: sm_length: 140 = 0x008c 2010-08-29 23:23:12 [27180] [10] DEBUG: short_message: 2010-08-29 23:23:12 [27180] [10] DEBUG:Octet string at 0x90d870: 2010-08-29 23:23:12 [27180] [10] DEBUG: len: 140 2010-08-29 23:23:12 [27180] [10] DEBUG: size: 141 2010-08-29 23:23:12 [27180] [10] DEBUG: immutable: 0 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 05 00 03 21 02 01 72 b9 5c 2e 97 cb e5 72 b9 58 ...!..r.\r.X 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 2e 97 cb e5 72 b9 5c 4e 96 cb e5 72 b9 5c 2e 97 r.\N...r.\.. 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 9b e5 72 b9 5c 2e 97 cb e5 68 b9 5c 2e 97 cb e5 ..r.\h.\ 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 72 b9 5a 2e 97 cb e5 72 b9 5c ce 96 cb e5 72 b9 r.Zr.\r. 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 5c 2e 97 bb e5 72 b9 5c 2e 97 cb e5 70 b9 5c 2e \r.\p.\. 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 97 cb e5 72 da 5c 2e 97 cb e5 72 b9 1c 2c 97 cb ...r.\r..,.. 2010-08-29 23:23:12 [27180] [10] DEBUG: data: e5 72 b9 5c 2e 17 cb e5 72 b9 5c 2e 97 cb c9 72 .r.\r.\r 2010-08-29 23:23:12 [27180] [10] DEBUG: data: b9 5c 2e 97 cb e5 72 b3 5c 2e 97 cb e5 72 b9 1c .\r.\r.. 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 2d 97 cb e5 72 b9 5c 2e 57 cb e5 72 -...r.\.W..r 2010-08-29 23:23:12 [27180] [10] DEBUG:Octet string dump ends. 2010-08-29 23:23:12 [27180] [10] DEBUG: user_message_reference: 109 = 0x006d 2010-08-29 23:23:12 [27180] [10] DEBUG: SMPP PDU dump ends. 2010-08-29 23:23:12 [27180] [10] DEBUG: SMPP[X-XX]: UDH length read as 6 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xb9) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0x97) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xcb) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xe5) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xb9) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0x97) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xcb) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xe5) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xb9) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0x96) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xcb) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xe5) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xb9) to Unicode. 2010-08-29 23:23:12 [27180] [10]
Strange concatenated MO issue
Hello all, I have an SMSC connection to Telecom New Zealand. When I test my connection by sending a multipart text message from a handset to a shortcode I get weird text at kannel. Sending a single part text message from exactly the same handset works correctly. My long text message is: 99192939495969798Z9091929394959612345 What I receive at the get-url for the text is: text=r%C3%96.rX.r%C3%96Nr%C3%96.r%C3%96.h%C3%96.rZ.r%C3%96r%C3%96.r%C3%96.p%C3%96.r%C3%96.r%C3%86%2Cr%C3%96.%CE%A8r%C3%96.r%C3%96.r%C3%96.r%C3%86-r%C3%96.Wrr%C3%96.d3Z When I urldecode that I get (in hex, with a space between characters): c3 96 2e 72 58 2e 72 c3 96 4e 72 c3 96 2e 72 c3 96 2e 68 c3 96 2e 72 5a 2e 72 c3 96 72 c3 96 2e 72 c3 96 2e 70 c3 96 2e 72 c3 96 2e 72 c3 86 2c 72 c3 96 2e ce a8 72 c3 96 2e 72 c3 96 2e 72 c3 96 2e 72 c3 86 2d 72 c3 96 2e 57 72 72 c3 96 2e 64 33 5a Has anyone seen something similar to this and can point me at a solution (or in the direction of likely things to look at)? The initial PDU (with some information obfuscated and with some following messages) is: 2010-08-26 04:27:12 [30851] [10] DEBUG: Optional parameter tag (0x0204) 2010-08-26 04:27:12 [30851] [10] DEBUG: Optional parameter length read as 2 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP[X-XX]: Got PDU: 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP PDU 0xe0f580 dump: 2010-08-26 04:27:12 [30851] [10] DEBUG: type_name: deliver_sm 2010-08-26 04:27:12 [30851] [10] DEBUG: command_id: 5 = 0x0005 2010-08-26 04:27:12 [30851] [10] DEBUG: command_status: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: sequence_number: 351 = 0x015f 2010-08-26 04:27:12 [30851] [10] DEBUG: service_type: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr_ton: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr_npi: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr: 649 2010-08-26 04:27:12 [30851] [10] DEBUG: dest_addr_ton: 2 = 0x0002 2010-08-26 04:27:12 [30851] [10] DEBUG: dest_addr_npi: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: destination_addr: 2010-08-26 04:27:12 [30851] [10] DEBUG: esm_class: 64 = 0x0040 2010-08-26 04:27:12 [30851] [10] DEBUG: protocol_id: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: priority_flag: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: schedule_delivery_time: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: validity_period: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: registered_delivery: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: replace_if_present_flag: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: data_coding: 240 = 0x00f0 2010-08-26 04:27:12 [30851] [10] DEBUG: sm_default_msg_id: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: sm_length: 140 = 0x008c 2010-08-26 04:27:12 [30851] [10] DEBUG: short_message: 2010-08-26 04:27:12 [30851] [10] DEBUG:Octet string at 0xe0f4b0: 2010-08-26 04:27:12 [30851] [10] DEBUG: len: 140 2010-08-26 04:27:12 [30851] [10] DEBUG: size: 141 2010-08-26 04:27:12 [30851] [10] DEBUG: immutable: 0 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 05 00 03 16 02 01 72 b9 5c 2e 97 cb e5 72 b9 58 ..r.\r.X 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 2e 97 cb e5 72 b9 5c 4e 96 cb e5 72 b9 5c 2e 97 r.\N...r.\.. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 9b e5 72 b9 5c 2e 97 cb e5 68 b9 5c 2e 97 cb e5 ..r.\h.\ 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 72 b9 5a 2e 97 cb e5 72 b9 5c ce 96 cb e5 72 b9 r.Zr.\r. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 5c 2e 97 bb e5 72 b9 5c 2e 97 cb e5 70 b9 5c 2e \r.\p.\. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 97 cb e5 72 da 5c 2e 97 cb e5 72 b9 1c 2c 97 cb ...r.\r..,.. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: e5 72 b9 5c 2e 17 cb e5 72 b9 5c 2e 97 cb c9 72 .r.\r.\r 2010-08-26 04:27:12 [30851] [10] DEBUG: data: b9 5c 2e 97 cb e5 72 b3 5c 2e 97 cb e5 72 b9 1c .\r.\r.. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 2d 97 cb e5 72 b9 5c 2e 57 cb e5 72 -...r.\.W..r 2010-08-26 04:27:12 [30851] [10] DEBUG:Octet string dump ends. 2010-08-26 04:27:12 [30851] [10] DEBUG: user_message_reference: 85 = 0x0055 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP PDU dump ends. 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP[MAS01-RX]: UDH length read as 6 2010-08-26 04:27:12 [30851] [10] WARNING: Could not convert GSM (0xb9) to Unicode. 2010-08-26 04:27:12 [30851] [10] WARNING: Could not convert GSM (0x97) to Unicode. 2010-08-26 04:27:12 [30851] [10] WARNING: Could not convert GSM (0xcb) to Unicode. 2010-08-26 04:27:12 [30851] [10] WARNING: Could not convert GSM (0xe5) to Unicode. 2010-08-26 04:27:12 [30851] [10] WARNING: Could
ViewCVS link doesn't work?
Hello, I was looking at: http://www.kannel.org/download.shtml and I saw a link to ViewCVS: http://www.kannel.org/cgi-bin/viewcvs.cgi The link gives a 404 though. Has the URL changed? or is viewCVS no longer used? Not a big deal, I'll just use cvs at the command line, just pointing it out so webmaster can fix :-). tiger -- Gerald Timothy Quimpo http://bopolissimus.blogspot.com gqui...@qsr.com.ph bopolissimus.li...@gmail.com Public Key: gpg --keyserver pgp.mit.edu --recv-keys 672F4C78 Usually, a very large amount of work goes into the parsing step (Perl and C++ are probably the best examples of this-both are basically unparseable.)
