SIP trunking

SIP trunking

Connect your own SIP trunk — a telco gateway, wholesale carrier, or PBX — directly to Telenow. No CPaaS sits in between: signaling is native SIP over UDP and media is G.711 RTP, terminated by Telenow's own gateway.

Find it under Developers → SIP trunks.

A SIP trunk is not a purchasable carrier. You don't search or buy DIDs here. You point your own carrier's trunk at Telenow, then enter each DID it routes (in E.164) by hand. Trunks need the developer, admin, or owner role; deleting one needs admin or owner.

The platform endpoint

The top card on the page shows the platform's SIP endpoint — this is what your carrier/PBX points its trunk at. The values come from the deployment's configuration (SIP_PUBLIC_HOST / SIP_PUBLIC_IP / SIP_BIND), not a hardcoded address, so on a white-label or self-hosted deployment they reflect that host:

• Signaling — host:port over UDP (port is derived from the gateway's bind address, default 5060).
• Media IP — where RTP flows from/to. Allow-list it on your side.
• Codecs — G.711 PCMU and PCMA; DTMF via RFC 2833 (and SIP INFO).
• Gateway status — active or disabled. If the gateway is disabled on this deployment (SIP_ENABLED not turned on), the card warns you and trunk calls won't connect until the operator enables it.

Point your trunk's termination/origination at the signaling address, route your DIDs to it, and allow-list the media IP.

Importing a trunk from a provider

The fastest way to add a trunk is the Import from provider wizard (button at the top of the SIP trunks page). It walks you through six steps and, at the end, creates the trunk and proves it's reachable. The wizard supports presets for Twilio, Plivo, Vobiz, Vonage, Telnyx, and a Custom option for anything else that speaks SIP over UDP.

1. Provider — pick your provider. Each preset fills in a sensible termination placeholder (e.g. yourtrunk.pstn.twilio.com, zt….sip.plivo.com, sip.telnyx.com, sip.nexmo.com) and, where published, a starter list of the carrier's signaling IPs (editable — confirm the current list in the carrier's own docs). This step also shows our platform SIP endpoint so you can copy it into your provider's origination settings.
2. Auth — choose how inbound calls authenticate:
   • IP-based (ACL) — inbound INVITEs are accepted only from the source IPs you list; outbound needs no credentials. This is the norm for wholesale trunks and PRI gateways.
   • Username / password (digest) — used when your trunk challenges our outbound INVITEs (401/407). Stored encrypted. Inbound is still authorized by source IP, so add your carrier's signaling IPs here too if this trunk receives calls.
3. Gateway — name the trunk, set its direction (inbound only / outbound only / both), the termination URI (host[:port] we send outbound INVITEs to; port defaults to 5060), and an optional default caller ID.
4. Advanced — transport (UDP only in this version), codecs (PCMU, PCMA · RFC 2833 DTMF), and status (active or disabled).
5. Review — a summary of everything you entered.
6. Validate — the wizard creates the trunk, then runs a real SIP OPTIONS ping to the termination URI to check it's reachable and report the round-trip latency (see Validating a trunk). The created trunk is kept so a failed validation never duplicate-creates on retry — you can Retry the check or fix the trunk later from the list.

Creating a trunk manually

Prefer to fill it in yourself? Click New trunk. The fields are:

Validating a trunk

Validation is a genuine connectivity check, not a config lint: Telenow sends a SIP OPTIONS datagram from this server to the trunk's termination URI and waits up to 4 seconds for a reply. It works even when the gateway's inbound listener is off, because it's an outbound probe.

• Reachable — the URI answered; the result shows the latency in milliseconds.
• Not verified — no answer in the window, or the URI isn't routable. The trunk is still created; you can fix it and re-check later.
• An inbound-only trunk has no termination URI, so validation reports that there's nothing to dial — verify your carrier points at our platform endpoint instead.

The wizard runs this automatically on its last step; you can also re-run it any time from the API (POST /orgs/:orgId/trunks/:id/validate).

DIDs on a trunk

Attach the phone numbers your carrier routes to the trunk — these are entered by hand, not searched or purchased. On a trunk card, click Add number and type the DID in E.164 (e.g. +1 415 555 0142). Each DID becomes an ordinary Telenow number row (provider sip) tied to its trunk:

• Bind an AI agent — assign the DID to an agent on the Phone numbers page. Inbound INVITEs to the DID answer with the agent (ringback plays while the first response synthesizes).
• Allocate to a team member — inbound rings the member's dashboard when they're online, with mobile fallback. See Team & workplace — the inbound-exclusivity rule applies (a DID answers with an agent or rings a member, never both; the conflict is a 409).
• Outbound — the dialer, agent calls, and campaigns dial out through the trunk using the DID as caller ID.

Remove a DID with the × on its chip (releases that number). Deleting a whole trunk releases all of its DIDs in one transaction and stops inbound to them.

Warm transfer

When an agent transfers a SIP call, Telenow acts as the bridge (B2BUA): it dials the transfer target as a second leg on the same trunk, plays ringback to the caller while it rings, then cross-wires the two legs. Both sides of the bridged conversation are recorded. If the target doesn't answer, the AI conversation resumes automatically. (Telenow does not use SIP REFER — it owns the media for the whole call.)

Billing

SIP legs carry no per-minute carrier charge from Telenow (you pay your own carrier); platform usage is billed on call duration as usual. Calls appear in Call history with disposition, duration, and recording like any carrier call.

Current limits

• UDP transport only (no TCP/TLS or SRTP yet), IPv4 only.
• IP-based inbound auth — no REGISTER. Telenow does not REGISTER to your trunk, and registration from your equipment isn't accepted. Use static termination + source-IP allow-lists (the norm for wholesale/PRI gateways). PBXes behind NAT keep media flowing via symmetric RTP latching.
• Answering-machine detection isn't available on SIP outbound.

Troubleshooting

• Inbound calls get 403 / 404. A 404 means the dialed DID isn't registered on a live sip trunk — add the DID. A 403 means either the trunk is disabled / not set to accept inbound, or the source IP isn't in the trunk's allow-list — add your carrier's signaling IPs.
• Validation says "Not verified". The termination URI didn't answer the OPTIONS ping in 4 seconds. Confirm the host/port, that it's reachable over UDP from the platform, and that your carrier admits our media/signaling IP.
• Outbound fails after answering. If your carrier challenges INVITEs (401/407) and no digest credentials are set, the dial fails — add the username/password under the trunk's auth fields.
• Calls won't connect at all. Check the Gateway status on the endpoint card. If it reads disabled, the operator hasn't set SIP_ENABLED on this deployment.

API

Everything is available over the API under /api/orgs/{orgId}/trunks — gateway config, list/create/update/delete, validate, and add/remove DIDs. See the Carriers & trunks API.