Re: Interface to bearerbox

Hi,

Therefore I believe you have your answer. As Andreas says, in many countries in Europe and the US, it is illegal to "wiretap" the content of your clients. In other countries, like India, as you say, you are supposed to. If that code was introduced in kannel, even if configurable, it could create a lashback and possibly legal problems to operators using kannel in Europe. 

I feel that the best way would be an external application/process that could be introduced in the flow and would be implemented only when required. However, I don't know how difficult it is. For MTs you would have to support HTTP & SMMP (examples for the latter you can find in test/drive_smpp.c). But for MOs you would have to implement pretty much most of the smscs, if you plan to do something more than simple dropping. Or use the smsc-reroute option to route it to your application and reintroduce it later on.

BR,
Nikos
  ----- Original Message ----- 
  From: Sreekanth GS 
  To: Andreas Fink 
  Cc: [email protected] 
  Sent: Thursday, November 19, 2009 9:58 AM
  Subject: Re: Interface to bearerbox


  Hello Andreas,

  1. A2P messaging does not come under privacy of information. Hence, it is legal for us to track each and every A2P messages.

  2. Neither operator nor sender takes responsibility for spam in the court of law, and the only liable person is the channel provider, that is us.

  3. We can only disconnect the client from sending further messages, and can file a suit against that person for sending spam, however, TRAI, the govt. body in our country strictly wants all vendors to enforce spam prevention mechanisms, to identify and reject spams. So spam is indeed defined by us and TRAI.

  4. The sending customer puts in an ALPHA sender ID, and hence cannot be tracked as originator. Hence, all complaints finally has us as land point.

  5. Network congestion occurs, and queues build up. We often need to prevent certain messages from getting delivered late hours, but send them next day.

  We have assembled an 8 member team to start working on the project.

  Regards,
  Sreekanth



  On Thu, Nov 19, 2009 at 12:31 PM, Andreas Fink <[email protected]> wrote:

    there's an additional issue here.
    how to define "spam".
    in my case, the customer who sends the message is the originator. He is liable for any spam complaints. However I can not filter messages away because what I see as "spam" he might not see as spam and the receiver neither. The receiver might have agreed to receive advertisement messages from the sender.Β 


    The second issue is that we are not allowed to look at the content. Privacy laws are very strict. Telecommunications Β are covered under privacy. You can not wiretap your customers phone line neither.


    The third issue is the customer pays you money to deliver the messages. So you are obliged to deliver them.


    Normally what we see is that operators put pretty clear rules into their contracts. If you get complaints from the receivers, you can simply hold the sender liable. In other words, Β "not your problem".


    On 19.11.2009, at 06:43, Alejandro Guerrieri wrote:


      smppbox has a plugin mechanism you could hook into. That would be the most elegant approach imho. Check the examples, there's a C plugin showing how to do it.


      Regards,

      --
      Alejandro Guerrieri
      [email protected]






      On 19/11/2009, at 4:23, Sreekanth GS wrote:


        Hello Nikos,

        1. The SMPP Connection is not used by a single client, he re-distributes it to n levels. So the source of spam may not be from the direct client. In countries like ours [India], there is no spam filtration from the operator, and we are directly connected to the operator. So, above us, no spam filtration works.

        2. We transmit around 1-1.5 million messages a day, in a 16 hour window, and hence we badly need the spam filtration mechanism, and it is not viable for us to reject messages assuming spam, and we can only hold, verify and then release to the SMSC.

        3. Even if a message is caught as spam, and rejected, we need to acknowledge back that it was rejected due to spam. I really dont think a firewall would be above to send back that rejected PDU information, rather than dropping the packets.

        Regards,
        Sreekanth


        2009/11/19 Nikos Balkanas <[email protected]>

          Hi,

          I will have to agree with Alvaro. Data mining, fraud, illegal and spam messages are a can of worms that if kannel ever gets into, there is no way out, with all legal ramifications. Not to mention a performance killer. Plus a modular front end filtering would be much more flexible and customizable.

          For the smppbox interface I would like to stress 2 things:

          1) The average spammer or drug dealer won't use an SMPP connection to send their messages. Upstream ESMEs will take responsibility for filtering them.
          2) An intelligent firewall could be used, one that would block all offensive packages, based on content.

          BR,
          Nikos

          ----- Original Message ----- From: <[email protected]>
          To: "Alvaro Cornejo" <[email protected]>
          Cc: <[email protected]>
          Sent: Thursday, November 19, 2009 2:41 AM

          Subject: Re: Interface to bearerbox



            Hello Alvaro,

            Indeed the same would suffice for kannel, but when the it comes to usage with smppbox, I personally don't think it is enough for that is our experience.

            Regards,
            Sreekanth
            Sent from BlackBerryΒ® on Airtel

            -----Original Message-----
            From: Alvaro Cornejo <[email protected]>
            Date: Wed, 18 Nov 2009 18:55:44
            To: Sreekanth GS<[email protected]>
            Cc: <[email protected]>
            Subject: Re: Interface to bearerbox

            Hi

            Kannel is a backend or a gateway for sending/receiving messages.
            Kannel is designed to handle huge amount of SMS traffic transparently
            to/from any external application, so you donΞ„t need to handle all kind
            of protocol issues.

            All you said is usually done through an external application of your
            own, with whom you can do all filtering/billing/features you
            need/want/desire.

            You do not need to patch / modify kannel for do what you want. Just
            with your own frontend will suffice.

            Regards

            Alvaro

            On Wed, Nov 18, 2009 at 6:27 PM, Sreekanth GS <[email protected]> wrote:

              Hello All,

              We are presently engaged in using kannel as our SMPP Client, and for the
              backend of smppbox. However, the interfacing to bearerboxes has been quite
              inadequate for us.

              Hence, we plan to develop a viable interface to bearerbox that will/can:

              1. Accept connections from smppbox, smsbox, sqlbox etc.
              2. Log received MSG structs to a db pool.
              3. Select specific messages from db pool using regex.
              4. Transmit selected messages in (3) to bearerbox.

              Similarly, catch MO/DLR returned by bearerbox.
              1. Select specific messages from db MO/DLR pool using regex.
              2. Send back the same to smppbox, smsbox, sqlbox etc.

              Why all this?

              smppbox transmits messages directly to bearerbox.
              -> There is no hold and transmit scenario.
              -> Manual approval of messages is not possible (in case of spam threats).
              -> In between prioritizing of messages is not possible.
              -> Manual modification of data is impossible, only automates is possible
              using plugins.
              -> Reject messages, hold messages (in case of queues at off-times/night) for
              a duration is impossible
              -> There is no flexible control over the messages.

              How to proceed:
              1. Accept connections from other boxes.
              2. Communicate with other boxes.
              3. Store and retrieve data to and from db pool.
              4. Communicate with bearerbox.

              Hoping to see some helping hands,

              Regards,
              Sreekanth





            -- 
            |-----------------------------------------------------------------------------------------------------------------|

            EnvΞ½e y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
            celular y Nextel
            en el PerΟ, MΞΉxico y en mas de 180 paises. Use aplicaciones 2 vias via

            SMS y GPRS online
            Β  Β  Β  Β  Β  Β  Visitenos en www.perusms.NET www.smsglobal.com.mx y
            www.pravcom.com







        -- 
        Regards
        Sreekanth G S
        Chief Technology Officer
        +91.9249522046

        TNGiCUBE Technology Resources (I) PVT LTD
        B-29, Krishna,
        Althara Nagar
        Sasthamangalam P.O.
        Trivandrum 10

        Tel +91-9961412227
        +91-9947033004
        +91-471-3056763


        The information contained in this email is private & confidential. It is intended only for the use of the person(s) named. If you are not the intended recipient, you are notified that any dissemination or copying of this communication is prohibited and kindly requested to notify the sender and then to delete the message. TNGiCUBE gives no representation or guarantee with respect to the integrity of any emails or attached files and the recipient should check the integrity of and scan this email and any attached files for viruses prior to opening.








  -- 
  Regards
  Sreekanth G S
  Chief Technology Officer
  +91.9249522046

  TNGiCUBE Technology Resources (I) PVT LTD
  B-29, Krishna,
  Althara Nagar
  Sasthamangalam P.O.
  Trivandrum 10

  Tel +91-9961412227
  +91-9947033004
  +91-471-3056763


  The information contained in this email is private & confidential. It is intended only for the use of the person(s) named. If you are not the intended recipient, you are notified that any dissemination or copying of this communication is prohibited and kindly requested to notify the sender and then to delete the message. TNGiCUBE gives no representation or guarantee with respect to the integrity of any emails or attached files and the recipient should check the integrity of and scan this email and any attached files for viruses prior to opening.