Industry · Software and AI companies
SIP connectivity for voice applications and AI agents
If you build voice bots, AI agents or other telephony software, your product needs phone numbers and a reliable connection to the public telephone network. We provide the SIP trunk and numbers; your application connects through a SIP-compatible gateway or SBC that you run.
- Standard SIP and RTP
- G.711 baseline
- Test and production numbers
Scope
Connectivity, not the application
We are a voice connectivity provider. We do not supply an AI agent, speech recognition or conversation platform.
Your stack typically includes a SIP-compatible gateway or session border controller, a media pipeline, and the application logic, which may use speech recognition, language models and speech synthesis. We connect that stack to the telephone network: numbers callers can dial, outbound calling to the destinations you need, and a SIP trunk configured to the parameters your gateway expects.
Keeping the boundary clear helps when something goes wrong. We investigate the signalling and routing between the telephone network and your gateway with you; what happens after the gateway answers is within your application.
Call flows
Inbound and outbound call flows
Both directions use standard SIP signalling and RTP media between our platform and your gateway.
Inbound: a caller reaches your application
- A caller dials a number assigned to your application.
- The carrier network routes the number to your SIP trunk.
- We send a SIP INVITE to your SIP-compatible gateway or session border controller (SBC), with the dialled number and caller ID.
- Your gateway answers and passes the audio stream to your application, for example a speech recognition and synthesis pipeline or an AI agent.
- The application handles the conversation and either ends the call or hands it to a person.
Outbound: your application places a call
- Your application asks your gateway to place a call.
- The gateway sends a SIP INVITE to the trunk, authenticated by IP address or credentials, presenting a number you are authorised to use.
- The trunk passes the call to the carrier network for delivery.
- When the called party answers, media flows between the destination and your gateway as RTP.
Media
Media transport, codecs and latency
Audio quality and delay decide whether a conversational application feels natural. These settings are agreed before testing.
-
Codecs
G.711 is uncompressed 8 kHz audio at 64 kbit/s and is supported almost everywhere. It avoids transcoding, which adds delay and can reduce recognition accuracy. Other codecs depend on the route.
-
RTP and SRTP
Audio travels as RTP packets, usually in 20 ms frames. SRTP with TLS signalling encrypts the call between our platform and your gateway, where both sides support it.
-
Latency
Conversational applications are sensitive to delay. Host your gateway close to the signalling and media addresses on your configuration sheet, and keep recognition and synthesis processing near the gateway.
-
DTMF
Keypad input arrives as RTP events. Your gateway should accept RFC 4733 so callers can enter account numbers or choose options.
Handover
Transferring calls to human agents
Most voice applications need a way to pass a caller to a person.
Transfers are initiated by your platform. Depending on its design, it may send a SIP REFER asking for the call to be connected elsewhere, or it may place a new call leg to your agents’ PBX or contact-centre platform and bridge the two, updating the session with a re-INVITE where needed.
Which method works, and how the transferred call is presented, depends on your platform and the trunk configuration. We confirm the behaviour during testing, including the caller ID shown to the receiving agent and what happens if the agent does not answer.
Numbers
Numbers for testing and production
Separate test numbers let your team develop and run regression tests without touching production traffic.
- Request a small set of numbers for development and testing, routed to a non-production gateway.
- Order production numbers by country and type once call flows are stable.
- Numbers may need address or business documentation, depending on the country.
- If you provide numbers to your own customers, keep a record of which customer uses each number.
- Availability and lead times are confirmed for each country before you commit.
Security and privacy
Security, recording and data handling
Restrict your gateway to accept SIP only from the addresses on your configuration sheet, use TLS and SRTP where supported, and apply channel and destination limits so a fault in your application cannot generate unexpected outbound traffic.
Voice applications often record, transcribe or analyse calls. Informing callers, obtaining consent where required, and storing, processing and deleting recordings and transcripts lawfully are your responsibility as the operator of the application. Rules on automated calls and on disclosing that a caller is speaking with an automated system also vary by country.
Our privacy policy describes the call data we process to deliver the service.
Technical requirements
Technical requirements checklist
Have these details ready before testing begins. Each item is recorded on your configuration sheet.
Technical requirements for connecting a voice application
-
SIP endpoint
- A SIP-compatible gateway or SBC reachable from the internet, with a public address or FQDN
-
Authentication
- Static public IP for IP authentication, or support for digest registration
-
Transport
- UDP or TCP for SIP; TLS where encrypted signalling is required
-
Codecs
- G.711 µ-law or A-law at a minimum
-
Media
- RTP (or SRTP) with the agreed port range open on your firewall
-
DTMF
- RFC 4733 telephone events
-
Transfers
- Your platform’s method for handing calls to people, confirmed during testing
-
Capacity
- Expected peak concurrent calls in each direction
-
Numbers
- Countries, number types and quantities for testing and for production
Recommended services
Services voice application teams use
FAQ
Questions from software teams
Do you provide the AI agent or speech platform?
No. We provide SIP connectivity and phone numbers. Your application, speech services and any AI models run on your own platform or one you choose, connected through a SIP-compatible gateway or SBC.
Can our application connect without a separate SBC?
If your platform includes a SIP stack that can authenticate, negotiate codecs and handle RTP from the public internet, it may act as the endpoint directly. Many teams use a dedicated SBC for security and protocol normalisation. We review your setup during testing.
Is WebRTC or a media streaming API supported?
The service is delivered over standard SIP and RTP. If your application expects WebRTC or a streaming API, a gateway on your side converts between them.
Can outbound calls be placed automatically?
Yes, within agreed channel and call rate limits and using caller IDs you are authorised to present. Automated and AI-generated outbound calls are restricted or regulated in many countries; you are responsible for complying with the rules that apply to your calls.
Next step
Connect your voice application
Describe your gateway and call flows. We will confirm compatibility, agree the technical parameters and set up test numbers.
Helpful to include
- SIP gateway or SBC product and how it is hosted
- Public IP address or FQDN, and preferred transport
- Codecs supported and whether you need SRTP
- How your platform transfers calls to people
- Countries and quantities for test and production numbers