Re: are these bugs when sending concatenated SMSs

Hi Alex, Thanks for your great response. Its great to know that the message ERROR: System error 104 is not a Kannel bug. Thanks again.

Re: are these bugs when sending concatenated SMSs

Hi, I've been looking at the spec 03.40 and I've also tested and 154 is the max amount of chars you can use before becoming another SMS. If I re-read the spec below with this information, can I assume Kannel is using compressed GSM Default alphabet 7 bit data and you always lose 6 octets to give

Re: are these bugs when sending concatenated SMSs

Hi, for 7bit (text message) kannel send 154 octets of text + 6 octets udh that give you 160 Octets together. SMPP doesn't pack because it's not necessary following the spec but SMSC packs then those. Am 31.01.2007, 09:41 Uhr, schrieb Hillel [EMAIL PROTECTED]: Hi, I've been looking at

Re: are these bugs when sending concatenated SMSs

Here's the exact calculation of the PDU splitting borders. On the wire and in the air, a SMS PDU always contains a maximum of 140 octets. Thats why you can pack 140*8/7 = 160 characters into an SMS. If a UDH header is used (udh indicator bit is set), then the beginning of the SMS-PDU

RE: are these bugs when sending concatenated SMSs

Hi Andreas, But with Kannel you can send 154 characters in a concatenated SMS and are not limited to 153? Why is this the case? Thanks -Original Message- From: Andreas Fink [mailto:[EMAIL PROTECTED] Sent: 31 January 2007 12:40 To: devel Devel Cc: Hillel Subject: Re: are these

Re: are these bugs when sending concatenated SMSs

This depends on send it where its being sent. Kannel does automatically split long SMS. Also it might be that your SMSC splits it or discards the last char. On 31.01.2007, at 12:50, Hillel wrote: Hi Andreas, But with Kannel you can send 154 characters in a concatenated SMS and are not

[PATCH] generic lookup dictionary (hash) - extends gwlib/dict.[ch]

Hi list, attached is an enhanced version of our gwlib/dict.[ch], now called gwlib/gw-dict.[ch] that can used generic key types. Generic means void* key actually, and now Octstr* key as current Dict does. Why? Because under certain conditions it's too expensive to do all the string mangling

Re: [PATCH] generic lookup dictionary (hash) - extends gwlib/dict.[ch]

Stipe Tolj wrote: Hi list, attached is an enhanced version of our gwlib/dict.[ch], now called gwlib/gw-dict.[ch] that can used generic key types. Generic means void* key actually, and now Octstr* key as current Dict does. Why? Because under certain conditions it's too expensive to do all

Re: [PATCH] generic lookup dictionary (hash) - extends gwlib/dict.[ch]

Hi, I don't know now how to use this code but code reviews show: 1) gw_dict_ops_t doesn't define function to destroy key. Because key is not Octstr anymore you need to know which function to call. 2) because of (1) you don't destroy keys = memleak 3) +List *gw_dict_keys(gw_dict_t *dict) +{

Only one DLR requested for multi-part messages?

At line 277 of gw/sms.c (from CVS 2007-01-31) there is this comment and code, which only requests one DLR for a multi-part message: /* * if its a DLR request message getting split, * only ask DLR for the first one */ if ((msgno 1)

Re: Only one DLR requested for multi-part messages?

the reason for this is because the user has submitted ONE long sms. it would get confusing for receiving multiple delivery reports for ONE long sms submitted if the user splits the parts himself, then those are multiple individual SMS's for kannel and each will receive its own delivery