Re: STRANGE: kannel source and destination address inversion in deliver_sm not happening

[Sayed Hadi Rastgou Haghi]

Hi.

No need to reverse numbers. because in dlr responses kannel only tells the
smsc that it got the dlr.
In logs, kannel tells you the originating data of message (sender,
receiver).


On Fri, Jul 5, 2019 at 9:32 PM Amritesh Rachelwar 
wrote:

> Hello Guys,
>
> I am observing a very strange behavior of kannel. When it is receiving
> DLRs its not reversing the source and destination.
>
> Is it like that only, because smpp v3.4 says we suppose to reverse it.
>
> Please help me out to fix this issue. Is it some configuration glitch or
> kannel don't follow smpp v3.4.
>
>
> *Please find access logs as*
>
> 2019-07-05 18:41:52 *Sent SMS* [SMSC:BQRDLR] [SVC:cc] [ACT:] [BINF:]
> [FID:1329246017] [META:?smpp_resp?] [*from:557*] [*to:55219918072*]
> [flags:-1:0:-1:0:19] [msg:12:Hello 177747] [udh:0:]
>
> 2019-07-05 18:43:44 *Receive DLR* [SMSC:BQRDLR] [SVC:cc] [ACT:test]
> [BINF:] [FID:1329246017] [META:?smpp?dlr_err=%03%00%00&] [*from:557*]
> [*to:55219918072*] [flags:-1:-1:-1:-1:1]
> [msg:140:id:4f3aaf41-92b1-44de-9677-b534d923f982 sub:001 dlvrd:001 submit
> date:1907051641 done date:1907051643 stat:DELIVRD err:000 text:Hello
> 3H3170] [udh:0:]
>
>
> *opensmppbox.log*
>
> 2019-07-05 16:43:42 [2748] [1] DEBUG: DLR[mysql]: Looking for DLR
> smsc=smpp, ts=c394e4c2-4376-41d5-a504-b8101ee52960, dst=+55219918072, type=1
> 2019-07-05 16:43:42 [2748] [1] DEBUG: sql: SELECT `mask`, `service`,
> `url`, `source`, `destination`, `boxc` FROM `dlr` WHERE `smsc`=? AND
> `ts`=?  LIMIT 1
> 2019-07-05 16:43:42 [2748] [1] DEBUG: column=mask buffer_type=3
> max_length=0 length=10
> 2019-07-05 16:43:42 [2748] [1] DEBUG: column=service buffer_type=253
> max_length=0 length=40
> 2019-07-05 16:43:42 [2748] [1] DEBUG: column=url buffer_type=253
> max_length=0 length=255
> 2019-07-05 16:43:42 [2748] [1] DEBUG: column=source buffer_type=253
> max_length=0 length=40
> 2019-07-05 16:43:42 [2748] [1] DEBUG: column=destination buffer_type=253
> max_length=0 length=40
> 2019-07-05 16:43:42 [2748] [1] DEBUG: column=boxc buffer_type=253
> max_length=0 length=40
> 2019-07-05 16:43:42 [2748] [1] DEBUG: DLR[mysql]: created DLR message for
> URL 
> 2019-07-05 16:43:42 [2748] [1] DEBUG: removing DLR from database
> 2019-07-05 16:43:42 [2748] [1] DEBUG: sql: DELETE FROM `dlr` WHERE
> `smsc`=? AND `ts`=?  LIMIT 1
> 2019-07-05 16:43:42 [2748] [1] DEBUG: SMPP[smpp]: Sending PDU:
> 2019-07-05 16:43:42 [2748] [1] DEBUG: SMPP PDU 0x7f6a6400b2b0 dump:
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   type_name: deliver_sm
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   command_id: 5 = 0x0005
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   command_status: 0 = 0x
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   sequence_number: 1 = 0x0001
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   service_type: NULL
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   source_addr_ton: 2 = 0x0002
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   source_addr_npi: 1 = 0x0001
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   source_addr: "557"
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   dest_addr_ton: 1 = 0x0001
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   dest_addr_npi: 1 = 0x0001
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   destination_addr: "55219918072"
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   esm_class: 4 = 0x0004
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   protocol_id: 0 = 0x
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   priority_flag: 0 = 0x
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   schedule_delivery_time: NULL
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   validity_period: NULL
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   registered_delivery: 0 = 0x
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   replace_if_present_flag: 0 =
> 0x
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   data_coding: 0 = 0x
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   sm_default_msg_id: 0 = 0x
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   sm_length: 0 = 0x
> 2019-07-05 16:43:42 [2748] [1] DEBUG:   short_message:
> 2019-07-05 16:43:42 [2748] [1] DEBUG:Octet string at 0x7f6a6400b000:
> 2019-07-05 16:43:42 [2748] [1] DEBUG:  len:  140
> 2019-07-05 16:43:42 [2748] [1] DEBUG:  size: 1024
> 2019-07-05 16:43:42 [2748] [1] DEBUG:  immutable: 0
> 2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 69 64 3a 63 33 39 34 65
> 34 63 32 2d 34 33 37 36   id:c394e4c2-4376
> 2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 2d 34 31 64 35 2d 61 35
> 30 34 2d 62 38 31 30 31   -41d5-a504-b8101
> 2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 65 65 35 32 39 36 30 20
> 73 75 62 3a 30 30 31 20   ee52960 sub:001
> 2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 64 6c 76 72 64 3a 30 30
> 31 20 73 75 62 6d 69 74   dlvrd:

STRANGE: kannel source and destination address inversion in deliver_sm not happening

[Amritesh Rachelwar]

Hello Guys,

I am observing a very strange behavior of kannel. When it is receiving DLRs
its not reversing the source and destination.

Is it like that only, because smpp v3.4 says we suppose to reverse it.

Please help me out to fix this issue. Is it some configuration glitch or
kannel don't follow smpp v3.4.


*Please find access logs as*

2019-07-05 18:41:52 *Sent SMS* [SMSC:BQRDLR] [SVC:cc] [ACT:] [BINF:]
[FID:1329246017] [META:?smpp_resp?] [*from:557*] [*to:55219918072*]
[flags:-1:0:-1:0:19] [msg:12:Hello 177747] [udh:0:]

2019-07-05 18:43:44 *Receive DLR* [SMSC:BQRDLR] [SVC:cc] [ACT:test] [BINF:]
[FID:1329246017] [META:?smpp?dlr_err=%03%00%00&] [*from:557*] [
*to:55219918072*] [flags:-1:-1:-1:-1:1]
[msg:140:id:4f3aaf41-92b1-44de-9677-b534d923f982 sub:001 dlvrd:001 submit
date:1907051641 done date:1907051643 stat:DELIVRD err:000 text:Hello
3H3170] [udh:0:]


*opensmppbox.log*

2019-07-05 16:43:42 [2748] [1] DEBUG: DLR[mysql]: Looking for DLR
smsc=smpp, ts=c394e4c2-4376-41d5-a504-b8101ee52960, dst=+55219918072, type=1
2019-07-05 16:43:42 [2748] [1] DEBUG: sql: SELECT `mask`, `service`, `url`,
`source`, `destination`, `boxc` FROM `dlr` WHERE `smsc`=? AND `ts`=?  LIMIT
1
2019-07-05 16:43:42 [2748] [1] DEBUG: column=mask buffer_type=3
max_length=0 length=10
2019-07-05 16:43:42 [2748] [1] DEBUG: column=service buffer_type=253
max_length=0 length=40
2019-07-05 16:43:42 [2748] [1] DEBUG: column=url buffer_type=253
max_length=0 length=255
2019-07-05 16:43:42 [2748] [1] DEBUG: column=source buffer_type=253
max_length=0 length=40
2019-07-05 16:43:42 [2748] [1] DEBUG: column=destination buffer_type=253
max_length=0 length=40
2019-07-05 16:43:42 [2748] [1] DEBUG: column=boxc buffer_type=253
max_length=0 length=40
2019-07-05 16:43:42 [2748] [1] DEBUG: DLR[mysql]: created DLR message for
URL 
2019-07-05 16:43:42 [2748] [1] DEBUG: removing DLR from database
2019-07-05 16:43:42 [2748] [1] DEBUG: sql: DELETE FROM `dlr` WHERE `smsc`=?
AND `ts`=?  LIMIT 1
2019-07-05 16:43:42 [2748] [1] DEBUG: SMPP[smpp]: Sending PDU:
2019-07-05 16:43:42 [2748] [1] DEBUG: SMPP PDU 0x7f6a6400b2b0 dump:
2019-07-05 16:43:42 [2748] [1] DEBUG:   type_name: deliver_sm
2019-07-05 16:43:42 [2748] [1] DEBUG:   command_id: 5 = 0x0005
2019-07-05 16:43:42 [2748] [1] DEBUG:   command_status: 0 = 0x
2019-07-05 16:43:42 [2748] [1] DEBUG:   sequence_number: 1 = 0x0001
2019-07-05 16:43:42 [2748] [1] DEBUG:   service_type: NULL
2019-07-05 16:43:42 [2748] [1] DEBUG:   source_addr_ton: 2 = 0x0002
2019-07-05 16:43:42 [2748] [1] DEBUG:   source_addr_npi: 1 = 0x0001
2019-07-05 16:43:42 [2748] [1] DEBUG:   source_addr: "557"
2019-07-05 16:43:42 [2748] [1] DEBUG:   dest_addr_ton: 1 = 0x0001
2019-07-05 16:43:42 [2748] [1] DEBUG:   dest_addr_npi: 1 = 0x0001
2019-07-05 16:43:42 [2748] [1] DEBUG:   destination_addr: "55219918072"
2019-07-05 16:43:42 [2748] [1] DEBUG:   esm_class: 4 = 0x0004
2019-07-05 16:43:42 [2748] [1] DEBUG:   protocol_id: 0 = 0x
2019-07-05 16:43:42 [2748] [1] DEBUG:   priority_flag: 0 = 0x
2019-07-05 16:43:42 [2748] [1] DEBUG:   schedule_delivery_time: NULL
2019-07-05 16:43:42 [2748] [1] DEBUG:   validity_period: NULL
2019-07-05 16:43:42 [2748] [1] DEBUG:   registered_delivery: 0 = 0x
2019-07-05 16:43:42 [2748] [1] DEBUG:   replace_if_present_flag: 0 =
0x
2019-07-05 16:43:42 [2748] [1] DEBUG:   data_coding: 0 = 0x
2019-07-05 16:43:42 [2748] [1] DEBUG:   sm_default_msg_id: 0 = 0x
2019-07-05 16:43:42 [2748] [1] DEBUG:   sm_length: 0 = 0x
2019-07-05 16:43:42 [2748] [1] DEBUG:   short_message:
2019-07-05 16:43:42 [2748] [1] DEBUG:Octet string at 0x7f6a6400b000:
2019-07-05 16:43:42 [2748] [1] DEBUG:  len:  140
2019-07-05 16:43:42 [2748] [1] DEBUG:  size: 1024
2019-07-05 16:43:42 [2748] [1] DEBUG:  immutable: 0
2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 69 64 3a 63 33 39 34 65 34
63 32 2d 34 33 37 36   id:c394e4c2-4376
2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 2d 34 31 64 35 2d 61 35 30
34 2d 62 38 31 30 31   -41d5-a504-b8101
2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 65 65 35 32 39 36 30 20 73
75 62 3a 30 30 31 20   ee52960 sub:001
2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 64 6c 76 72 64 3a 30 30 31
20 73 75 62 6d 69 74   dlvrd:001 submit
2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 20 64 61 74 65 3a 31 39 30
37 30 35 31 36 34 31date:1907051641
2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 20 64 6f 6e 65 20 64 61 74
65 3a 31 39 30 37 30done date:19070
2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 35 31 36 34 33 20 73 74 61
74 3a 44 45 4c 49 56   51643 stat:DELIV
2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 52 44 20 65 72 72 3a 30 30
30 20 74 65 78 74 3a   RD err:000 text:
2019-07-05 16:43:42 [2748] [1] DEBUG:  data: 48 65 6c 6c 6f 20 33 48 33
31 37 30   Hello 3H3170
2019-07-05 16:43:42 [2748] [1] DEBUG:Octet string dump ends.
2019-07-05 1

Re: Kannel Redis - can I force the destination in the key name?

[Robert Chen]

Thanks for the clarification. Turned out that in my case, some of the
message IDs would get recycled given enough time and volume. So in order to
generate unique redis keys, I still had to include the destination.

In case anyone is interested, I ended up making a local change to
gw/smsc/smsc_smpp.c, by setting the use_dst flag to 1 for the dlr_find and
dlr_add method calls. Just had to be mindful that the redis key only uses
the last 7 characters of the destination.

@@ -1535,7 +1535,7 @@

 dlrmsg = dlr_find(smpp->conn->id,

 tmp, /* smsc message id */

 destination_addr, /* destination */

-dlrstat, 0);

+dlrstat, 1);



 octstr_destroy(msgid);

 } else

@@ -1854,7 +1854,7 @@

  * order to get it logged to access-log.

  */

 if (DLR_IS_ENABLED_DEVICE(msg->sms.dlr_mask)) {

-dlr_add(smpp->conn->id, tmp, msg, 0);

+dlr_add(smpp->conn->id, tmp, msg, 1);

 octstr_destroy(tmp);

 } else {

 octstr_destroy(msg->sms.foreign_id);


On Tue, Nov 1, 2016 at 5:33 PM, Donald Jackson <donaldjs...@gmail.com>
wrote:

> Ts is just the old variable name, the remote message id is used for that
> field, not a time stamp. So as long as your supplier provides a unique
> message ID you won't have collisions
>
>
> On Tuesday, 01 November 2016, Robert Chen <robert.chen@
> thorntechnologies.com> wrote:
>
>> Hi, I'm trying to set up Kannel with Redis. My concern is that some DLRs
>> would be lost due to timestamp collisions. And my question is whether
>> hard-coding dlr_redis_add to use the destination (at least for my personal
>> installation) is the best approach.
>>
>> dlr_redis.c:
>> Changing:
>> if (entry->use_dst && entry->destination)
>> To this:
>> if (entry->destination) { ... }
>>
>> Here's my train of thought:
>>
>> I'm load-balancing Kannel. And according to community recommendations,
>> each instance is using the same smsc-id:
>>
>>- http://kannel.6189.n7.nabble.com/How-to-Multiple-SMSC-s-conf
>>iguration-and-how-to-Load-balancing-B-W-Muliple-SMSC-s-td17874.html
>>
>> <http://kannel.6189.n7.nabble.com/How-to-Multiple-SMSC-s-configuration-and-how-to-Load-balancing-B-W-Muliple-SMSC-s-td17874.html>
>>- https://francispereira.com/kannel-setting-up-active-active-l
>>oad-balanced-smpp-gateways.html
>>
>> <https://francispereira.com/kannel-setting-up-active-active-load-balanced-smpp-gateways.html>
>>- http://stackoverflow.com/questions/10322269/kannelroute-mess
>>age-through-2-smsc
>>
>> The current Kannel setup is using 1.4.4 with MySQL. I'm in the process of
>> migrating the whole thing to cloud hosting, but using Redis this time.
>>
>> I'm worried that DLRs could be lost if they come back with the same
>> timestamp. Within dlr_redis.c, it looks like it does one of two things:
>>
>> 1. If the REDIS_PRECHECK flag is set, it uses HSETNX (only creating a key
>> if it does not exist)
>> 2. Otherwise, it uses HMSET (overriding whatever dictionary is tied to
>> that key)
>>
>> Either way, it looks like one of the DLRs will get lost if there's ever a
>> conflict.
>>
>> Within dlr_redis.c, it looks like the key can be one of two formats:
>>
>> 1. ::
>> 2. :::
>>
>> After analyzing a MySQL CSV dump containing 1 million messages, I'm
>> finding rows with identical timestamps. And for Redis, this could spell a
>> key collision. But, I can get all the keys to be unique by including the
>> destination.
>>
>> I'm trying to figure out how to force Kannel to include the destination.
>> According to the documentation, it seems like this is determined by the
>> SMSC:
>>
>> “Some SMSCs also append the destination to the DLR keyname resulting DLR
>> keynames in the format :::.”
>>
>> It seems as though cimd2 and emi are the SMSC types that append the
>> destination.
>>
>> gateway-1.4.4/gw $ grep -iR dlr_add .
>> ./smsc/http/clickatell.c:dlr_add(conn->id, msgid, msg, 0);
>> ./smsc/http/generic.c:dlr_add(conn->id, msgid,
>> msg, 0);
>> ./smsc/http/generic.c:dlr_add(conn->id, msgid, msg, 0);
>> ./smsc/http/xidris.c:dlr_add(conn->id, mid, msg, 0);
>> ./smsc/smsc_at.c:dlr_add(privdata->conn->id,
>> dlrmsgid, msg, 0);
>> ./smsc/smsc_cgw.c:dlr_add(conn->id, ts, msg, 0);
>>

Re: Kannel Redis - can I force the destination in the key name?

[Donald Jackson]

Ts is just the old variable name, the remote message id is used for that
field, not a time stamp. So as long as your supplier provides a unique
message ID you won't have collisions

On Tuesday, 01 November 2016, Robert Chen <robert.c...@thorntechnologies.com>
wrote:

> Hi, I'm trying to set up Kannel with Redis. My concern is that some DLRs
> would be lost due to timestamp collisions. And my question is whether
> hard-coding dlr_redis_add to use the destination (at least for my personal
> installation) is the best approach.
>
> dlr_redis.c:
> Changing:
> if (entry->use_dst && entry->destination)
> To this:
> if (entry->destination) { ... }
>
> Here's my train of thought:
>
> I'm load-balancing Kannel. And according to community recommendations,
> each instance is using the same smsc-id:
>
>- http://kannel.6189.n7.nabble.com/How-to-Multiple-SMSC-s-conf
>iguration-and-how-to-Load-balancing-B-W-Muliple-SMSC-s-td17874.html
>
> <http://kannel.6189.n7.nabble.com/How-to-Multiple-SMSC-s-configuration-and-how-to-Load-balancing-B-W-Muliple-SMSC-s-td17874.html>
>- https://francispereira.com/kannel-setting-up-active-active-
>load-balanced-smpp-gateways.html
>
> <https://francispereira.com/kannel-setting-up-active-active-load-balanced-smpp-gateways.html>
>- http://stackoverflow.com/questions/10322269/kannelroute-
>message-through-2-smsc
>
> The current Kannel setup is using 1.4.4 with MySQL. I'm in the process of
> migrating the whole thing to cloud hosting, but using Redis this time.
>
> I'm worried that DLRs could be lost if they come back with the same
> timestamp. Within dlr_redis.c, it looks like it does one of two things:
>
> 1. If the REDIS_PRECHECK flag is set, it uses HSETNX (only creating a key
> if it does not exist)
> 2. Otherwise, it uses HMSET (overriding whatever dictionary is tied to
> that key)
>
> Either way, it looks like one of the DLRs will get lost if there's ever a
> conflict.
>
> Within dlr_redis.c, it looks like the key can be one of two formats:
>
> 1. ::
> 2. :::
>
> After analyzing a MySQL CSV dump containing 1 million messages, I'm
> finding rows with identical timestamps. And for Redis, this could spell a
> key collision. But, I can get all the keys to be unique by including the
> destination.
>
> I'm trying to figure out how to force Kannel to include the destination.
> According to the documentation, it seems like this is determined by the
> SMSC:
>
> “Some SMSCs also append the destination to the DLR keyname resulting DLR
> keynames in the format :::.”
>
> It seems as though cimd2 and emi are the SMSC types that append the
> destination.
>
> gateway-1.4.4/gw $ grep -iR dlr_add .
> ./smsc/http/clickatell.c:dlr_add(conn->id, msgid, msg, 0);
> ./smsc/http/generic.c:dlr_add(conn->id, msgid,
> msg, 0);
> ./smsc/http/generic.c:dlr_add(conn->id, msgid, msg, 0);
> ./smsc/http/xidris.c:dlr_add(conn->id, mid, msg, 0);
> ./smsc/smsc_at.c:dlr_add(privdata->conn->id,
> dlrmsgid, msg, 0);
> ./smsc/smsc_cgw.c:dlr_add(conn->id, ts, msg, 0);
> ./smsc/smsc_cimd2.c:dlr_add(conn->name, ts, msg, 1);
> ./smsc/smsc_emi.c: dlr_add((conn->id ? conn->id : privdata->name),
> ts, m, 1);
> ./smsc/smsc_fake.c:dlr_add(conn->id, tmp, sms, 0);
> ./smsc/smsc_http.c:dlr_add(conn->id, mid, msg, 0);
> ./smsc/smsc_loopback.c:dlr_add(conn->id, mid, sms, 0);
> ./smsc/smsc_oisd.c:dlr_add(conn->name, ts, msg, 0);
> ./smsc/smsc_smpp.c:dlr_add(smpp->conn->id, tmp, msg,
> 0);
> ./smsc/smsc_soap.c:dlr_add(conn->id, octstr_imm(tmpid), msg, 0);
> ./smsc/smsc_soap_parlayx.c:    dlr_add(conn->id, mid, sms, 0);
> ./smsc/smsc_soap_parlayx.c:dlr_add(conn->id, mid, msg, 0);
> The problem though is that I'm using smpp. (I verified against my SMSC
> that the format coming back is indeed ::)
>
> So I guess my question is, should I just hard-code my local install to
> append the destination? Or is there a better approach or some configuration
> flat I'm just not seeing?
>
> Thanks!
> Robert Chen
>


--

Kannel Redis - can I force the destination in the key name?

[Robert Chen]

Hi, I'm trying to set up Kannel with Redis. My concern is that some DLRs
would be lost due to timestamp collisions. And my question is whether
hard-coding dlr_redis_add to use the destination (at least for my personal
installation) is the best approach.

dlr_redis.c:
Changing:
if (entry->use_dst && entry->destination)
To this:
if (entry->destination) { ... }

Here's my train of thought:

I'm load-balancing Kannel. And according to community recommendations, each
instance is using the same smsc-id:

   - http://kannel.6189.n7.nabble.com/How-to-Multiple-SMSC-s-
   configuration-and-how-to-Load-balancing-B-W-Muliple-SMSC-s-td17874.html
   
<http://kannel.6189.n7.nabble.com/How-to-Multiple-SMSC-s-configuration-and-how-to-Load-balancing-B-W-Muliple-SMSC-s-td17874.html>
   - https://francispereira.com/kannel-setting-up-active-
   active-load-balanced-smpp-gateways.html
   
<https://francispereira.com/kannel-setting-up-active-active-load-balanced-smpp-gateways.html>
   - http://stackoverflow.com/questions/10322269/
   kannelroute-message-through-2-smsc
   
<http://stackoverflow.com/questions/10322269/kannelroute-message-through-2-smsc>

The current Kannel setup is using 1.4.4 with MySQL. I'm in the process of
migrating the whole thing to cloud hosting, but using Redis this time.

I'm worried that DLRs could be lost if they come back with the same
timestamp. Within dlr_redis.c, it looks like it does one of two things:

1. If the REDIS_PRECHECK flag is set, it uses HSETNX (only creating a key
if it does not exist)
2. Otherwise, it uses HMSET (overriding whatever dictionary is tied to that
key)

Either way, it looks like one of the DLRs will get lost if there's ever a
conflict.

Within dlr_redis.c, it looks like the key can be one of two formats:

1. ::
2. :::

After analyzing a MySQL CSV dump containing 1 million messages, I'm finding
rows with identical timestamps. And for Redis, this could spell a key
collision. But, I can get all the keys to be unique by including the
destination.

I'm trying to figure out how to force Kannel to include the destination.
According to the documentation, it seems like this is determined by the
SMSC:

“Some SMSCs also append the destination to the DLR keyname resulting DLR
keynames in the format :::.”

It seems as though cimd2 and emi are the SMSC types that append the
destination.

gateway-1.4.4/gw $ grep -iR dlr_add .
./smsc/http/clickatell.c:dlr_add(conn->id, msgid, msg, 0);
./smsc/http/generic.c:dlr_add(conn->id, msgid, msg,
0);
./smsc/http/generic.c:dlr_add(conn->id, msgid, msg, 0);
./smsc/http/xidris.c:dlr_add(conn->id, mid, msg, 0);
./smsc/smsc_at.c:dlr_add(privdata->conn->id,
dlrmsgid, msg, 0);
./smsc/smsc_cgw.c:dlr_add(conn->id, ts, msg, 0);
./smsc/smsc_cimd2.c:dlr_add(conn->name, ts, msg, 1);
./smsc/smsc_emi.c: dlr_add((conn->id ? conn->id : privdata->name), ts,
m, 1);
./smsc/smsc_fake.c:dlr_add(conn->id, tmp, sms, 0);
./smsc/smsc_http.c:dlr_add(conn->id, mid, msg, 0);
./smsc/smsc_loopback.c:dlr_add(conn->id, mid, sms, 0);
./smsc/smsc_oisd.c:dlr_add(conn->name, ts, msg, 0);
./smsc/smsc_smpp.c:dlr_add(smpp->conn->id, tmp, msg, 0);
./smsc/smsc_soap.c:dlr_add(conn->id, octstr_imm(tmpid), msg, 0);
./smsc/smsc_soap_parlayx.c:dlr_add(conn->id, mid, sms, 0);
./smsc/smsc_soap_parlayx.c:dlr_add(conn->id, mid, msg, 0);
The problem though is that I'm using smpp. (I verified against my SMSC that
the format coming back is indeed ::)

So I guess my question is, should I just hard-code my local install to
append the destination? Or is there a better approach or some configuration
flat I'm just not seeing?

Thanks!
Robert Chen

Re: Modifying destination address when acting as ESME

[Juan Nin]

Is that bind specific for just Netherlands?

If so you could hardcode the country code on the sms-service using %2B31%p

On Tue, Feb 23, 2016 at 9:36 PM, SA  wrote:

> Hi,
>
> I have a kannel system running that connects to multiple providers. The
> majority of the providers send messages back to me in full E.164 format.
> However I have a new provider that sends me messages to my Netherlands
> numbers without the country code.
>
> I receive:
> DEBUG:   destination_addr: "635xx"
>
> I'd like to be able to prefix +31 to it so that the system I send it on to
> from there can processes it.
>
> I tried using the unified-prefix as follows and it doesn't work:
>
> group = smsc
> smsc = smpp
> smsc-id = superawesomelamesmsc
> host = xx.xx.xx.xx
> port = 2775
> smsc-username = "Bob"
> smsc-password = Super12345
> system-type = "smpp34"
> address-range = ""
> transceiver-mode = 1
> enquire-link-interval = 30
> connection-timeout = 35
> unified-prefix = "+3163,063,63"
>
>
> I can not put the same unified-prefix in the Core/Smsbox section because I
> also have Philippines numbers on my platform and their country code is 63.
>
> Is there another way I should be thinking about accomplishing this?
>

Modifying destination address when acting as ESME

[SA]

Hi,

I have a kannel system running that connects to multiple providers. The
majority of the providers send messages back to me in full E.164 format.
However I have a new provider that sends me messages to my Netherlands
numbers without the country code.

I receive:
DEBUG:   destination_addr: "635xx"

I'd like to be able to prefix +31 to it so that the system I send it on to
from there can processes it.

I tried using the unified-prefix as follows and it doesn't work:

group = smsc
smsc = smpp
smsc-id = superawesomelamesmsc
host = xx.xx.xx.xx
port = 2775
smsc-username = "Bob"
smsc-password = Super12345
system-type = "smpp34"
address-range = ""
transceiver-mode = 1
enquire-link-interval = 30
connection-timeout = 35
unified-prefix = "+3163,063,63"


I can not put the same unified-prefix in the Core/Smsbox section because I
also have Philippines numbers on my platform and their country code is 63.

Is there another way I should be thinking about accomplishing this?

Re: Change the sender based in the destination prefix

[Filipe Carvalho]

My SMSC operator allow I send with the sender in three formats:
+351920012345
+351920012345
+351920012345

ha...@aeon.pk wrote:

You might be able to do this in kannel but your SMSC operator would not
let you allow to put anyone's number in the FROM address.

Use REGEX to handle the sender based on destination.

On Sat, Nov 7, 2015 at 1:37 AM, Filipe Carvalho
<filipe.f.carva...@gmail.com <mailto:filipe.f.carva...@gmail.com>> wrote:

Hello,

Nowadays, I've a simple working configuration

Application -> smsbox (http interface) -> smsc -> smsc gateway

In smsc configuration I've configured the global sender, for
example, 12345

When sending international sms, with sender 12345, it is blocked and
I need to configure an international phone number, like
+351920012345 <tel:%2B351920012345>

It is possible to configure kannel to change the sender based in the
destination prefix?

Can you give me a hint how to do it?

I can not change in the application the URL in order to apply this
logic.

Regards,
Filipe

Re: Change the sender based in the destination prefix

[Filipe Carvalho]

My SMSC Operator allow the sender in three formats:

+351920012345 (international)
920012345 (national)
12345 (short code?)

I've created two smsc

smsc-id = int
allowed-smsc-id = "int;all"
denied-prefix   = "+351"
unified-prefix  = "+351920012345,12345"

smsc-id = nac
allowed-smsc-id = "nac;all"
allowed-prefix = "+351"

And a sendsms-user group

group   = sendsms-user
default-sender  = "12345"
default-smsc= all


I tried some combinations of this setup but never have been have to send 
the correct send... or always 12345 or +351920012345, depending in what 
is configured in sendsms-user group.


So, where can I use REGEX to do the magic?



ha...@aeon.pk wrote:

You might be able to do this in kannel but your SMSC operator would not
let you allow to put anyone's number in the FROM address.

Use REGEX to handle the sender based on destination.

On Sat, Nov 7, 2015 at 1:37 AM, Filipe Carvalho
<filipe.f.carva...@gmail.com <mailto:filipe.f.carva...@gmail.com>> wrote:

Hello,

Nowadays, I've a simple working configuration

Application -> smsbox (http interface) -> smsc -> smsc gateway

In smsc configuration I've configured the global sender, for
example, 12345

When sending international sms, with sender 12345, it is blocked and
I need to configure an international phone number, like
+351920012345 <tel:%2B351920012345>

    It is possible to configure kannel to change the sender based in the
destination prefix?

Can you give me a hint how to do it?

I can not change in the application the URL in order to apply this
logic.

Regards,
Filipe

No Destination / Originator Addresses

[Artem Chekulaev]

We have "strange" USSD connection.
First message in session contains only originator address and no
destination, but has TLV ussd_session_id. We disabled check on destination
address is "null", so we can work with it. But other messages in session
contains no destination / originator, only ussd_session_id from first
message.

Is it possible to work with that? How to proceed such messages to
sms-service (or to http application)???

Re: Change the sender based in the destination prefix

[ha...@aeon.pk]

You might be able to do this in kannel but your SMSC operator would not let
you allow to put anyone's number in the FROM address.

Use REGEX to handle the sender based on destination.

On Sat, Nov 7, 2015 at 1:37 AM, Filipe Carvalho <filipe.f.carva...@gmail.com
> wrote:

> Hello,
>
> Nowadays, I've a simple working configuration
>
> Application -> smsbox (http interface) -> smsc -> smsc gateway
>
> In smsc configuration I've configured the global sender, for example, 12345
>
> When sending international sms, with sender 12345, it is blocked and I
> need to configure an international phone number, like +351920012345
>
> It is possible to configure kannel to change the sender based in the
> destination prefix?
>
> Can you give me a hint how to do it?
>
> I can not change in the application the URL in order to apply this logic.
>
> Regards,
> Filipe
>
>

Change the sender based in the destination prefix

[Filipe Carvalho]

Hello,

Nowadays, I've a simple working configuration

Application -> smsbox (http interface) -> smsc -> smsc gateway

In smsc configuration I've configured the global sender, for example, 12345

When sending international sms, with sender 12345, it is blocked and I 
need to configure an international phone number, like +351920012345


It is possible to configure kannel to change the sender based in the 
destination prefix?


Can you give me a hint how to do it?

I can not change in the application the URL in order to apply this logic.

Regards,
Filipe

Allow only specified destination numbers on SMPP connection

[Pablo Gus]

Hi all,

I have different destination numbers within a SMPP connection. Is there any
way to specify which destination numbers are allowed in Kannel for SMS
incoming?

I would appreciate if someone has an example about this.

Thanks! Regards,
Pablo.

Reject SMPP MO messages by destination shortcode

[Germán Bobr]

Hi guys,

A client gave me a SMPP receiver connection where there are lots of
messages circulating for different shortcodes.
They want me to only take messages directed to a given shortcode and reject
the rest so another ESME can take these messages.

Is such thing possible? if so, wich configuration options should i use?

Thank you very much,
-- 


*Germán Bobr *german.b...@redmondsoftware.com
[image: Description: redmond]

OPENSMPP DLR source and Destination addresses inverted

[MOSES KARIUKI]

Hey all,

Anyone knows why the dlr from an ESME to Opensmppbox to ESME are inveted?

Help,
Mose

Invalid Destination Address

[Qqblog Qqblog]

After I submit a plenty of sms. I see the log show SMSC returned error code 
0x000b (Invalid Destination Address) in response to submit_sm.

How can I know which number is invalid from log ?

RE: Invalid Destination Address

[Rene Kluwen]

Look for destination_addr in your logs, with log-level = 0.

 

== Rene

 

From: users [mailto:users-boun...@kannel.org] On Behalf Of Qqblog Qqblog
Sent: donderdag 15 augustus 2013 11:26
To: users@kannel.org
Subject: Invalid Destination Address

 

After I submit a plenty of sms. I see the log show SMSC returned error code 
0x000b (Invalid Destination Address) in response to submit_sm.

 

How can I know which number is invalid from log ?

 

Re: Invalid Destination Address

[Willy Mularto]

Or you can set dlr-mask=3. All failed DLR should be returned. And it is great 
if you have your unique internal message-id to match each MT and DLR.



On Aug 15, 2013, at 5:05 PM, Rene Kluwen rene.klu...@chimit.nl wrote:

 Look for destination_addr in your logs, with log-level = 0.
  
 == Rene
  
 From: users [mailto:users-boun...@kannel.org] On Behalf Of Qqblog Qqblog
 Sent: donderdag 15 augustus 2013 11:26
 To: users@kannel.org
 Subject: Invalid Destination Address
  
 After I submit a plenty of sms. I see the log show SMSC returned error code 
 0x000b (Invalid Destination Address) in response to submit_sm.
  
 How can I know which number is invalid from log ?

Remove prefix from address destination

[AMOUZOU Amen]

Hi all,

I have set up Kannel and now I get messages. But messages come with the
kinds of numbers 228 but I want to send the MT using only .
I used in [smsc group], unified-prefix = - 228 but it does not seem to
work.

Please, can you help me ?

Thank you.

– Amen

RE: Can I get destination msisdn and message from submit sm resp ???

[Rene Kluwen]

Please post your logs.

Maybe you need to set msg-id-type.

 

From: users-boun...@vm1.kannel.org [mailto:users-boun...@vm1.kannel.org] On
Behalf Of chen yee tan
Sent: vrijdag 7 december 2012 5:55
To: users@kannel.org
Subject: Can I get destination msisdn and message from submit sm resp ???

 

Hi,

 

I am running async receiver and transmitter. When I use transmitter to send
out sms, my receiver will get submit sm resp event. I am able to get message
id from it. I tried to get message text and it is empty. i tried to get
destination address and got null pointer. Is there a way to get destination
address and message text ?

 

Chen Yee

Can I get destination msisdn and message from submit sm resp ???

[chen yee tan]

Hi,

I am running async receiver and transmitter. When I use transmitter to send out 
sms, my receiver will get submit sm resp event. I am able to get message id 
from it. I tried to get message text and it is empty. i tried to get 
destination address and got null pointer.Is there a way to get destination 
address and message text ?

Chen Yee

RE: Outgoing SMS routing via different SMSC by destination number prefix

[Rene Kluwen]

group = smsc
smsc = fake
smsc-id = smsc-0
port = 1
connect-allow-ip = 127.0.0.1
denied-prefix = 007;008

-Original Message-
From: users-boun...@vm1.kannel.org [mailto:users-boun...@vm1.kannel.org] On
Behalf Of Eugene Prokopiev
Sent: Thursday, 13 September, 2012 07:08
To: us...@vm1.kannel.org
Subject: Outgoing SMS routing via different SMSC by destination number
prefix

Hi,

What is the right way to route outgoing SMS routing via different SMSC by
destination number prefix + default route for any unknown prefixes?
I tried to do it by this configuration:

group = core
admin-port = 13000
admin-password = admin
smsbox-port = 13001
dlr-storage = internal

group = smsbox
bearerbox-host = localhost
smsbox-id = smsbox-0
sendsms-port = 13013

group = smsc
smsc = fake
smsc-id = smsc-7
port = 10007
connect-allow-ip = 127.0.0.1
allowed-prefix = 007

group = smsc
smsc = fake
smsc-id = smsc-8
port = 10008
connect-allow-ip = 127.0.0.1
allowed-prefix = 008

group = smsc
smsc = fake
smsc-id = smsc-0
port = 1
connect-allow-ip = 127.0.0.1

group = sendsms-user
username = 
password = 

Messages with prefox 007 are routed via smsc-7 but sometimes are routed via
smsc-0. Why can it be? What is the best configuration for my use case?

--
Regards,
Eugene Prokopiev

Outgoing SMS routing via different SMSC by destination number prefix

[Eugene Prokopiev]

Hi,

What is the right way to route outgoing SMS routing via different SMSC
by destination number prefix + default route for any unknown prefixes?
I tried to do it by this configuration:

group = core
admin-port = 13000
admin-password = admin
smsbox-port = 13001
dlr-storage = internal

group = smsbox
bearerbox-host = localhost
smsbox-id = smsbox-0
sendsms-port = 13013

group = smsc
smsc = fake
smsc-id = smsc-7
port = 10007
connect-allow-ip = 127.0.0.1
allowed-prefix = 007

group = smsc
smsc = fake
smsc-id = smsc-8
port = 10008
connect-allow-ip = 127.0.0.1
allowed-prefix = 008

group = smsc
smsc = fake
smsc-id = smsc-0
port = 1
connect-allow-ip = 127.0.0.1

group = sendsms-user
username = 
password = 

Messages with prefox 007 are routed via smsc-7 but sometimes are
routed via smsc-0. Why can it be? What is the best configuration for
my use case?

--
Regards,
Eugene Prokopiev

RE: Responsibility for inversion of source and destination address for DLR

[info.ubichip]

Hello,

I'm currently facing a similar issue using opensmppbox.

Does someone has been able to find a patch or any resolution of this issue ?

Thanks in advance for your answer


-Message d'origine-
De : users-boun...@kannel.org [mailto:users-boun...@kannel.org] De la part
de Nikos Balkanas
Envoyé : lundi 1 août 2011 04:27
À : Mike Nelson; us...@vm1.kannel.org
Objet : Re: Responsibility for inversion of source and destination address
for DLR

Hi,

Bb has assumed this responsibility since almost 10 years now. It inverts
addresses to the original before submitting to the endpoint (smsbox). Since
then a number of add-on boxes have been developed since (sqlbox, smppbox). 
It seems to me, that since they were created as add-ons to bb, they should
abide by the bb communication API. That means that they should treat
addresses as original and handle them according to their needs.

If bb were to change, so would smsbox. Since both of these preexisted the
other boxes, it seems to me that these boxes should align themselves to bb,
not the other way around.

If you decide to patch your bb, the code is in gw/dlr.c: 436 in dlr_find(). 
Bear in mind that if you do so, you will be branching off and future updates
may need merging.

BR,
Nikos
- Original Message -
From: Mike Nelson
To: users@kannel.org
Sent: Sunday, July 31, 2011 11:43 PM
Subject: Responsibility for inversion of source and destination address for
DLR


Hello All,

I was wondering if anyone might be able to help explain to me what box has
the responsibility of inverting source and destination addresses in DLRs. 
If possible, a pointer to where in the source code this is *supposed* to
happen would also be helpful. I emphasize supposed to because it is my
understanding from reading prior threads that there is an erroneous
inversion of these fields in smsc_smpp.c's handle_pdu function.

Here is some background on the motivation of this question. I am trying to 
troubleshoot a problem with a closed-source kannel smppbox.   The issue is 
that the source and destination address of the deliver_sm (DLR) message is
the same as the source and destination in the submit_sm message.  My
understanding is that this is not the proper default behavior -- that
instead the source_addr of the DLR should be the destination_addr of the
submit_sm and vice-versa. I wish to determine whether the problem is
stemming from within this smppbox, or if the problem is in my bearerbox
configuration.  I am still new to kannel though, so I am not sure where one
would normally expect to see the inversion of these two fields occur.  By
the way, the DLRs come downstream from an http smsc, but I don't think the
configuration of this smsc could be the problem since the look-up in the DLR
database is only being based on the dlr-mid and smsc-id -- the 'to' field
seems to basically be ignored.

I have been trying to trace my way through the kannel source code to
determine where you would normally see the source_addr and destination_addr
fields be swapped when constructing a DLR, but so far I have not been able
to spot it.  To me, it seems as though the source_addr always gets assigned
as the source and the destination_addr always gets assigned as the
destination when dropping this information into the DLR database and when
pulling it out of the DLR database.  It seems as though they continue to be
uninverted as they are converted into 'msg'es, and these msg's are then sent
to the smppbox for delivery to the ESME.  Is this how it works though, or
have the source_addr and destination_addr already been inverted at some
point during the process of handing the message from smppbox to bearerbox to
DLR database and back out?  I have been staring at too much code lately, so
I am hoping that someone can show me what I have missed.  That is, can
someone explain at what step the source_addr (sender) of the submit_sm
message should get placed into the role of destination_addr, or receiver,
for the DLR's deliver_sm PDU?

Many thanks,

Mike 

Is there a way for kannel to not forward to SMSC SMS whose destination numbers are less than a specified number of characters.

[Engel L]

Hi,

I am using Kannel 1.4.3 and am looking for a means for the gateway to
drop messages destined to numbers with missing characters. The reason
being sometimes clients send texts to numbers less than the in-my-case
acceptable 12 digits and the NOs charge me for them.

Regds,

Engel

RE: Is there a way for kannel to not forward to SMSC SMS whose destination numbers are less than a specified number of characters.

[Rene Kluwen]

Why don't you check for nr of characters before you send them to the
/cgi-bin/sendsms interface?

== Rene

-Original Message-
From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf
Of Engel L
Sent: Tuesday, 08 November, 2011 10:04
To: users@kannel.org
Subject: Is there a way for kannel to not forward to SMSC SMS whose
destination numbers are less than a specified number of characters.

Hi,

I am using Kannel 1.4.3 and am looking for a means for the gateway to
drop messages destined to numbers with missing characters. The reason
being sometimes clients send texts to numbers less than the in-my-case
acceptable 12 digits and the NOs charge me for them.

Regds,

Engel

Re: Is there a way for kannel to not forward to SMSC SMS whose destination numbers are less than a specified number of characters.

[Engel L]

Hi Rene,

Thank you for the suggestion.

I was hoping I could achieve the same at the gateway level. This is
because we have multiple front-end applications calling the sendsms
interface.

Regds,

On Tue, Nov 8, 2011 at 9:42 PM, Rene Kluwen rene.klu...@chimit.nl wrote:
 Why don't you check for nr of characters before you send them to the
 /cgi-bin/sendsms interface?

 == Rene

 -Original Message-
 From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf
 Of Engel L
 Sent: Tuesday, 08 November, 2011 10:04
 To: users@kannel.org
 Subject: Is there a way for kannel to not forward to SMSC SMS whose
 destination numbers are less than a specified number of characters.

 Hi,

 I am using Kannel 1.4.3 and am looking for a means for the gateway to
 drop messages destined to numbers with missing characters. The reason
 being sometimes clients send texts to numbers less than the in-my-case
 acceptable 12 digits and the NOs charge me for them.

 Regds,

 Engel

RE: Is there a way for kannel to not forward to SMSC SMS whose destination numbers are less than a specified number of characters.

[Rene Kluwen]

Check the white-list-regex configuration entry of group = core.

== Rene

-Original Message-
From: Engel L [mailto:choch...@gmail.com] 
Sent: Tuesday, 08 November, 2011 19:47
To: Rene Kluwen
Cc: users@kannel.org
Subject: Re: Is there a way for kannel to not forward to SMSC SMS whose
destination numbers are less than a specified number of characters.

Hi Rene,

Thank you for the suggestion.

I was hoping I could achieve the same at the gateway level. This is
because we have multiple front-end applications calling the sendsms
interface.

Regds,

On Tue, Nov 8, 2011 at 9:42 PM, Rene Kluwen rene.klu...@chimit.nl wrote:
 Why don't you check for nr of characters before you send them to the
 /cgi-bin/sendsms interface?

 == Rene

 -Original Message-
 From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf
 Of Engel L
 Sent: Tuesday, 08 November, 2011 10:04
 To: users@kannel.org
 Subject: Is there a way for kannel to not forward to SMSC SMS whose
 destination numbers are less than a specified number of characters.

 Hi,

 I am using Kannel 1.4.3 and am looking for a means for the gateway to
 drop messages destined to numbers with missing characters. The reason
 being sometimes clients send texts to numbers less than the in-my-case
 acceptable 12 digits and the NOs charge me for them.

 Regds,

 Engel

RE: Is there a way for kannel to not forward to SMSC SMS whose destination numbers are less than a specified number of characters.

[Rene Kluwen]

Ah... sorry... ignore my post. The white-list-regex is for sender id's.

-Original Message-
From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf
Of Rene Kluwen
Sent: Tuesday, 08 November, 2011 22:53
To: 'Engel L'
Cc: users@kannel.org
Subject: RE: Is there a way for kannel to not forward to SMSC SMS whose
destination numbers are less than a specified number of characters.

Check the white-list-regex configuration entry of group = core.

== Rene

-Original Message-
From: Engel L [mailto:choch...@gmail.com] 
Sent: Tuesday, 08 November, 2011 19:47
To: Rene Kluwen
Cc: users@kannel.org
Subject: Re: Is there a way for kannel to not forward to SMSC SMS whose
destination numbers are less than a specified number of characters.

Hi Rene,

Thank you for the suggestion.

I was hoping I could achieve the same at the gateway level. This is
because we have multiple front-end applications calling the sendsms
interface.

Regds,

On Tue, Nov 8, 2011 at 9:42 PM, Rene Kluwen rene.klu...@chimit.nl wrote:
 Why don't you check for nr of characters before you send them to the
 /cgi-bin/sendsms interface?

 == Rene

 -Original Message-
 From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf
 Of Engel L
 Sent: Tuesday, 08 November, 2011 10:04
 To: users@kannel.org
 Subject: Is there a way for kannel to not forward to SMSC SMS whose
 destination numbers are less than a specified number of characters.

 Hi,

 I am using Kannel 1.4.3 and am looking for a means for the gateway to
 drop messages destined to numbers with missing characters. The reason
 being sometimes clients send texts to numbers less than the in-my-case
 acceptable 12 digits and the NOs charge me for them.

 Regds,

 Engel

RE: Is there a way for kannel to not forward to SMSC SMS whose destination numbers are less than a specified number of characters.

[Rene Kluwen]

How about using allowed-receiver-prefix-regex?

-Original Message-
From: Rene Kluwen [mailto:rene.klu...@chimit.nl] 
Sent: Tuesday, 08 November, 2011 22:55
To: 'Rene Kluwen'; 'Engel L'
Cc: users@kannel.org
Subject: RE: Is there a way for kannel to not forward to SMSC SMS whose
destination numbers are less than a specified number of characters.

Ah... sorry... ignore my post. The white-list-regex is for sender id's.

-Original Message-
From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf
Of Rene Kluwen
Sent: Tuesday, 08 November, 2011 22:53
To: 'Engel L'
Cc: users@kannel.org
Subject: RE: Is there a way for kannel to not forward to SMSC SMS whose
destination numbers are less than a specified number of characters.

Check the white-list-regex configuration entry of group = core.

== Rene

-Original Message-
From: Engel L [mailto:choch...@gmail.com] 
Sent: Tuesday, 08 November, 2011 19:47
To: Rene Kluwen
Cc: users@kannel.org
Subject: Re: Is there a way for kannel to not forward to SMSC SMS whose
destination numbers are less than a specified number of characters.

Hi Rene,

Thank you for the suggestion.

I was hoping I could achieve the same at the gateway level. This is
because we have multiple front-end applications calling the sendsms
interface.

Regds,

On Tue, Nov 8, 2011 at 9:42 PM, Rene Kluwen rene.klu...@chimit.nl wrote:
 Why don't you check for nr of characters before you send them to the
 /cgi-bin/sendsms interface?

 == Rene

 -Original Message-
 From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf
 Of Engel L
 Sent: Tuesday, 08 November, 2011 10:04
 To: users@kannel.org
 Subject: Is there a way for kannel to not forward to SMSC SMS whose
 destination numbers are less than a specified number of characters.

 Hi,

 I am using Kannel 1.4.3 and am looking for a means for the gateway to
 drop messages destined to numbers with missing characters. The reason
 being sometimes clients send texts to numbers less than the in-my-case
 acceptable 12 digits and the NOs charge me for them.

 Regds,

 Engel

Responsibility for inversion of source and destination address for DLR

[Mike Nelson]

Hello All,

 

I was wondering if anyone might be able to help explain to
me what box has the responsibility of inverting source and destination
addresses in DLRs.  If possible, a
pointer to where in the source code this is *supposed* to happen would also be
helpful. I emphasize supposed to because it is my understanding
from reading prior threads that there is an erroneous inversion of these fields
in smsc_smpp.c's handle_pdu function. 

 

Here is some background on the motivation of this question. I
am trying to troubleshoot a problem with a closed-source kannel smppbox.   The 
issue is that the source and destination
address of the deliver_sm (DLR) message is the same as the source and
destination in the submit_sm message.  My
understanding is that this is not the proper default behavior -- that instead
the source_addr of the DLR should be the destination_addr of the submit_sm and
vice-versa. I wish to determine whether the problem is stemming from within
this smppbox, or if the problem is in my bearerbox configuration.  I am still 
new to kannel though, so I am not
sure where one would normally expect to see the inversion of these two fields
occur.  By the way, the DLRs come downstream from an
http smsc, but I don't think the configuration of this smsc could be the
problem since the look-up in the DLR database is only being based on the
dlr-mid and smsc-id -- the 'to' field seems to basically be ignored.

 

I have been trying to trace my way through the kannel source
code to determine where you would normally see the source_addr and
destination_addr fields be swapped when constructing a DLR, but so far I have
not been able to spot it.  To me, it
seems as though the source_addr always gets assigned as the source and the
destination_addr always gets assigned as the destination when dropping this
information into the DLR database and when pulling it out of the DLR database.  
It seems as though they continue to be
uninverted as they are converted into 'msg'es, and these msg's are then sent to
the smppbox for delivery to the ESME.  Is
this how it works though, or have the source_addr and destination_addr already
been inverted at some point during the process of handing the message from
smppbox to bearerbox to DLR database and back out?  I have been staring at too 
much code lately,
so I am hoping that someone can show me what I have missed.  That is, can 
someone explain at what step the
source_addr (sender) of the submit_sm message should get placed
into the role of destination_addr, or receiver, for the DLR's
deliver_sm PDU?  

 

Many thanks,

 

Mike
  

Re: Responsibility for inversion of source and destination address for DLR

[Nikos Balkanas]

Hi,

Bb has assumed this responsibility since almost 10 years now. It inverts 
addresses to the original before submitting to the endpoint (smsbox). Since 
then a number of add-on boxes have been developed since (sqlbox, smppbox). 
It seems to me, that since they were created as add-ons to bb, they should 
abide by the bb communication API. That means that they should treat 
addresses as original and handle them according to their needs.


If bb were to change, so would smsbox. Since both of these preexisted the 
other boxes, it seems to me that these boxes should align themselves to bb, 
not the other way around.


If you decide to patch your bb, the code is in gw/dlr.c: 436 in dlr_find(). 
Bear in mind that if you do so, you will be branching off and future updates 
may need merging.


BR,
Nikos
- Original Message - 
From: Mike Nelson

To: users@kannel.org
Sent: Sunday, July 31, 2011 11:43 PM
Subject: Responsibility for inversion of source and destination address for 
DLR



Hello All,

I was wondering if anyone might be able to help explain to me what box has 
the responsibility of inverting source and destination addresses in DLRs. 
If possible, a pointer to where in the source code this is *supposed* to 
happen would also be helpful. I emphasize supposed to because it is my 
understanding from reading prior threads that there is an erroneous 
inversion of these fields in smsc_smpp.c's handle_pdu function.


Here is some background on the motivation of this question. I am trying to 
troubleshoot a problem with a closed-source kannel smppbox.   The issue is 
that the source and destination address of the deliver_sm (DLR) message is 
the same as the source and destination in the submit_sm message.  My 
understanding is that this is not the proper default behavior -- that 
instead the source_addr of the DLR should be the destination_addr of the 
submit_sm and vice-versa. I wish to determine whether the problem is 
stemming from within this smppbox, or if the problem is in my bearerbox 
configuration.  I am still new to kannel though, so I am not sure where one 
would normally expect to see the inversion of these two fields occur.  By 
the way, the DLRs come downstream from an http smsc, but I don't think the 
configuration of this smsc could be the problem since the look-up in the DLR 
database is only being based on the dlr-mid and smsc-id -- the 'to' field 
seems to basically be ignored.


I have been trying to trace my way through the kannel source code to 
determine where you would normally see the source_addr and destination_addr 
fields be swapped when constructing a DLR, but so far I have not been able 
to spot it.  To me, it seems as though the source_addr always gets assigned 
as the source and the destination_addr always gets assigned as the 
destination when dropping this information into the DLR database and when 
pulling it out of the DLR database.  It seems as though they continue to be 
uninverted as they are converted into 'msg'es, and these msg's are then sent 
to the smppbox for delivery to the ESME.  Is this how it works though, or 
have the source_addr and destination_addr already been inverted at some 
point during the process of handing the message from smppbox to bearerbox to 
DLR database and back out?  I have been staring at too much code lately, so 
I am hoping that someone can show me what I have missed.  That is, can 
someone explain at what step the source_addr (sender) of the submit_sm 
message should get placed into the role of destination_addr, or receiver, 
for the DLR's deliver_sm PDU?


Many thanks,

Mike 

Re: issue with DLR and destination Field

[Nikos Balkanas]

Hi,

I don't think that your patch was ever commited. I submitted the dlr patch 
adding support for dest numbers. This depends on the use_dest parameter 
which is turned on for emi  cimd smscs. There was some discussion about 
having it configurable, but at the time that depended only on the smsc. 
Therefore, use_dest is hardcoded on only for these 2 smscs in their drivers.


BR,
Nikos
- Original Message - 
From: info.ubichip

To: users-requ...@kannel.org ; users@kannel.org
Sent: Tuesday, January 11, 2011 1:20 AM
Subject: issue with DLR and destination Field


Hello,

In 2005, I make a small patch in dlr_mysql.c for the Β for people using 
kannel with modems. Β At this time the patch was using the triplet TS, SMSC, 
and DST to find the right dlr and then make update/delete operation


I realized there has been some modification of the 1.5.0 release and my 
patch has been reformated.
Now my previous solution Β is working if the field dst is passed to the 
function dlr_remove or dlr_update and it depend on a field which the name is 
use_dst. But despict my search, I don't know how to set up ON this 
use_dst (in a configuration file or in kannel conf ???).


Does someone met similar issue ?

thanks in advance for your help and Β happy new year 

issue with DLR and destination Field

[info.ubichip]

Hello,

 

In 2005, I make a small patch in dlr_mysql.c for the  for people using kannel 
with modems.  At this time the patch was using the triplet TS, SMSC, and DST to 
find the right dlr and then make update/delete operation

 

I realized there has been some modification of the 1.5.0 release and my patch 
has been reformated.

Now my previous solution  is working if the field dst is passed to the function 
dlr_remove or dlr_update and it depend on a field which the name is use_dst. 
But despict my search, I don't know how to set up ON this use_dst (in a 
configuration file or in kannel conf ???).

 

Does someone met similar issue ?

 

thanks in advance for your help and  happy new year

Re: Re : SMSC returned error code 0x0000000b (Invalid Destination Address) in response to submit_sm.

[Emmanuel CHANSON]

Finally Kidi did you solve this issue ?

Me no, I found out my issue maybe linked to ESM_CLASS, will try the patch
below as maybe my SMS-C does not accept the default message mode Kannel
uses: 0x03 (Store and Forward), Most SMS-C use 0x00 (Default Mode).

Well, regarding esm_class, I always have to modify smsc_smpp.c on line:

pdu-u.submit_sm.esm_class = ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE

to

pdu-u.submit_sm.esm_class = ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE

In order for my operator's SMSCs being able to process my messages.
They seem to like a 0 instead of a 3 on esm_class.

I'd love to be able to do that without patching Kannel! I think a
config directive would suffice for me, but I think that maybe there
are some people that would also like to do that on a message basis...

Regards,

BTW, I am not not in France Elton :), but thanks for your help

BR,

Emmanuel

2010/10/8 Elton Hoxha elt...@gmail.com

 Both of you guys are posting from France, probably connected to the same
 SMSC :)

 Maybe operator is having any night activity and destination tables of SMSC
 have been affected.

 On Fri, Oct 8, 2010 at 1:28 AM, Kidi Kidi kidi...@yahoo.fr wrote:

  either i use the parameters below or not i get the same result. i have a
 shortcode 2845 and i want to sent a message to a long phone number.

 source-addr-ton=1
 source-addr-npi=1
 dest-addr-ton=1
 dest-addr-npi=1
 bind-addr-ton=1
 bind-addr-npi=1

  --
 *De :* Emmanuel CHANSON emmanuelchan...@gmail.com
 *À :* Kidi Kidi kidi...@yahoo.fr
 *Cc :* users@kannel.org
 *Envoyé le :* Jeu 7 octobre 2010, 23h 12min 58s
 *Objet :* Re: SMSC returned error code 0x000b (Invalid Destination
 Address) in response to submit_sm.

 I have exactly the same issue at the moment and I try to determine if it
 is a Kannel or SMSC issue:
 I try different combination of TON  NPI without success.

 For the moment I would say it is a SMSC configuration issue...but

 bearerbox.log
 -
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: Got PDU:
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP PDU 0xb3802be0 dump:
 2010-10-07 10:54:34 [16729] [6] DEBUG:   type_name: enquire_link_resp
 2010-10-07 10:54:34 [16729] [6] DEBUG:   command_id: 2147483669 =
 0x8015
 2010-10-07 10:54:34 [16729] [6] DEBUG:   command_status: 0 = 0x
 2010-10-07 10:54:34 [16729] [6] DEBUG:   sequence_number: 37 = 0x0025
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP PDU dump ends.
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
 2010-10-07 10:55:00 [16729] [18] DEBUG: boxc_receiver: sms received
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: Sending PDU:
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU 0xb3803980 dump:
 2010-10-07 10:55:00 [16729] [6] DEBUG:   type_name: submit_sm
 2010-10-07 10:55:00 [16729] [6] DEBUG:   command_id: 4 = 0x0004
 2010-10-07 10:55:00 [16729] [6] DEBUG:   command_status: 0 = 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   sequence_number: 38 = 0x0026
 2010-10-07 10:55:00 [16729] [6] DEBUG:   service_type: NULL
 2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr_ton: 2 = 0x0002
 2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr_npi: 1 = 0x0001
 2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr: 5656
 2010-10-07 10:55:00 [16729] [6] DEBUG:   dest_addr_ton: 1 = 0x0001
 2010-10-07 10:55:00 [16729] [6] DEBUG:   dest_addr_npi: 1 = 0x0001
 2010-10-07 10:55:00 [16729] [6] DEBUG:   destination_addr: x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   esm_class: 3 = 0x0003
 2010-10-07 10:55:00 [16729] [6] DEBUG:   protocol_id: 0 = 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   priority_flag: 0 = 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   schedule_delivery_time: NULL
 2010-10-07 10:55:00 [16729] [6] DEBUG:   validity_period: NULL
 2010-10-07 10:55:00 [16729] [6] DEBUG:   registered_delivery: 0 =
 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   replace_if_present_flag: 0 =
 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   data_coding: 0 = 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   sm_default_msg_id: 0 = 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   sm_length: 4 = 0x0004
 2010-10-07 10:55:00 [16729] [6] DEBUG:   short_message: test
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU dump ends.
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (1.00,0.00)
 2010-10-07 10:55:00 [16729] [18] DEBUG: send_msg: sending msg to box:
 127.0.0.1
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (1.00,0.00)
 2010-10-07 10:55:00 [16729] [6] WARNING: SMPP: PDU NULL terminated string
 (message_id) has no NULL.
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: Got PDU:
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU

SMSC returned error code 0x0000000b (Invalid Destination Address) in response to submit_sm.

[Kidi Kidi]

Hi,
I use kannel SMPP ESME and i get this error whenever i try to send a MT message 
:

SMSC returned error code 0x000b (Invalid Destination Address) in response 
to 
submit_sm.


  

SMSC returned error code 0x0000000b (Invalid Destination Address) in response to submit_sm.

[Kidi Kidi]

Hi,
I use kannel SMPP ESME and i get this error whenever i try to send a MT message 
:

SMSC returned error code 0x000b (Invalid Destination Address) in response 
to 
submit_sm.


  

Re: SMSC returned error code 0x0000000b (Invalid Destination Address) in response to submit_sm.

[Emmanuel CHANSON]

I have exactly the same issue at the moment and I try to determine if it is
a Kannel or SMSC issue:
I try different combination of TON  NPI without success.

For the moment I would say it is a SMSC configuration issue...but

bearerbox.log
-
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: Got PDU:
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP PDU 0xb3802be0 dump:
2010-10-07 10:54:34 [16729] [6] DEBUG:   type_name: enquire_link_resp
2010-10-07 10:54:34 [16729] [6] DEBUG:   command_id: 2147483669 = 0x8015
2010-10-07 10:54:34 [16729] [6] DEBUG:   command_status: 0 = 0x
2010-10-07 10:54:34 [16729] [6] DEBUG:   sequence_number: 37 = 0x0025
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP PDU dump ends.
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
2010-10-07 10:55:00 [16729] [18] DEBUG: boxc_receiver: sms received
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: Sending PDU:
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU 0xb3803980 dump:
2010-10-07 10:55:00 [16729] [6] DEBUG:   type_name: submit_sm
2010-10-07 10:55:00 [16729] [6] DEBUG:   command_id: 4 = 0x0004
2010-10-07 10:55:00 [16729] [6] DEBUG:   command_status: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   sequence_number: 38 = 0x0026
2010-10-07 10:55:00 [16729] [6] DEBUG:   service_type: NULL
2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr_ton: 2 = 0x0002
2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr_npi: 1 = 0x0001
2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr: 5656
2010-10-07 10:55:00 [16729] [6] DEBUG:   dest_addr_ton: 1 = 0x0001
2010-10-07 10:55:00 [16729] [6] DEBUG:   dest_addr_npi: 1 = 0x0001
2010-10-07 10:55:00 [16729] [6] DEBUG:   destination_addr: x
2010-10-07 10:55:00 [16729] [6] DEBUG:   esm_class: 3 = 0x0003
2010-10-07 10:55:00 [16729] [6] DEBUG:   protocol_id: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   priority_flag: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   schedule_delivery_time: NULL
2010-10-07 10:55:00 [16729] [6] DEBUG:   validity_period: NULL
2010-10-07 10:55:00 [16729] [6] DEBUG:   registered_delivery: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   replace_if_present_flag: 0 =
0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   data_coding: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   sm_default_msg_id: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   sm_length: 4 = 0x0004
2010-10-07 10:55:00 [16729] [6] DEBUG:   short_message: test
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU dump ends.
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (1.00,0.00)
2010-10-07 10:55:00 [16729] [18] DEBUG: send_msg: sending msg to box:
127.0.0.1
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (1.00,0.00)
2010-10-07 10:55:00 [16729] [6] WARNING: SMPP: PDU NULL terminated string
(message_id) has no NULL.
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: Got PDU:
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU 0xb3802f50 dump:
2010-10-07 10:55:00 [16729] [6] DEBUG:   type_name: submit_sm_resp
2010-10-07 10:55:00 [16729] [6] DEBUG:   command_id: 2147483652 = 0x8004
2010-10-07 10:55:00 [16729] [6] DEBUG:   command_status: 11 = 0x000b
2010-10-07 10:55:00 [16729] [6] DEBUG:   sequence_number: 38 = 0x0026
2010-10-07 10:55:00 [16729] [6] DEBUG:   message_id: NULL
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU dump ends.
2010-10-07 10:55:00 [16729] [6] ERROR: SMPP[m]: *SMSC returned error code
0x000b (Invalid Destination Address) in response to submit_sm.*
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (1.00,0.00)



Regards,

Emmanuel

2010/10/8 Kidi Kidi kidi...@yahoo.fr

 Hi,
 I use kannel SMPP ESME and i get this error whenever i try to send a MT
 message :

 SMSC returned error code 0x000b (Invalid Destination Address) in
 response to submit_sm.

Re : SMSC returned error code 0x0000000b (Invalid Destination Address) in response to submit_sm.

[Kidi Kidi]

either i use the parameters below or not i get the same result. i have a 
shortcode 2845 and i want to sent a message to a long phone number.

source-addr-ton=1
source-addr-npi=1
dest-addr-ton=1
dest-addr-npi=1
bind-addr-ton=1
bind-addr-npi=1





De : Emmanuel CHANSON emmanuelchan...@gmail.com
À : Kidi Kidi kidi...@yahoo.fr
Cc : users@kannel.org
Envoyé le : Jeu 7 octobre 2010, 23h 12min 58s
Objet : Re: SMSC returned error code 0x000b (Invalid Destination Address) 
in 
response to submit_sm.

I have exactly the same issue at the moment and I try to determine if it is a 
Kannel or SMSC issue:
I try different combination of TON  NPI without success.

For the moment I would say it is a SMSC configuration issue...but

bearerbox.log
-
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: Got PDU:
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP PDU 0xb3802be0 dump:
2010-10-07 10:54:34 [16729] [6] DEBUG:   type_name: enquire_link_resp
2010-10-07 10:54:34 [16729] [6] DEBUG:   command_id: 2147483669 = 0x8015
2010-10-07 10:54:34 [16729] [6] DEBUG:   command_status: 0 = 0x
2010-10-07 10:54:34 [16729] [6] DEBUG:   sequence_number: 37 = 0x0025
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP PDU dump ends.
2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
2010-10-07 10:55:00 [16729] [18] DEBUG: boxc_receiver: sms received
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: Sending PDU:
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU 0xb3803980 dump:
2010-10-07 10:55:00 [16729] [6] DEBUG:   type_name: submit_sm
2010-10-07 10:55:00 [16729] [6] DEBUG:   command_id: 4 = 0x0004
2010-10-07 10:55:00 [16729] [6] DEBUG:   command_status: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   sequence_number: 38 = 0x0026
2010-10-07 10:55:00 [16729] [6] DEBUG:   service_type: NULL
2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr_ton: 2 = 0x0002
2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr_npi: 1 = 0x0001
2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr: 5656
2010-10-07 10:55:00 [16729] [6] DEBUG:   dest_addr_ton: 1 = 0x0001
2010-10-07 10:55:00 [16729] [6] DEBUG:   dest_addr_npi: 1 = 0x0001
2010-10-07 10:55:00 [16729] [6] DEBUG:   destination_addr: x
2010-10-07 10:55:00 [16729] [6] DEBUG:   esm_class: 3 = 0x0003
2010-10-07 10:55:00 [16729] [6] DEBUG:   protocol_id: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   priority_flag: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   schedule_delivery_time: NULL
2010-10-07 10:55:00 [16729] [6] DEBUG:   validity_period: NULL
2010-10-07 10:55:00 [16729] [6] DEBUG:   registered_delivery: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   replace_if_present_flag: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   data_coding: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   sm_default_msg_id: 0 = 0x
2010-10-07 10:55:00 [16729] [6] DEBUG:   sm_length: 4 = 0x0004
2010-10-07 10:55:00 [16729] [6] DEBUG:   short_message: test
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU dump ends.
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (1.00,0.00)
2010-10-07 10:55:00 [16729] [18] DEBUG: send_msg: sending msg to box: 
127.0.0.1
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (1.00,0.00)
2010-10-07 10:55:00 [16729] [6] WARNING: SMPP: PDU NULL terminated string 
(message_id) has no NULL.
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: Got PDU:
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU 0xb3802f50 dump:
2010-10-07 10:55:00 [16729] [6] DEBUG:   type_name: submit_sm_resp
2010-10-07 10:55:00 [16729] [6] DEBUG:   command_id: 2147483652 = 0x8004
2010-10-07 10:55:00 [16729] [6] DEBUG:   command_status: 11 = 0x000b
2010-10-07 10:55:00 [16729] [6] DEBUG:   sequence_number: 38 = 0x0026
2010-10-07 10:55:00 [16729] [6] DEBUG:   message_id: NULL
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU dump ends.
2010-10-07 10:55:00 [16729] [6] ERROR: SMPP[m]: SMSC returned error code 
0x000b (Invalid Destination Address) in response to submit_sm.
2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (1.00,0.00)



Regards,

Emmanuel


2010/10/8 Kidi Kidi kidi...@yahoo.fr

Hi,
I use kannel SMPP ESME and i get this error whenever i try to send a MT 
message 
:

SMSC returned error code 0x000b (Invalid Destination Address) in response 
to 
submit_sm.






  

Re: Re : SMSC returned error code 0x0000000b (Invalid Destination Address) in response to submit_sm.

[Elton Hoxha]

Both of you guys are posting from France, probably connected to the same
SMSC :)

Maybe operator is having any night activity and destination tables of SMSC
have been affected.

On Fri, Oct 8, 2010 at 1:28 AM, Kidi Kidi kidi...@yahoo.fr wrote:

  either i use the parameters below or not i get the same result. i have a
 shortcode 2845 and i want to sent a message to a long phone number.

 source-addr-ton=1
 source-addr-npi=1
 dest-addr-ton=1
 dest-addr-npi=1
 bind-addr-ton=1
 bind-addr-npi=1

  --
 *De :* Emmanuel CHANSON emmanuelchan...@gmail.com
 *À :* Kidi Kidi kidi...@yahoo.fr
 *Cc :* users@kannel.org
 *Envoyé le :* Jeu 7 octobre 2010, 23h 12min 58s
 *Objet :* Re: SMSC returned error code 0x000b (Invalid Destination
 Address) in response to submit_sm.

 I have exactly the same issue at the moment and I try to determine if it is
 a Kannel or SMSC issue:
 I try different combination of TON  NPI without success.

 For the moment I would say it is a SMSC configuration issue...but

 bearerbox.log
 -
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: Got PDU:
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP PDU 0xb3802be0 dump:
 2010-10-07 10:54:34 [16729] [6] DEBUG:   type_name: enquire_link_resp
 2010-10-07 10:54:34 [16729] [6] DEBUG:   command_id: 2147483669 =
 0x8015
 2010-10-07 10:54:34 [16729] [6] DEBUG:   command_status: 0 = 0x
 2010-10-07 10:54:34 [16729] [6] DEBUG:   sequence_number: 37 = 0x0025
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP PDU dump ends.
 2010-10-07 10:54:34 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
 2010-10-07 10:55:00 [16729] [18] DEBUG: boxc_receiver: sms received
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (0.00,0.00)
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: Sending PDU:
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU 0xb3803980 dump:
 2010-10-07 10:55:00 [16729] [6] DEBUG:   type_name: submit_sm
 2010-10-07 10:55:00 [16729] [6] DEBUG:   command_id: 4 = 0x0004
 2010-10-07 10:55:00 [16729] [6] DEBUG:   command_status: 0 = 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   sequence_number: 38 = 0x0026
 2010-10-07 10:55:00 [16729] [6] DEBUG:   service_type: NULL
 2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr_ton: 2 = 0x0002
 2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr_npi: 1 = 0x0001
 2010-10-07 10:55:00 [16729] [6] DEBUG:   source_addr: 5656
 2010-10-07 10:55:00 [16729] [6] DEBUG:   dest_addr_ton: 1 = 0x0001
 2010-10-07 10:55:00 [16729] [6] DEBUG:   dest_addr_npi: 1 = 0x0001
 2010-10-07 10:55:00 [16729] [6] DEBUG:   destination_addr: x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   esm_class: 3 = 0x0003
 2010-10-07 10:55:00 [16729] [6] DEBUG:   protocol_id: 0 = 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   priority_flag: 0 = 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   schedule_delivery_time: NULL
 2010-10-07 10:55:00 [16729] [6] DEBUG:   validity_period: NULL
 2010-10-07 10:55:00 [16729] [6] DEBUG:   registered_delivery: 0 =
 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   replace_if_present_flag: 0 =
 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   data_coding: 0 = 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   sm_default_msg_id: 0 = 0x
 2010-10-07 10:55:00 [16729] [6] DEBUG:   sm_length: 4 = 0x0004
 2010-10-07 10:55:00 [16729] [6] DEBUG:   short_message: test
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU dump ends.
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (1.00,0.00)
 2010-10-07 10:55:00 [16729] [18] DEBUG: send_msg: sending msg to box:
 127.0.0.1
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (1.00,0.00)
 2010-10-07 10:55:00 [16729] [6] WARNING: SMPP: PDU NULL terminated string
 (message_id) has no NULL.
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: Got PDU:
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU 0xb3802f50 dump:
 2010-10-07 10:55:00 [16729] [6] DEBUG:   type_name: submit_sm_resp
 2010-10-07 10:55:00 [16729] [6] DEBUG:   command_id: 2147483652 =
 0x8004
 2010-10-07 10:55:00 [16729] [6] DEBUG:   command_status: 11 = 0x000b
 2010-10-07 10:55:00 [16729] [6] DEBUG:   sequence_number: 38 = 0x0026
 2010-10-07 10:55:00 [16729] [6] DEBUG:   message_id: NULL
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP PDU dump ends.
 2010-10-07 10:55:00 [16729] [6] ERROR: SMPP[m]: *SMSC returned error code
 0x000b (Invalid Destination Address) in response to submit_sm.*
 2010-10-07 10:55:00 [16729] [6] DEBUG: SMPP[m]: throughput (1.00,0.00)



 Regards,

 Emmanuel

 2010/10/8 Kidi Kidi kidi...@yahoo.fr

Hi,
 I use kannel SMPP ESME and i get this error whenever i try to send a MT
 message :

 SMSC returned error code 0x000b (Invalid Destination Address) in
 response to submit_sm.

Re: DLR without destination information

[Nikos Balkanas]

You missunderstood me. Source code only selects on db based on ts and smsc. 
Patch was supposed to add destination matching as well, but looking at the 
source code never made it. Therefore selects are still done using ts and 
smsc only. Arguments to the functions include destination, which is, 
however, not used in the final select.


I don't know how the http smsc will handle this case. Please post logs.

BR,
Nikos
- Original Message - 
From: Willy Mularto sangpr...@gmail.com

To: Nikos Balkanas nbalka...@gmail.com
Cc: users@kannel.org
Sent: Friday, April 23, 2010 3:46 AM
Subject: Re: DLR without destination information


Thanks for the reply Nikos, the telco used SMPP before. But now they migrate 
to HTTP, and on it's new system they don't provide the destination 
information on DLR. But if we check Kannel architecture, it checks the 
destination information (I don't use 1.4.3). Do you know the patch name in 
order to get DLR without destination address?




sangprabv
sangpr...@gmail.com


On Apr 22, 2010, at 9:41 PM, Nikos Balkanas wrote:


Hi,

Interesting. Up till start of 2009, launch of 1.4.3, dlr matching would 
actually get done only with message_id (ts) and smsc. Sure all calling 
functions passed also destination, but it was never used in the actual 
select. That created a problem, since a lot of SMPP smscs used as ts the 
timestamp to the second, and during high traffic, it didn't guarantee 
uniqueness. So it was patched to select also based on the destination 
number.


At that point it was not considered that there were SMScs with DLRs 
without destination numbers. According to SMPP 3.4 spec SMPP PDUs are not 
allowed to have destination_addr NULL.


What is your SMSc?

BR,
Nikos
- Original Message - From: Willy Mularto sangpr...@gmail.com
To: users@kannel.org
Sent: Thursday, April 22, 2010 4:43 PM
Subject: DLR without destination information


Hi list,
Is it possible for Kannel to lookup DLR without destination information? 
Since my telco only send message id, date, and status information. Thanks 
alot.




sangprabv
sangpr...@gmail.com

DLR without destination information

[Willy Mularto]

Hi list,
Is it possible for Kannel to lookup DLR without destination information? Since 
my telco only send message id, date, and status information. Thanks alot.



sangprabv
sangpr...@gmail.com

Re: DLR without destination information

[Nikos Balkanas]

Hi,

Interesting. Up till start of 2009, launch of 1.4.3, dlr matching would 
actually get done only with message_id (ts) and smsc. Sure all calling 
functions passed also destination, but it was never used in the actual 
select. That created a problem, since a lot of SMPP smscs used as ts the 
timestamp to the second, and during high traffic, it didn't guarantee 
uniqueness. So it was patched to select also based on the destination 
number.


At that point it was not considered that there were SMScs with DLRs without 
destination numbers. According to SMPP 3.4 spec SMPP PDUs are not allowed to 
have destination_addr NULL.


What is your SMSc?

BR,
Nikos
- Original Message - 
From: Willy Mularto sangpr...@gmail.com

To: users@kannel.org
Sent: Thursday, April 22, 2010 4:43 PM
Subject: DLR without destination information


Hi list,
Is it possible for Kannel to lookup DLR without destination information? 
Since my telco only send message id, date, and status information. Thanks 
alot.




sangprabv
sangpr...@gmail.com

Re: DLR without destination information

[Willy Mularto]

Thanks for the reply Nikos, the telco used SMPP before. But now they migrate to 
HTTP, and on it's new system they don't provide the destination information on 
DLR. But if we check Kannel architecture, it checks the destination information 
(I don't use 1.4.3). Do you know the patch name in order to get DLR without 
destination address?



sangprabv
sangpr...@gmail.com


On Apr 22, 2010, at 9:41 PM, Nikos Balkanas wrote:

 Hi,
 
 Interesting. Up till start of 2009, launch of 1.4.3, dlr matching would 
 actually get done only with message_id (ts) and smsc. Sure all calling 
 functions passed also destination, but it was never used in the actual 
 select. That created a problem, since a lot of SMPP smscs used as ts the 
 timestamp to the second, and during high traffic, it didn't guarantee 
 uniqueness. So it was patched to select also based on the destination number.
 
 At that point it was not considered that there were SMScs with DLRs without 
 destination numbers. According to SMPP 3.4 spec SMPP PDUs are not allowed to 
 have destination_addr NULL.
 
 What is your SMSc?
 
 BR,
 Nikos
 - Original Message - From: Willy Mularto sangpr...@gmail.com
 To: users@kannel.org
 Sent: Thursday, April 22, 2010 4:43 PM
 Subject: DLR without destination information
 
 
 Hi list,
 Is it possible for Kannel to lookup DLR without destination information? 
 Since my telco only send message id, date, and status information. Thanks 
 alot.
 
 
 
 sangprabv
 sangpr...@gmail.com
 
 
 

Problem matching DLR to MT (destination mismatch)

[Konstantin Vayner]

Hello, users!

I have a problem matching a DLR to the original message.
Here's what happens: I send a message to an smsc with international msisdn
(+97250...), and get back DLR for local number (050... )
Is there anything i can do on my side?

Here's transaction dump from the log:

2009-09-16 10:30:46 [4977] [6] DEBUG: SMPP[smsc_pelephone_mt]: Manually
forced source addr ton = 1, source add npi = 1
2009-09-16 10:30:46 [4977] [6] DEBUG: SMPP[smsc_pelephone_mt]: Sending PDU:
2009-09-16 10:30:46 [4977] [6] DEBUG: SMPP PDU 0x81bda20 dump:
2009-09-16 10:30:46 [4977] [6] DEBUG:   type_name: submit_sm
2009-09-16 10:30:46 [4977] [6] DEBUG:   command_id: 4 = 0x0004
2009-09-16 10:30:46 [4977] [6] DEBUG:   command_status: 0 = 0x
2009-09-16 10:30:46 [4977] [6] DEBUG:   sequence_number: 67 = 0x0043
2009-09-16 10:30:46 [4977] [6] DEBUG:   service_type: NULL
2009-09-16 10:30:46 [4977] [6] DEBUG:   source_addr_ton: 1 = 0x0001
2009-09-16 10:30:46 [4977] [6] DEBUG:   source_addr_npi: 1 = 0x0001
2009-09-16 10:30:46 [4977] [6] DEBUG:   source_addr: 1234
2009-09-16 10:30:46 [4977] [6] DEBUG:   dest_addr_ton: 1 = 0x0001
2009-09-16 10:30:46 [4977] [6] DEBUG:   dest_addr_npi: 1 = 0x0001
2009-09-16 10:30:46 [4977] [6] DEBUG:   destination_addr: *972507867645*
2009-09-16 10:30:46 [4977] [6] DEBUG:   esm_class: 3 = 0x0003
2009-09-16 10:30:46 [4977] [6] DEBUG:   protocol_id: 0 = 0x
2009-09-16 10:30:46 [4977] [6] DEBUG:   priority_flag: 0 = 0x
2009-09-16 10:30:46 [4977] [6] DEBUG:   schedule_delivery_time: NULL
2009-09-16 10:30:46 [4977] [6] DEBUG:   validity_period: NULL
2009-09-16 10:30:46 [4977] [6] DEBUG:   registered_delivery: 1 = 0x0001
2009-09-16 10:30:46 [4977] [6] DEBUG:   replace_if_present_flag: 0 =
0x
2009-09-16 10:30:46 [4977] [6] DEBUG:   data_coding: 0 = 0x
2009-09-16 10:30:46 [4977] [6] DEBUG:   sm_default_msg_id: 0 = 0x
2009-09-16 10:30:46 [4977] [6] DEBUG:   sm_length: 4 = 0x0004
2009-09-16 10:30:46 [4977] [6] DEBUG:   short_message: test
2009-09-16 10:30:46 [4977] [6] DEBUG: SMPP PDU dump ends.
2009-09-16 10:30:46 [4977] [6] DEBUG: SMPP[smsc_pelephone_mt]: Got PDU:
2009-09-16 10:30:46 [4977] [6] DEBUG: SMPP PDU 0x81bda20 dump:
2009-09-16 10:30:46 [4977] [6] DEBUG:   type_name: submit_sm_resp
2009-09-16 10:30:46 [4977] [6] DEBUG:   command_id: 2147483652 = 0x8004
2009-09-16 10:30:46 [4977] [6] DEBUG:   command_status: 0 = 0x
2009-09-16 10:30:46 [4977] [6] DEBUG:   sequence_number: 67 = 0x0043
2009-09-16 10:30:46 [4977] [6] DEBUG:   message_id: FF0208008043
2009-09-16 10:30:46 [4977] [6] DEBUG: SMPP PDU dump ends.
2009-09-16 10:30:46 [4977] [6] DEBUG: DLR[internal]: Adding DLR
smsc=smsc_pelephone_mt, ts=FF0208008043, src=1234, *dst=+972507867645*,
mask=31, boxc=
2009-09-16 10:30:46 [4977] [6] DEBUG: SMSC[smsc_pelephone_mt]: creating DLR
message
2009-09-16 10:30:46 [4977] [6] DEBUG: SMSC[smsc_pelephone_mt]: DLR =
http://127.0.0.1/imsc/interfaces/kannel_http/dlr.php?msg_id=1287dlr=%dreason=%A

...and then comes the DLR...


2009-09-16 10:30:49 [4977] [6] DEBUG: SMPP[smsc_pelephone_mt]: Got PDU:
2009-09-16 10:30:49 [4977] [6] DEBUG: SMPP PDU 0x81c dump:
2009-09-16 10:30:49 [4977] [6] DEBUG:   type_name: deliver_sm
2009-09-16 10:30:49 [4977] [6] DEBUG:   command_id: 5 = 0x0005
2009-09-16 10:30:49 [4977] [6] DEBUG:   command_status: 0 = 0x
2009-09-16 10:30:49 [4977] [6] DEBUG:   sequence_number: 64 = 0x0040
2009-09-16 10:30:49 [4977] [6] DEBUG:   service_type: NULL
2009-09-16 10:30:49 [4977] [6] DEBUG:   source_addr_ton: 1 = 0x0001
2009-09-16 10:30:49 [4977] [6] DEBUG:   source_addr_npi: 1 = 0x0001
2009-09-16 10:30:49 [4977] [6] DEBUG:   source_addr: *0507867645*
2009-09-16 10:30:49 [4977] [6] DEBUG:   dest_addr_ton: 1 = 0x0001
2009-09-16 10:30:49 [4977] [6] DEBUG:   dest_addr_npi: 1 = 0x0001
2009-09-16 10:30:49 [4977] [6] DEBUG:   destination_addr: 1234
2009-09-16 10:30:49 [4977] [6] DEBUG:   esm_class: 4 = 0x0004
2009-09-16 10:30:49 [4977] [6] DEBUG:   protocol_id: 0 = 0x
2009-09-16 10:30:49 [4977] [6] DEBUG:   priority_flag: 0 = 0x
2009-09-16 10:30:49 [4977] [6] DEBUG:   schedule_delivery_time: NULL
2009-09-16 10:30:49 [4977] [6] DEBUG:   validity_period: NULL
2009-09-16 10:30:49 [4977] [6] DEBUG:   registered_delivery: 0 = 0x
2009-09-16 10:30:49 [4977] [6] DEBUG:   replace_if_present_flag: 0 =
0x
2009-09-16 10:30:49 [4977] [6] DEBUG:   data_coding: 0 = 0x
2009-09-16 10:30:49 [4977] [6] DEBUG:   sm_default_msg_id: 0 = 0x
2009-09-16 10:30:49 [4977] [6] DEBUG:   sm_length: 111 = 0x006f
2009-09-16 10:30:49 [4977] [6] DEBUG:   short_message:
2009-09-16 10:30:49 [4977] [6] DEBUG:Octet string at 0x81c3fa0:
2009-09-16 10:30:49 [4977] [6] DEBUG:  len:  111
2009-09-16 10:30:49 [4977] [6] DEBUG:  size: 112
2009-09-16 10:30:49 [4977] [6] DEBUG:  immutable: 0
2009-09-16 10:30:49 [4977] [6] DEBUG:  data: 69 64 3a 32 38 30 

+ in destination

[satish]

Hi All
Can any body help me to put + as prefix in destination . I am using 
this url for sending(sendsms)


Example:
http://127.0.0.1:13013/cgi-bin/sendsms?username=abcpassword=defto=+91from=xxtext=test%20messagesmsc=smsc_test
when i am sending this url it not sending + appended with number
what changes i need to add in configuration files for that problem

My smsc configuration file is as

group = smsc
smsc = smpp
smsc-id = smpp_g
allowed-smsc-id = smpp_g
host = localhost
port = 2345
receive-port = 2345
#transceiver-mode = 0
system-type = smpp
#system-type = VMA
smsc-username = xyx
smsc-password = zzz
source-addr-ton = 1
source-addr-npi = 1
dest-addr-ton = 1
dest-addr-npi = 1
enquire-link-interval = 30
#allowed-prefix = 0
#denied-prefix = 0
#max-pending-submits = 0
#throughput = 0
msg-id-type = 0
source-addr-autodetect = yes
thanks  regards
Satish

Re: + in destination

[Alejandro Guerrieri]

You have to url encode it, + translates into a space if you use it on an
url.
Use %2B instead.

Regards,

Alejandro

On Fri, Sep 4, 2009 at 1:59 PM, satish satish.b...@routesms.com wrote:

 Hi All
 Can any body help me to put + as prefix in destination . I am using this
 url for sending(sendsms)

 Example:

 http://127.0.0.1:13013/cgi-bin/sendsms?username=abcpassword=defto=+91from=xxtext=test%20messagesmsc=smsc_test
 when i am sending this url it not sending + appended with number
 what changes i need to add in configuration files for that problem

 My smsc configuration file is as

 group = smsc
 smsc = smpp
 smsc-id = smpp_g
 allowed-smsc-id = smpp_g
 host = localhost
 port = 2345
 receive-port = 2345
 #transceiver-mode = 0
 system-type = smpp
 #system-type = VMA
 smsc-username = xyx
 smsc-password = zzz
 source-addr-ton = 1
 source-addr-npi = 1
 dest-addr-ton = 1
 dest-addr-npi = 1
 enquire-link-interval = 30
 #allowed-prefix = 0
 #denied-prefix = 0
 #max-pending-submits = 0
 #throughput = 0
 msg-id-type = 0
 source-addr-autodetect = yes
 thanks  regards
 Satish

Re: + in destination

[seikath]

did you try to urlencode the + ?

the other approach is to mess with the npi-tone settings values.

satish wrote:
 Hi All
 Can any body help me to put + as prefix in destination . I am using
 this url for sending(sendsms)
 
 Example:
 http://127.0.0.1:13013/cgi-bin/sendsms?username=abcpassword=defto=+91from=xxtext=test%20messagesmsc=smsc_test
 
 when i am sending this url it not sending + appended with number
 what changes i need to add in configuration files for that problem
 
 My smsc configuration file is as
 
 group = smsc
 smsc = smpp
 smsc-id = smpp_g
 allowed-smsc-id = smpp_g
 host = localhost
 port = 2345
 receive-port = 2345
 #transceiver-mode = 0
 system-type = smpp
 #system-type = VMA
 smsc-username = xyx
 smsc-password = zzz
 source-addr-ton = 1
 source-addr-npi = 1
 dest-addr-ton = 1
 dest-addr-npi = 1
 enquire-link-interval = 30
 #allowed-prefix = 0
 #denied-prefix = 0
 #max-pending-submits = 0
 #throughput = 0
 msg-id-type = 0
 source-addr-autodetect = yes
 thanks  regards
 Satish
 
 
 

Re: PPG destination Port

[Nikos Balkanas]

Hi Irfan,

Sorry for answering late, I've been away on business.

What you ask is the easy part: wbxml encode PAP + si and send as SMS over wap 
port. 

Now the difficult part:

What is a mobile to do with a binary message over an unknown port? You see wap 
service on mobiles listens on a specific port. What most likely will happen is 
to reject the connection altogether. If it happens to be an open port, chances 
are that it will be for another service, and therefore not understand the push.

In summary: If you want to send wap on a non standard port to a mobile, you 
will need to add support to the mobile for wap messages on that port.

BR,
Nikos

- Original Message - 
  From: Irfan Malik 
  To: users@kannel.org 
  Sent: Wednesday, May 27, 2009 2:04 PM
  Subject: PPG destination Port


  Hi,

   

  I have configured PPG service in kannel. 

   

  group = ppg

  ppg-url = /wappush

  ppg-port = 8080

  concurrent-pushes = 100

  users = 1024

  ppg-allow-ip = 127.0.0.1 

  global-sender = +92xxx

  default-smsc = SMSC-1

  trusted-pi = true

  service-name = ppg1

   

   

  It is working fine and I can generate a WAP push using PAP method. I want 
that WAP push to be sent on customized port other then standard port i.e. 2948. 
How can I change destination port of WAP Push generated by PPG service? I can 
send WAP Push on customized port using following

   

   
http://localhost:13013/cgi-bin/sendsms?username=usernamepassword=passurl=www.mycompan.commsg=ClickMeudh=%06%05%04%74%%23%F0
 

   

   

  Is it possible that I can do the same with PAP message? So, when I use push 
initiator and hit Push Proxy Gateway , the resulting WAP Push will be sent to 
customized port for example 16700

   

  It will be of great help if you can guide me which file PPG use for creation 
of wap push so I can update it’s UDH accordingly.

   

  Any help will be highly appreciated. 

   

   

PPG destination Port

[Irfan Malik]

Hi,

 

I have configured PPG service in kannel. 

 

group = ppg

ppg-url = /wappush

ppg-port = 8080

concurrent-pushes = 100

users = 1024

ppg-allow-ip = 127.0.0.1 

global-sender = +92xxx

default-smsc = SMSC-1

trusted-pi = true

service-name = ppg1

 

 

It is working fine and I can generate a WAP push using PAP method. I want
that WAP push to be sent on customized port other then standard port i.e.
2948. How can I change destination port of WAP Push generated by PPG
service? I can send WAP Push on customized port using following

 

 http://localhost:13013/cgi-bin/sendsms?username=username
http://localhost:13013/cgi-bin/sendsms?username=usernamepassword=passurl=
www.mycompan.commsg=ClickMeudh=%06%05%04%74%25%23%F0
password=passurl=www.mycompan.commsg=ClickMeudh=%06%05%04%74%%23%F0 

 

 

Is it possible that I can do the same with PAP message? So, when I use push
initiator and hit Push Proxy Gateway , the resulting WAP Push will be sent
to customized port for example 16700

 

It will be of great help if you can guide me which file PPG use for creation
of wap push so I can update it's UDH accordingly.

 

Any help will be highly appreciated. 

 

 

SMS Box Not Accepting - 59898 Destination Address - How to override

[Madan KN]

Hi,
How do i override so that my sms box, accepts 59898 kind of short codes as
destination address.

MO -- SMSC -- (59898) -- Kannel.

But kannel is asking me destination address not less than 7 digits.


This is my conf:

#
# SMSC Connections
#

group = smsc
smsc = smpp
host = 192.168.1.100
port = 13003
receive-port = 13003
smsc-username = mpower
smsc-password = mpower
system-type = VMA
address-range = 
#my-number = 59898


#
# SMS Box Group
#
group = smsbox
bearerbox-host = localhost
log-file = /var/log/kannel/smsbox.log
log-level = 0
sendsms-port = 13004
#global-sender = 13004
#global-sender = 59898


Thanks,
Madan KN

Re: SMS Box Not Accepting - 59898 Destination Address - How to override

[Alejandro Guerrieri]

Which version of Kannel are you using?

ton and npi settings?

Regards,

Alejandro

On Sat, Jun 7, 2008 at 8:58 AM, Madan KN [EMAIL PROTECTED] wrote:

 Hi,
 How do i override so that my sms box, accepts 59898 kind of short codes as
 destination address.

 MO -- SMSC -- (59898) -- Kannel.

 But kannel is asking me destination address not less than 7 digits.


 This is my conf:

 #
 # SMSC Connections
 #

 group = smsc
 smsc = smpp
 host = 192.168.1.100
 port = 13003
 receive-port = 13003
 smsc-username = mpower
 smsc-password = mpower
 system-type = VMA
 address-range = 
 #my-number = 59898


 #
 # SMS Box Group
 #
 group = smsbox
 bearerbox-host = localhost
 log-file = /var/log/kannel/smsbox.log
 log-level = 0
 sendsms-port = 13004
 #global-sender = 13004
 #global-sender = 59898


 Thanks,
 Madan KN

Re: SMS Box Not Accepting - 59898 Destination Address - How to override

[Alejandro Guerrieri]

Madan,

That means you've managed to make it work?

In that case You were using NPI = 1 before right?

Older versions enforced = 7 digits on international NPI (1). When you
changed it to 3, you've removed the constrain (but you're using a
non-standard value). If that's the case, upgrading kannel will replace the
error for a warning.

Otherwise please provide:

1. Kannel version you're using.
2. The exact error you're getting.
3. Are you prefixing the destination address with a +?
4. Those TON/NPI values were given by the carrier?

Regards,

Alejandro

On Sat, Jun 7, 2008 at 11:40 AM, Madan KN [EMAIL PROTECTED] wrote:

 *Thanks a ton **Alejandro

 source-addr-ton = 0
 source-addr-npi = 0
 dest-addr-ton = 0
 dest-addr-npi = 3

 The above settings worked for me.

 Thanks,
 Madan KN*

 On Sat, Jun 7, 2008 at 7:50 PM, Alejandro Guerrieri 
 [EMAIL PROTECTED] wrote:

 Which version of Kannel are you using?

 ton and npi settings?

 Regards,

 Alejandro


 On Sat, Jun 7, 2008 at 8:58 AM, Madan KN [EMAIL PROTECTED] wrote:

 Hi,
 How do i override so that my sms box, accepts 59898 kind of short codes
 as destination address.

 MO -- SMSC -- (59898) -- Kannel.

 But kannel is asking me destination address not less than 7 digits.


 This is my conf:

 #
 # SMSC Connections
 #

 group = smsc
 smsc = smpp
 host = 192.168.1.100
 port = 13003
 receive-port = 13003
 smsc-username = mpower
 smsc-password = mpower
 system-type = VMA
 address-range = 
 #my-number = 59898


 #
 # SMS Box Group
 #
 group = smsbox
 bearerbox-host = localhost
 log-file = /var/log/kannel/smsbox.log
 log-level = 0
 sendsms-port = 13004
 #global-sender = 13004
 #global-sender = 59898


 Thanks,
 Madan KN

RE: why the destination phone didn't receive the message

[Alvaro Cornejo]

Hi Elsie

Are you sending destinations #s as international format? Here in mexico if
you call to a cell phone you must use 044 prefix; however, for sending
messages some carriers does not allow to use that prefix. You either use the
local/national prefix or international format.

In order no to have problems I always use intenational format.

Try that

Alvaro





-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Enviado el: Domingo, 09 de Diciembre de 2007 23:29
Para: users@kannel.org
Asunto: why the destination phone didn't receive the message


hi,everyone

now I am using nokia to setup a virtual smsc, when I send a message from my
phone , I found the message is sent because the fee is cost. but the
destination phone didn't receive the message. I don't what the problem of
it.

please give me some advice , thank you.

I will appreciate with your reply.

elsie

--
This message was sent on behalf of [EMAIL PROTECTED] at
openSubscriber.com
http://www.opensubscriber.com/messages/users@kannel.org/topic.html

why the destination phone didn't receive the message

[xiaoxia716]

hi,everyone

now I am using nokia to setup a virtual smsc, when I send a message from my 
phone , I found the message is sent because the fee is cost. but the 
destination phone didn't receive the message.
I don't what the problem of it.

please give me some advice , thank you.

I will appreciate with your reply.

elsie

--
This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com
http://www.opensubscriber.com/messages/users@kannel.org/topic.html

How to validate destination number length ??

[shehan]

Hi All,
In my project kannel act as ESME client  it is bound to SMPP server. I
want to send sms, those desination number length is 11, through this
connection only. Other lengths should be discarding. How to that in
kannel ??
BR,
Shehan

smpp: mysql delivery pdu message has no destination - dest_addr_ton needed ?

[Julien Buratto]

Actually I'm using a new carrier and it seems that the DLR is inserted
correctly but not retrived propertly from kannel in the dlr_mysql.c

In kannel logs, upon smpp deliver_sm, I get all the parsing of the PDU
and at the end kannel reports:

2007-03-16 16:34:29 [10563] [6] DEBUG: DLR[mysql]: Looking for DLR
smsc=mysmsc, ts=101748338, dst=0, type=2

But in the PDU I can read:
2007-03-16 16:34:29 [10563] [6] DEBUG:   dest_addr_ton: 0 = 0x
2007-03-16 16:34:29 [10563] [6] DEBUG:   dest_addr_npi: 0 = 0x
2007-03-16 16:34:29 [10563] [6] DEBUG:   destination_addr: 393356359515

Infact usually I get:
2007-01-25 00:34:44 [2346] [7] DEBUG: DLR[mysql]: Looking for DLR
smsc=myothersmsc, ts=250107004454, dst=00393356359515, type=2


So, the question is:
do you think I should set the dest_addr_ton and npd in a special way to
get the dst correctly parsed ?

Thanks
Julien

PS: The smsc I'm using reports to be smpp 3.4 standard compliant

PPS: I know that kannel does not use, in its original version, the dst
value to retrive the DLR from the database, but using only the TS can be
a problem when using EMI smsc that has no unique sms id

Provider doesnt want + on destination MSISDN

[Alex Kinch]

Hello list,

I've just had an email from a provider who wants me to test their
service. I tried last week and it failed on all messages I sent.. but
they've said now that it's because I put a + in front of the
destination MSISDN.

I've always done this, and thought it was standard. Can someone be so
kind to confirm whether I'm right, and removing + is a strange thing
to ask?

Thanks,
Alex

Sending a Wap PUSH sms to a destination port

[Oscar Elfving]

How do I send a wap push to a destination port? I have a MIDP 2.0
application registered at sms://:1669, how do I format a wap push
message so that the application activates?

I can send regular sl and si messages just fine thought.

Regards,
Oscar

Re: Sending a Wap PUSH sms to a destination port

[Loïc Minier]

Hi,

On Tue, Mar 21, 2006, Oscar Elfving wrote:
 How do I send a wap push to a destination port? I have a MIDP 2.0
 application registered at sms://:1669, how do I format a wap push
 message so that the application activates?

 The destination port is in the UDH, the following link has some
 samples:
 
http://www.nowsms.com/framer.htm?http://www.nowsms.com/discus/messages/132/518.html

 I suggest you build your own UDH and message and send them via the HTTP
 interface (via the sendsms CGI).

 The general format of UDH is specified in GSM 03.40 (ETSI) or 23040
 (3GPP).

 I can send regular sl and si messages just fine thought.

 You can see the format of the outgoing messages (UDH and text) in the
 bearerbox access log.  The UDH of a WAP PUSH (which implies you're
 doing WAP over SM) is usually logged as:
udh:7:0605040B8423F0

 The 0B84 and 23F0 destination and source ports are reserved by IANA
 (http://www.iana.com/assignments/port-numbers):
 wap-push2948/tcp   WAP PUSH
 wap-push2948/udp   WAP PUSH
 wap-wsp9200/tcpWAP connectionless session service
 wap-wsp9200/udpWAP connectionless session service

 You should pick a high port number to avoid landing on a reserved port.

 However, if you send it to another destination port, it won't be
 decoded as a WAP PUSH anymore (the terminal won't act upon the contents
 and interpret the payload as being connection less WSP).
   But if you're doing MIDP 2, I understand you might not be interested
 in WAP PUSH, but in the general payload of the SM.

   Cheers,

-- 
Loïc Minier [EMAIL PROTECTED]
Current Earth status:   NOT DESTROYED

Re: Destination and src_addr

[acidburn]

Thank You!
It worked..:)



On Tue, 7 Feb 2006 14:55:11 +0530, Sriram [EMAIL PROTECTED] wrote:
 By Changing the Global Sender field in SMS box group to 930040801 in
 smskannel.conf..rstart bearerbox and smsbox...and here u go !
 
 Sriram..
 
 - Original Message -
 From: [EMAIL PROTECTED]
 To: users@kannel.org
 Sent: Tuesday, February 07, 2006 2:40
 Subject: Destination and src_addr
 
 
 Hi!
 I'm a newbie in kannel and SMS things.

 So my problem is:

 I receive an SMS from a phone.
 In the deliver_sm the destination_addr is my service number 9300408
 My sms-service works I mean the deliver_sm_resp works.
 But in the response SMS to the phone process: submit_sm the source_addr
 of
 course is my service number 9300408 on which the kannel received the sms.
 The question is how to add to the source_addr a 01 string. I need that
 source_addr is 930040801. The 01 is for money charging.


 Thanks!

 Waiting for an answer!

Re: Destination and src_addr

[acidburn]

So. Next question. That is the Global Sender.
But now I need to change the sender depending on SMSC. I have two SMSC's. for 
one SMSC the sender must be 930040801 and for the other one 2300408



On Tue, 7 Feb 2006 12:28:17 +0200, [EMAIL PROTECTED] wrote:
 Thank You!
 It worked..:)
 
 
 
 On Tue, 7 Feb 2006 14:55:11 +0530, Sriram [EMAIL PROTECTED]
 wrote:
 By Changing the Global Sender field in SMS box group to 930040801 in
 smskannel.conf..rstart bearerbox and smsbox...and here u go !

 Sriram..

 - Original Message -
 From: [EMAIL PROTECTED]
 To: users@kannel.org
 Sent: Tuesday, February 07, 2006 2:40
 Subject: Destination and src_addr


 Hi!
 I'm a newbie in kannel and SMS things.

 So my problem is:

 I receive an SMS from a phone.
 In the deliver_sm the destination_addr is my service number 9300408
 My sms-service works I mean the deliver_sm_resp works.
 But in the response SMS to the phone process: submit_sm the source_addr
 of
 course is my service number 9300408 on which the kannel received the
 sms.
 The question is how to add to the source_addr a 01 string. I need that
 source_addr is 930040801. The 01 is for money charging.


 Thanks!

 Waiting for an answer!

Was: Re: Destination and src_addr

[Girts Legzdins]

So... 
I think this is a sms routing problem, or smth like that.
So I have 2 SMSC's 
And I need to set it up so, that when a SMS comes in through SMSC1 a reply is 
sent out through SMSC1
and so with SMSC2.



-- 
Girts Legzdins
Head Of IT Group
+3716510443
Latvia, Riga
Ventspils 56/58

Re: Was: Re: Destination and src_addr

[Girts Legzdins]

The routing I figured out.
But now I need, that SMSC1 changes the sender number to one I need.
The SMSC2 can leave the one that he knows and that is working now.


On Tue, 7 Feb 2006 14:27:48 +0200, Girts Legzdins [EMAIL PROTECTED] wrote:
 So...
 I think this is a sms routing problem, or smth like that.
 So I have 2 SMSC's
 And I need to set it up so, that when a SMS comes in through SMSC1 a reply
 is sent out through SMSC1
 and so with SMSC2.
 
 
 
 
-- 
Girts Legzdins
Head Of IT Group
+3716510443
Latvia, Riga
Ventspils 56/58

Re: wappush on CDMA, source port and destination port

[Aarno Syvänen]

Jon,
Just another module. Inside it you code as you like (though remember 
coding style ;)
only provide the interface.

Aarno
On 14.4.2005, at 15:16, Jonathan Houser wrote:
  Aarno,
I was was speaking about module level architecture. (It would be 
ideal, if you just
add a module and its public interface).
Currently push has four levels: ppg, ota, wsp and wdp. SMS is 
generated only at
wdp level, other levels are about creating its content. So it would 
be ideal if you
could add to wapbox.c a new branch:
if addresstype is cdma,
   create cdma message for push
Your own module would then handle splitting.
 That's fine with me.  Would my module essentially be another box? 
 Is there mayhaps a document describing how to create my own module 
for Kannel?

Jon

Re: wappush on CDMA, source port and destination port

[Aarno Syvänen]

Jon,
I was was speaking about module level architecture. (It would be ideal, 
if you just
add a module and its public interface).

Currently push has four levels: ppg, ota, wsp and wdp. SMS is generated 
only at
wdp level, other levels are about creating its content. So it would be 
ideal if you
could add to wapbox.c a new branch:

if addresstype is cdma,
   create cdma message for push
Your own module would then handle splitting.
Aarno
On 12.4.2005, at 15:15, Jonathan Houser wrote:
  Aarno,
can you share architecture you are using for WAP Push over CDMA ? One
really wants (at least this applies to myself) changes only in wdp 
level, this
is in the wapbox.
This of course excludes handling of a new network type, for cdma.
 Essentially I added the ability to specify params either in the 
config or on a GET/POST or in the XML doc (ie. for things like 
service-type).  I then, for my personal implementation, added the 
ability to send a data_sm via SMPP (and another param to specify that 
you want to send one).  Finally I had to patch the segmentation code 
so that if we were sending a data_sm (which has a max data size of 
65k), it wouldn't segment the data.  I'm going to go back and 
re-examine the latest code and re-implement all of this (perhaps 
differently) before I submit any patches.  So if any of that you'd 
like to see done differently, etc., please offer suggestions now.  
Like I said, I have another 2-3 patches to submit before I even start 
this.

Jon
P.S.  Everyone we've worked with in the CDMA world uses data_sm for 
WAP pushes (this includes both SMSCs I connect to with my MMSC and 
MMSCs that connect to our SMSC), so this is pretty much required.

Re: wappush on CDMA, source port and destination port

[Jonathan Houser]

  Aarno,
I was was speaking about module level architecture. (It would be ideal, 
if you just
add a module and its public interface).

Currently push has four levels: ppg, ota, wsp and wdp. SMS is generated 
only at
wdp level, other levels are about creating its content. So it would be 
ideal if you
could add to wapbox.c a new branch:

if addresstype is cdma,
   create cdma message for push
Your own module would then handle splitting.
 That's fine with me.  Would my module essentially be another box? 
 Is there mayhaps a document describing how to create my own module for 
Kannel?

Jon

RE: wappush on CDMA, source port and destination port

[Mario Noboa]

Thanks Jonathan, thats the answer that i was looking. I hope you submit the
patch.

Mario

-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre
de Jonathan Houser
Enviado el: Tuesday, April 12, 2005 8:16 AM
Para: Aarno Syvänen
CC: Kannel lst
Asunto: Re: wappush on CDMA, source port and destination port



  Aarno,

 can you share architecture you are using for WAP Push over CDMA ? One
 really wants (at least this applies to myself) changes only in wdp
 level, this
 is in the wapbox.

 This of course excludes handling of a new network type, for cdma.

  Essentially I added the ability to specify params either in the
config or on a GET/POST or in the XML doc (ie. for things like
service-type).  I then, for my personal implementation, added the
ability to send a data_sm via SMPP (and another param to specify that
you want to send one).  Finally I had to patch the segmentation code so
that if we were sending a data_sm (which has a max data size of 65k), it
wouldn't segment the data.  I'm going to go back and re-examine the
latest code and re-implement all of this (perhaps differently) before I
submit any patches.  So if any of that you'd like to see done
differently, etc., please offer suggestions now.  Like I said, I have
another 2-3 patches to submit before I even start this.

Jon

P.S.  Everyone we've worked with in the CDMA world uses data_sm for WAP
pushes (this includes both SMSCs I connect to with my MMSC and MMSCs
that connect to our SMSC), so this is pretty much required.

Invalid sms destination address

[chandana]

hi all ,

when i send a sms to a certain destination after that delevered to that
address , it sends another message to the 002 adrees . How that come ? 
In my configuration there is no such a number . can u help me to solve
this prob ?



2003-08-15 14:08:38 FAILED Send SMS [SMSC:Nokia 30] [SVC:default] [ACT:]
[from:12529] [to:002] [flags:0:1:0:0:0] [msg:31:Could not fetch
content, sorry.] [udh:0:]

Thanx
chandana