Re: WAP Push
Hi, log files for succesfull v. unsuccessfull delivery attempt would be nice. In addition, I would like to see configuration files. Aarno - Original Message - From: Randeep Singh Bhatia [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 17, 2002 6:09 PM Subject: FW: WAP Push Hi, We are trying to use the WAP push implemented via the Kannel PPG gateway in development version 1.1.6. We are using Hay Systems Limited (www.hsl.uk.com) for the underlying SMS messaging via SMPP 3.4. In our tests the WAP push seems to work once in a while, but most of the time the WAP push is not recieved by the phone. The SMS provider claims that they are delivering the SMS to the phone everytime and so the message must show up on the phone. Also the phone has no problem recieving SMS via other interfaces (http) from the same SMS provider. Does anyone have any clue on what might be going wrong Our settings for the SMSC in pushkannel.conf uses system-type = SMPP Thanks Randeep
Re: Respond Msg to Deliver Message
The deliver_sm is meant to make the ESME (in this case Kannel) respond with a deliver_sm_resp PDU in order to confirm receipt of the deliver_sm message. This message is only meant to go from the ESME (Kannel) to the SMSC (your provider) as not a message to the phone subscriber that submitted the message. Messages to the subscriber that submitted the message are sent with submit_sm which are ESME (Kannel) to SMSC messages. In this case the SMSC responds with a submit_sm_resp PDU to tell you that it has received the message. Feel free to contact me if you need to make more sense of that! Alex On Mon, 20 May 2002, Le Nhu Hai wrote: Hi all, I try to use Kannel 1.1.6 to connect to SMSC via SMPP with a service number assigned to GW. When a subscriber send any SM to service number, the msg will deliver to GW. In the source, file smsc_smpp.c, function: handle_pdu(): case deliver_sm (void) bb_smscconn_receive(smpp-conn, pdu_to_msg(pdu)); resp = smpp_pdu_create(deliver_sm_resp, pdu-u.deliver_sm.sequence_number); break; Thatn means, GW only respond to SMSC a deliver_sm_resp message. In fact, the sender who send a SM to service number (GW) would receive a msg with content: No service specified Who know why ? Does Kannel 1.1.6 support flash message? Thank for any reply! __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com -- Alex Judd http://www.skywire.co.uk
Re: SMPP DLR Reports
Alex Judd wrote: I'm doing some fairly heavy work on the smsc_smpp.c driver at the moment to ramp it up a bit and I've got a couple of questions re: the esm_class values that the code currently thinks are DLR reports. The current code checks for 0x02 and 0x04 as DLR reports, however the 3_4 SMPP standard says that bits 1-0 are ignored, and that valid DLR values are 0x04 for for receipts and 0x08 and 0x10 for acknowledgments. Anyone know why we check for 0x02? Andreas Fink may be a good candidate to answer this, Andreas? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Respond Msg to Deliver Message
Le Nhu Hai wrote: I try to use Kannel 1.1.6 to connect to SMSC via SMPP with a service number assigned to GW. When a subscriber send any SM to service number, the msg will deliver to GW. In the source, file smsc_smpp.c, function: handle_pdu(): case deliver_sm (void) bb_smscconn_receive(smpp-conn, pdu_to_msg(pdu)); resp = smpp_pdu_create(deliver_sm_resp, pdu-u.deliver_sm.sequence_number); break; Thatn means, GW only respond to SMSC a deliver_sm_resp message. In fact, the sender who send a SM to service number (GW) would receive a msg with content: No service specified Who know why ? Does Kannel 1.1.6 support flash message? yes, kannel supports flash messages. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: More Info: Problem with EMI2, latest cvs
Dima Milentiev wrote: Hi Bruno, i've sent the patch to list 2 weeks ago and still have not any comments. May be you can look at it? +1, commited to cvs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Patch submission and release policy (Was: [PATCH] problems with HTTPS and base support for per message billing)
Oded Arbel wrote: Agreed. I was hoping that at least the billing issue (I remember it being talked about in the list a while back) would interest people. I do think, though, that fixes to problems not yet detected in the wild should go in anyway : that's why it's called a development tree, if the solution does not break anything - of course. IMHO, the current situation where the CVS build must never be broken because it is the production version and so patches require careful scrutiny before going in is not healthy. CVS _is_ the place to test fixes and new features - when you require that people will download and apply your patches one by one, the number of testers will shrink to the number of people interested in the specfic patch - which in a not-so-high visibility project like Kannel could easily get down to 1~2 people - or even less. case in point is the +CMTI patch by Alex Judd - it seems like a perfectly valid feature, but only 2 or 3 people on this list are at the same time interested and skilled to test it - under a circumstences where some of them cannot find the time to do so, this perfectly good feature would simply be abandoned. I suggest we should roll out a release ASAP, using the following schedule : - branch the tree now (yesterday would have been a good time too ;-) and label it 1.2.0. - bug fixes may be submitted to either of the trees, and then ported to the other. - new features may be submitted only to the HEAD tree. - features and bug fixes will be submitted freely to the HEAD tree with minimum checks for style and obvious coding errors. - the HEAD tree will be considered unstable and fit only for development work. Using this method we would not further degrade the current situation (where people who have problems are told to upgrade their production servers to the CVS version - as it is more stable), while stabilizing the development effort for a full fledged stable release w/o hampering further feature development. Opinions please ? +1 for most of that. I was anyway concidering asking the developers about releasing 1.2.0. I'd like to hear from Bruno, Andreas and some others what they think about if current CVS HEAD is stable enough to make it a stable release 1.2.0? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: More Info: Problem with EMI2, latest cvs
Dima Milentiev wrote: Hi Bruno, i've sent the patch to list 2 weeks ago and still have not any comments. May be you can look at it? +1, commited to cvs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Patch submission and release policy (Was: [PATCH] problems with HTTPS and base support for per message billing)
Oded Arbel wrote: Agreed. I was hoping that at least the billing issue (I remember it being talked about in the list a while back) would interest people. I do think, though, that fixes to problems not yet detected in the wild should go in anyway : that's why it's called a development tree, if the solution does not break anything - of course. IMHO, the current situation where the CVS build must never be broken because it is the production version and so patches require careful scrutiny before going in is not healthy. CVS _is_ the place to test fixes and new features - when you require that people will download and apply your patches one by one, the number of testers will shrink to the number of people interested in the specfic patch - which in a not-so-high visibility project like Kannel could easily get down to 1~2 people - or even less. case in point is the +CMTI patch by Alex Judd - it seems like a perfectly valid feature, but only 2 or 3 people on this list are at the same time interested and skilled to test iX-Mozilla-Status: 0009tences where some of them cannot find the time to do so, this perfectly good feature would simply be abandoned. I suggest we should roll out a release ASAP, using the following schedule : - branch the tree now (yesterday would have been a good time too ;-) and label it 1.2.0. - bug fixes may be submitted to either of the trees, and then ported to the other. - new features may be submitted only to the HEAD tree. - features and bug fixes will be submitted freely to the HEAD tree with minimum checks for style and obvious coding errors. - the HEAD tree will be considered unstable and fit only for development work. Using this method we would not further degrade the current situation (where people who have problems are told to upgrade their production servers to the CVS version - as it is more stable), while stabilizing the development effort for a full fledged stable release w/o hampering further feature development. Opinions please ? +1 for most of that. I was anyway concidering asking the developers about releasing 1.2.0. I'd like to hear from Bruno, Andreas and some others what they think about if current CVS HEAD is stable enough to make it a stable release 1.2.0? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Respond Msg to Deliver Message
Le Nhu Hai wrote: I try to use Kannel 1.1.6 to connect to SMSC via SMPP with a service number assigned to GW. When a subscriber send any SM to service number, the msg will deliver to GW. In the source, file smsc_smpp.c, function: handle_pdu(): case deliver_sm (void) bb_smscconn_receive(smpp-conn, pdu_to_msg(pdu)); resp = smpp_pdu_create(deliver_sm_resp, pdu-u.deliver_sm.sequence_number); break; Thatn means, GW only respond to SMSC a deliver_sm_resp message. In fact, the sender who send a SM to service number (GW) would receive a msg with content: No service specified Who know why ? Does Kannel 1.1.6 support flash message? yes, kannel supports flash messages. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: SMPP DLR Reports
Alex Judd wrote: I'm doing some fairly heavy work on the smsc_smpp.c driver at the moment to ramp it up a bit and I've got a couple of questions re: the esm_class values that the code currently thinks are DLR reports. The current code checks for 0x02 and 0x04 as DLR reports, however the 3_4 SMPP standard says that bits 1-0 are ignored, and that valid DLR values are 0x04 for for receipts and 0x08 and 0x10 for acknowledgments. Anyone know why we check for 0x02? Andreas Fink may be a good candidate to answer this, Andreas? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [BUG] more problems with SSL
Oded Arbel wrote:
another problem with an SSL connection, is that if the socket connection
in conn_open_tcp() called from conn_open_sll() fails, it returns NULL,
but conn_open_ssl() immidietly tries to refer to it as initialized
structure - which of course causes Kannel to crash.
conn_open_ssl() should check whether the socket was successfuly opened,
returning NULL if not, so adding this -
if (!ret)
return NULL;
immidietly after conn_open_tcp() will solve the problem.
you're right.
BTW, I'm wondering if the part:
/*
* make the socket is non-blocking while we do SSL_connect
*/
if (socket_set_blocking(ret-fd, 0) 0) {
goto error;
}
is necessary in conn_open_ssl() because the socket is already set to
non-blocking mode in conn_wrap_fd()?
I'll fix the issue you were raising here Oded.
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Münsterstr. 248
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are
Re: smsc_smpp.c - reconnection/enquiry timings
Hello,
Here's the final patches to include smpp reconnection timings etc to be
able to be set via config. As I mentioned before I have added the fields
to the smpp structure (see patches below for details).
Cheers,
Alan
On Tue, 2002-05-14 at 12:57, Alan McNatty wrote:
Ok - here's a couple of quick patches which I will be testing but have
posted for comment. I've added the 3 vars into the smpp sturcture and
set to SMPP_ vars if not in config (also required patch for
gwlib/cfg.def which is also required). Comments, etc always appreciated.
Cheers,
Alan
Index: cfg.def
===
RCS file: /home/cvs/gateway/gwlib/cfg.def,v
retrieving revision 1.57
diff -u -r1.57 cfg.def
--- cfg.def 26 Apr 2002 10:49:27 - 1.57
+++ cfg.def 21 May 2002 00:43:10 -
-208,6 +208,11
OCTSTR(source-addr-npi)
OCTSTR(dest-addr-ton)
OCTSTR(dest-addr-npi)
+OCTSTR(enquire-link-interval)
+OCTSTR(max-pending-submits)
+OCTSTR(reconnect-delay)
OCTSTR(transceiver-mode)
)
Index: smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc_smpp.c,v
retrieving revision 1.57
diff -u -r1.57 smsc_smpp.c
--- smsc_smpp.c 1 May 2002 18:23:39 - 1.57
+++ smsc_smpp.c 21 May 2002 00:42:35 -
-41,9 +41,8
#endif
-
/*
- * Some constants.
+ * Some defaults.
*/
#define SMPP_ENQUIRE_LINK_INTERVAL 30.0
-51,7 +50,6
#define SMPP_RECONNECT_DELAY 10.0
-
/***
* Implementation of the actual SMPP protocol: reading and writing
* PDUs in the correct order.
-79,6 +77,9
int transmit_port;
int receive_port;
int quitting;
+long enquire_link_interval;
+long max_pending_submits;
+long reconnect_delay;
SMSCConn *conn;
} SMPP;
-89,6 +90,9
Octstr *address_range, Octstr *our_host,
int source_addr_ton, int source_addr_npi,
int dest_addr_ton, int dest_addr_npi,
+ int enquire_link_interval,
+ int max_pending_submits,
+ int reconnect_delay,
Octstr *my_number)
{
SMPP *smpp;
-114,6 +118,9
smpp-my_number = octstr_duplicate(my_number);
smpp-transmit_port = transmit_port;
smpp-receive_port = receive_port;
+smpp-enquire_link_interval = enquire_link_interval;
+smpp-max_pending_submits = max_pending_submits;
+smpp-reconnect_delay = reconnect_delay;
smpp-quitting = 0;
smpp-conn = conn;
-303,7 +310,7
SMPP_PDU *pdu;
Octstr *os;
-if (date_universal_now() - *last_sent SMPP_ENQUIRE_LINK_INTERVAL)
+if (date_universal_now() - *last_sent smpp-enquire_link_interval)
return;
*last_sent = date_universal_now();
-339,7 +346,7
if (*pending_submits == -1)
return;
-while (*pending_submits SMPP_MAX_PENDING_SUBMITS) {
+while (*pending_submits smpp-max_pending_submits ) {
/* Get next message, quit if none to be sent */
msg = list_extract_first(smpp-msgs_to_send);
if (msg == NULL)
-774,8 +781,8
else
conn = open_receiver(smpp);
if (conn == NULL) {
- error(0, SMPP: Couldn't connect to SMS center.);
- gwthread_sleep(SMPP_RECONNECT_DELAY);
+ error(0, SMPP: Couldn't connect to SMS center (retrying in %ld seconds)., smpp-reconnect_delay);
+ gwthread_sleep(smpp-reconnect_delay);
smpp-conn-status = SMSCCONN_RECONNECTING;
continue;
}
-784,7 +791,7
pending_submits = -1;
len = 0;
for (;;) {
- timeout = last_enquire_sent + SMPP_ENQUIRE_LINK_INTERVAL
+ timeout = last_enquire_sent + smpp-enquire_link_interval;
- date_universal_now();
if (smpp-quitting || conn_wait(conn, timeout) == -1)
break;
-902,7 +909,9
SMPP *smpp;
int ok;
int transceiver_mode;
-
+long enquire_link_interval;
+long max_pending_submits;
+long reconnect_delay;
my_number = NULL;
transceiver_mode = 0;
-931,6 +940,15
octstr_destroy(system_id);
}
+/* Check for timings */
+
+if (cfg_get_integer(enquire_link_interval, grp, octstr_imm(enquire-link-interval)) == -1)
+ enquire_link_interval = SMPP_ENQUIRE_LINK_INTERVAL;
+if (cfg_get_integer(max_pending_submits, grp, octstr_imm(max-pending-submits)) == -1)
+ max_pending_submits = SMPP_MAX_PENDING_SUBMITS;
+if (cfg_get_integer(reconnect_delay, grp, octstr_imm(reconnect-delay)) == -1)
+ reconnect_delay = SMPP_RECONNECT_DELAY;
+
/* Check that config is OK */
ok = 1;
if (host == NULL) {
-961,7 +979,9
smpp = smpp_create(conn, host, port, receive_port, system_type,
username, password, address_range, our_host,
source_addr_ton, source_addr_npi, dest_addr_ton,
- dest_addr_npi,
