Voice and messaging

Voice is part of our story

From those first AzurePCS experiments, we have reached full VoLTE and SMS over IP. Building a telephone service has become a major part of the work behind Lodestar.

A normal call over our 4G network

VoLTE means Voice over LTE. A compatible phone uses the normal dialler to make and receive calls over the 4G connection. IMS handles registration and call control, while the media path carries the conversation. Making data work was one milestone. Making a phone register, ring, answer and keep clear two-way audio has been another substantial part of this build.

Texts through the same service platform

SMSoIP means SMS over IP. Our mobile text messaging uses the IMS service layer, with SIP MESSAGE carrying the message between the handset and the messaging systems. It still feels like an ordinary text to the person using the phone. Behind that familiar action are identity checks, routing, delivery records and acknowledgements.

Lodestar Voice for homes and businesses

Lodestar Voice brings a UK telephone number and Internet calling to compatible SIP equipment and softphones. It sits alongside mobile VoLTE and uses the wider voice applications and media work I have been building. Voicemail, caller display and our telephone services are part of making it useful in everyday life. We are preparing public ordering, with the launch plans and features on our Voice pages.

Explore Lodestar Voice

The system behind a phone call

Getting a phone online is one part of the job. Giving it a telephone service means knowing who is calling, where they are and how to reach the other person.

Our voice service layer

Our IP Multimedia Subsystem, or IMS, brings these decisions together. A compatible handset registers with IMS over its IP connection. The network can then associate that phone with its subscriber identity and direct calls, messages and telephone applications to the right place.

Three jobs inside IMS

The proxy function is the phone's entry point. The interrogating function finds the appropriate serving function using subscriber information. The serving function handles registration and service routing. Separating these jobs makes the system easier to understand: the phone reaches an entrance, the network finds its record, and a serving function manages its service.

From a connection to a conversation

Our IMS connects with Lodestar Voice, FreeSWITCH applications, messaging services and RTPengine. Together they handle telephone accounts, voicemail, spoken services and the audio path. This is why a mobile network needs more than a fast Internet connection. A call also needs identity, routing and several components to agree about the same conversation. I have spent a great deal of time making those joins work.

How your phone registers for voice

Before a call can arrive, our IMS needs to know that your phone is available and belongs to the subscriber using it.

Find the subscriber

The phone sends a registration request through our proxy. Diameter exchanges with the Home Subscriber Server identify the subscriber and the appropriate serving function.

Authenticate the handset

IMS Authentication and Key Agreement challenges the phone and checks its response. The network then supplies the trusted identity used by calls and messages.

Remember the return path

A contact binding records where the handset can be reached. We persist changes in PostgreSQL and reload saved bindings at startup. Refreshes and expiry keep those contacts useful as phones sleep, move and reconnect.

A call has two separate journeys

A call has two related paths. Signalling controls the conversation, while media carries the sound. Each path needs to reach the right place.

The signalling path

SIP sets up, answers, changes and ends a call. Our routing selects local mobiles, fixed voice accounts, telephone applications or permitted carrier routes.

The audio path

SDP describes media addresses and codecs. RTP carries the sound. RTPengine provides relay and codec interworking where needed; some local mobile calls can use a more direct path.

Keep the conversation usable

I have worked on clear ownership of media handling, along with hold, early audio, voicemail, cancellation and session refreshes. These details keep the different parts cooperating throughout the call.

More to explore on the telephone

I wanted our telephone platform to have useful services and some character of its own. A simple call can open a directory, check the time or explore something interesting.

Lodestar Live

Our service hub uses 120, with a directory on 122 for supported network accounts. The applications include spoken information, original stories, quizzes and a telephone sound museum. The museum recreates familiar equipment and tones through synthesised audio. It is a small celebration of the sounds that made many of us interested in telecommunications.

Familiar practical tools

The service dialplan includes the speaking clock on 123 and a line test on 17070. Voicemail retrieval uses 121 or 1571, with the authenticated account selecting the mailbox. Recent incoming caller information is available through 1471. These functions sit alongside the wider work on registration, routing and media.

Information without opening a browser

Our application work includes weather, traffic, selected Underground departures, bank holidays, headlines, weather warnings and daylight information. Freshness checks help keep old information from being presented as current. There are also music selections, callback and alarm functions. Account access and the relevant information feeds determine which services can be used. The aim is to make a familiar telephone interface useful, approachable and worth exploring.

What happens when you send a text

A text passes through several systems. Our messaging transport keeps track of the handovers so that a lost reply does not automatically become a duplicate message.

Receive and identify

SMS over IMS uses SIP MESSAGE. Our application uses the authenticated network identity for the sender and separates submissions, incoming delivery and acknowledgements.

Store before sending

The transport records an operation before contacting the carrier. Local receipt, onward acceptance and handset delivery remain separate stages.

Handle uncertainty carefully

If an onward reply is lost, stored identifiers and result matching help determine what happened. Retry rules avoid blindly sending again. Lodestar Live also supports authenticated text commands with short, controlled responses. Reliable messaging depends on getting these less visible steps right.

Building Lodestar Voice

Lodestar Voice is our fixed telephone service, with public ordering being prepared. It brings SIP devices and softphones into the same wider environment as our mobile voice applications.

A home for SIP devices

A SIP registrar records where an authenticated telephone account can be reached. Our Lodestar Voice registrar includes persistent registrations, NAT handling and a TLS signalling listener. This helps devices behind home routers maintain a usable contact while keeping customer authentication separate from trusted network routing decisions.

Shared applications and media

The service connects registered accounts with local destinations, mobile routing and telephone applications. FreeSWITCH provides voicemail and spoken features. RTPengine supplies media handling where needed. Reusing these foundations means that the work on voice quality and applications can benefit more than one access method.

Connecting with other telephone networks

Our carrier integration uses Simwood for permitted external traffic and incoming fixed numbers. Routing normalises UK numbers and applies destination controls before choosing the onward path. Incoming numbers are associated with the correct account through the directory. I am building this towards a service that is practical to manage as well as pleasant to use. Like other Internet telephone services, it depends on working power and connectivity, so a charged mobile phone remains a useful backup at home.