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, TCP or TLS, media is RTP (or SRTP) in whichever codec the two sides agree on, 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 and TCP (same port, default 5060), plus TLS on its own port (default 5061) when the deployment has a certificate configured. The card lists exactly which transports this gateway is listening on.
• Media IP — where RTP/RTCP flows from/to. Allow-list it on your side. RTP and RTCP use a pair of adjacent ports per call.
• Codecs / DTMF — every codec this gateway build negotiates, in the platform's preference order (see Codecs, SRTP and transports); DTMF via RFC 4733 / 2833 telephone-event (and SIP INFO). If the platform's default SRTP policy is optional or required it is shown here too.
• 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.

Codecs, SRTP and transports

Every call is negotiated with standard SDP offer/answer (RFC 3264), so the trunk and Telenow settle on a codec per call rather than being pinned to one:

• Codecs — the gateway can carry G.711 μ-law and A-law, G.722, G.726-32 (both nibble orders), L16, and — when the deployment is built with them — Opus, GSM, Speex, iLBC, AMR-NB/WB and G.729. The endpoint card lists what this deployment has. Comfort noise (CN) from your side is accepted.
• Preference — by default we offer everything, G.711 first (it is the platform's native format, so nobody transcodes). A trunk's Codec preference reorders or restricts that list per trunk: put PCMA first for an Indian A-law trunk; put G722 or opus first to run an agent under a wideband codec. On inbound calls we answer with the codecs we have in common — in your order (RFC 3264) unless the trunk sets a codec preference, in which case that order wins; on outbound we offer the list and use whatever your side picks first.
• A note on audio quality — the agent pipeline itself runs at 8 kHz. A wideband codec on the wire negotiates and carries audio correctly, but the caller hears narrowband speech.
• SRTP — media encryption with SDES keys in the SDP (RTP/SAVP, suites AES_CM_128/256_HMAC_SHA1_80/32 and AEAD_AES_128/256_GCM). The trunk's Media encryption setting is off (plain RTP; an encrypted offer is refused), optional (encrypt whenever the trunk offers keys — including the Asterisk/FreeSWITCH habit of keys on RTP/AVP — and offer keys ourselves), or required (SRTP or the call is refused with 488). Leave it on Platform default to follow the deployment's SIP_SRTP policy. SRTP normally goes with SIP over TLS so the keys themselves travel encrypted.
• Transports — inbound calls arrive over whatever your trunk connects with. For calls we place, the trunk's Signalling transport (udp, tcp, tls) chooses; a termination URI written as sips:… or with ;transport=tls overrides it. TLS trunks are certificate-verified against the system trust store (the operator can relax that for a self-signed PBX with SIP_TLS_VERIFY=false).
• Mid-call changes — hold/resume, codec changes and media re-anchoring by an SBC (re-INVITE or UPDATE) are honoured, as are "late offer" INVITEs that carry no SDP.
• Not supported — DTLS-SRTP / ICE (the WebRTC style of key exchange) is declined with 488; use SDES. Browser callers do not come in this way — they use the web widget.

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 — unless you tick Register to this provider, in which case calls from the registrar are admitted automatically (see Registration-based trunks).
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 — the signalling transport we use to call the trunk (UDP / TCP / TLS), the media encryption policy, an optional codec preference, and status (active or disabled). All three media settings can be left at their defaults and changed on the trunk later.
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:

Registration-based trunks

Wholesale carriers and CPaaS trunks authenticate by source IP. The other half of the market — ITSP accounts, hosted-PBX seats, any trunk sold to equipment on a broadband line without a static IP — works the other way round: you register to them with a username and password, and the provider sends your calls to wherever you registered from.

Turn on Register to this provider on a trunk (or tick it on the wizard's Auth step) and Telenow does exactly that:

• It sends REGISTER to the trunk's termination URI with the trunk's digest credentials, answers the challenge, and keeps the binding refreshed on the registrar's own schedule (a shorter lifetime in the 200 OK, or a 423 Interval Too Brief, are both honoured).
• Registration domain (optional) is the address-of-record domain, for providers whose realm differs from the host you register to; Registration user (optional) is the account's user part when it differs from the digest username. Expiry is the lifetime we ask for (60–3600 s, default 600).
• Inbound calls from the registrar's address are accepted onto the trunk without listing it in the allow-list (its proxies, if different, still need to be listed).
• Outbound INVITEs on a registering trunk use the registration domain in From unless the trunk sets its own From domain.
• The trunk card shows the live state — registered (with the seconds left), registering, or failed with the registrar's own reason (403 account refused, 404 unknown user/domain, no response…). Failures retry on a backoff (30 s → 5 min) forever; nothing is queued while unregistered, calls simply don't arrive, so watch the chip after saving.

Telenow does not act as a registrar: your PBX or handset cannot register to Telenow. For that topology use a static termination and an IP allow-list.

Early media on outbound calls

When Telenow places a call, the network usually says something before anyone answers: ringback, or a recorded announcement — "the number you are calling is switched off", "not reachable", "busy", often after SIT tones. Indian mobile networks in particular deliver these as audio in a 183 Session Progress rather than as a SIP failure code, and some never release the call at all.

The gateway listens to that pre-answer audio and classifies it in a few seconds (ringback tone, announcement, SIT tones, silence):

• The verdict lands on the call record next to the SIP outcome, so a 480 or a timeout reads "early media: a network announcement (5.4 s of speech-like audio before any answer)" instead of a bare code.
• A recorded announcement that runs past the platform's threshold (default 6 s) with no ringback ever heard cancels the dial immediately and records carrier announcement as the cause — a campaign learns "switched off" in ~7 s instead of ringing out for 30–60 s. Ringback never cancels anything; a call that rings and is not answered still gets the full ring window.
• On a warm transfer, the person being transferred hears the real network — ringback, an IVR, an announcement — instead of Telenow's synthetic tone as soon as the far end sends audio. Transfer legs are never cancelled on announcements (a "please hold" IVR before pickup is legitimate).

The operator can tune or disable the cancel (SIP_EARLY_ANNOUNCEMENT_CANCEL_MS, 0 = classify only) and early media altogether (SIP_EARLY_MEDIA=false).

Validating a trunk

Validation is a genuine connectivity check, not a config lint: Telenow sends a SIP OPTIONS from this server to the trunk's termination URI — over the trunk's own transport, so a TLS-only SBC is probed over TLS — 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

• No inbound REGISTER. Telenow registers to providers (see above) but is not a registrar: registration from your equipment isn't accepted. Use static termination + source-IP allow-lists for that topology. This applies over TCP and TLS too — a connection is not an identity. PBXes behind NAT keep media flowing via symmetric RTP latching.
• SRTP keys are SDES only — DTLS-SRTP / ICE offers are refused (488).
• IPv6 media needs the deployment to have a public IPv6 configured (SIP_PUBLIC_IP6); otherwise IPv6 offers are refused.
• Early media is classified and relayed to a transferred caller, but the AI agent itself does not hear pre-answer audio (nothing to converse with before the answer).
• Answering-machine detection isn't available on SIP outbound.

How we dial out

Carriers disagree about how a dialled number should look on the wire, and many answer a format they don't expect with 404 Not Found or 484 Address Incomplete rather than anything descriptive. The How we dial out section on each trunk controls what we put in the outbound INVITE:

New trunks default to E.164 with +. Trunks created before this setting existed keep the Digits only behaviour they have always had — nothing about them changes until you edit them here. Editing any other part of a trunk never moves its dial plan: each of these four settings is preserved unless you change it.

If your carrier expects the digits-only form, pick it explicitly; E.164 with + being the default is a starting point, not a requirement.

Media is offered as every codec the gateway has, G.711 μ-law and a-law first (or the trunk's own codec preference), so a-law-only trunks — the norm across India and Europe — negotiate without a transcoding licence on your side, and a trunk that prefers G.729 or G.722 gets it if this deployment carries it.

Troubleshooting

Every failed trunk call records why on its call record — the carrier's SIP code, its reason phrase, any Warning/Reason header it sent, and a hint about which setting to change. Open the call from Call history and read the "Why this call didn't connect" banner before changing anything; the code below tells you which of these sections applies.

• Outbound calls fail instantly (0 seconds) with 403 Forbidden. The trunk refused the call. Either your carrier hasn't whitelisted this platform's signalling IP (shown on the endpoint card at the top of the page), or the caller ID isn't one the trunk may present. If your carrier requires an asserted identity, set the From / P-Asserted-Identity domain and turn on Send P-Asserted-Identity.
• Outbound calls fail instantly with 404 Not Found or 484. The carrier couldn't route the number in the format we sent. Change Number format on the trunk — Indian trunks usually want E.164 with + or one of the national forms.
• Outbound calls fail with 488 Not Acceptable Here. No common media: the carrier accepted none of the codecs we offered, wants SRTP we are not configured to send (or the reverse), or uses DTLS key exchange. Check the trunk's Codec preference and Media encryption against what the carrier documents; the Warning header on the call record names which of the three it was (305 codec, 306 encryption, 302 transport).
• Inbound calls get 488. Same causes, our side refusing: the offer had no codec we run, offered RTP/SAVP while the trunk's encryption is off, sent plain RTP while it is required, or used DTLS/ICE.
• Audio is silent in one or both directions on an SRTP trunk. Usually a key mismatch — both sides negotiated but one is decrypting with the wrong key. The gateway logs a warning on the first packet that fails authentication.
• Outbound calls fail with "carrier announcement". The network played a recorded message instead of ringing — the number is switched off, out of coverage or not in service — and the dial was cancelled early (Early media). Retry later; nothing is wrong with the trunk. If a legitimate destination plays an IVR before answering and gets cut, the operator can raise or disable SIP_EARLY_ANNOUNCEMENT_CANCEL_MS.
• The trunk card says "registration failed". Read the reason on the chip: 403 means the provider refused the account (wrong username, or the account is locked/unpaid), 404 means the registration domain or user is not one the registrar knows, "no response" means the termination host/port/transport is wrong or a firewall is in the way. Fix the trunk and the next retry (≤ 5 min) picks it up; editing the trunk re-registers immediately.
• Outbound calls fail with "no SIP response". Nothing came back at all within 32 seconds of retransmits. Almost always our source IP is not whitelisted on your side, a firewall is dropping UDP 5060, or the termination host/port is wrong. Note that Test connection can still pass here — it probes from a different socket, so it proves the host answers SIP, not that your trunk admits our calls.
• 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 over the trunk's transport. Confirm the host/port and transport (a TLS trunk needs 5061 or an explicit port; a self-signed certificate needs the operator's SIP_TLS_VERIFY=false), that it's reachable from the platform, and that your carrier admits our media/signaling IP.
• Outbound fails with 401 / 407. Your carrier challenges INVITEs for digest auth and no credentials are set — 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.