RE: [RFC] mcc and mnc
-Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Angel Fradejas wrote: Not true in multi-operator links. if your multi-operator incoming link tells you the original SMSC the message comes from (passing the %i) then youre back in business. If you implement mnc and mcc and the multi-operator link doesnt tell you this, you're back to square one, hence the original smsc name is as good as mnc and mcc. Better a practical (and simplified) example: you have only one link group = smsc smsc-id = custom_driver_whatever smsc = custom_type The protocol of this link tells you (in one way or another) the operator originating the MO. Your %i will be custom_driver_whatever. Hope this clarifies. yep, if you do receive messages from different networks over one link, which is what you think of, the %i only tells the sms-service that it has arrived from this smsc. In this case I suggest you're backend system should know the prefix of the MO message, hence your backend system has to figure out from which network the request is coming by parsing the prefix number value. Since the smsc_id in the MO is set by the driver, and this only applies to custom/proprietery or future drivers, I think that setting the smsc_id of the MO to something that represents the mcc/mnc will suffice (maybe a concatenation of their values), and is a good solution. Otherwise, adding another two members for msg-sms structure and allowing for options in the get/post/xmlrpc sms-service query to use them wouldn't be such a hurdle IMO - it won't be useful for most people, but there are other things there which aren't useful for most people, and still in Kannel. Adding these members will also allow to pass more message information into the module - for example, if you need to connect to an SMSC where you can set the MCC/MNC values in some fields independent of the UDH (just a speculation, haven't seem something which allows/requires that, but with all the XML messaging going on around, it's likely something like this will come up sooner or later). So my opinion is that if the implementation is clean - it will do no harm and potentioally can do good. just my € 0.02 -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. The C Programming Language -- A language which combines the flexibility of assembly language with the power of assembly language.
smsbox crashed
Hi All, smsbox crashed with the followong last entry in smsbox log file. I am using Kannel develepment release on Redhat 6.2 2002-06-04 16:30:27 [1] PANIC: gwlib/http.c:1535: port_put_request: Assertion `p!= NULL' failed. what should i DO. Also i want to purchase new hardware for machine. How much RAM would enough. I have decided to buy P3 Intel server board (Scsi built-in) regards CIPHER _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
(no subject)
Hi All, smsbox crashed with the followong last entry in smsbox log file. I am using Kannel develepment release on Redhat 6.2 2002-06-04 16:30:27 [1] PANIC: gwlib/http.c:1535: port_put_request: Assertion `p!= NULL' failed. what should i DO. Also i want to purchase new hardware for machine. How much RAM would enough. I have decided to buy P3 Intel server board (Scsi built-in) regards CIPHER _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
RE: [RFC] mcc and mnc
Since the smsc_id in the MO is set by the driver, and this only applies to custom/proprietery or future drivers, I think that setting the smsc_id of the MO to something that represents the mcc/mnc will suffice (maybe a concatenation of their values), and is a good solution. Yes Oded, that was an option I evaluated too. But then you have all of your routing rules (allowed-smsc-id, preferred-smsc-id, denied-smsc-id) invalidated (as MO smsc_id is copied to MT), or extremely bloated (you would have to declare every mcc-mnc combination) or you would have to mess around later in the application handling the MO to output a X-Kannel-SMSC header to correct it. So my opinion is that if the implementation is clean - it will do no harm and potentioally can do good. Thx, Oded. Angel Fradejas Mediafusin Espa a, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08
RE: [RFC] mcc and mnc
In this case I suggest you're backend system should know the prefix of the MO message, hence your backend system has to figure out from which network the request is coming by parsing the prefix number value. Yes Stipe, but this is mainly guessing, because of mobile number portability. Here in Spain it is not a big problem (about 1% of numbers) but I think in Germany this percentage is bigger (please, correct me if I'm wrong). If you are absolutely sure in the entry point of the MO (kannel) of what is the mobile operator, why guess later? Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08
Re: smsbox crashed
Cipher Strength kirjoittaa tiistaina, 4. kesäkuuta 2002, kello 10:31: smsbox crashed with the followong last entry in smsbox log file. I am using Kannel develepment release on Redhat 6.2 2002-06-04 16:30:27 [1] PANIC: gwlib/http.c:1535: port_put_request: Assertion `p!= NULL' failed. what should i DO. Sending smsbox and bearerbox logs is useful ;) In addition, more data about the message causing the crash (there are unhandled NULL pointer here, and one must know first, is the assertion itself necessary) Also i want to purchase new hardware for machine. How much RAM would enough. I have decided to buy P3 Intel server board (Scsi built-in) 400 - 500 M would certainly be enough. Kannel should not let long queues happen in the first place. Aarno
RE: EMI: Serious Problem PANIC: Too many concurrent allocations
Kannel currently has configuration variable maximum-queue-length. See user- guide for details. Yes, but when this is triggered bb_smscconn_receive () logs the event and returns -1. All the SMSC drivers except HTTP ignore the return code from bb_smscconn_receive (). Therefore, the message is silently dropped from the application and the SMSC point of view. This is IMHO a bad thing and not something you could use in a production environment. I think a better solution would be to; * When possible, map the queue full event to an SMSC protocol error indicating a temporary resource shortage; otherwise fail the message with the most appropriate error code. * Introduce a flow control admin. message to tell the SMS box (and any other clients using the SMS box interface) to stop/start sending messages. The SMS box could in turn signal to the various sendsms applications that a temporary resource shortage event has occurred (HTTP 503 maybe ?) * Use high and low watermark variables instead of maximum-queue-length. This prevents thrashing around the maximum-queue-length value. A sort of SMS hysteresis curve :-).
[PATCH] simple patch to make gcc 3.1 not complain so much.
Hi list. When compiling under gcc 3.1, the compiler complain about discarding qulifiers when passing __func__ to mutex_un/lock_real and unlock_out/in_real - apparently under gcc 3.1, __func__ is declared as const char* (why not under 2.96 too?). simply changing the decleration of the relevant functions (which don't modify *func anyway) made gcc happy. can we get 1.2.0 out and only then apply this patch, please ? -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. if you evaluate C++, you still get C, but C gets bigger -- Erik Naggum
Re: few Kannel daemons on the same server
Has someone encountered problems whilte trying to run more than one kannel daemons on the same machine ? Is there any limit on the numbers accroding to Kannel ? No real limits. just have to make sure you dont run into any conflicts like same logfile name or same tcp port etc. On the other hand, there's no real reason to run multiple ones as you can combine the function of multiple ones into one. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
RE: few Kannel daemons on the same server
Avner, I have a few simultaneous kannel daemons running in the same box. The only problem I had (at the beginning) was a port conflict because of a misconfiguration: In the core group I had the line wdp-interface-name=*. This makes the bearerbox to listen on the standard wap ports. If you have more than one bearerbox with this line you will have problems. Hope this helps. Erick -Original Message- From: Andreas Fink [mailto:[EMAIL PROTECTED]] Sent: martes, 04 de junio de 2002 9:54 To: Avner Sternheim Cc: [EMAIL PROTECTED] Subject: Re: few Kannel daemons on the same server Has someone encountered problems whilte trying to run more than one kannel daemons on the same machine ? Is there any limit on the numbers accroding to Kannel ? No real limits. just have to make sure you dont run into any conflicts like same logfile name or same tcp port etc. On the other hand, there's no real reason to run multiple ones as you can combine the function of multiple ones into one. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
%b parameter question
Hi all, I've encountered a problem while using %b parameter in the SMS-service section in the configuration file, while using this option I can't redirect the message to different URL, since the Kannel can't read the the keyword (the first word in the message) that according to it the Kannel redirect the message. Is there a known fix ? workaround ? another paramter ? Regards Avner Sternheim P.S. I need the %b since I get data messages in GET mode -Original Message- From: Andreas Fink [SMTP:[EMAIL PROTECTED]] Sent: â 04 éåðé 2002 17:54 To: Avner Sternheim Cc: [EMAIL PROTECTED] Subject: Re: few Kannel daemons on the same server Has someone encountered problems whilte trying to run more than one kannel daemons on the same machine ? Is there any limit on the numbers accroding to Kannel ? No real limits. just have to make sure you dont run into any conflicts like same logfile name or same tcp port etc. On the other hand, there's no real reason to run multiple ones as you can combine the function of multiple ones into one. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Bind Tranceiver implementation.
Hello guys: I would like to know yours opinion about implementing connections with bind tranceiver towards the ESME. Most of products based in SMPP, uses Bind Transmitter and Bind Receiver to send and to receive SMS from the ESMEs.Kannel even does this. Are there reason to implement the Bind Tranceiver is these solutions? I was trying modify smpp pdu from kannel for use Bind Tranceiver, but i don't know where the PDU structure is located and how can affect this modification to bearer box o smsbox. Thanks for your help. Regards Gustavo Sepulveda _ Únase con MSN Hotmail al servicio de correo electrónico más grande del mundo. http://www.hotmail.com
RE: Bind Tranceiver implementation.
Bind transceiver is supported directly by cvs version of kannel. Just use transceiver-mode = yes and unset receive-port on your smpp config. Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Gustavo Sepulveda Enviado el: martes 4 de junio de 2002 19:26 Para: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Asunto: Bind Tranceiver implementation. Hello guys: I would like to know yours opinion about implementing connections with bind tranceiver towards the ESME. Most of products based in SMPP, uses Bind Transmitter and Bind Receiver to send and to receive SMS from the ESMEs.Kannel even does this. Are there reason to implement the Bind Tranceiver is these solutions? I was trying modify smpp pdu from kannel for use Bind Tranceiver, but i don't know where the PDU structure is located and how can affect this modification to bearer box o smsbox. Thanks for your help. Regards Gustavo Sepulveda _ Únase con MSN Hotmail al servicio de correo electrónico más grande del mundo. http://www.hotmail.com
[REPOST] emi2 MO timestamps (was: bug with date_convert_universal() )
Andreas Fink wrote: this is definitively the case. The EMI timestamps are also is inLOCAL TIME, not GMT The current code asumes GMT timestamps from the SMS-C and this is not the case (at least with the providers I connect). Does anybody need the current behaviour? Or can we fix it? Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08
few Kannel daemons on the same server
Has someone encountered problems whilte trying to run more than one kannel daemons on the same machine ? Is there any limit on the numbers accroding to Kannel ? Regards Avner Sternheim
Re: [REPOST] emi2 MO timestamps (was: bug withdate_convert_universal() )
Hi Angel, I am not farmiliar with the emi2 code but have noticed that that kannel can be configured to run in GMT or localtime. My logs where printing GMT which is confusing - someone from the list pointed out that you can compile and enable localtime (./configure --enable-localtime ). You might like to try this. Cheers, Alan ps. I don't see this as a problem with kannel although it makes having a binary download less useful. As a result I _have to_ compile from source - the debian 1.1.5 package exhibits this problem too - I have notified the maintainer. I guess it just ends up being extra work for distro maintainers to ensure that kannel packages comply with defacto standards, etc. On Wed, 2002-06-05 at 06:19, Angel Fradejas wrote: Andreas Fink wrote: this is definitively the case. The EMI timestamps are also is in LOCAL TIME, not GMT The current code asumes GMT timestamps from the SMS-C and this is not the case (at least with the providers I connect). Does anybody need the current behaviour? Or can we fix it? Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -- Alan McNatty -- Catalyst IT Ltd -- http://www.catalyst.net.nz Level 2, 150-154 Willis St, PO Box 11-053, Wellington, NZ Mob: +64 21-312136, DDI: +64 4 9167203, Office: +64 4 4992267 ... error accessing whit Segmentation fault (core dumped)
Re: [PATCH] simple patch to make gcc 3.1 not complain so much.
Oded Arbel wrote: Hi list. When compiling under gcc 3.1, the compiler complain about discarding qulifiers when passing __func__ to mutex_un/lock_real and unlock_out/in_real - apparently under gcc 3.1, __func__ is declared as const char* (why not under 2.96 too?). simply changing the decleration of the relevant functions (which don't modify *func anyway) made gcc happy. can we get 1.2.0 out and only then apply this patch, please ? hmm, what patch, none attached ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
