The term “store and forward” is one that keeps being referenced in terms of Mobile Voice Recording (MVR) and compliance. It seems to generate a lot of fear, uncertainty and doubt and no-one seems to have explained it clearly yet. Our CTO, Dr Richard Wheeldon sheds some light.
“Store and forward” is a really simple idea – a process reads in a load of data, stores it locally, does some processing with it and passes it on.
Yes, that’s it – simple. So far, so good. Why write a blog article about it? Why care? Because it’s a very bad thing. Except when it’s not. Then it’s a very good thing. Bear with me…
Store and forward is a standard industry term, frequently used during my time at Cisco. As the technical lead for the Cloud Web Security product, I was largely responsible for a global, cloud-scale, secure proxy. Not too dissimilar to my current role in many ways. The network is different (Telecoms as opposed to The Web), the company is different (small and nimble as opposed to acquisition-crazy behemoth) but much of the rest remains the same.
IP-based networks are organised in layers. For example, an Ethernet frame may encapsulate an IP packet containing a UDP datagram with a bit of video data. Switches direct Ethernet frames to the right place. Routers direct IP packets to the right place. Doing this quickly is what turned Cisco into the most valuable company on the planet (for a while and many years ago).
At the routing and switching layers of an IP network, store and forward is often a really bad idea just because it’s incredibly slow (which in network terms means wasting too many nanoseconds!). All the information needed to redirect an Ethernet frame or IP packet is contained within the first few bytes. The rest is payload. There’s no good reason to wait for the payload to be fully received before starting to transmit the first bits/bytes of data – assuming, of course, that the output network and input network operate at comparable speeds. If they don’t and the output cable is only capable of handling a single packet/frame at a time, then a bit-by-bit or byte-by-byte stream would tie the output speed to a slower input speed and reduce overall performance, which implies that store and forward might be more suitable.
That’s enough about IP networks! What’s this got to do with MVR?
There are two scenarios where the store and forward has a clear meaning. Firstly, when the mobile device (cell phone) in question stores the call and forwards it to a remote storage service (typically cloud-based). Secondly, when a cloud-based service stores a recorded call and forwards it to another storage engine, typically in a customer’s data centre.
The first scenario, of a device capturing the call and forwarding it to a remote server, is plagued with difficulties. Most importantly, the data channel the recording is typically sent over is different from the cellular channel over which normal calls are made. This has a cost implication. Although legislation and customer pressure have driven down European roaming data charges, in other parts of the world they’re still egregious. Worse still from a compliance point of view, the data channel might not be available – it could be broken or unreliable due to poor coverage or battery levels and it can be switched off by the user. All this leads to a greater likelihood of unrecorded calls
In the second scenario, the conditions and the logic change. Forwarding a compressed voice recording over a VPN or other encrypted link over the public internet has negligible costs. Establishing a branching call via SIP to a remote recorder is entirely possible and has the advantage that a compliance officer may be able to listen to part of a call before it’s been completed but tying the reliability of a globally distributed, highly redundant, elastic cloud to the reliability of a single data-center link is a little bit crazy. Hence, we should either use store and forward or we have a streaming system with a store and forward fallback. The former has the obvious advantage of simplicity.
Finally, the trust boundaries change – if a system is being used to manage the behaviour of an end user, it is unreasonable to trust the end-user whose behaviour is being observed but it’s reasonable to trust that behaviour management system. These changing conditions imply a different recommendation.
Having explained all this, some of you may still be looking for a subtle analogy between these technical descriptions of store-and-forward data processing and the picture above of Barcelona’s forward Lionel Messi sitting in the Adidas store, … I’ll get my coat.