Re: [FYI] RADIOUS accounting proxy commited
David Chkhartishvili schrieb: Stipe, Could you please look at my debug output? Radius proxy gets msisdn fro nas correctly, but doesn't include MSISDN header. yes, I'll check. Stay tuned... Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [REQ] UAProf suppport
Paul Keogh wrote: now basically they complain that Kannel does not check the UAProf profile of a device and hence does not recognize that certain mime-types can or can't be accepted by the device. But can the list of acceptable MIME types not be checked against the Accept: MIME headers ? I don't see this as a UAProf activity. Is it the case that not all supported MIME types are listed in the Accept: headers and that the UAProf document holds the definitive list ? sort of. To be honest I'm also not aware of if 100%. They claimed that Kannel dropped the HTTP response because the HTTP server responded with text/html and *if* Kannel would have supported UAProf it *would* know that the device can do something with it. Something like that. BTW, did you sign the NDA stuff for Open Group? I'd like to have you boarded in the REFPOOL issue. yes, I guess UAProf is not only about passing the information. It is also about dealing with it in terms of allowing to modify mime-types to fit the needs of the device. Or am I wrong here? I think that what a gateway is supposed to do with UAProf information is not specified in the WAP standards and is implementation dependent. agreed. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] cookie support per detault in wapbox?!
Stipe Tolj wrote: Hi list, I'd like to throw the --enable-cookie directive from configure and make cookie support for wapbox now a permanent default feature. Any objections for doing this? no objections?! Votes please. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[REQ] fixing userguide.xml
Ok, I broke something in there in the new RADIUS section, but I can't see by hand what. Could someone of the jade gurus please have an eye on this and provide a fix?! Thanks. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: GNU autoconf experts arround?!
Stipe Tolj wrote: I'm fidling arround with a modified configure/make process to allow adding new add-on boxes (ie. smppbox) to the build. I come up with --with-box[=NAME] inside configure.in and this works, even while this is really an un-nice hack ;) Unfortunatly I can't give more then one --with-box statement to configure. Can anyone give me a good hint or example code on how to implement --with-foobar=1 --with-foobar=2 ... inside M4 macro code for confifure.in??? Any help is appritiated, since release date for smppbox and mmsbox depends on it ;) anyone?!?!?! Pleasse. Seems like you guys don't want us to release smppbox, emibox and mmsbox?! ;)) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] cookie support per detault in wapbox?!
Vjacheslav Chekushin wrote: Hi, Stipe. There are 2 issues. Current cookie implementation cache this cookie in session machine. So it works only for connection-oriented mode and only for current session. From other side, WAP user can't manage own cookies with this approach. And by cookie's RFC (RFC 2109) user agent must be able to completely disable the sending and saving of cookies (7.1) So I recommend to support cookies by implementing normal WSP-HTTP cookie header encoding, couse almost all modern WAP phones can deal with cookies by itself. Current implementation doesn't know how to encode Cookie's headers: 2003-06-20 14:20:56 [1] ERROR: WSP: Do not know how to encode header type 65 2003-06-20 14:20:56 [1] WARNING: Skipping header: Set-Cookie: JSESSIONID=bhFsO7t57CM7; Path=/ ahh, ok. Can we determine via the WSP headers send by the device if it's capable to handle cookies on it's own? If yes, we can have them store the cookies and for older phones leaving them in the session cache scope of Kannel?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] cookie support per detault in wapbox?!
Vjacheslav, Current implementation doesn't know how to encode Cookie's headers: 2003-06-20 14:20:56 [1] ERROR: WSP: Do not know how to encode header type 65 2003-06-20 14:20:56 [1] WARNING: Skipping header: Set-Cookie: JSESSIONID=bhFsO7t57CM7; Path=/ could you please add this as a bug report to http://bugs.kannel.org/ so that it does not get forgotten?! Please. Someone will have to pick this issue up and implement this inside the WSP header packing/unpacking routines. Unfortunatly I'm unable now. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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 Query/Update/Delete Message PDU
Nisan Bloch wrote: The question is not really how to implement these in the smsc module, as the above 3 are trivial. How do we interface this to smsbox? Is this a querybox? Does it generate the appropriate dlr and pass back the status via the dlr mechanism? yep, agreeing Nisan here fully. Implementation of the PDUs itself is trivial. But how to provide the services to the outside world?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: using Kannel as SMSC over SMPP
Grei Zhang wrote: Hi there: 1. Is that possible to using Kannel as a SMSC Simulator(use GSM modem, for sms sending) over SMPP v3.4 for other WAP GATEWAY to send Push Message? 2. If it does, then what about the inter-connectivity, is there a list of vendor whose wap gateway have been tested? 3. If it does, does Kannel support MMS notification when simulating SMSC? 4. If it does not, then could you recommand SMSC Simulator, which support the function I metioned here? for 1 you would need SMPP server abilities, which are yet not included. It's present in our smppbox implementation, and it will be included shortly. about 2: if you provide an SMPP v3.4 server interface, then you have to expect that WAP gw that do Push messaging via the SMPP link act spec conform. No, we had no testing of commercial WAP gw vendors. If someone of the vendors is reading: Drop us a free license copy and we will test. Or we can provide a public SMPP v3.4 server for it?! about 3: yes, you can push *any* kind of messages via Kannel. Even MMS notification. We do this in our own mmsbox (MMSC) implementation fully based on Kannel. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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 header
Guanghua Hou wrote: Hi, To send a push message through SMSC. How to set the application type in SMPP? Which header will be used? UDH or service_type or protocol_id? SMSC may support applications such as text, voice mail notification, WAP, CSSD and etc. My question is how to distinguish these application by terminal and how to set the application type in SMPP. AFAIR, it's enough when you send the binary message via the text and udh HTTP parameters to have the SMSC transport it accordingly to the device. Unfortunatly smsbox has to be abstracted for other SMSC module types, hence you don't have the full potential to set SMPP specific parameters of the submit_sm PDU. What kind of messages are you trying to send? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Strange smsbox/bearerbox problem : SMS messages not being sent
Nisan Bloch wrote: Hi We have a queue load balancer in front of Kannel, that through a statusbox monitors Kannel, and knows extended information about each gateway that kannel is connected to. This way we can control the throughput of any of the Kannel connections, as well as load balance them If messages are going to throttle I would rather see the throttling happening before a messages is commited to a particular smsc, so one can reroute it if need be. yep, that would be good. Any chance to have that statusbox freed from the south?! ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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 header
You simple use the UDH header to set the source and destination ports (like on machine ports) for identifying the destination application that handles the message. Please see test/test_ppg to see how to send SI/SL documents to an device. Otherwise consult the appropriate WAP Forum specs. The main things is: You don't have to use the special SMPP PDU flagging to tell the SMSC (it simply does not have to know!) or the mobile which message type it is. The mobile device will determine this anyway by comparing the UDH header you are sending. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[FYI] 'throughput' abstracted
Hi list, I just commited: 2003-06-23 Stipe Tolj [EMAIL PROTECTED] * gw/smscconn[_p].[ch]: added 'throughput' MT message per sec. limitation to abstraction layer. * gw/smsc/smsc_emi2.c: moved 'throughput' from EMI2 specific directive to abstracted directive to provide it to other SMSC client modules too. * gw/smsc/smsc_smpp.c: added 'throughput' feature to SMPP client module. * gwlib/cfg.def: moved all abstracted directives to the top of 'smsc' group which abstracts the 'throughput' directive formerly known only to the EMI2 module for all module types. SMPP has it know included too. Can some of the other module users yield a patch for them?! This would let me do more work on the configure/make process for the boxes waiting. BTW, I just got a deeper view into autoconf manual, and it looks there are no pre-defined macro functions that allow --with-box=foobar1 --with-box=foobar2 etc processing so you could have abstractation of the unknown box names. It looks like we either have to use --with-box=foobar1,foobar2,... (which makes parsing more complicate) or --with-foobar1 --with-foobar2 etc which makes maitainance of configure.in more cerious for new exernal box types. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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 header
ok, once again: can is *able* to send *any* kind of SMS messages. This includes *all* kind of binary messages (ie. WAP Push document SI, SL, MMS-notification). Kannel has it's own PPG inside and hence deals with those binary messages quite commonly. So if you want to use Kannel as WAP Push Proxy, simply connect to your SMPP provider and use Kannel's PPG to deliver push messages to remote devices. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [FYI] 'throughput' abstracted
Stipe Tolj wrote: which abstracts the 'throughput' directive formerly known only to the EMI2 module for all module types. SMPP has it know included too. commited also for modules: smasi, fake and http Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Kannel Routing and Performance Issues !
Himalay Gopu wrote: list I have been using kannel for almost 2 months now but i have been facing few problems Iam using kannel stable version on SuSe 8.1 Approach I am connected to 4 smsc ( 2 smpp and 2 UCP ) Two of smsc connections are through VPN Kannel is binding to 6 servers for receiving SMS and one to send SMS for one SMPP SMSC --- I have 7 smsc connections with same smsc-id Is this rite approach Anything going wrong in my approach Issues 1) I have seen that most of my messages are routed through a particular smsc even after i set the CGI variable smsc have you 'allowed-smsc-id' directives in the smsc groups?! If no, then Kannel will simply pick the first one that is considered online. 2) I have not crossed 30 sms for min throughput ( does VPN got to do anything with throughput of Kannel ) I don't think so. I guess your internet connection itself is not the limiting factor. I guess it's more to the SMSC provider itself. The fastes we got was 55 msg/sec. to O2 (Germany). All others are performing less. So it's not a limitation of Kannel. Kannel can deal with a *lot* more. How can make Kannel more robust can anyone tickle their brains and throw some tips First of all, if you use 1.2.1 stable, you may consider upgrading to current cvs tree, which is almost 1.3.2-pre (hence 1.3.2 will be released shortly). We have cvs tree running on our production servers with 307 links in 3 instances, performing very reliable. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[RFC] new try: 1.3.2 devel?
Hi list, ok, some time passed now and some fixes have been commited. Are we ready for releasing 1.3.2 devel (as release candicate for 1.4.0 stable)? Any cerious issues that have yet not been commited? Oded, what about the SOAP module? Can I bind it to the SMSCConn layer now with your latest patch? David Chkhartishvili [EMAIL PROTECTED] has successfully tested the new RADIUS proxy thread for MSISDN provisioning. At least with Cisco NAS this seems to work perfectly, even while I got still damn problem with the authentication secret checking on my stone-age old Ascend MAX 2000. Schedule: * release 1.3.2 devel * branch of the tree for further maintainance and fixing * include configure/make changes to allow adding the new boxes (smppbox, mmsbox, etc). * work on the shared object loading of the smsc modules (Alexander?!) * work on the general module API Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] new try: 1.3.2 devel?
what about the memory leak someone reported lately?! AFAIK it was with performing heavy HTTP traffic to smsbox, right? Did valgrind show any leak positions? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: AT2 with Nokia 6210 memory problem
Edwin R. Poot wrote: I run into problemns with one of my modems, the Nokia 6210 phone. This phone is connected to Kannel and although I have configured kannel with using the phone memory instead of SIM memory () I keep getting a dialog on the phone, saying memory is full. As a result, the operator SMS-c does not deliver any more incoming SMS-es. The only thing that helps is turning the phone off and on and restarting kannel. Only then messages are delivered again from the SMS-c to the phone. Does anyone know a solution for this, I never ran into such problems with my Wavecom modems. beware *always* with using real phones as GSM modems. There are *never* as reliable as real GSM modems, even if manufacuters claim. That's all I can say. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] new try: 1.3.2 devel?
Nisan Bloch wrote: At 02:16 PM 6/24/03 +0200, Stipe Tolj wrote: what about the memory leak someone reported lately?! AFAIK it was with performing heavy HTTP traffic to smsbox, right? We havent noticed this. However under relatively heavy usage - polling the Kannel status pages via http every 15secs (eg using mon on our lvs cluster) eventually ends up with a unresponsive http server in bearebox. It carries on receiving messages from the smsbox and sending etc via the smsc modules. We have never been able to track the source of this. we have the same effect. Especially after long time running bearerbox. It seems as if there is something wrong the the HTTP server module. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [-] Re: non standard message_id breaks DLR
Andreas Fink schrieb: On Donnerstag, Juni 26, 2003, at 11:30 Uhr, David Tully wrote: Yes - saw that.. That's the consolation prize.. :) I need to strip off the extra stuff and I'll have the hex message_id. Any ideas out there on the quickest way to do that? ;) and please ask him which SMPP SMSC vendor he is using. We'd like to put operator SMSCs to a 'conformance list', so Kannel users know directly that they don't have any protocoll issue problems when connecting. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: smsbox CPU Utlization 99%
Cipher Strength wrote: Hi All, I am using cvs version of 3rd June on my production server. The CPU Utlization of smsbox is 99% during peak hours.Any suggestions ? can you please forward us the corresponding smsbox.log in debug level?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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] dbpool + dbpool support for mysql storage
Hi list, anyone tested Alexander's patch?! Votes please. This should go into 1.3.2 too. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: libsdb support in 1.2.1
Hi John, can you please re-send the patch against the current cvs head tree?! The stable 1.2.1 is pretty old and there have been some changes in the code since then. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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] libsdb support in 1.3.1
Alexander Malysh schrieb: Hi John, thank you very much for fixing some stupid bugs introduced by me :( Can you please send diff with whitespace ignore flag set. (cvs diff -Naub) Thanks in advance... P.S. Stipe, I will look in it and commit relevant parts... ok, please test against mysql and oracle if possible. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[Fwd: SL-notification]
Hi, forwarded to the list. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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---BeginMessage--- Hi Stipe, I found your mails in the mail archive of kannel.org. I configured kannel 1.3.1 as a push proxy gateway, it works fine with sending si-notifications for wap. But I have some troubles with kannel 1.3.1 with sending sl-notifications to a Sony Ericsson T68i. If I send a sl-notification to my T68i phone, i don't receive a message at the phone! Do you know what could be wrong? Do I have to change the configuration in my phone? Thank you very much in advance! Best regards John ---End Message---
Re: [PATCH] libsdb support in 1.3.1
Alexander Malysh wrote: Hi John, just commited fixed version for sdb support. I have added LIMIT 1 alternative for Oracle (ROWNUM 2) also. This version was successfully tested against Oracle 8i. Please check out new version and try it. NOTE: libsdb has very bad Oracle support. I have seen, that no permanent connection to Oracle supported (for every sql statement, connection will be opened and closed). Opening connection to Oracle need more time as e.q. select statement itself. It would be better to add native support for Oracle into kannel... agreed. LibSDB was a quick shoot which did work. That was the intention. It was not a concern of performance or speed. BTW, same for PostgreSQL. I guess having Oracle, MySQL and PostgreSQL support would be what be want here, right?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[Fwd: [Kannel 0000035]: Kannel does not handle 'multipart/form-data' as defined by WAP specs]
Hi list, just filed this bug to Mantis. Do we have mechanisms for content-type converters for the request side too? This is essential for decoding binary encoded 'multipart/form-data' and also for Bruno's suggestion in having decoding MMS binary POSTS via wapbox internally to plain-text HTTP multiparts that are passed to an HTTP server that does not have to be aware of MMS binary magic. Aarno, any ideas from your side here? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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---BeginMessage--- The following NEW bug has been ADDED. === http://bugs.kannel.org/view_bug_page.php?f_id=35 === Reporter: tolj Handler: === Project:Kannel Bug ID: 035 Category: WAP connection-orientated (port 9201) Reproducibility:always Severity: feature Priority: none Status: new === Date Submitted: 07-02-03 18:01 BST Last Modified: 07-02-03 18:01 BST === Summary:Kannel does not handle 'multipart/form-data' as defined by WAP specs Description: When a client passes a POST containing 'application/vnd.wap.multipart.form-data' the body is binary encoded as binary multipart. Kannel should decode this to 'multipart/form-data' and hence send a plain text multipart POST reques to the HTTP server. Currently Kannel sends a POST to the HTTP server, but it simply drops the binary body in it. === ---End Message---
[Fwd: [Kannel 0000035]: Kannel does not handle 'multipart/form-data' as defined by WAP specs]
Some more details about the problem. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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---BeginMessage--- A BUGNOTE has been added to this bug. === http://bugs.kannel.org/view_bug_page.php?f_id=035 === Reporter: tolj Handler: === Project:Kannel Bug ID: 035 Category: WAP connection-orientated (port 9201) Reproducibility:always Severity: feature Priority: none Status: new === Date Submitted: 07-02-03 18:01 BST Last Modified: 07-03-03 00:15 BST === Summary:Kannel does not handle 'multipart/form-data' as defined by WAP specs Description: When a client passes a POST containing 'application/vnd.wap.multipart.form-data' the body is binary encoded as binary multipart. Kannel should decode this to 'multipart/form-data' and hence send a plain text multipart POST reques to the HTTP server. Currently Kannel sends a POST to the HTTP server, but it simply drops the binary body in it. === --- tolj - 07-03-03 00:15 BST --- ok, here are some details: when you have the following go inside your WML deck: go href=/uri method=post enctype=multipart/form-data postfield name=name1 value=value1/ postfield name=name2 value=value2/ /go then the WAP client will send the following WSP header in the request: 2003-06-28 15:30:46 [1] DEBUG: WSP: decoding headers: 2003-06-28 15:30:46 [1] DEBUG: Octet string at 0x8249360: 2003-06-28 15:30:46 [1] DEBUG: len: 1 2003-06-28 15:30:46 [1] DEBUG: size: 2 2003-06-28 15:30:46 [1] DEBUG: immutable: 0 2003-06-28 15:30:46 [1] DEBUG: data: a4. 2003-06-28 15:30:46 [1] DEBUG: Octet string dump ends. 2003-06-28 15:30:46 [1] DEBUG: WSP: decoded headers: 2003-06-28 15:30:46 [1] DEBUG: Content-Type: application/vnd.wap.multipart.form-data 2003-06-28 15:30:46 [1] DEBUG: WSP: End of decoded headers. which means the body of the POST request is an binary encoded format of the 'multipart/form-data', which is this block: 2003-06-28 15:30:46 [10] DEBUG: data: xx xx xx xx 02 0e 06 03 2003-06-28 15:30:46 [10] DEBUG: data: 83 81 ea ae 08 80 85 6e ...n 2003-06-28 15:30:46 [10] DEBUG: data: 61 6d 65 31 00 76 61 6c ame1.val 2003-06-28 15:30:46 [10] DEBUG: data: 75 65 31 0e 06 03 83 81 ue1. 2003-06-28 15:30:46 [10] DEBUG: data: ea ae 08 80 85 6e 61 6d .nam 2003-06-28 15:30:46 [10] DEBUG: data: 65 32 00 76 61 6c 75 65 e2.value 2003-06-28 15:30:46 [10] DEBUG: data: 322 which means Kannel sends a POST HTTP request with the *binary* encoded mutltipart. But it *should* decode 'application/vnd.wap.multipart.form-data' to plain text 'multipart/form-data' request that is then POST'ed to the HTTP server. So Kannel needs to do binary decode convertion within the request also. ---End Message---
Re: [FYI] some Kannel describing document
even more: http://plg.uwaterloo.ca/~migod/846/caseStudy/Lu-kannel-slides.pdf Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[FYI] SMPP Forum Link
Hi list, Kannel is now listed among others as basic SMPP tool, see http://smsforum.net/smpp_tools.html Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: announce: cookies, accept headers and multipart/mixed
Bruno Rodrigues wrote: Multipart/mixed - convertion between multipart/mixed and application/vnd.wap.multipart.mixed. Mime-type parsing code is done and tested but for the actual conversion I'm about to do a system.exec(perl) ;))) --1 ;)) After I finish this I'll need help to debug SAR because kannel sometimes is very fast and other times you see it sending three packets at a time, in logs, and it's very slow, and we need to understand the difference. get into touch with those implemented SAR. Check ChangeLog, I missed the name (sorry ;). But he should be obviously reading the list. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Kannel quits without reporting fatal error
Alan McNatty wrote: Can anyone think of a reason why Kannel might give up on a bad connection after a time (is there something in io_thread in smpp module that might cause a shutdown without reporting - I can only see, if fail continue, etc - all looks good). it may be a memory exhausture. Either bearerbox (by looping in the re-connection state) or other processes have been consuming to much memory and the OS would deside on which process to drop silently. Just an idea. Alternatively can anyone suggest position of addition debug printouts or some external monitoring of processors/threads that I can do that might help find the problem. The obvious thing to do is setup test connection and simply drop the interface to SMSC and leave running trying to connect - just wondering about supplementary logging that might help. We have a so called 'safe_wrapper' bash script arround the bearerbox that acts mainly the same was as 'safe_mysqld' for mysqld. Whenever bearerbox fails by crashing, the script would create a failure log directory timestamp and 'tail -2000' all logs to that failure log directory, so admins can at least try to see what has happened. Usually we have a PANIC in bearerbox that caused to stop. SEGFAULT or other heavy failures are very rare in the past here at Wapme at least. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: announce: cookies, accept headers and multipart/mixed
Bruno Rodrigues wrote: Is there any flag that device uses to say I want sar even if it is 100 bytes ? yes. Because if the phone is SAR capable it will request in SAR mode. Why? Because the phone does not know (while it passed the request) what the outcoming size of the response will be. Hence it can't know if it fits to an non-SARed response or if it has to be SARed anyway because of size. Send Igor some logs and he can double-check on the behaviour. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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 about EMS
Dziugas Baltrunas wrote: Hi list, I tried to redirect EMS short message (with picture) to one of those short numbers that mine Kannel is connected with. SMSC is SMPP. here is what i got: bearerbox.log 2003-07-10 11:58:48 [8] ERROR: SMPP[xxx]: I/O error or other error. Re-connecting. 2003-07-10 11:58:48 [7] ERROR: SMPP[xxx]: I/O error or other error. Re-connecting. 2003-07-10 11:58:48 [8] ERROR: connect failed 2003-07-10 11:58:48 [8] ERROR: error connecting to server `xxx' at port `xxx' 2003-07-10 11:58:48 [8] ERROR: SMPP[xxx]: Couldn't connect to server. 2003-07-10 11:58:48 [8] ERROR: SMPP[xxx]: Couldn't connect to SMS center (retrying in 10 seconds). 2003-07-10 11:58:48 [7] ERROR: connect failed 2003-07-10 11:58:48 [7] ERROR: error connecting to server `xxx' at port `xxx' 2003-07-10 11:58:48 [7] ERROR: SMPP[xxx]: Couldn't connect to server. 2003-07-10 11:58:48 [7] ERROR: SMPP[xxx]: Couldn't connect to SMS center (retrying in 10 seconds). 2003-07-10 11:58:58 [7] DEBUG: SMPP[xxx]: Sending PDU: access.log 2003-07-10 11:57:24 Receive SMS [SMSC:xxx] [SVC:] [ACT:] [from:xxx] [to:xxx] [flags:0:1:0:0:0] [msg:0:] [udh:0:] sumarizing, there are few things strange: 1) Kannel gets only one sms, but there should be two (or three - as shows my phone) 2) There is no UDH in the message and that's not true, because every picture according to EMS is coded into UDH (I looked through userguide and there is n near SMPP and Can receive octet data with UDH - maybe that's the key) so obviously the SMSC is not passing all the UDH information to your Kannel instance, right?! 3) After receiving such message, connection with SMSC DIES for the moment hmmm, so you are trashing the SMSC while you have them process the inbound EMS? ;) 4) There is NO answer sent back while smsaccess.log shows different: 2003-07-10 11:57:24 SMS request sender:xxx request: '' fixed answer: 'Bad request.' but there is nothing about it in access.log. because if bearerbox's SMPP connection goes down. Kannel will pass it to the store-file and re-try on the next restart. That's why you don't see anything in access.log. access.log entries are writen when the SMSC has confirmed the receiption of the SM-MT itself. Up to this point, the message may be still in your store-file. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: PDU's per TCP Packet
in general this *is* an option to thing about. Apache does this too for serving the response files over the TCP stream. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Core dump when using smsc=emi_ip
Nisan Bloch wrote: hi Have you tried the new emi module? smsc_emi2 is a rework of the older smsc_emi. try the same config with smsc=emi2. which brings us up again to the question if we should drop the old ones, ie. emi, at? Any votes for dropping them. I'll be +1 in this case. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Latest CVS problems with wap stack (cookie?)
Hi David, 2003-07-18 11:49:20 [10] DEBUG: HTTP: Status line: HTTP/1.1 301 Moved Permanently so wap.sonyericsson.com does reply with a HTTP 301, hence Kannel should follow the Location header. 6e 74 65 6e 74 chunked..Content 2003-07-18 11:49:20 [10] DEBUG: data: 2d 54 79 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c -Type: text/html and the response body is text/html encoded, hence 2003-07-18 11:49:20 [8] WARNING: WSP: Content type text/html not supported by client, deleting body. 2003-07-18 11:49:20 [8] WARNING: WSP: content-type text/plain not supported Kannel claims that the content-type is not accepted by the client and replies with a non-displayable WSP message. This effect has nothing to do with cookies, btw. I just wonder why Kannel's HTTP module did not follow the HTTP Location?! Anyone having an idea if the WAP specific HTTP calls are reglemented for following the HTTP Location header?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [ANNOUNCE] dropping smsc_at and renaming smsc_emi/emi2
Bruno Rodrigues wrote: I'm gonna drop smsc_at module and rename at2 to at. I'm also gonna rename emi to emi_x25 and emi2 to emi, and document that this emi_x25 should be used for UCP/EMI through X25 unless someone wants to code it on smsc_emi (new one). Is it ok for you ? even while you already did it ;) +1. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: PDU to trigger Mobile
Bruno Rodrigues wrote: I doubt it as we are looking for a different solution to grab imei from our network. There is a solution, but it's not generic sms - you can have an SIM toolkit application in customers simcard reading his imei and then you'll comunicate with the toolkit through sms's (pid=127 for example) If you discover any way to do this with generic sms I'd be glad to know ;) yep, me too. I agree with Bruno here. I guess you won't have controll into the phone core unless you do it via the sim toolkit itself. There *may* be generic sms solutions that device vendors implemented on their own, but there is definetly no public specification about this. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [ANNOUNCE] Compatibility breaking in next release
Alexander Malysh wrote: Hi Bruno, can you please first post such radical changes to ML before you commit these? It would be great first to review this patch... We are in pre-release phase now (imo)... or ? agreed *fully* here! Bruno, you *have to* ask for votes in case commiting changes are considered behaviour changes ins any way!! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: ENABLE_NOT_ACCEPTED
Aarno Syvänen wrote: Hi List, does new code that checks does phone accept some content type work with wildcards ? (Some phones send just Accept: */*, which is quite stupid, of course.) There seems to be some problems with mms now. Bruno, I think this was your code ? yes, Bruno has a bit ambicious in the last days and commited things without *asking* people if they would have problems with it! *grrr* ;) Bruno-Credit-Counter -= 100; ;)) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: SAR problem
Yury Mikhienko schrieb: I tried to fetch the 170K application into Nokia7650 ower Kannel's SAR (CVS version), but get the following error: ... 2003-07-23 14:06:07 [6] DEBUG: WTP: resp_machine 13, state RESULT_RESP_WAIT, event RcvAck. 2003-07-23 14:06:07 [6] DEBUG: WTP: continue_sar_result(): lsegm=251, nsegm=332, csegm=248 2003-07-23 14:06:07 [6] DEBUG: WTP: dispath_to_wdp(): psn = 252 2003-07-23 14:06:07 [6] DEBUG: WTP: dispath_to_wdp(): psn = 253 2003-07-23 14:06:07 [6] DEBUG: WTP: dispath_to_wdp(): psn = 254 2003-07-23 14:06:07 [6] DEBUG: WTP 13: New state RESULT_RESP_WAIT 2003-07-23 14:06:09 [6] DEBUG: WTP: resp_machine 13, state RESULT_RESP_WAIT, event RcvAck. 2003-07-23 14:06:09 [6] DEBUG: WTP: continue_sar_result(): lsegm=254, nsegm=332, csegm=251 2003-07-23 14:06:09 [6] DEBUG: WTP: dispath_to_wdp(): psn = 255 2003-07-23 14:06:09 [6] PANIC: gwlib/octstr.c:1683: octstr_set_bits: Assertion `value = mask' failed. ... Can I fix that bug? it seems the maximum packet counter (255) has been reached and Kannel run into an assertion checking before serving all 332 requires SAR packets. Igor, is this the Extended-SAR thing you talked about?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: WAP-183-ProvCont-20010724-a specification
No, at least not directly. the ota_prov_attr.h contains the tokens as defined by the Ericsson/Nokia OTA config protocol, *not* the official WAP specs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Segmentation fault
Alexander Malysh wrote: sorry that where changes from me in bb_store :( I am looking on resolving it, or want you resolve it Stipe? nop, your job! ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: SAR problem
yep, and this PANIC is reported as bug #4 in bugs.kannel.org and if noone fixes it I will myself. (No, I won't be able to implement ESAR myself, don't even think about that Stipe :P) hmmm, it was the first thing that got into my mind ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFV] late request for voting/vetting for several stuff
Bruno Rodrigues wrote: I should have asked for comments before, but I'm really work-free now and I'd like to implement stuff as fast as I can, even if there's momentary cvs versions with major bugs. If you can, please test cvs versions as hardly as you can and report everything you find to this list so I can see if I did something wrong and be able to fix it right away. These are the features I've implemented and after that, a list of stuff I'm about to fix/implement unless you complain very hard ;) I'd like to ear your comments and/or any reason against them. It's still not too late to rollback anything. (Here we go, by your request Stipe) to be more precise: by consensus of the group ;) 2003.07.07 - header packing implemented I've implemented this feature to aggregate similar headers because some devices I have sends so many headers that if we send one header per value, I get too many headers, if I aggregate them all in one header, I get header too long. http_header_pack packs headers with 256 characters (defineable) definetly +1. Even while we make a workarround for too tightly confiured HTTP servers. We've seen these problems on various devices too. 2003.07.13 - wbxml dynamic version byte and wap dynamic version byte I'm looking at device header sent and I'm setting wbxml version acordly. I'm looking at wml's externalid declaration and settings wbxml's wap version acordly. This was required because SE-T610 looks at them and would ignore some 1.3 tags if version was 1.1 - it won't respect form type=multipart/form-data for example so this fixed the 'multipart/form-data' thing for SE? (BTW, for all others reading, SE = SonyEricsson) 2003.07.13 - added wap deconverters to decode application/vnd.wap.multipart.form-data to multipart/form-data. working +1 2003.07.13 - preliminary support to decode mms binary into text. deconverter is implemented, I'm just waiting for Stipe's commits for his mms code. +1, it's coming. Let me have my hands on the configure/make process and you will have a bunch of commits here. It's gonna be anyway after 1.3.2 has been released. 2003.07.13 - preliminary suport for multipart/mixed to application/vnd.wap.multipart.mixed, on hold until I fix some more important stuff (and Stipe's mms encoder would also help me) 2003.07.13 - kannel now tries to adapt xml/xhtml content's charset to the one supported by device. Kannel already adds other Accept-Charsets to request headers, so this looks like a needed feature to me (needs to be tested with other charsets beside utf8 and iso-8859-1) Note: Panasonic GAD87 devices (at least in Portugal) became very broken with this because they are really broken and announce that they only support utf-8 but they really only support iso-8859-1 - accented chars are totally mangled. I don't want to make exceptions in kannel and I've already complained to Panasonic. +1, yep, good way. 2003.07.13 - removed Version=0 parameter when sending cookies to external servers. This is not very explicit in specification but I haven't ever seen a client sending this parameter +0, ok with me. 2003.07.14 - added http response 406 back to device if content type is not supported by it. (today I've fixed the */* problem). This was required for (at least) Nokia 7650 +1. 2003.07.18 - smsbox - mo-recode now tries to also recode to utf-8 if iso fails. for external servers, it's easier to process utf8 than ucs2/utf16 (documented) +0. 2003.07.19 - smsbox - dlr won't work at all if smsc-id is undefined - dlr_add and dlr_find just returns if no smsc-id. smsc-id required for dlr processing was documented +1 2003.07.20 - removed smsc_at, renamed at2 to at; moved emi to emi_x25, removed internal emi_ip and renamed emi2 to emi, documented it definetly +1. 2003.07.20 - broken smsbox compatibility to enable mclass=0..3, coding=0..2 and pid=0..255. This was already talked about and it's required to be able to set pid=0 and to be consistent with specification (it's dificult to explain to someone that for etsi's message class 0 you need to set kannel's mclass to 1) yep, +1. Did you test all dependencies on this?! 2003.07.20 - added hplmn and auth-code support, although not yet implemented on smsc_emi (bug #54) ?? (have to check mantis) 2003.07.20 - maintained parameter consistency and always use urlencoding for udh and binary data in POST headers and in xml. I had several complains because common sense will make you send url-encode in http udh header and then you ask yourself why is it not working ??? (didn't get the point. too less coffee this morning? ;)) 2003.07.21 - made wap cookies enable per default. Please complain about what is not working with them so I can fix it. So far, I know, and I'm working thowards it, that we should try to send cookies to device (bug 34), that cookies are not checked for domain, path and secure (bug 64), and that they might not work at all
Re: [RFV] late request for voting/vetting for several stuff
Bruno Rodrigues wrote: I don't think it's a HTTP server problem. I have devices that sends way too many headers (more than 30 accepts if I remember) and a Cisco alteon alike just dropped my connection with those many headers. I guess what we are doing now is the right thing. ;) hmmm, yeah maybe. AFAIR there is no hard limit in RFC2818 (HTTP/1.1) for *how many* accept headers are allowed to be passed. Yep, SE looked at wml-1.1 and POST'ed with appl/x-www-urlencoded. As soon as I set wml1.3, it POST's with right appl/mult.form-data. ahh. 2003.07.18 - smsbox - mo-recode now tries to also recode to utf-8 if iso fails. for external servers, it's easier to process utf8 than ucs2/utf16 (documented) +0. This is important to help our clients, and besides you'll get a nice string text in logs instead of a 00xx00xx00xx... ;) agreed. 2003.07.20 - broken smsbox compatibility to enable mclass=0..3, coding=0..2 and pid=0..255. This was already talked about and it's required to be able to set pid=0 and to be consistent with specification (it's dificult to explain to someone that for etsi's message class 0 you need to set kannel's mclass to 1) yep, +1. Did you test all dependencies on this?! I've done some tests with at(2) (I was at home), which tested smsbox code and sms.c code (fields-dcs), so it should work with all the others. SMAPI is using directly sms.mclass and other parameters, but I guess I've also fixed it. we'll see as soon as we update our production server that run some SM/ASI links ;) 2003.07.20 - maintained parameter consistency and always use urlencoding for udh and binary data in POST headers and in xml. I had several complains because common sense will make you send url-encode in http udh header and then you ask yourself why is it not working ??? (didn't get the point. too less coffee this morning? ;)) in query-string, udh=%xx%yy%zz. In http headers, you use udh=xxyyzz, in my xml was more or less undefined (i guess it was xxyyzz). It's better to be consistent and always use urlencode. This is easily rollbacked (it's two lines) and I'd really like to ear comments about this. have to check, but in general I'm a fan of consitency ;) 2003.07.21 - made wap cookies enable per default. Please complain about what is not working with them so I can fix it. So far, I know, and I'm working thowards it, that we should try to send cookies to device (bug 34), that cookies are not checked for domain, path and secure (bug 64), and that they might not work at all with connectionless wap. I need cookie support and I'd rather activate it and fix it. +1, we have to work on passing the Cookies in WSP encoding to the device. I'm first fixing cookie domain/path support and then I'll do this. ok. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[FYI] new bearerbox rerouting feature
Hi list, I just commited this new bearerbox rerouting feature: Main idea was to allow MOs to be passed directly to the MT queues of smsc-ids configured in the same bearerbox. Hence messages can be proxyied without passing them to external boxes (smsbox, smppbox, or whatever). Therefore 3 new directives for the smsc group have been defined: reroute - boolean, if set to yes, all MOs from this smsc-id will be passed to the general routing function within bearerbox (as if the message would come from an external box). reroute-smsc-id - string, route all MOs explicitely to the smsc-id given here. reroute-receiver - string, route MOs by receiver numbers to specific smsc-ids. Ie. route messages with receiver 111 or 222 to smsc-id A and receiver 333 or 444 to smsc-ids B would look like A,111,222; B,333,444 (yet no wildcard processing.) This rerouting feature allows to connect/proxy messages between networks that are physically (on a below layer) unable to exchange messages. So you can use SMPP and/or EMI/UCP to connect CDMA and TDMA and GSM networked SMSCs. Comments and improvements welcome. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: sending picture message
Hi, yes it can. See the official specs of the vendors (Nokia, Ericsson, Siemens, et all) for information on how. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: two deallocations in url_result_thread in smsbox
Aarno Syvänen wrote: I think we have a problem in smsbox: Url_result_thread has octstr_destroy(charset). Charset is copied (without allocation) to msg structure, and deallocated when msg_destroy is called. so this is resulting in a segfault?! And another thing: is there are no charset defined with content type, default is, as per rfc 2616, iso-8859-1. which indicates Bruno's transcoding changes in wapbox are wrong?! He tries to transcode to utf-8 whenever possible. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: two deallocations in url_result_thread in smsbox
Yep, got problems with ppg sms level delivery reports. any suggestions?! In just looking at this... Drop into IRC: #kannel (irc.freenode.net) for discussion No, this is a different thing. It is just that if http receives something, and there is no charset specified, it must assume that charset is iso-8859-1. Kannel internal coding is another matter. ok, is Kannel misbehaving in this mean anywhere? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: two deallocations in url_result_thread in smsbox
Aarno Syvänen wrote: Just remove octstr_destroy ? No deallocation without allocation! which one of the two? Third chat program to be installed. Probably worth of it, however. definetly! I can drop you my ICQ too if you like?! http library should return charset value ISO-8859-1, not , when there is no explicit charset. ok, can we have this in mantis?! Can you post a report to mantis on this, please. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFT] Kannel Keyword Handling
Ok, another 2ct from me. 1st of all we could addopt Netikos keyword matching logic, they have enhanced it and code can be derived from their tree. 2nd, PCRE or regexp support would be definetly nice to have and mostly easy to implement I guess. Any volonteers? 3rd, keyword dependency matching should be done (IMO) via an OpenLDAP tree. This solves also the issues of restarting Kannel for service group changes. So your LDAP tree would look like services | -- service A | -- keyword 1.A keyword 2.A keyword 2.B -- keyword 1.B which means smsbox would match the first keyword (keyword 1.A) and then traverse the node for more dependency matchings (if available), hence match for keyword 2.B and execute the defined action (get-url, exec, or whatever) Does anyone know if OpenLDAP supports client side caching? Ideally the OpenLDAP client code would hold the tree in memory (without issueing lookup request to the server) until the server signals clients to update their table because updates in the tree have happened. Any LDAP gurus arround? @Alex: can you have a deeped look at Netikos version for the keyword matching features they implemented in their Kannel tree?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] commiting changes to ppg bugfixes
Hi Aarno, a) bugfixes to ppg (most important one is one spotted by Juan Enriques) +1 b) a change to ppg: it will use Kannel headers, not cgivars, to control PPG SMS level (delivery reports). +0. Stipe ;) [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [FYI] rewrote gwlib/http.c:parse_url()
Stipe Tolj wrote: David Chkhartishvili wrote: Hi Stipe, I've tried latest CVS. Seems likes kannel doesn't send X-WAP-Network-Client-MSISDN any more. in terms of the RADIUS acct proxy? Bruno changed some things in there for his 'wap-[url|user]-map' thing. Let me see... yep, he broke it! -1 I'll try to fix it directly. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [FYI] rewrote gwlib/http.c:parse_url()
David Chkhartishvili wrote: Yes. I mean, radius accounting working, but kannel stopped to send X-WAP-Network-Client-MSISDN header. see changes he made in gw/wap-appl.c:add_msisdn(). Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: freebsd 4.8 @ kannel cvs problems
Dziugas Baltrunas wrote: Hi list, I recently made box upgrade with the FreeBSD 4.8 OS inside. I cvs'ed up Kannel, and interesting things happend. firstly, there is someting strange in access log: 2003-08-03 18:42:40 Receive SMS [SMSC:xxx] [SVC:] [ACT:] [from:xxx] [to:xxx] [flags:-1:0:-1:0:-1] [msg:3:xxx] [udh:0:] 2003-08-03 18:42:41 Sent SMS [SMSC:xxx] [SVC:xxx] [ACT:] [from:xxx] [to:xxx[flags:-1:0:-1:-1:-1] [msg:41:xxxudh:0:] what do flags 1:0:-1:0:-1 meen? seems like they now apply for every text message. the -1 are the new default values for the Kannel msg structure Bruno introduced. So -1 means here that the values have not been explicetly set. what is more, smsbox behaviour is unexpectable and it often don't handle messages if I request to do it quit frequently, i.e. it doesn't respont to queries. the bad thing is that smsbox dies after few requests: 2003-08-03 18:43:17 [3] INFO: smsbox: Got HTTP request /cgi-bin/sendsms from xxx 2003-08-03 18:43:17 [3] INFO: sendsms used by test 2003-08-03 18:43:17 [3] INFO: sendsms sender:test:xxx (xxx) to:xxx msg:xxx 2003-08-03 18:43:17 [3] DEBUG: message length 3, sending 1 messages 2003-08-03 18:43:17 [3] DEBUG: Status: 202 Answer: Sent. 2003-08-03 18:43:17 [3] DEBUG: HTTP: Resetting HTTPClient for `xxx'. 2003-08-03 18:43:17 [4] INFO: Starting to service xxx from xxx to xxx 2003-08-03 18:43:17 [9] DEBUG: Parsing URL `http://xxx/engine/getsong.php?key=xxx: 2003-08-03 18:43:17 [9] DEBUG: Scheme: http:// 2003-08-03 18:43:17 [9] DEBUG: Host: smsbox.m-1.lt 2003-08-03 18:43:17 [9] DEBUG: Port: 80 2003-08-03 18:43:17 [9] DEBUG: Username: (null) 2003-08-03 18:43:17 [9] DEBUG: Password: (null) 2003-08-03 18:43:17 [9] DEBUG: Path: /engine/getsong.php 2003-08-03 18:43:17 [9] DEBUG: Query: key=xxx 2003-08-03 18:43:17 [9] DEBUG: Fragment: (null) 2003-08-03 18:43:17 [9] DEBUG: HTTP: Opening connection to `smsbox.m-1.lt:80' (fd=30). 2003-08-03 18:43:17 [9] DEBUG: Socket connected at once 2003-08-03 18:43:17 [9] DEBUG: HTTP: Sending request: 2003-08-03 18:43:17 [9] DEBUG: Octet string at 0x80fbdd0: 2003-08-03 18:43:17 [9] DEBUG: len: 97 2003-08-03 18:43:17 [9] DEBUG: size: 98 2003-08-03 18:43:17 [9] DEBUG: immutable: 0 2003-08-03 18:43:17 [9] DEBUG: data: 47 45 54 20 2f 65 6e 67 69 6e 65 2f 67 65 74 73 GET /engine/gets 2003-08-03 18:43:17 [9] DEBUG: data: 6f 6e 67 2e 70 68 70 3f 6b 65 79 3d 6d 31 20 48 ong.php?key=xxx H 2003-08-03 18:43:17 [9] DEBUG: data: 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 73 TTP/1.1..Host: x 2003-08-03 18:43:17 [9] DEBUG: data: 6d 73 62 6f 78 2e 6d 2d 31 2e 6c 74 0d 0a 55 73 xx..Us 2003-08-03 18:43:17 [9] DEBUG: data: 65 72 2d 41 67 65 6e 74 3a 20 4b 61 6e 6e 65 6c er-Agent: Kannel 2003-08-03 18:43:17 [9] DEBUG: data: 2f 63 76 73 2d 32 30 30 33 30 38 30 33 0d 0a 0d /cvs-20030803... 2003-08-03 18:43:17 [9] DEBUG: data: 0a . 2003-08-03 18:43:17 [9] DEBUG: Octet string dump ends. 2003-08-03 18:43:17 [8] DEBUG: HTTP: Status line: HTTP/1.1 200 OK 2003-08-03 18:43:17 [8] DEBUG: HTTP: Received response: 2003-08-03 18:43:17 [8] DEBUG: Octet string at 0x80fbec0: 2003-08-03 18:43:17 [8] DEBUG: len: 241 2003-08-03 18:43:17 [8] DEBUG: size: 242 2003-08-03 18:43:17 [8] DEBUG: immutable: 0 2003-08-03 18:43:17 [8] DEBUG: data: 44 61 74 65 3a 20 53 75 6e 2c 20 30 33 20 41 75 Date: Sun, 03 Au 2003-08-03 18:43:17 [8] DEBUG: data: 67 20 32 30 30 33 20 31 35 3a 34 33 3a 31 37 20 g 2003 15:43:17 2003-08-03 18:43:17 [8] DEBUG: data: 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 41 70 61 GMT..Server: Apa 2003-08-03 18:43:17 [8] DEBUG: data: 63 68 65 2f 31 2e 33 2e 32 38 20 28 55 6e 69 78 che/1.3.28 (Unix 2003-08-03 18:43:17 [8] DEBUG: data: 29 20 50 48 50 2f 34 2e 33 2e 33 52 43 31 0d 0a ) PHP/4.3.3RC1.. 2003-08-03 18:43:17 [8] DEBUG: data: 58 2d 50 6f 77 65 72 65 64 2d 42 79 3a 20 50 48 X-Powered-By: PH 2003-08-03 18:43:17 [8] DEBUG: data: 50 2f 34 2e 33 2e 33 52 43 31 0d 0a 54 72 61 6e P/4.3.3RC1..Tran 2003-08-03 18:43:17 [8] DEBUG: data: 73 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 63 sfer-Encoding: c 2003-08-03 18:43:17 [8] DEBUG: data: 68 75 6e 6b 65 64 0d 0a 43 6f 6e 74 65 6e 74 2d hunked..Content- 2003-08-03 18:43:17 [8] DEBUG: data: 54 79 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c 0d Type: text/html. 2003-08-03 18:43:17 [8] DEBUG: data: 0a 0d 0a 44 61 62 61 72 20 4d 2d 31 20 65 74 65 ...x 2003-08-03 18:43:17 [8] DEBUG: data: 72 79 6a 65 3a 20 4a 4f 48 4e 20 4d 41 59 45 52 2003-08-03 18:43:17 [8] DEBUG: data: 20 2d 20 59 6f 75 72 20 42 6f 64 79 20 49 73 20 2003-08-03 18:43:17 [8] DEBUG: data: 41 20 57 6f 6e 64 65 72 6c 61 6e 64 2e 20 4d 2d 2003-08-03 18:43:17 [8] DEBUG: data: 31 20 42 49 4b 49 4e 49 20 73 65 7a 6f 6e
Re: freebsd 4.8 @ kannel cvs problems
Dziugas Baltrunas schrieb: The situation could be repeated in very simple way - you just have to invoke http sendsms wrapper several times one by another and smsbox suddenly dies. sms-service groups also works in very unexpected way, offen not providing any reply. in my opinion, it's really very critical behaviour. btw, will the userguide be provided with new meanings of SM flags? can you please update your local cvs tree and try to reproduce the behaviour again?! I just commited a fix to smsbox. If it still fails with the same behaviour, then please provide us your configuration and an detailed description on how to reproduce. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: freebsd 4.8 @ kannel cvs problems
Aarno Syvänen schrieb: Got same panic, found double deallocation and told Stipe. He promised to fix this. (see gw/smsbox.c, line 1052; msg_destroy deallocates charset, too). commited to cvs some min ago. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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 ID 0000071
I've just tried to add wap-map-url group to kannel.conf (http://bugs.kannel.org/view_bug_page.php?f_id=071), but got error: 2003-08-04 14:47:25 [0] INFO: Debug_lvl = 0, log_file = none, log_lvl = 0 2003-08-04 14:47:25 [0] ERROR: Group 'wap-map-url' may not contain field 'group'. 2003-08-04 14:47:25 [0] ERROR: Error found on line 67 of file `/etc/kannel2.conf'. 2003-08-04 14:47:25 [0] PANIC: Couldn't read configuration from `/etc/kannel2.conf'. please do pass us the conf block to review. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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 ID 0000071
group = wap-map-url url = http://* send-msisdn-header = X-WAP-Network-Client-MSISDN it's 'group = wap-url-map', see gwlib/cfg.def. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: problem with CMG and one mutual SEND/RCV connection
Andreas Fink wrote: if this is really the case, then we have a bug to fix. Bruno what you think of this? I'd like to hear Alexander's opinion too?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Anam and Kannel
Nisan Bloch wrote: does anyone know what version of Kannel the Anam WirelessWindow gateway is built off? how about asking Paul directly?! ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [Fwd: [Kannel 0000077]: gwlib/dict.c seems to loose entries in the Dict structure]
Alexander Malysh wrote: Hi Stipe, i hope not ;) It's pretty simple. You use in your test rand. The rand can not generate really unique keys. So if you key equal one which already stored in the dict , then old key will be overwritten with new one. Key _must_ be always unique. Just try attached patch for ur test_dict.c... ooops, good hint Alex!!! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] Number portability hooks
An HTTP 'callback' sounds good as an initial implementation. Generic and flexible. yep. I'm also in a favor of this. Where API should be very simplified like: earerbox calls http://www.foob.com/?msisdn=msisdn and that HTTP server replies with either an smsc-id as body/header(?!) or nothing (indicating he doesn't know where to route). The question is would we do some kind of internal caching for this? This would speed up things drastically. Maybe using a *huge* Dict hash? Has anyone used huge Dict hashs? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] get rid of --with-dlr option
Alexander Malysh wrote: On Friday 08 August 2003 16:51, Stipe Tolj wrote: David Tully wrote: +1 Makes no sense to me to have to use 3 directives when you want to compile DLR mysql support.. --with-dlr=mysql --enable-mysql --with-mysql=/usr/.. Unless there is another reason for them all?! ok, from my perspektive --enable-mysql is useless. nope... --with-mysql used _only_ if you have mysql installed in the nonstandard path. If you have mysql installed in the standard path, then --enable-mysql is enough... but that's semantically not how autoconf treat --enable-foobar and --with-foobar. --enable-foobar is for activiating components that are inside the configurable package and --with-foobar is for adding functionality from a 3rd party package (hence mysql in this case). So a ./configure --with-dlr=internal --with-mysql may be a reasonable approach if the mysql support is used somewhere else. but why you need --with-dlr ??? internal will compiled in per default. mysql will be only compiled in if you have mysql libs installed and want use these. ok, --with-dlr is definetly out of need, since we can configure which storage type to use in the config file itself. I agree. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[PATCH] WSP Encoding-Version support
headers as an Octstr.
* The second argument is true if the encoded headers should have
* a leading content-type field. See the note for wsp_headers_unpack. */
-Octstr *wsp_headers_pack(List *headers, int separate_content_type);
+Octstr *wsp_headers_pack(List *headers, int separate_content_type, int wsp_version);
#endif
diff -ur --exclude=CVS* old/gateway/wap/wsp_server_method_states.def
gateway/wap/wsp_server_method_states.def
--- old/gateway/wap/wsp_server_method_states.defTue Nov 28 22:15:33 2000
+++ gateway/wap/wsp_server_method_states.defThu Aug 7 17:06:25 2003
@@ -260,7 +260,7 @@
new_pdu-u.Reply.status =
wsp_convert_http_status_to_wsp_status(e-status);
new_pdu-u.Reply.headers =
- wsp_headers_pack(e-response_headers, 1);
+ wsp_headers_pack(e-response_headers, 1, WSP_1_2);
new_pdu-u.Reply.data = octstr_duplicate(e-response_body);
/* Send TR-Result.req to WTP */
diff -ur --exclude=CVS* old/gateway/wap/wsp_server_session_machine.def
gateway/wap/wsp_server_session_machine.def
--- old/gateway/wap/wsp_server_session_machine.def Tue Apr 30 11:07:03 2002
+++ gateway/wap/wsp_server_session_machine.def Thu Aug 7 14:28:13 2003
@@ -19,23 +19,24 @@
MACHINE(
- INTEGER(state)
- INTEGER(connect_handle)
- INTEGER(resume_handle)
- INTEGER(session_id)
- ADDRTUPLE(addr_tuple)
+INTEGER(state)
+INTEGER(connect_handle)
+INTEGER(resume_handle)
+INTEGER(session_id)
+ADDRTUPLE(addr_tuple)
- CAPABILITIES(request_caps)
- CAPABILITIES(reply_caps)
+CAPABILITIES(request_caps)
+CAPABILITIES(reply_caps)
- INTEGER(MOR_push)
- INTEGER(client_SDU_size)
+INTEGER(MOR_push)
+INTEGER(client_SDU_size)
+INTEGER(encoding_version)
- HTTPHEADERS(http_headers)
- COOKIES(cookies)
-REFERER(referer_url)
- MACHINESLIST(methodmachines)
-MACHINESLIST(pushmachines)
+HTTPHEADERS(http_headers)
+COOKIES(cookies)
+REFERER(referer_url)
+MACHINESLIST(methodmachines)
+MACHINESLIST(pushmachines)
)
#undef INTEGER
diff -ur --exclude=CVS* old/gateway/wap/wsp_server_session_states.def
gateway/wap/wsp_server_session_states.def
--- old/gateway/wap/wsp_server_session_states.def Tue Dec 3 13:33:10 2002
+++ gateway/wap/wsp_server_session_states.def Thu Aug 7 16:42:22 2003
@@ -49,12 +49,31 @@
}
if (pdu-u.Connect.headers_len 0) {
- List *hdrs;
+List *hdrs;
+Octstr *encoding;
- hdrs = wsp_headers_unpack(pdu-u.Connect.headers, 0);
- http_header_pack(hdrs);
- gw_assert(sm-http_headers == NULL);
- sm-http_headers = hdrs;
+hdrs = wsp_headers_unpack(pdu-u.Connect.headers, 0);
+http_header_pack(hdrs);
+gw_assert(sm-http_headers == NULL);
+sm-http_headers = hdrs;
+
+/*
+ * Get WSP encoding version if provided by device and remember in
+ * session machine for later use in encoding tokenized values.
+ */
+encoding = http_header_value(sm-http_headers,
octstr_imm(Encoding-Version));
+if (encoding != NULL) {
+debug(wsp,0,WSP: Session machine: Encoding-Version: %s,
+ octstr_get_cstr(encoding));
+sm-encoding_version = wsp_encoding_string_to_version(encoding);
+} else {
+/* WAP-230-WSP-20010705-a, section 8.4.2.70, page 97 defines
+ * by a MUST argument that a non-present Encoding-Version header
+ * should be interpreted as WSP 1.2 compliant.
+ */
+sm-encoding_version = WSP_1_2;
+}
+octstr_destroy(encoding);
}
/* Send S-Connect.ind to application layer */
diff -ur --exclude=CVS* old/gateway/wap/wsp_session.c gateway/wap/wsp_session.c
--- old/gateway/wap/wsp_session.c Thu Jun 19 13:49:12 2003
+++ gateway/wap/wsp_session.c Thu Aug 7 17:03:57 2003
@@ -2,6 +2,7 @@
* wsp_session.c - Implement WSP session oriented service
*
* Lars Wirzenius
+ * Stipe Tolj
*/
@@ -127,7 +128,8 @@
static void main_thread(void *);
static int id_belongs_to_session (void *, void *);
-
+static int wsp_encoding_string_to_version(Octstr *enc);
+static Octstr *wsp_encoding_version_to_string(int version);
/***
@@ -1011,6 +1013,8 @@
/* First the case that we have no Encoding-Version header at all.
* This case we must assume that the client supports version 1.2
* or lower. */
+
+/*
if (is_default_version(m)) {
encoding_version = octstr_create
Re: Possible bug with smsc-stop
Bill Brigden wrote: Hi, Im running cvs-20030811, and we have 9 connections to our providers: 1 transmitter/receiver to provider 1 3 transmitters to provider 2 1 receiver to provider 2 1 transceiver to provider 3 2 transmitters to provider 4 1 receiver to provider 4 now each provider has the same smsc-id, so it will load balance within each set of provider connections However, if I do a smsc-stop via the http admin, it will only stop the first smsc-id that matches, and the other smsc connections with the same smsc-id stay connected. Is this behaviour expected? this brings up again to the case that we want 'group = smsc-group' to have gathering real smsc-ids that have *unique* IDs to groups for start/stop'ing a whole bunch of local smsc connections. I'll see how fat I get with this in the coming days. BTW, I also worked in smsc aliases. Espacially to solve SMPP related configuration issues with more than 1 configured smsc group, but only one of those with a real connection. Unfortunatly seting up such virtual smsc groups in Kannel is not as easy as I thought. It's pretty tricky to have the messages re-routed in case the real smsc goes away while routing happens. Anyone having a good idea on how to implement smsc aliases *without* changing the code too heavily? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[RFC] WSP Encoding-Version patch reviewed?!
Hi list, did someone have the chance to review the patch I send in: Subject: [PATCH] WSP Encoding-Version support Date: Fri, 08 Aug 2003 22:17:33 +0200 ??? As there haven't been any vetos, I will commit this to cvs to have it included into 1.3.2 development release. Any issues that have to be solved before releasing? (Ok, I know, I asked this several times and most of you will say: Now, come on, release it now and don't ask stupid questions ;) After we have 1.3.2 devel we will branch of the devel tree and only commit fixed for 1.4.0 stable which then (hopefully) will get WAP certification. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[RFC] chaning global function names (for 3rd party compatibility)
Hi list, when trying to use Kannel's libraries with 3rd party software we have some function naming clashes. This will make it very hard to use Kannel's libraries for writing modules to other software components, like Apacke modules, Exim transports and so on. I'd like to propose to change naming contenvion for functions that are used inside gwlib (and gw?). Maybe prefixing all function names with knl_foobar()?? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: splitting messages
I have a little issue here I hope someone can shed some light on. what i want to do is to split a binary message (operator logo) and send it to a mobile. simple..yes, but i want to sent it using 2 different froms. it doesnt seem to work. it works ok if i use the same from. Please find here the sample (nokia operator logo with udh ) and my debugs. sorry its quite long seeing your SMPP PDUs at least the SMSC does not complain about it, right?! So it's the phone that actually does not accept an concatenated SMS from different source addresses. It is subject that the phone may use the source address as identifying qualifier when re-assembling the message on the device. I never tried to send concatenated messages with different source addresses, but I would suppose that it is the phone that breaks the acceptance here. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: splitting messages
well there is a sort of message id inside the udh ..its the concatenated short message reference number ,.. there is no need to use the short number that's your interpretation. Nokia's may differ ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] chaning global function names (for 3rd party compatibility)
Alexander Malysh schrieb: On Wednesday 20 August 2003 11:54, Stipe Tolj wrote: Prefix gw causes naming clashes, too, I suppose ? haven't seen that, but maybe, yes. I guess we should prefix all functions to somewhat symantically, like Apache's portable runtime does it with apr_foobar() yep, +1 from me... I hope that no one 3rd party software will use knl_ as prefix ;) I guess we have to investigate and propagate this. ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: MMS and stuff..
What is the current status for MMS and stuff ? Stipe.. you have been working on some stuff ? What does need help etc. ? mmsbox is present. We still need the --add-box switch in Kannel's configure to cleanly seperate cvs modules and the build process. @Alexander: could you preliminary release your new autoconf build tarball snapshot? I could pull that from your cvs machine and drop it to a www.kannel.org place for review of developers? Which one to take? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Kannel Gateway in Realtime
Andreas Fink wrote: no. mobile send SMS to SMSC, SMSC sends to mobile --or-- mobile sends SMS to SMSC, SMSC sends to gateway (kannel), gateway sends to APPLICATION (on http) Application replies or sends answer to gateway, gateway sends to SMSC, SMSC delviers answer to mobile Andreas, we have the ICM (inter-carrier messaging) feature now in bearerbox! Which means you can utilize the following chain: mobile A - SMSC A - Kannel (bearerbox) - SMSC B - mobile B *without* passing message to smsbox or any other backend system. I have to send sms via pc to a mobile device (realtime moblie number). Can i use Kannel gateway to send sms to realtime devices.. what you call realtime in this respect? yep, I'd like to know that too? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Kannel Gateway in Realtime
We have this since a long time by doing it over HTTP in smsbox ;-) How you route this in the config? of course. But this approach is a lot more faster, beause there is no need to pass messages to the external application server. See reroute-* config directives in smsc group in user's guide. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] Resouce leak/Denial of service in bb_boxc.c
Paul Keogh wrote:
In boxc_sender (), the code
/* wait for smsbox identification */
if (bb_status != BB_DEAD conn-alive conn-is_wap == 0) {
mutex_lock(conn-boxc_id_mutex);
debug(bb.boxc, 0, boxc_sender: sender unlocked);
mutex_unlock(conn-boxc_id_mutex);
}
means that this thread waits until a cmd_identity message is received.
However, if a client simply connects and disconnects to the SMS Box
port, then this thread never exits. This is easy to test with a simple
script that makes a TCP connect() to the port and then closes immediately.
I think some code is needed in boxc_receive() to cater for this; ie.
msg = read_from_box(conn);
if (msg == NULL) { /* garbage/connection lost */
conn-alive = 0;
if (conn - boxc_id == NULL)
mutex_unlock(conn-boxc_id_mutex);
break;
}
so if the boxc_id is NULL, no cmd_identity message has been received and the
corresponding boxc_sender() thread is still blocked on the
conn-boxc_id_mutex
mutex.
agreed. Sounds reasonable.
BTW, can someone tell me why the mutex_unlock() *after* the
mutex_lock() is necessary in the boxc_sender() block?!
When cmd_identify is received the boxc_receiver() thread unlock's the
mutex and the debug is thrown. Why does it have to unlock once again
there?
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
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: [RFC] Resouce leak/Denial of service in bb_boxc.c
I think some code is needed in boxc_receive() to cater for this; ie.
msg = read_from_box(conn);
if (msg == NULL) { /* garbage/connection lost */
conn-alive = 0;
if (conn - boxc_id == NULL)
mutex_unlock(conn-boxc_id_mutex);
break;
}
so if the boxc_id is NULL, no cmd_identity message has been received and the
corresponding boxc_sender() thread is still blocked on the
conn-boxc_id_mutex
mutex.
nop, this won't work. Because smsbox client *may* connect without
explicite ID and hence conn-boxc_id would be left == NULL.
So when a smsbox connection breaks, and the smsbox was not having an
smsbox-id then the mutex is tried to unlock and crash:
2003-08-25 11:45:05 [10] ERROR: Connection to box 127.0.0.1 broke.
2003-08-25 11:45:05 [10] PANIC: gwlib/thread.c:100: mutex_unlock_real:
Mutex failure! (Called from gw/bb_boxc.
c:199:boxc_receiver.)
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
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
[PATCH] boxc connections
Hi list,
I'm forwarding this Patch for Alexander.
This patch is about to solve a bajor that cause currently problems in
bearerbox - smsbox routing:
When an smsbox passes an MT message bearerbox will send an ACK for it,
that is passed to the global incoming queue. From this global
incoming queue all smsboxes are reading. Hence there is no garantee
that ACKs are delivered to the right smsbox.
Alexander follows with this patch and the change to have a seperate
incoming queue per smsbox connection like we have for wapbox
connections.
Please review and vote for commiting this to cvs!
BTW, thanks to Alexander for identifying the problem and providing a
patch for it.
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
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 areIndex: gw/bb_boxc.c
===
RCS file: /home/cvs/gateway/gw/bb_boxc.c,v
retrieving revision 1.69
diff -a -u -r1.69 bb_boxc.c
--- gw/bb_boxc.c21 Aug 2003 17:06:45 - 1.69
+++ gw/bb_boxc.c25 Aug 2003 18:49:42 -
@@ -43,9 +43,9 @@
static List*smsbox_list = NULL;
/* dictionaries for holding the smsbox routing information */
-static Dict *smsbox_by_id = NULL;
-static Dict *smsbox_by_smsc = NULL;
-static Dict *smsbox_by_receiver = NULL;
+static Dict *smsbox_by_id = NULL;
+static Dict *smsbox_by_smsc = NULL;
+static Dict *smsbox_by_receiver = NULL;
static longsmsbox_port;
static int smsbox_port_ssl = 0;
@@ -57,7 +57,7 @@
static longboxid = 0;
-extern Mutex *boxid_mutex;
+extern Mutex *boxid_mutex;
typedef struct _boxc {
@@ -65,17 +65,20 @@
intis_wap;
long id;
intload;
-time_t connect_time;
+time_t connect_time;
Octstr *client_ip;
-List *incoming;
-List *retry; /* If sending fails */
+List *incoming;
+List *retry; /* If sending fails */
List *outgoing;
volatile sig_atomic_t alive;
-Octstr *boxc_id; /* identifies the connected smsbox instance */
-Mutex *boxc_id_mutex; /* stops boxc_sender until smsbox identification*/
+Octstr *boxc_id; /* identifies the connected smsbox instance */
} Boxc;
+/* forward declaration */
+static void sms_to_smsboxes(void *arg);
+
+
/*-
* receiver thingies
*/
@@ -88,6 +91,7 @@
pack = NULL;
while (bb_status != BB_DEAD boxconn-alive) {
+/* XXX: if box doesn't send (just keep conn open) we block here while
shutdown */
pack = conn_read_withlen(boxconn-conn);
gw_claim_area(pack);
if (pack != NULL)
@@ -225,33 +229,28 @@
/* if this is an identification message from an smsbox instance */
else if (msg_type(msg) == admin msg-admin.command == cmd_identify) {
-/*
+/*
* any smsbox sends this command even if boxc_id is NULL,
* but we will only consider real identified boxes
*/
if (msg-admin.boxc_id != NULL) {
-List *newlist;
/* and add the boxc_id into conn for boxc_status() output */
-if (conn-boxc_id == NULL)
-conn-boxc_id = octstr_duplicate(msg-admin.boxc_id);
-/*
- * re-link the incoming queue for this connection to
- * an own independent queue
- */
-newlist = list_create();
-list_add_producer(newlist);
-conn-incoming = newlist;
-conn-retry = newlist;
-
-/* add this identified smsbox to the dictionary */
-dict_put(smsbox_by_id, msg-admin.boxc_id, conn);
+if (conn-boxc_id != NULL) {
+dict_remove(smsbox_by_id, msg-admin.boxc_id);
+octstr_destroy(conn-boxc_id);
+}
+
+conn-boxc_id = msg-admin.boxc_id;
+msg-admin.boxc_id = NULL;
+
+/* add this identified smsbox to the dictionary */
+/* XXX check for equal boxc_id in Dict, otherwise we overwrite it
*/
+dict_put(smsbox_by_id, conn-boxc_id, conn);
debug(bb.boxc, 0, boxc_receiver: got boxc_id %s from %s,
- octstr_get_cstr(msg-admin.boxc_id),
+ octstr_get_cstr(conn-boxc_id),
[FYI] changed www.kannel.org homepage
Hi list, I changed the hompage to express our (I hope I'm speaking for most/all of us) protest against the discussions about the new EU software-patent regulations. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] Call for 1.3.2
I would like to ask for any showstopper for 1.3.2 developer release? I do not see any, if such should exists please tell here , so we can fix it and roll new release out. I see only a few pending patches, that should be commited or rejected ;) So please _all_ developer, vote for the pending patches and let us make new release, so we can get more users try it... we definetly *have to* resolve the MSISDN provisioning via RADIUS acct proxy for WAP *before* releasing. This mis-behaviour has been introduced by Bruno's changes and the new wap-user-map groups. I can have this reviewed and fixed today hopefully. I agree with Alex, we have *tooo few* votes in the past time, so please do try and vote for commitment. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [RFC] Call for 1.3.2
Alexander Malysh wrote: is it issue #71 ? why is it marked as resolved then? Stipe, please reopen this issue and assign it to you, so we can see which issue still open and should be fixed... re-opened. I can have this reviewed and fixed today hopefully. It would be great ;) looking into this. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: MMS Notification
Rory Campbell-Lange wrote: I'd be grateful to know if someone has written up the precise steps needed to make an MMS Notification. (I am at present using Kannel's SMPP services.) you should poll the mailing list archives. There has been a lot of topics coverered. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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] Re: Problems with the handling of DLR's / SMPP
this patch has been comited by Alexander to cvs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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] SMPP inactivity+transaction timeouts
this patch has been commited by Alexander to cvs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[FYI] wtls status
Ivone Uribe wrote: I would like to know which is the status of the wtls development in kannel, any advance? I'm using the kwtls patch but it have a lot of memory leaks bugs and it is a big problem. Anybody is working on it? If any body is working on it, please tell me. AFAIK, there is currently *no* one actively working on it. Help is highly appritiated. Can you provide coding support for the WTLS stack?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[Fwd: question on kannel Xser]
forwarded to the list. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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---BeginMessage--- hi, just want to ask how did you configure the XSer field in the emi smsc? my telco provider told me to define the Xser field type 0C which is the billing class, and honestly i have no idea about it... please help thanks. dave ---End Message---
[CFP] own KSF vs. ASF project
Hi list, this is a call for participation: Alexander and me would like to invite all codebase developers with CVS rights to participate in an online discussion via IRC for the future organizational aspects of Kannel. The place is: IRC channel #kannel irc.freenode.net The date and time is: Fri, 19th Sep 2003 --! mark this in your diary ;) 2:00pm CET The topics we want to have discussed are mainly on how we are about forming a legal body to hold all copyright of the Kannel source code and act as representative to the outside world. There are two options we currently focus on. First - forming an own foundation, the KSF. Seconds - letting Kannel incubate into the Apache Software Foundation (ASF) as project. The second option has some objectives that should be reviewed, please see http://incubator.apache.org for more details on how Apache incubates projects. Main effect we would reach with an Apache incubation would be IMO: * more popularity for the who project, in means of new developers and commercial companies incorporating the software into commerical products (think of adding Kannel into IBM's WebSphere application server, etc.) * less organizational overhead, in means of all the things we would have to do while forming an own legal body. * a well organized developer community and infrastructure base. Discussions should be opened now on this mail thread and actively tomorrow in the IRC session! Please paticipate actively! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [CFP] own KSF vs. ASF project
Too bad.. I wont be there as I have a conference call exactly at this time... I might be there a bit later the discussion whould be open a couple of hours. I guess all of us who are online can have their IRC clients open until evening, so we can have a wide ranged discussion. BTW, we will also log the session and make it available afterwards for review. So be warned ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: patching dlr_sdb for same smsc all the time
Rory Campbell-Lange wrote: Will this work? why not try?! ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: dlr_sdb bug
Rory Campbell-Lange wrote: Another note is that some people may wish to keep a record of their dlrs and not have them deleted by default. I patched dlr.c to call update on delete rather than delete, which meant that the dlr status is recorded in the dlr table. hmmm, we didn't intend this inside the DLR storage itself. You will have a DLR SMS inside your access log file for it, so it will be recorded. IMO, you should not keep these inside the temporary storage space of the DLRs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Connection failed ?
An SMS is sent from a user's mobile phone to kannel. Kannel identifies the specific service, and a URL is requested via the GET-method. Kannel expects the response from the URL, BUT, the connection between kannel and HTTP Server is lost, BEFORE kannel receives the response SMS, that is supposed to return as an answer to user. Is there any way to handle this situation, e.g. sending an SMS to the user after waiting for 2 or 3 minutes and not having a response from the HTTP server? I understand that kannel can handle some situations like requestfailed, couldnotfetch, requestfailed, emptymessage, but I don't think that can handle the above scenario. Am I correct? Do you have any ideas ? Waiting for your response. Thanks in advance yes, Kannel (or specifically the smsbox) can handle this. smsbox can have an HTTP request queueing mechanism where you can have several tries to deliver the HTTP request to the HTTP server. Please see user's guide for configuration directives. Now as smsbox will tried all HTTP GETs as failed, when no answer is given, it will retry to N times that you can configure. If it fails for all N times, then the smsbox will pass a could not fetch message to the user via bearerbox. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: dlr_sdb bug
that was a reason why I added sdb_get_limit_str(), so if db support another limit clause (as oracle ROWNUM) then you can just add it there... Using libsdb is anyway a bad idea, because libsdb doesn't support persistent db connections. And from my experience, I know that opening a db connection take more time as sql statement itself. yep, this should be stated as notice into the user's guide. Using libsdb as a DLR repository should be the first try or low throughput solution. When facing a high-load system, then users should move to an other option, mainly Oracle or MySQL. SQLite may also me an alternative. I have the dbpool already for this, but yet not the DLR stuff. Heh, in order to find this unique key you must make select statement anyway. Later if you have found a appropriate row, yes we should do it. But if you speek about performance, then first what we should do (imo): get rid of libsdb support and add native db support for db's we want... Rory, this is valid in case you have several msg/sec. on traffic. Anyway Rory uses PostgreSQL, and we don't have native support for it. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[FYI] log of IRC #kannel session
Hi list, thanks a lot for the people who participated in the Friday IRC meeting. A transcript/log of the session can be found for review at: http://www.kannel.org/irc-sessions/ Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Kannel and Radius ?
I would like to know how select the incomming call with kannel. I imagine to install OpenRadius to select them, but i would like to know if an another solution is possible ? Kannel can act as RADIUS Accounting packet proxy for MSISDN provisioning of caller IDs to the HTTP server for WAP traffic. Which means, you *NEED* a NAS (either CSD dial-in via PPP, or GPRS APN) and configure that to use Kannel's wapbox as RADIUS acct server. Kannel will hence maintain mapping tables of client IPs and MSISDNs and forward all packets to the original RADIUS server (GNU radius in our case). See chapter 5 of the user's guide for the MSISDN provisioning conecpts. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [CFP] IRC session at 4pm (!!) *NOT* 2pm
sorry for the confussion. We wanted to have it a bit latter, so people can have their regular tasks handled first before moving to the IRC session. So the time is 4pm. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [CFP] IRC session at 2pm
Andreas Fink schrieb: Please announce such things at least 48 hours before! I read this one minute before it happens... so is it now 14:00 CET or 16:00 CET? ist is 4pm CET which is 16:00 CET. I *did* announce it in the last IRC session on friday which is more than 48 hours ago ;p Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
[FYI] Kannel reference
Hi list, just to let you know, a reference I found while googling: Open source wireless tools emerge http://www-106.ibm.com/developerworks/library/wi-p2papps.html For those who are interested. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: please guide
[EMAIL PROTECTED] wrote: Can any one guide me how to use this sms gateway on windows NT server. I suggest you have a look into http://www.kannel.3glab.org/download/kannel-userguide-snapshot/userguide.html which doesn't care on which platform you run. For WinNT you can go either with Cygwin 1.x as based OS and install Kannel from sources out-of-the-box. If you don't have UNIX/POSIX know-how, then please get yourself a dessent UNIX guru, but avoid questions on these topics in this forum. Thanks. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
