Woosh cannot block 0900 calls - only bar all toll calls

Forums › New Zealand Broadband › Woosh cannot block 0900 calls - only bar all toll calls

geek4me

830 posts

Ultimate Geek
+1 received by user: 77

Trusted

Lifetime subscriber

Topic # 12919 13-Apr-2007 14:23

Woosh Help Desk tell me they cannot block Woosh phone lines from making 0900 calls they can only bar all toll calls. Telecom provide an 0900 call blocking service that allows other toll calls.

Is there a reason why Woosh can not block 0900 calls while allowing other toll calls to go through?

(The reason is a staff member accidentally pressed 0900 while intending to call an 0800 number. 0800 numbers are 6 digits long while 0900 ones are 5 digits long. If you call 0900 by mistake using 6 digits you're in for an expensive surprise - for us $20. The extra digit put the call through to a fax machine cutting off any warning message)

Hoping Woosh can change their system to block 0900 like Telecom can but Woosh say they can't. What would be the reason for this?

tonyhughes

Hawkes Bay
8477 posts

Uber Geek
+1 received by user: 4

Mod Emeritus

Trusted

Lifetime subscriber

Reply # 67039 13-Apr-2007 16:52

Perhaps their system just wasnt designed to do that>?

Visit http://www.thecloud.net.nz for New Zealand based Hosted Exchange, Virtual Servers, Web Hosting, FTP Backup & more.
(1GB free FTP storage, or larger plans from $5.75)

- Setup your own mailserver at home on Ubuntu Server - full step by step howto here.
- Have you seen this: Nathan "KFC4LIFE" Dunn.

geek4me

830 posts

Ultimate Geek
+1 received by user: 77

Trusted

Lifetime subscriber

Reply # 67154 15-Apr-2007 14:59

tonyhughes: Perhaps their system just wasnt designed to do that>?

If it's a hardware issue perhaps you're right. I would have thought that a software change could bar 0900 calls. When you make a call wouldn't Woosh know which customer is making the call and if an account has had an 0900 block set up be able to prevent it going through?

tonyhughes

Hawkes Bay
8477 posts

Uber Geek
+1 received by user: 4

Mod Emeritus

Trusted

Lifetime subscriber

Reply # 67160 15-Apr-2007 16:39

geek4me:
tonyhughes: Perhaps their system just wasnt designed to do that>?

If it's a hardware issue perhaps you're right. I would have thought that a software change could bar 0900 calls. When you make a call wouldn't Woosh know which customer is making the call and if an account has had an 0900 block set up be able to prevent it going through?

Even if its software (which it probably is) someone somewhere still has to code that feature in...

From the telcos point f view, how many customers do they have that require this feature, how much would it cost to implement it, and how valuable would it be (customer retention, increased profit etc etc).

I dont see those things present for Woosh and 0900 blocking at the moment, not if it was going to cost any significant sum to implement.

Annoying for the few that do want it though, especially if you are used to having it elsewhere,

geek4me

830 posts

Ultimate Geek
+1 received by user: 77

Trusted

Lifetime subscriber

Reply # 67225 16-Apr-2007 14:05

tonyhughes:

Even if its software (which it probably is) someone somewhere still has to code that feature in...

Presuming Woosh staff maintain their own source code and don't outsource changes. Also assuming a software change could block the 0900 call, how about the following line of code run when a customer makes a call:

if (customername endswith "*" and numbercalled starts with "0900") goto endcall

Where customername is a lookup of the customer name of the Woosh phone making the call. If it contains an asterisk flag to block 0900 calls (a customer preferences field lookup would be better) then bypass the code that connects the call if the number called is 0900 and jump to call ended code.

Some variant of the above should do the trick its just a matter of getting management approval.

jpollock

600 posts

Ultimate Geek
+1 received by user: 5

Trusted

Reply # 67240 16-Apr-2007 15:31

I write code like that for a living. :) You would think it would be cheap, but it most certainly isn't.

1) It assumes that Woosh writes their own code. Not likely. Telecom and Telstra Clear don't, what makes you think Woosh does? Heck, Lucatel New Zealand doesn't!
2) It assumes that regular expressions are good. Eeek! They are performance hogs and the only thing more avoided are threads. I've seen systems processing thousands of calls per second killed by someone who wrote a poorly performing regular expression. It's not pretty.
3) It assumes there is processing space on the service platform. Even the act of looking will probably cost money.
4) It assumes there is disk space on the management and service platforms.
5) It assumes there are screens to populate the data on the management platform.
6) The generic problem, rejecting calls that will cost more than a certain threshold is difficult in a cold-billed network, since Woosh doesn't know how much the call will cost when it is made. (Cold billing is when the bill arrives after the call completes. Hot billing is the other side, which is where the call is billed during the call - prepaid calls are hot billed)

The systems we are talking about here tend to be 5 9's, with their configuration under tight control. This makes them very expensive to change.

Depending on the capabilities of the platform, the cost to change could be between NZ$200k-NZ$1m, more if they don't already involve an intelligent device in every call. (All Call Query)

Definitely, it's a fairly small change once they have all of the capabilities in place.

Perhaps a rule in your local PBX? I don't know what woosh allows, but PBXs tend to be more flexible because they are only processing your calls, not everyones. :)

Jason

---
http://blog.jason.pollock.ca

geek4me

830 posts

Ultimate Geek
+1 received by user: 77

Trusted

Lifetime subscriber

Reply # 67335 17-Apr-2007 12:39

Wow Jason, I'm gob smacked by your answer! I write code for a living too. I must remember to quote my customers NZ$200,000 for every line of code I change I've obviously been undercharging!

Joking aside, there probably is an element of truth in what you are saying.

If what you say is true there's no point anyone requesting a software change or new feature from Woosh as any multi line code change would probably make Woosh go broke.

Perhaps someone from Woosh would care to comment?

freitasm

BDFL - Memuneh
61021 posts

Uber Geek
+1 received by user: 11850

Administrator

Trusted

Geekzone

Lifetime subscriber

Reply # 67339 17-Apr-2007 13:08

I've worked in the Telco practice of a large system integration company, and yes I was involved with Telecom New Zealand's voice platform, had my hand in the Vodafone Australia voice mail service, and a few other clients around the world.

Change Requests are not cheap. All that Jason posted is true - and he didn't even list all the unit testing, regresion testing, acceptance testing involved, and other things such as test environment, standards compliance and more.

There is a lot of difference between coding for a bank, airline or telecommunication company when compared with creating off-the-shelf business accounting solutions for sale in your friendly computer store in the corner...

Backblaze cloud backup (personal and business) | Geekzone broadband switch | Amazon (Geekzone aff) | MightyApe (Geekzone aff) |

My technology disclosure | Business Transformation | Enterprise Content Management |

jpollock

600 posts

Ultimate Geek
+1 received by user: 5

Trusted

Reply # 67348 17-Apr-2007 14:21

Let's put it this way... When the software generates US$1-2m of revenue per day, problems with it become very important, very quickly. That generally means that the carrier demands an SLA with a penalty clause. I've regularily seen penalty clauses where the supplier pays the customer US$50k per HOUR of downtime.

In that type of market, there is signicant risk to any code change. It can still be made, but it must be priced according to the risk that something may go wrong with it. Most of that cost is then spent in risk mitigation activities, such as platform performance analysis, planning and testing.

Additionally, as I've said, the actual cost of making the code change is minimal once the functionality is already present in the network. However, I doubt that Woosh has the capability today.

Let's look at how Telecom probably offers this service:

Telecom can block 900 calls because their 900 service was probably originally implemented as an overlay network. Since 900 calls would be routed to a different set of switches, any gateway logic such as "bar calls to 900 services by this number" is performed by those switches, not by your local switch. That allows them to reduce the load on their core network.

I have no idea how it's implemented now. I'm pretty sure that they don't do all call query, that depends on how number portability is implemented.

Basically, it boils down to, "Telecom already had the capability to run this type of logic in their network, so it was cheap."

Woosh is a basic VoIP provider. I'm pretty sure that they don't write their own code. It looks like they are using ipWireless' products. This is a UMTS product line. Nifty, that explains Vodafone's investment. It also explains how they are managing to lose NZ$20m per year and stay afloat.

I can't find anything describing their VoIP product, so I'm going to assume a basic product. There is no mention of them offering 800 number services, which would indicate that they have the capability. In fact, it says that they don't offer it at this time.

So, let's assume that all they have is a basic class-5 softswitch equivalent. This class of device is built to offer the standard endpoint services and not much more. If you would like to ask someone about capabilities in the network, the vxnet guys might be a good model.

Let's take the simplest route. Let's break down the code and analysis that needs to be performed.

Analysis: Standard call situations. When is this piece of code triggered? On every call? Calls to 111? How about incoming calls? On net calls? Off net? Are there any strange routing digits or parameters in the messages that may affect the format of the number presented to the code?

This may seem stupid, but you are essentially inserting a piece of code (not just an if statement, the entire framework around it) into the call flow. You need to be sure how it will interact with other features, like call waiting, call forward, etc.

Things that I think might interact:
1) Off and On-net Destination busy, voicemail
2) Off and On-net Destination busy, forward
3) Off and On-net Destination call forward
4) Calls to 111
5) What happens if this phone is call forwarded to a 900 number and someone calls it?
6) Interaction with number portability?
7) Interaction with the billing systems? We have to make sure that the call is billed _after_ we check to see if we're allowed to call it...

That's on top of the basic, standard flows.

Additionally, there are regulatory requirements to check. The telecom's regulations are huge in every country, with a lot of intersting conflictings. Will the police squeak? Does this affect their call intercept requirements? Any fraud holes being opened up?

Once we've done the analysis we will know whether or not it is even possible to offer the service, and if there are any signalling changes, we can talk about hardware.

There would need to be an additional field(s) presented to their call center team.
There would need to be funds to train their call center team.

Now, we get to the systems that will actually run this line of code. Assuming that 1 system can run the entire call load for the entire network (AKL and WGTN), we will need 4 of them. Two in Auckland and two in Wellington, offering both hardware and site redundancy.

Let's add this up - we haven't even looked at writing a line of code yet.

Analysis: 1 month requirements analysis - NZ$30k (divided between internal customer cost and vendor charges)
Training: 1 week prep and 1 day delivery - NZ$20k.
Hardware: NZ$80k. (NZ$20k/system)

So, even before we've made the code change, we've going to be hitting the customer up for NZ$130k. I don't know enough about pricing to figure out the software licensing charges. However, you would be looking at a pretty significant implementation program to get this in.

It should now be apparent why they are reticent to add this feature to their network. It also explains why there is a large push for application server standards.

Jason

---
http://blog.jason.pollock.ca

geek4me

830 posts

Ultimate Geek
+1 received by user: 77

Trusted

Lifetime subscriber

Reply # 67356 17-Apr-2007 15:10

Thanks Jason for your comprehensive responses. I understand better now why changes are so expensive. We can consider ourselves very lucky if a customer change request is implemented by any telco. No harm in asking though and if enough ask for the same thing it just may happen.