Disabling free accounts - Not the way to go IMO

[ydgmdlu]

Wait a minute... There are almost THREE THOUSAND users with a SIP device registered? I'm sorry, but that's just an amazing number. And the cost of the server is $2500 per year? So how's this for an idea: Disable free service for ALL current users. Charge everyone $10 per year to use the service. I don't see how anyone can really complain. That's less than $1 per month. Anybody can scrape together $10, easily. It just means one less meal at a restaurant, per year.

I became an SS user last week. I had to pay about $32 on eBay through Buy It Now. Some auctions have gone well over $40. SS is clearly a service that's in relatively high demand, and people will pay quite a bit just to use it. Assuming an annual fee of $10, then what I paid upfront would cover over three years of service. Three years is a long time. I would definitely have rather paid less upfront and had the option to renew every year.

At $10 per year, you'd be receiving almost $30,000 annually. Not only would that be a nice profit for you, but you could also grow the service, make it more robust and sustainable for more active users. I can't see any downsides to this. Anyone who's unwilling to pay the $10 probably doesn't need the service very badly anyway. (Of course, there is no other service quite like SS right now.)

[MikeTelis]

This idea is not new. Read Aaron's reply on the 2nd page.

[hmmwhatsthisdo]

I never ended up getting a response. Is there a certain part of SS that takes up most of the bandwidth?

[Aaron]

I never ended up getting a response. Is there a certain part of SS that takes up most of the bandwidth?

What didn't you get a response to? There's been a bit of jumping around on this thread .

As to the part of sipsorcery that takes up the most bandwidth it's not really that relevant as bandwidth isn't an issue. Because sipsorcery only deals with the SIP traffic and not the audio the bandwidth requirements are small. The issue is CPU utilisation and the two agents that produce most of the load are the Registration Agent, which does the periodic registrations to 3rd part SIP providers, and the Registrar, which handles registrations for end user devices registering with sipsorcery.

[hmmwhatsthisdo]

So, if registrations to all SIP providers (sipgate, ekiga, gizmo5, etc.) were disabled, what would the prognosis of the SIP Sorcery server be?

[Aaron]

So, if registrations to all SIP providers (sipgate, ekiga, gizmo5, etc.) were disabled, what would the prognosis of the SIP Sorcery server be?

Resource wise peak CPU utilisation would drop from 80 to 100% down to 40 to 60%. Functionality wise one of the main beenfits of the service would be lost since people wouldn't be able to use sipsorcery to receive incoming calls (or make Google Voice calls with certain callback providers) or make outgoing calls through those providers that require a current registration.

[hmmwhatsthisdo]

Well, let's look at it a different way. Do you have a way to access dialplans for each user? If so, how many users have Sys.GoogleVoiceCall in their primary outbound dialplan?

Most (if not all) of these users probably use The Google Voice / SipSorcery dialplan, which implies that they use Google Voice. Most of these people probably use SipGate (or a similar provider) as their PSTN->SIP DID provider. All of these people could instead use IPKall, which contacts SS, not the other way around. This could dramatically cut down on the server's load. The users probably wouldn't notice the difference (spare that they would need to change forwarding phone numbers in GV)

[Aaron]

Yes it's already been suggested that all sipgate regsitrations should be blocked and instead get users to set up SIP URI forwarding through the sipgate web interface. But again that defeats one of the points of sipsorcery which is to make managing multiple different provider and devices more convenient. I think most people would agree that getting up and running with sipsorcery is not the easiest of tasks and if additional rules to manage different providers in different ways were implemented it would become even harder.

Plus it wouldn't solve the problem merely delay it. If some extra CPU was squeezed from the server and free accounts were enabled again then within a few months at most the problem would be back.

[hmmwhatsthisdo]

Yes, it doesn't resolve the problem. There may not be a viable option that completely resolves the problem. But, it buys time.

Another thought: What if we asked the entirety of the SS community what their opinion was? I have a feeling that you have a pretty good handle on Silverlight, what if you were to build in a required survey into the SS app that every user will need to complete upon next login? Perhaps gather a list of possible alleviation measures for the SS server load (temporary or otherwise), and put into a multi-choice survey?

Also, here was yet another thought I had: Not everyone is online all the time. People with SIP phone apps shut off their computers, phones, etc. at sometime in all likelihood. If someone's not using their SIP account, then why register with their SIP providers? If an account hasn't had any registrations sent to it from SIP phones in x seconds, then perhaps halt outbound registrations for that account until another registration command is recieved, OR the user logs into the SIP Sorcery app. That way, people who aren't using their phones aren't taking up as much bandwidth.

[MikeTelis]

Yes, it doesn't resolve the problem. There may not be a viable option that completely resolves the problem. But, it buys time.

In my opinion, there are only two viable solutions:

1. Get some sponsorship.
2. Find a source of income that would be proportional to the number of users (like modest annual fee I suggested).

Therefore, all the ideas leading to reduce the load onto server we should consider as the way to reduce "annual fee" (or whatever mechanism is used to generate the "proportional income"). "Buying time" is not an option because you can't buy a year or two, just a few months.

Also, here was yet another thought I had: Not everyone is online all the time. People with SIP phone apps shut off their computers, phones, etc. at sometime in all likelihood. If someone's not using their SIP account, then why register with their SIP providers? If an account hasn't had any registrations sent to it from SIP phones in x seconds, then perhaps halt outbound registrations for that account until another registration command is recieved, OR the user logs into the SIP Sorcery app. That way, people who aren't using their phones aren't taking up as much bandwidth.

I strongly oppose this idea. sys.Dial('acnt@local') is not the only way of forwarding of incoming calls. Some people I know do not register any SIP devices to SS server. Instead, they are forwarding incoming calls to their landline or cell phones (like sys.Dial('12125551212@provider')). There are some who want to receive notifications (by e-mail or SMS) of missed calls when their ATA was offline. And finally, some are bridging calls via Voxalot; their ATA is registered to Voxalot and there are no active SIP bindings to Sipsorcery.

That's why I consider this idea totally wrong unless it's implemented as an option ("check this box if you want Sipsorcery to stop 3rd party registrations when there are no SIP bindings").