Callers Anon

Growth in international telephony services is generally a good thing, and we enjoy ever-falling costs and ever increasing competition for these services. However, a downside is the increased flow of unwelcome sales calls and the diminishing trust in (or even usefulness of) Caller-ID.

 

Falling costs have made it attractive for companies to increase cold-calling and to reach out internationally for more prospects. Some have made the choice to hide their numbers (or present a wrong one).  This might be to avoid pre-screening, so that you answer the phone to them, or to avoid you returning their call and making a complaint. Anyway, services exist for them to block or dissemble numbers.

At the extreme of this phenomenon is the genuinely crooked and unethical company who would spoof Caller-ID in order to break the chain of evidence; to avoid meaningful reporting to law enforcement and to assume another company’s identity, or misrepresent their country of origin.

VoIP has been unfairly blamed as being the engine for hiding or changing numbers, but actually if you look hard enough for loopholes, these can be found in legacy telecom systems too. In fact it’s hard to draw a clear line now between VoIP and legacy telco, because even “traditional” carriers use the infrastructure of wholesale VoIP companies: part competitor; part co-operator based on maximizing margin by using the lowest-cost links.

Ironically, telcos themselves know what the callers’ numbers are; the backbone SS7 interconnects need to know, as of course it is the basis of billing as well as international call routing. However, supplemental services allow callers to suppress their numbers, and telcos feel duty bound to obey the suppression requests, even where this does not serve the interests of the majority. In theory, telcos have the ability to block malicious callers, and mechanisms exist for reporting bad guys, but on the whole these seem to be hard for users to access, and pretty ineffective.

There certainly is room here for improved services to customers.  A constant stream of unwelcome cold calls from wide and abroad is now only punctuated by the occasional call from self-styled “Windows Technical Support” who would encourage you disable your home computer with a Trojan of their own design as part of an extortion scheme.

The dam is broken with ever-falling call costs, and these types of calls now will never diminish with the cheerful help of those responsible for the deluge.

We feel that a wider variety of blocking services (available to telcos and individuals) is warranted and are actively working on several projects to deliver this. We’re particularly excited about a unique process we have, that will become a new feature on our Matrix platform, on which we’re also filing patent and is designed to deliver trust back into the network.

Beyond caller-id, we see a requirement for a better means to negotiate a call based on time of day, context, how busy I am etc. There are now many factors that determine my “interuptability” and we don’t seem to have evolved very far.

There has been a natural evolution to caller-id that is the preceding Instant Message or SMS that says “Have you got a moment?” (with the caller-id in the MetaData/From header). There’s a lot of richness that we’ve discovered can be added around these types of interactions that precede a call.

In you’re interested in these elements of User-Experience around communications – get in touch and pop in and see some of the things we’re working on.

Posted in Design Thinking, Digital Communication, Industry, security, Voxygen Tech

The Hegemony of TCP

There’s an interesting article in the Spectrum magazine about the history of open networking and how ultimately the open standards defined by ITU committees got overtaken by TCP/IP. We still sometimes talk about the 7-layer model ( a product of those committees), but in truth networking is now synonymous with TCP/IP, which has 2-layers ( network and transport ) with some various link layers below, and an application sat directly on top.

Many of the applications that were expensively developed in the OSI model (like X.400 for email and FTAM for file transfer) are eclipsed by their rather less rigorous TCP equivalents (e.g. SMTP/IMAP and FTP or HTTP ).  The world’s international X.25 networks have closed down, and X.400 is now relegated to specialised public sector usage, having been long bumped from conventional implementations like Microsoft Exchange.

In some ways, the packet-switching adventure is now reaching its final victory. Part of the drive for OSI came from the need to use packet-switched networks to use network infrastructure more efficiently than the existing circuit-switched model could. Now, with developments like LTE we are looking for packet switching (UDP/IP) to implement the transport of voice all the way to the handset, even in wireless systems.

There’s a sense of rebelliousness and anarchy in the world of IP that has been good for creativity, and for creating large-scale systems that just work. It gives you hope just to look at it.

 

 

 

Posted in Digital Communication, Industry

Signs and Signals

A recent discussion about nautical language (footloose, cut-of-your-jib etc) started a train of thought about words that jump from one usage to another over the years. Sometimes words become obsolete in their original context, and computing and communications are full of examples of words that have been shifted to new meanings.

For example “semaphore” is a word that has mainly lost currency in its original context: a messaging system involving two operators waving flags at each other to spell out the alphabet. This line-of-sight signaling system had a good technological run before electricity came along, and a number of European countries had towers in the 18th century with wooden signaling arms atop that could send messages across the country. In the UK, a chain of towers was used to send messages from the admiralty in London down to the naval dockyard at Portsmouth. It was even possible to synchronize clocks at the two sites to within a quarter of a minute: important, since correct navigation relied on precise track of time on board ship.

Some types of railway signal (with a moving arm) are still called semaphore, but pretty much the term is archaic, except in computing. In operating systems, software flags called semaphores are used to synchronize multiple processes or threads when they access a shared, limited resource. A semaphore allows a program to indivisibly reduce a counter and block if the resource is exhausted.  Once the program is finished with the resource it “signals” the semaphore, which again indivisibly increase the count again. These operations go on constantly in operating systems, and multi-tasking systems could not work without them.

Incidentally, the phrase “multi-tasking” once only related to computers and operating systems, but has been absorbed back into mainstream English, and  teenagers now tell us that they can do their homework, while simultaneously operating Facebook and texting, via their “multi-tasking” skills.

In communications, “signaling” is a big deal. Telephony systems have a “signaling layer” (e.g. SIP, SS7 or Q.931) responsible for call set-up and tear-down.  We use the term “digital signal processing” to describe algorithms we apply to audio/voice streams in order to encode, decode, compress or filter them for digital systems. We talk about analog signals (i.e. a representation of audio) that can be sampled and quantized into digital signals that can then be held, manipulated or transmitted using media like IP networks. Computers also have “signals”, which are software messages that tell a process to stop what it’s doing and do something else.

The provenance of the word “signal” is interesting. Signe in Latin really meant a sign, and the word “signal” comes to us via French or Italian (signale/segnale). Late Roman period Emperor Constantine was said to have seen an early Christian symbol in the sky, and was told “in hoc signo vinces”, or “in this sign you will conquer”. A sign in the sky is certainly a form of communication, pretty rarely used, and the more powerful for it.

“Signals” have been used in a military context for a long time. In the navy, sequences of flags were run up the mast, e.g. Nelson’s 1805 “England expects every man to do his duty”, or waving semaphore flags for a more interactive communication. Incidentally, Nelson originally said “confides”, but the word “expects” could be done with fewer flags.  In modern communications, the same concerns still exist: we change the representation of messages or compress them in order to more efficiently use the medium; to optimize transmission time, bandwidth or storage space. Military communication is still today referred to as “signals”, and there are specialist “signals” divisions.

Arguably, the use of the word signal in digital communication is quite divergent from the original meaning. Technology has the ability to bring new meaning to language as well as to hijack and re-purpose existing words. Computing and communication shapes the world as profoundly as ships did from the 15th to the 20th century, and much of that specialized vocabulary will no doubt shape the spoken language of the future in the way that nautical language already has.

Posted in Digital Communication

T-Birds are Go

We recently finished our T-birds conference controller (we’re all big Jeff Tracy fans here), and presented it to Jamie Finn and colleagues at Telefónica, to much hilarity.

The T-birds conference controller allows 5 chosen mobile users to be summoned at the touch of a button into a conference call.  The photographs for each user (part of Jamie’s team Photoshop’ed onto Thunderbirds characters) have LED backlit eyes that flash when a call is connecting (just like in the original TV series – we have the sound effect too, it just doesn’t come out that well in the video). Speaking events (talk-on – talk-off) are indicated by the LED built into the switch beneath each user.

It’s a kind of hardware interface to an Uber Conference style app.

The genesis of this project was many months ago when we first started experimenting with the Raspberry-Pi, to see what kind of “internet-of-things” applications we might be able to build for our platform. After some initial messing about with LEDs and switches, we realized that adding WiFi to the Raspberry-Pi (there are a number of compatible USB Wi-Fi devices) opens up more interesting possibilities by creating a cloud-connected box that needs only power to function, and a variety of sensors can be hosted on a box like this.

We used the BlueVia APIs (Voxygen developed the voice call control APIs in the latest BlueVia platform) to initiate calls, and we added some secret sauce of our own to generate the realtime voice activated messages from the platform.  For T-birds, this realtime stream is great for call control (i.e. we can see from the application whether calls to mobiles are ringing, answered, hung-up etc), and we can also see conference messages. For T-birds, we generate “start-talking” and “stop-talking” messages that show us which of the conference participants is speaking; we can use this to switch that participants button light on/off to give the conference initiator a view of who’s talking.

In hardware terms, the inside of T-birds consists of:

  • Raspberry-PI
  • The ‘slice of PI/O’ board, to interface our 10 LEDs and 5 switches
  • 5 push-buttons with integrated LED
  • 5 pairs of White-LED ‘eyes’
  • A small amplifier and speaker for sound effects
  • Power supply and a few ancilliary electronic components

The software consists of:

  • Standard Pi Debian wheezy operating system
  • Application code, written in PHP 5
  • Some interfacing code in C that allows switching of LEDs and sensing of switches

PHP was a natural choice for this, as it allows easy construction and delivery of commands to the BlueVia webservice API that uses POST/GET and embedded JSON structures, as well as easy processing of realtime messages, which are also JSON.  With PHP we were able to experiment, quickly get something going, then iterate towards final functionality.

The external casing was masterminded by Elliot, one of our interns, with the final paint finish really lifting the box into a superior category above “home-made”. Martyn, a master of the soldering iron, created the electronics and wrote the C and PHP code to make it work. Dean was project director and also involved in a number of constructing, painting and software tasks; he was also our conscience ever reminding us of slipping schedules and overspends (“the switches cost how much?”).

For your enjoyment, we created this “making of” video, which gives some idea of how this all came together, and what the final user experience is like.

We’re thinking of putting a complete kit on kickstarter – would you buy one?

Posted in Industry

Where Cloud APIs Meet Cellco

A blog post and video demo from our friend and collaborator Murray shows how the BlueVia service can implement an advertising-funded calling model.

Allowing users to stack-up call minutes by volunteering to listen to adverts is a model that has been used in South America, and there is still a lot of industry effort involved in connecting mobile to ad-funding in any number of ways using data/web, voice, SMS.

Murray points out that in the BlueVia model, there’s no need to switch the call out to another voice server and have the complexity of managing 2 call-legs, and using up extra trunks and so forth. Within the O2 network it makes more sense to use IN to change the processing of the call; the user’s account is marked with a special flag (in the HLR) so that whenever a call takes place the “intelligence” in the network allows the calls to always be processed by a BlueVia application.  In this case the logic allows audio play out for the ad, followed by proceeding to connect the two-way voice channel. Very neat compared to some solutions.

By the way, Voxygen’s cloud platform is a contributing piece of technology to this demo and Voxygen also developed the voice APIs for BlueVia, hence the mention of Voxygen in Murray’s post. RESTful APIs for voice and conference control is one of Voxygen’s areas of expertise.

 

Posted in Mobile, Voxygen Tech
← Older posts