Thursday, 16 May 2013

Monopoly collection

It is slightly odd to have more than one monopoly but I seem to be making quite a collection now, and somewhat out of the blue Mikey has just got me an original John Waddington Ltd (pat. app. for No. 3796-36) 1930's monopoly board, in original box with original tokens and dice and instructions.


I am impressed! Thanks Mikey.

The rules are very slightly different to the modern game, but not fundamentally. They are, if anything, slightly clearer. They don't, of course, have any of the silly variants like "fines collected and paid on landing on free parking", or "must do one turn of the board before buying property" which are all too common.

Interestingly they do have a separate little "Q&A" for the rules which clarifies a couple of points I did not know. You can sell (to the bank) the houses or hotel on one site without selling the other houses on other sites in the group - the "even building" rule only applies to building not selling! You also cannot sell the logical 5th house that is a hotel leaving 4 houses left - you have to sell the hotel and separately buy houses at full price, having only got half price back for the hotel (half of cost of 5 hours).

Oh, an unlike the british Bletchley Park set it does, of course, use POUNDS.

Very cool!

Saturday, 11 May 2013

One day, technology will "just work"

I have to admit it is getting simpler, but sometimes technology does not work so well.

James has been watching the F1 Qualifying on iPlayer in Sweden, as you do, and iMessaged to say it was worth watching. Sandra still has no idea how to get such things on TV, so asks me. How to make me look like an idiot...

So...
  1. Sky box, on demand, catch up, sky sports: "The F1 show". No sign of qualifying. Grr
  2. Sky box, on demand, iplayer, BBC one, today: Some breakfast show. No sign of F1. Grr
  3. TV, iplayer, channels, BBC one, today: F1 Qualifying. Yay! "Sorry there is a problem". WTF?
  4. iPad mini, iplayer, bbc one, today: F1 Qualifying. Yay! Plays! Woot! Small screen though.
  5. Finally: Air play to AppleTV to play on real TV
Sorted. And almost simple... :-)

Just start to watch and get a call, someone needs a lift, so on pause for next half hour. Grrr. If only families were as simple as technology...

Friday, 10 May 2013

New VoIP platform

We have an existing VoIP platform which has various features and which has evolved over a few years. It has registered SIP phones, relaying to configured SIP endpoints, multiple "also ring" targets with delays and all sorts. Works well. I coded it all on linux from scratch.

We are working on moving to a new platform, whilst retaining the features of the existing system. This is going to be fun. I blogged on code wearing out before - well this code is a tad dusty to say the least.

The new system uses FireBrick VoIP platform, which, from a VoIP point of view, is completely new code. It is a lot better than my previous linux code. It works well and we have been using it for what?, a year, in the office.

The newest code works by using RADIUS to make call routing decisions. This is really good from a redundancy and scalability basis as it allows the call servers(s) to talk to multiple RADIUS servers to find the answer. If there is a problem with one then within hundreds milliseconds they are trying another. There is even an RFC covering the SIP based authentication logic (http auth).

The FireBrick code is pretty much ready, but I expect changes when I am using it "in anger" on the new system. The plan is to mimic the current operation of "speechless" by providing suitable RADIUS replies to the new "voiceless" system. As I type I am already pondering a few minor tweaks.

Once I have this code sorted over the next few days, we can get traillists on board. Even so, we are missing a key feature which is call recording, so that is the next job on the FireBrick side. I am very keen to keep something of a unique feature in that we make stereo a-law call recordings.

There are a lot of advantages to moving to a new system. The separation of control and authentication logic from the actual call routing will help reliability and scalability. The new system should easily allow multiple servers at the VoIP level, RADIUS level, and even for call recording and voicemail. The newer FireBrick SIP code is nicer and we are hoping we can even make it work with some styles of NAT (yuck).

The challenge is the current "speechless" code is all integrates VoIP/SIP and routing decisions. I have to understand my code, and make new code for my RADiUS servers. It is not too bad, but the code is a tad old and grey, so will be a fun challenge making it new and shiny.

Nose back to the grindstone over the weekend. That is, assuming the whole idea of a VoIP service is not screwed up by OFCOM.

Banks bouncing shit

How hard is it really?

If you are going to bounce something because it is over limit, bounce it. Or don't.

Dont fucking show it over limit on the on-line banking - let me transfer money from another account to cover it - and then, later, still bounce the original damn payment leaving the account in credit but payments bounced.

Arrrrrg!

Back to finding banks with clue...

Bank with clue?

I am looking for a bank that can provide me with any sort of real time electronic notification of incoming "faster payments".

Basically, I'm trying to find a way to make it easy for people to pay us for things using FP without the current manual checking process with our on-line banking.

I am not getting any where with google. So anyone got any clues?

I don't mind how it notifies: email, text (to and 01/02 number), SOAP/XML, or what, as long as we can, in some sort of real time, extract the details of incoming payments as they happen.

In an ideal world it would be SOAP/XML such that we can even provide the response message or even reject an invalid payment.

I have various business ideas that could make good use of this, including pre-pay data SIMs and so on.

Thursday, 9 May 2013

Future of voice calls?

Having made some suggestions of how OFCOM could tackle number allocation issues I do wonder where things have to end up on voice calls in the long run.

I am seeing a massive reduction in voice calls myself. People call to chat and gossip, but that is moving to facebook. People talk to businesses, but that is moving to web sites. Businesses talk to businesses, but that is moving to B2B systems and echat and so on. I am hard pushed to find a reason to talk to someone on the phone myself. Sometimes I want a chat with a friend or relative which is more face to face but I cannot be there - so I FaceTime them - we used FaceTime to show my parents their new great grandson. Most voice calls I have these days are junk calls ringing me and getting abuse.

So what has to happen to voice - long term?

In my opinion the long term for voice calls has to be that it becomes just another IP based protocol. We already use complex protocols for web pages, email, and much else. Voice can work over IP (VoIP/SIP). What it means is that a physical phone line becomes just a very restricted type of Internet access that only talks voice. The numbering becomes just a matter of DNS and domain names - something you pay for as a way of indexing your contact endpoint just like getting a co.uk domain for a web site.

It does not mean it becomes "free". Like any protocol over IP there are some costs, but many Internet access packages work with a large amount included for a fixed fee. To be honest "voice" is no longer the bandwidth hog (that's video, iPlayer, and so on). I send larger emails than the data in phone calls I make, without a thought, or a bill. As I record all my calls, I also send emails for each call I make/receive as well - it is good that emails don't have similar interconnect settlement fees!

Eventually, the idea of a physical landline that only talks voice protocol to the Internet, and not a general IP access, will seem strange and unnecessary, like faxes and telex. I wonder how long it will take.

The problem is, of course, a huge industry all over the world with a vested interest in considering "voice" to be a special protocol with special regulation, special number allocation controls, special interconnects and lots of money. To telcos the standard idea of "settlement free interconnect points" that are common in Internet terms (like LINX) is an abomination. They will not want this. But ultimately it will happen without them - we see that with iMessage and FaceTime now, traditional SMS and calls that bypass the telco monopolies.

They move with the times or they are left behind.

How OFCOM should handle UK number allocation

There is an issue with how they manage numbers, and areas running out. How would I solve it?

I think the only long term answer, which also addresses the "porting" nightmare, is to have a central per-number database. This means when any call is made by any telco they have to check the database to find where they send that call. The destination could still be an old fashion SS7 "point code" or whatever. The mechanism can be DNS, and have multiple servers and caches and even private intranet as used by mobile operators for things like GTP. DNS is such a well proven system that works for the Internet and works for a lot more DNS lookups per second than telephone calls per second.

A central database has several advantages:-
  • Allocation on per number basis removes any wastage
  • Porting is simply a database update and does not involve original telco in call routing
  • The database can have a few critical extras such as emergency services contact data and TPS/FPS flag
  • Numbers can be charged for per number not per block, which manages number hogging, but scales costs to customers so small telcos are not disadvantaged.
There are, however, problems with this idea - the main one is "how do you get there from here", and also "the existing telcos cannot cope". It may also mean that there are "golden" numbers that cost more, sadly.

So, here is the idea of how you get there from here:-
  1. Define a simple number allocation API and DNS style lookup - try avoiding having a huge committee for this - it can be standard enum DNS, and simple SOAP/XML API.
  2. Get a company to run the database as a pilot - there are a lot of companies that could do this. It is not rocket science.
  3. Allocate a block, as a pilot - perhaps in a conservation area, but maybe in 03 or some such.
  4. Data fill the block conventionally with a point code of a company that can handle the DNS lookups and forward correctly to the real endpoint (maybe same company running database)
  5. Define an extra high interconnect cost for routing the block via that legacy gateway
  6. Make it that legally the numbers are per number designated to the telco even though one telco is handling the legacy routing for the block
  7. Make it that legally the database is run on behalf of OFCOM and owned by OFCOM, just subcontracted
  8. Don't make it expensive for telcos, even small telcos, to access API and DNS - ideally that should be free. Just charge per number allocated.
This means telcos that do nothing will simply data fill and route conventionally, but be paying extra per call. That gives them an incentive to do something longer term. Companies that upgrade to handle the DNS style lookups can route directly and pay normal (low) interconnect rates. Any telco can get numbering that will work, on a per-number basis, and without the usual long delay for data fill (though they will have to data fill per number themselves for incoming calls).

Run pilot in stages:-
  • One block for testing everything
  • All conservation areas for all remaining blocks in those areas
  • All areas for all new blocks
  • Changing some existing blocks over to the new system
  • Changing mobile operators to same system, so same porting rules
There are a number of small telcos with a serious interest in making this happen and who would provide consultancy, specifications and test systems for OFCOM for a very reasonable rate, or even free.