TRAI SMS Regulations – An Optimist’s Solution

[A possible solution for the SMS mess that TRAI created. Cross posted from Raghuram K B’s Blog. Discussion invited! ]

Much has been blogged about whether TRAI did the right thing in handling the spams on phone. For most people it is a welcome move but many are confused.

As TRAI has defined 7 categories, you can either choose to opt in for a category or opt out of all messages in that category. TRAI should have made the subscription, not by category, but by the sender which would be a win-win situation for businesses as well as consumers. TRAI, instead of solving the problem, has introduced limit to the flow of information.

Rather than criticizing TRAI over its short-sighted measure, let us envision a simple and holistic solution.

Firstly, the masks should be unique. As a business, you have to define a mask and share it with your customers, who will in turn decide whether to opt in or not. The details of the masks and subscription have to be maintained by TRAI.

Following is an illustration for a website that has registered for the keyword ‘DEALS’ and how customers can subscribe to it. Remember keyword ‘DEALS’ is unique to this business/website and cannot be used by anybody else.

This simple solution would be beneficial to customers since they can choose from whom they would like to receive messages. Every SMS sent has to pass through NCPR, and only if registered, it should be delivered to the customer. This way, TRAI need not keep adding exceptions to its list of businesses as it did by publishing amendment to its law within 12 hours. This is going to be a continuous process as more and more businesses will be approaching TRAI to white-list them.

Though it is good to see that TRAI is serious in reducing the spam, it should have put more thought into its implementation. Anyways, I would be missing texts from all kinds of deals, hair and weight loss programs and all the coming-soon projects by top developers.


Beginning discussion from Pi Team:

Pratyush -The solution is OUT of scope of present implementation. There are other such solutions possible. There is also another fundamental – geeky flaw. Lets say TRAI says we have names till 6 chars – then number of options – = 26^6 + 26^5 … Most of these would be unusable e.g gtyyhg – so trai will sooon run out of such masks.

Naman – Nice. This might actually be a solution. It’s like each marketer has a channel registered with TRAI with permanent sender ID. Once this is implemented you can have 8 char IDs. Also then it will be a hot commodity like domain names. You use your TradeMark as sender ID. Pay a monthly fee to TRAI to retain the sender ID. While registering with SMS gateway, you share your certificate number for the that sender ID. Or share a unique token(like password) as an extra parameter till the msg reaches the operator, where the real scrubbing happens. Or the whole 11 char can be used as sender ID. TM / TD /TL etc.  operator code could be removed. If you allow only 8 chars also it is 26^8 = 208Bn . 26^6 is also 308Mn. Both are enough. Add numbers and symbol like “-” to it and it becomes 37^8 = 3.5Trillion. Even if 0.001% of that is usable it becomes 35Mn. It’s like 1 sender ID for each tax payer in India.
And even the unusable ones are better than random 6 digit codes that operators are using now.

Kunal Kant –  Just give you rough idea. Read Page 49 & 50 here from TRAI. I quote:
“The question of blocking by the service provider an unsolicited commercial communication sent by the telemarketer   to customer registered on NCPR was also discussed during the consultation process. Mixed views were expressed. While one set  of service providers have opined that filtering of calls and SMS may increase the load on the system and may be difficult to implement, others feel that technical solutions can be worked out to effectively block unsolicited commercial SMS.”
Second, all service provider need to provide telecom resource for handling complains, escalation, blocking & issuing service and lot more, which they are always short in allocation. Extra resource = increase in Opex. Hope this gives us some clarity.

What do you think? Is this a viable option given the technology overheads?

Leave a Reply