Receiving calls on an Indian number

In short: Inbound calls on RingTrunk are delivered from a fixed source IP to the origination URIs on your trunk, in priority order, with the number in 10-digit form on the request URI.

Inbound calls, called origination, are calls to your number. We send an INVITE to the origination URIs on your trunk. These legs carry no credentials, so your SIP server has to accept them by our source IP.

Three steps

1. Attach a number to the trunk. Incoming calls to that number are delivered down it.
2. Add an origination URI on the trunk's Origination tab: the host of the SIP server that should receive the calls, for example your-sip-server.example.com:5060 or 203.0.113.10;transport=tcp. No path, no IPv6 literal, no sips: scheme. If your platform identifies your account by the part before the @, put that ID there — see Platforms that route on the user part.
3. Allow SIP from our source IP. The IP is shown on the Origination tab. Firewalls and security groups match on the packet's source address, so this has to be an IP and not a hostname. A REGISTER-only or NAT'd endpoint cannot receive calls.

What the INVITE looks like

INVITE sip:[email protected] SIP/2.0
From: <sip:[email protected]>            ; the caller
To:   <sip:[email protected]>  ; your number
; codec: PCMA/8000, ptime 20

The user part of the request URI is your number in 10-digit form. Route on that.

Platforms that route on the user part

Some platforms give every customer the same host and tell them apart by the part before the @ — OpenAI's SIP connector is one (sip:proj_…@sip.api.openai.com). For those, put the ID before the @ in the origination URI:

[email protected]:5061;transport=tls

The request URI and the To header then carry your ID, and your number arrives in a P-Called-Party-ID header instead:

INVITE sip:[email protected] SIP/2.0
To: <sip:[email protected]>
P-Called-Party-ID: <sip:[email protected]>   ; the number that was dialed

Through the API the same thing is {"uri": "sip.api.openai.com:5061;transport=tls", "user": "proj_abc123"}; user may be given as its own field or embedded in uri.

TLS destinations

A transport=tls origination URI is delivered over TLS, and the media on that call is encrypted with SRTP. Platforms that require both — OpenAI's SIP connector does — need nothing further from you. On such a call the audio is relayed through RingTrunk rather than flowing directly between the carrier and your server, so the source IP of the media is the same as the signalling.

Failover

If you list several origination URIs, they are tried one at a time in ascending priority order until one accepts. This is failover, not load balancing. There is no traffic distribution across entries of equal priority.

Callback forwarding

If you only dial out from a number, people will still call it back, and there may be nothing on your SIP side to answer. Set a forwarding number on the trunk's Numbers tab, or through the API with forward_number on PATCH /api/v1/trunks/{sid}/numbers/{number}, and incoming calls to that number ring that phone instead of your SIP endpoints.

• Forwarding replaces delivery to your endpoints for that number. It is per number and only active while configured. Clear it and calls are delivered to your trunk again.
• The person answering sees the number itself as the caller ID. The real caller's number is on the call record.
• Outbound calling is unaffected; the number remains valid as a caller ID on the trunk.
• Your trunk traffic is unchanged. Media still flows directly between your server and the carrier. Only forwarded calls relay through our media plane, in region and without transcoding.

LiveKit specifics

On a LiveKit inbound trunk, do not set auth_username or auth_password; our INVITE carries none and credentials there make every call fail with 401. List the number in every form the To header may take: 9XXXXXXXXX, +919XXXXXXXXX, 09XXXXXXXXX, 919XXXXXXXXX. See Connect LiveKit Cloud.