[asterisk-users] Prevent multiple sip registrations

[Anselm Martin Hoffmeister]

Am Dienstag, den 11.09.2007, 19:09 +0500 schrieb Rizwan Hisham:
> The whole point of doing this is because if the user gives away his
> username/password to his friends or relative and allows them to use
> his account, that way we r gona have a lot more traffic in our
> asterisk server.
> Also we charge our users a fix amount of money every month for their
> account so if any user gives out his username and password then his
> account is more likely to do 2 to 3 times the calls as compared to aan
> account which is used by only one user. So ultimately we lose money. 

Dear Rizwan,

imagine one of your customers uses asterisk. His asterisk server
registers to your server, and he manages his own local dialplan to have
250 SIP devices using the one SIP account. (I think Asterisk can be told
to send a UserAgent ID other than the default "Asterisk whatever" - you
will not easily find out *reliably* wether someone is an Asterisk user
or not)

Are you screwed? Well, probably. You cannot outsmart some people if you
give them the liberty to play tricks on you.

If you want to go secure, buy the hardware they are going to use,
register all the SIP stuff into that hardware and make sure it cannot be
read-out easily (most SIP phones will not allow to read the password
that was previously entered, although some web-interfaces still contain
the old password in the HTML page source).

Your customers will hate you...

My personal approach would be to not bother with registrations but log
the IP addresses from which their phones register. If - over a busy
telephone day - the log shows a pattern like

123.45.67.89 - 11:15h
131.66.14.56 - 11:27h
123.45.67.89 - 11:58h
131.66.14.56 - 12:44h
123.45.67.89 - 14:05h
131.66.14.56 - 14:09h
123.45.67.89 - 14:32h

then you could still call the user and tell him to buy another account -
your contracts probably explicitely restrict usage to a single person,
right?

Even more, your contracts _could_ contain clauses like "for private
users only", and the option for immediate termination on your part if
any doubts on that arise (users tend to hate those statements as well).

Anyone having more than 400 outgoing minutes in more than 50 calls
(insert other numbers to your liking) on a day, or more than 7000
outgoing hours in more than 1000 calls in a month might attract your
special attention. You could have some log analysis to find power users.

Just an idea popping up: AFAIK you _can_ restrict asterisk SIP easily to
not more than one concurrent call for any account - and you probably
should with your business model. How about, once they trigger a certain
number of minutes threshold on their account (perhaps 2000 minutes
during the last 7*24 hours), preceding any outgoing call they make with
a short announcement like "*bling* your_telco_name Please be aware this
account is for private use only. Call customer service to get more
information *blong*"? At least this would sever re-selling of your
services - and legitimate users would in 99.99% of cases never hear that
announcement.

I know some SIP providers always send out CALLERID, not to be
suppressed, so those flat tarrifs are also less interesting for resale.
Some customers (like me) prefer being able to set that CALLERID, on the
other hand. And I surely do not abuse the tariffs I contracted for.

Whatever your system looks like in the end, that would of course be
interesting to me. On the other hand I can only advise you to not
publish the exact numbers, triggers and restrictions - for obvious
reasons.

Finally it all boils down to "you offer a flat fee, you suffer". Try to
attract customers that use less minutes than you calculated your tariff
for. Try make it attractive for the use it is intended for, and less
attractive for (irregular) power-users, re-sellers or call-center-like
businesses. Try to not irritate your users by unpopular, stupid
restrictions. If the world were just a better place, sometimes...

Just my 3 pence,

Anselm (just being returned from holidays in Kent, still in relaxed
mode)