Checking back in on our interns – demonstrating our APIs via games and automating SIP testing
Using telecoms to drive user engagement and interaction – and automating SIP testing from log data – our interns delivered.
What happened with our teams?
After a summer of hard work – and, by all accounts, a lot of fun – our interns have returned to their studies and have resumed the hard slog of their engineering and computer science education. They accomplished a great deal during their stay at Gintel – and delivered solutions from which we will continue to benefit.
First up, you may recall that they were divided into three teams. The first two collaborated to develop a new gaming application based on our APIs. One group focused on the middleware and backend software that enabled interaction with the game, while the other was tasked with creating the application and interface, ensuring that it could easily be navigated and offered an intuitive experience. The third team investigated test automation. Let’s see how they got on.
API control and integration
APIs are of course central to our solutions. We use them internally, and we also expose APIs that our operator customers use to build API monetisation programmes. We’ve been providing API gateways for more than 10 years, so we know a lot about what developers need (and also how to make API exposure programmes profitable – but that’s a story for later this year).
Now, we know that, while today APIs are used primarily to connect network functions to specialised enterprise software and processes that may need telecoms capabilities (call control, location, status, and so on), we can anticipate that these same functions can also be useful in a variety of other situations too. We don’t know what those are yet, but what we wanted to learn was, can our APIs be used by people from outside the telecoms domain to create useful things?
The answer – unsurprisingly – is yes. We were not interested in the commercial utility as such, but the principles. Can we use events in the telco world to influence applications and, of more relevance to our domain, to provide a means of real-time interaction?
Navigation and gamification
This was achieved in an elegant fashion by the teams. One made a game, in which users navigate a labyrinth but do so via real-time DTMF interaction rather than keystrokes or a more traditional interface. Gamers could dial in and use DTMF commands to move around the game environment.
And, because collaboration is important, multiple users could participate in the same session, helping or impeding each other, depending on allegiance. What this proved is that we can use, for example, DTMF to guide responders as a means of last resort, or we can use DTMF as a simple means of exploring an interface or providing crucial commands.
The other worked with our middleware and backend components to ensure that the relevant functions were exposed and mapped to the required user commands and requests. The exercise showed how our APIs can be used by any developer to interact with comms functions.
We’re so pleased with the results that we’ll be putting the game on our website – and then we’ll show you how you can leverage our API gateways and launch API exposure programmes for your customers.
Auto-generating SIP tests from network data
Testing is a continuous activity for any software developer, particularly as we move towards CI/CD (and CT)-based processes. Regression testing, acceptance testing and more require large batches of tests to be run in sequence, covering key scenarios. Automating such testing is straightforward – but what if you want to test a specific and new scenario, based on something that actually happened in the network?
Well, you could write a brand-new script, for example, and then execute it – but that takes time and introduces friction. This is particularly important if a new behaviour has been identified (let’s say a new software update for an SBC or IMS element that requires some modification from other processes) – we want to avoid barriers to checking the new scenario.
So, how can you approach this? Well, like all real-time systems, we create logs that are exported periodically. They provide the information you need to replicate new scenarios. So, our second team explored ways in which tests could be automatically generated from logfiles. You extract the log for the events in question, generate a script and run it, so it can be replicated and observed.
Our team was able to create Python-based programme that generates scripts – covering sessions with multiple calls – so that our QA team could evaluate new conditions. It ingested the files, read them and then provided the output that could be used to replicate situations of interest.
Of course, this accelerated the whole (essential) process. While it’s a lab-based model for now, it shows how such logs can be used as source material for automated, in-network test platforms in the future.
Thanks to Workcation – and our teams! You smashed it.
It’s been a productive summer – and our teams leave us with code and programmes that we can reuse. They’ve delivered – and we’re thrilled. But, as important as the output and the learning was the experience. Here, we’re grateful to our partners at Workation. They helped us to organise activities and events, so that our interns could socialise with others from different companies. We’re so impressed, we’ll be participating in the programme again next summer.
But the final word must go to the teams. They demonstrated enthusiasm, aptitude, and engagement throughout – making sure they delivered against their briefs – and helping to shape the projects with our own experts. Thanks for all of your efforts - we really hope some of you return and join Gintel!
