Re: [RFC] mcc and mnc
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. 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
[BUG] Kannel crashes on bad SMPP data
Hi Kannel people, here's a rarely occurring but fatal bug I found from 1.1.6 in a hard way: SMPP SMSC driver (for example function) does not check lengths of any fields when setting values to Msg struct _but_ assert in function smpp_pdu_pack in gw/smpp_pdu.c fails, if null-terminated string fields are over-lengthed. You can reproduce this by sending request from Kannel to your application and returning forced sender number that is more than 20 digits long. While there shouldn't exist real phone numbers that long, it's enough to have proper bug in other parts of the system feeding bad data to Kannel and it dies. I consider this as a bad thing. -- Jari Juslin, Development Team Leader MatchEm Ltd [EMAIL PROTECTED]http://www.matchem.com/ Mob. +358-44-380 0012 fax: +358-9-644 091
RE: [RFC] mcc and mnc
>>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. Angel Fradejas Mediafusion Espana, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08
RE: [RFC] mcc and mnc
> >Angel, what you want to do is to allow to forward mcc and mnc values >>that have to be entered by the system admin by hand to each smsc >>group, which means Kannel is only storing and forwarding still >>statical information. This blows only unnecessary the code of Kannel >>up. >> >>You can distunguish in each called sms-service from which smsc group >>the request came in, hence your backend system should deal with the >>translation from smsc-id to mnc, mcc pairs IMO. > >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. -- 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: [RFC] mcc and mnc
>Angel, what you want to do is to allow to forward mcc and mnc values >that have to be entered by the system admin by hand to each smsc >group, which means Kannel is only storing and forwarding still >statical information. This blows only unnecessary the code of Kannel >up. > >You can distunguish in each called sms-service from which smsc group >the request came in, hence your backend system should deal with the >translation from smsc-id to mnc, mcc pairs IMO. Not true in multi-operator links. This is mainly the kind of situation I was triyng to deal with. As I said before, fixed directives for direct operator links, copying theses attributes to msg->sms.mcc/mnc members. And then, if a link deals with several mcc and mncs, the driver could get (if possible) the values from the provider and set them in msg->sms.* I'm doing it with success. And I see no reason to think I'm a extremely rare case if SMS bussiness. (Btw, the solution of having one sms-service for each service/operator combination is simply impractical. We have as much as 5000+ services - we are a content developer and provider - so figure yourself). We have a working and practical kannel for a small number of services and smscs. Let's work towards a practical kannel for a huge number of them. (note when I say "let's work" I mean "i would contribute my working solution if anybody is interested"). 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: [RFC] mcc and mnc
Andreas Fink wrote: > > You can do that by adding &mnc=xxx&mcc=yyy inside the service > definition passing those values as a constant string. So you would > have an entry for every logo cgi for every SMSC connection. Or you > could simply use the %i which is the smsc name. Kannel has no way of > knowing which MNC and MCC goes with which SMSC so the smsc name is > as good as anything else. yep, Andreas is right here, from my point of view. Angel, what you want to do is to allow to forward mcc and mnc values that have to be entered by the system admin by hand to each smsc group, which means Kannel is only storing and forwarding still statical information. This blows only unnecessary the code of Kannel up. You can distunguish in each called sms-service from which smsc group the request came in, hence your backend system should deal with the translation from smsc-id to mnc, mcc pairs IMO. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: [RFC] mcc and mnc
Title: RE: [RFC] mcc and mnc smsc-id is almost as good, but not completely. mcc and mnc are normalized values, and when you have for example 20 connections to the same operator (as I do, one emi2 link for each short code), if you use smsc-id you'll have to translate this value in every application behind kannel, wich is error prone. Well frankly I dont think it makes sense to do it in kannel but simple mechanisms can be used in your app like a SMSC naming scheme "provider-shortid". I know kannel doesn't have a way to know mcc and mnc, that's why i suggest smsc directives. Frankly what will you do if you have an SMSC which deals with multiple MNC and MCCs? But for extensibility (i mean custom drivers) it would be a good thing: for example, a custom NetSize driver we have developed, gets mcc and mnc information directly from the provider, as you can have any mcc and mnc through this link. In this situation, neither using %i or appendind &mcc=xx&mnc=xx would work. in this situation kannel will simply not know it and even a directive wouldnt work. -- 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: [RFC] mcc and mnc
Title: Re: [RFC] mcc and mnc smsc-id is almost as good, but not completely. mcc and mnc are normalized values, and when you have for example 20 connections to the same operator (as I do, one emi2 link for each short code), if you use smsc-id you'll have to translate this value in every application behind kannel, wich is error prone. I know kannel doesn't have a way to know mcc and mnc, that's why i suggest smsc directives. But for extensibility (i mean custom drivers) it would be a good thing: for example, a custom NetSize driver we have developed, gets mcc and mnc information directly from the provider, as you can have any mcc and mnc through this link. In this situation, neither using %i or appendind &mcc=xx&mnc=xx would work. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 -Mensaje original-De: Andreas Fink [mailto:[EMAIL PROTECTED]]Enviado el: lunes 3 de junio de 2002 19:00Para: Angel FradejasCC: [EMAIL PROTECTED]Asunto: Re: [RFC] mcc and mnc A question for all developers, What do you think about having kannel pass mnc and mcc information to applications? Sometimes applications need to know the operator for the incoming MO (a logo download application being the typical example), and kannel is the closer element to the operator (and so the most reliable point to declare this info, so you have not to guess based on the mobile number). You can do that by adding &mnc=xxx&mcc=yyy inside the service definition passing those values as a constant string. So you would have an entry for every logo cgi for every SMSC connection. Or you could simply use the %i which is the smsc name. Kannel has no way of knowing which MNC and MCC goes with which SMSC so the smsc name is as good as anything else. -- Andreas FinkFink-Consulting--Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, SwitzerlandE-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com--Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: [RFC] mcc and mnc
Title: Re: [RFC] mcc and mnc A question for all developers, What do you think about having kannel pass mnc and mcc information to applications? Sometimes applications need to know the operator for the incoming MO (a logo download application being the typical example), and kannel is the closer element to the operator (and so the most reliable point to declare this info, so you have not to guess based on the mobile number). You can do that by adding &mnc=xxx&mcc=yyy inside the service definition passing those values as a constant string. So you would have an entry for every logo cgi for every SMSC connection. Or you could simply use the %i which is the smsc name. Kannel has no way of knowing which MNC and MCC goes with which SMSC so the smsc name is as good as anything else. -- 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
[RFC] mcc and mnc
A question for all developers, What do you think about having kannel pass mnc and mcc information to applications? Sometimes applications need to know the operator for the incoming MO (a logo download application being the typical example), and kannel is the closer element to the operator (and so the most reliable point to declare this info, so you have not to guess based on the mobile number). So we could have mcc=xx and mcc=xx directives in every sms-c (for direct operator connections), or in the case you have a multi-operator link (a NetSize o MobileWay one for example), we could give the driver the chance to set those attributes in msg->sms.mcc and msg->sms.mnc members, if possible. Maybe I am missing something obvious, but this is a thing I have implemented and find extremely useful. Comments? Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08
Re: [RFC] timeline for stable 1.2.0
Oded Arbel wrote: > > comes to think about it - it's stupid of me to submit the whole huge patch and ask >for special treatment of just one part. > Please ignore my previous email and commit the following patch, which only deals >with the memory bugs, to the CVS before doing 1.2.0 applied to cvs, thanks Oded! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Delivery report
Hi, I use version 1.1.3, emi2 configuration and I have a problem with delivery reports. I suppose to receive messages on 8155 port (my side) and connect to smsc on 5005 port. First try was to set our-port=9155 and idle-timeout = 60. In this case, if the dlr arrives in 1 minute (the mobile is connected to the network) i receive it. The strange thins is that i receive the dlr on the port I am connected to SMSC for sending messages (9155). The emi msg I send does not contain the field for notification address (supposed to be my ip+receiving port - in my case 8155). If missing,the SMSC acts this way : it sends the dlr to address+port the original message is send (ip+9155). So, after 1 minute my connection (if idle) with SMSC is closed, so i do not receive the dlr. If I don`t set an our-port parameter on configuration file, when i send an sms, bearer connects to smsc from a port that is free (not a fixed one , like 9155). But in this case I don`t receive dlr. How can I configure kannel to fill the notification address when i send a message with delivery request? Felly
Re: MMS
shaan j kirjoittaa maanantaina, 3. kesäkuuta 2002, kello 08:32:Hi List, > > I have following querries: > > 1). Can I use Kannel for testing my MMS applications ? > > 2). If yes, which version should I use ? Should I wait for the stable > release 1.2.0 ? > > 3). What all is required to set up such an environment ? > > 4). Has anybody tested MMS applications with Kannel ? I will start (after some bug corrections) work on this. I mean, making Kannel PPG and WAP gateway able to work with MMS centers. It is nice ti have testers ;) I think 1.2.0 will happen very soon, and without MMS support (there is vote on it now). Aarno
Re: [BUG] EMI2 crashing.
Oded Arbel kirjoittaa maanantaina, 3. kesäkuuta 2002, kello 10:04:Attached is a patch for octstr.c to make sure that even if null is submitted for an Octstr, nothing will break. > Applying it is really a philosophical question : does NULL is a valid > Octstr* value ? the code is confusing about it : some functions choke > when fed a NULL pointer, while others return with no error (w/o doing > anything useful either, but that is to be expected when you're handed a > NULL pointer). Some modules use NULL Octstr for "this variable has no value", and handle NULL using this semantics. For others, it is plain error. But I think they should handle NULL, too, for robustness. Aarno
Re: EMI: Serious Problem PANIC: Too many concurrent allocations
Kalle Marjola kirjoittaa maanantaina, 3. kesäkuuta 2002, kello 10:37:On Sat, 1 Jun 2002, Jari Juslin wrote: > >> So, panic to "Too many concurrent allocations" can happen if a) Kannel >> just has so high load, that is needs huge amounts of memory or b) if >> Kannel leaks too much memory. Am I right? > > Yes. The reason a) is encountered when incoming traffic is faster than > the > outgoign handle (namely SMS centers) and usually results in that > 'too many concurrent allocations'. This can be avoided by increasing the > size of the checking malloc buffers, but if things keep going like that > it > will eventually panic. Moreover, store files of several megabytes is > more > than a problem. This entire thing should be fixed so that more priority > is > given to outgoing messages, i.e. just make it impossible to grow queues > inside Kannel - just make the queues to build up into sockets/other > programs. Of course this is far from trivial with some SMS centers. Kannel currently has configuration variable maximum-queue-length. See user- guide for details. Aarno
Re: EMI: Serious Problem PANIC: Too many concurrent allocations
On Sat, 1 Jun 2002, Jari Juslin wrote: > So, panic to "Too many concurrent allocations" can happen if a) Kannel > just has so high load, that is needs huge amounts of memory or b) if > Kannel leaks too much memory. Am I right? Yes. The reason a) is encountered when incoming traffic is faster than the outgoign handle (namely SMS centers) and usually results in that 'too many concurrent allocations'. This can be avoided by increasing the size of the checking malloc buffers, but if things keep going like that it will eventually panic. Moreover, store files of several megabytes is more than a problem. This entire thing should be fixed so that more priority is given to outgoing messages, i.e. just make it impossible to grow queues inside Kannel - just make the queues to build up into sockets/other programs. Of course this is far from trivial with some SMS centers. -- &kalle marjola
