Skip to content
Telebyte

30 May 2026 · 9 min read · By Telebyte Solutions

VoipTalk Setup for ViciDial: SIP Trunk Configuration That Actually Works

A step-by-step working configuration for connecting VoipTalk SIP trunks to a ViciDial install — peer config, dialplan, CLI handling, inbound routing, and the errors people hit most often.

VoipTalk is the SIP carrier Telebyte uses internally and the carrier of choice for most Telebyte-managed UK ViciDial deployments. The reasons are unglamorous: their pricing is fair, their support actually understands ViciDial, and their porting team responds within working hours rather than next quarter. None of that explains why the configuration that makes them work with ViciDial is undocumented on the public web. This article fills that gap.

Everything below has been validated against a running production ViciDial deployment and against the VoipTalk-supplied test numbers. If you copy the configuration and substitute your own credentials, it will work.

What you need before you start

Before touching any configuration:

  • A VoipTalk Business or Wholesale account, with at least one SIP trunk enabled. The trial account works for testing but caps concurrent calls at one.
  • The SIP credentials VoipTalk emails after sign-up — typically a username (a numeric SIP ID), a password, and the SIP server hostname sip.voiptalk.org.
  • A working ViciDial install on Asterisk 18 or later. The configuration below is tested against Asterisk 18 LTS; Asterisk 16 and earlier have differences in sip.conf syntax that this article does not cover.
  • Outbound IP allowlisting on the VoipTalk side. Log into the VoipTalk portal and add your ViciDial server's public IP to the allowlist; without this the registration will silently fail.
  • A direct dial-in number (DDI) for inbound testing. VoipTalk allocates one with the account; if you have not seen it in your account, raise a support ticket.

If any of those preconditions are missing, the rest of this article will not get you anywhere. Sort them first.

The sip.conf peer configuration

Add this block to /etc/asterisk/sip.conf on the ViciDial server, replacing YOUR_USERNAME and YOUR_PASSWORD with the credentials VoipTalk supplied:

[voiptalk]
type=peer
host=sip.voiptalk.org
port=5060
fromuser=
fromdomain=sip.voiptalk.org
defaultuser=YOUR_USERNAME
secret=YOUR_PASSWORD
context=trunkinbound
insecure=invite,port
canreinvite=no
nat=force_rport,comedia
qualify=yes
disallow=all
allow=alaw
allow=ulaw
dtmfmode=rfc2833
trust_id_outbound=yes
sendrpid=pai
directmedia=no
videosupport=no

register => YOUR_USERNAME:YOUR_PASSWORD@sip.voiptalk.org/YOUR_USERNAME

A line-by-line walkthrough of the directives that actually matter:

  • fromuser= is deliberately blank. The temptation to set it to the VoipTalk username is universal among first-time installers and breaks per-campaign CLI rewriting. The dialplan sets the From URI; leave this empty.
  • canreinvite=no is required for ViciDial recording to work. If the carrier re-INVITEs to bridge media end-to-end, the recording engine never sees the RTP and the call records as silence.
  • nat=force_rport,comedia handles the NAT realities of a VPS-hosted ViciDial talking to a carrier over the public internet. Without this, RTP audio often arrives one-way only.
  • disallow=all then allow=alaw, allow=ulaw is the right codec stance for UK voice traffic. G.722 and Opus are sometimes available and rarely worth the trouble.
  • trust_id_outbound=yes plus sendrpid=pai is the two-line configuration that lets the dialplan set the outbound CLI and have VoipTalk respect it. Without these, VoipTalk strips the dialplan-set CLI and presents the account headline number instead.
  • directmedia=no is belt-and-braces alongside canreinvite=no — explicit double negation that media stays through the box.
  • register => is the standard registration line. The trailing /YOUR_USERNAME is what makes inbound calls route to a specific extension target.

After saving, reload SIP without restarting Asterisk:

asterisk -rx 'sip reload'
asterisk -rx 'sip show peers'

The output should show the voiptalk peer with status OK and a millisecond response time. If status is UNKNOWN for more than a minute, registration is failing — see the troubleshooting section below.

The outbound dialplan

VoipTalk expects UK numbers in international format (441234567890) on the outbound INVITE. ViciDial's dialer hands the dialplan a number in national format (01234567890) and expects the dialplan to do the conversion. The minimal outbound context, added to /etc/asterisk/extensions.conf:

[telebyte-outbound]
; Strip the leading 0 from UK national numbers and prepend +44.
exten => _0X.,1,NoOp(Outbound call to ${EXTEN})
exten => _0X.,n,Set(CALLERID(num)=${ARG1})  ; CLI passed in from ViciDial
exten => _0X.,n,Set(CALLERID(name)=${ARG2}) ; CLI name, also passed in
exten => _0X.,n,Dial(SIP/voiptalk/44${EXTEN:1},60,Tr)
exten => _0X.,n,Hangup()

; Mobiles, freephone, and other formats — pass through unchanged.
exten => _XXXX.,1,NoOp(Outbound call to ${EXTEN})
exten => _XXXX.,n,Dial(SIP/voiptalk/${EXTEN},60,Tr)
exten => _XXXX.,n,Hangup()

ViciDial calls into this context with the destination number as ${EXTEN} and the per-campaign CLI as the first and second arguments. The Set(CALLERID(num)=...) step is what surfaces the campaign CLI on the outbound INVITE. Without trust_id_outbound=yes in the peer config, the carrier will quietly replace this with the account default.

For per-campaign CLI configuration in ViciDial itself, set the Campaign CallerID field under the campaign's detail screen. ViciDial passes that value through as ${ARG1} automatically when the dialplan is wired this way.

The inbound dialplan

Inbound calls from VoipTalk arrive in the context defined by context=trunkinbound in the peer. The minimal inbound routing for a single DDI:

[trunkinbound]
; Replace 441234567890 with your VoipTalk-assigned DDI in international format.
exten => 441234567890,1,NoOp(Inbound call from ${CALLERID(num)})
exten => 441234567890,n,Goto(default,8300,1)  ; ViciDial inbound entry point 8300
exten => 441234567890,n,Hangup()

8300 is ViciDial's standard inbound-extension entry point. From there, ViciDial routes the call into the appropriate ingroup based on the configuration in the ViciDial admin UI. If your install uses a different inbound extension, substitute it.

For multiple DDIs into multiple ingroups, the pattern is the same with one exten => block per DDI. For DDIs that route to an IVR rather than directly to ingroups, replace the Goto(default,8300,1) with Goto(my-ivr-context,s,1).

Caller ID configuration

UK telephony rules permit a calling party to present any number they have a legitimate right to use. For an outbound call centre, that means:

  • A geographic number the operator owns, ported to or hosted with VoipTalk.
  • A non-geographic number (03xx) the operator owns.
  • A mobile number with the operator's documented consent.

It does not mean an arbitrary spoofed number. VoipTalk enforces this at the trunk level: any outbound CLI not on the allowlist for the account is replaced with the account default. To add a CLI:

  • Log into the VoipTalk portal.
  • Navigate to the SIP account.
  • Under Outbound CLI, add each number in international format (441234567890).
  • Save.

The change takes effect within a few minutes. If outbound calls present the wrong CLI after this step, the issue is either the dialplan (trust_id_outbound=yes or sendrpid=pai missing) or the campaign CallerID in ViciDial.

The firewall

The earlier ViciDial hosting article covers the full hardening pass. The VoipTalk-specific firewall rules:

# VoipTalk SIP signalling (TCP/UDP 5060) from the carrier's IP range.
ufw allow from 81.139.176.0/24 to any port 5060

# RTP media (UDP 10000–20000) from the same carrier range.
ufw allow from 81.139.176.0/24 to any port 10000:20000 proto udp

Replace the IP range with VoipTalk's current published egress range, which they keep up to date in the customer portal. The carriers move IPs occasionally; the firewall rules need to track.

Crucially, do not leave UDP/5060 open to the world. Public-internet SIP scanners produce thousands of fraudulent registration attempts per hour against any open SIP port, and even when they fail, the Asterisk log noise is brutal.

Testing the configuration

A quick end-to-end test sequence once the configuration is in place:

# Confirm registration.
asterisk -rx 'sip show registry'

# Confirm peer reachability.
asterisk -rx 'sip show peers'

# Place an outbound test call via the dialplan.
asterisk -rx 'channel originate Local/01234567890@telebyte-outbound application Wait 30'

Replace 01234567890 with a real test number — your mobile, ideally. The outbound test exercises the full path: ViciDial → dialplan → VoipTalk → PSTN. If the call connects and the CLI presents correctly, the configuration is working.

For inbound testing, dial the VoipTalk DDI from a separate phone. The call should land in ViciDial's inbound queue. If it does not, the most common issue is the inbound context routing rather than the SIP layer.

Troubleshooting common errors

A short list of the issues that come up most often:

  • sip show peers shows the peer as UNKNOWN or UNREACHABLE. Registration is failing. Check the credentials, check the VoipTalk allowlist includes your server's public IP, check the server can reach sip.voiptalk.org:5060 (a nc -zvu sip.voiptalk.org 5060 from the server is the quickest test).
  • Outbound calls connect but audio is one-way. Almost always an RTP firewall issue. The carrier's RTP range needs to be allowed inbound on UDP 10000–20000. If the firewall is correct, check nat=force_rport,comedia is in the peer config.
  • Outbound CLI is being rewritten by the carrier. Either trust_id_outbound=yes and sendrpid=pai are missing from the peer config, or the CLI is not on the VoipTalk allowlist. Set both and check the portal.
  • Outbound calls drop after exactly 30 seconds. Classic re-INVITE timeout. Confirm canreinvite=no and directmedia=no are both set.
  • Inbound calls do not arrive in ViciDial. The trunkinbound context routing is wrong. Confirm the DDI in the exten => line is in the format the carrier sends (some carriers send 01234567890, others 441234567890 — VoipTalk sends international). sip set debug on will show what is arriving.
  • Calls work but every call is recorded as silent. canreinvite=yes somewhere in the chain. Audit every peer in sip.conf; the offender is usually a leftover from a previous configuration.

For anything else, VoipTalk's support team responds within working hours and they understand ViciDial. Raise a ticket with the relevant sip set debug on output and the call trace.

Monitoring the trunk health

A working trunk on day one is not the same as a working trunk in week thirty. Telebyte monitors every production VoipTalk integration on three metrics:

  • SIP round-trip time to sip.voiptalk.org — alert when the seven-day rolling average exceeds 50ms or the per-minute peak exceeds 200ms.
  • Registration uptime — the peer status should be OK 99.95 per cent of the time. Brief flaps are normal; sustained UNREACHABLE longer than five minutes is an incident.
  • Codec negotiation failures — Asterisk logs these as No matching codec found. Any non-zero rate is worth investigating; it usually indicates the carrier has updated their codec menu and the peer config has drifted.

A small Prometheus exporter against Asterisk's AMI socket surfaces all three metrics in under an hour of work. Grafana dashboards on top, alerts to whichever paging system the operations team uses.

Adding a second carrier for failover

For any operation where a few hours of outbound downtime is a meaningful business event, the right architecture is two SIP carriers configured in parallel — VoipTalk as primary, a second provider (Gradwell, Magrathea, or another reputable UK SIP carrier) as failover.

The configuration pattern in ViciDial:

[gradwell]
type=peer
host=sip.gradwell.net
; ... rest of peer config matching the VoipTalk pattern.

In the dialplan:

exten => _0X.,1,NoOp(Outbound call to ${EXTEN})
exten => _0X.,n,Set(CALLERID(num)=${ARG1})
exten => _0X.,n,Dial(SIP/voiptalk/44${EXTEN:1},60,Tr)
exten => _0X.,n,GotoIf($["${DIALSTATUS}" = "CHANUNAVAIL"]?failover:end)
exten => _0X.,n(failover),NoOp(Failing over to Gradwell)
exten => _0X.,n,Dial(SIP/gradwell/44${EXTEN:1},60,Tr)
exten => _0X.,n(end),Hangup()

The pattern is straightforward: if the primary trunk returns CHANUNAVAIL, the dialplan retries the same call against the failover trunk. The customer experience is a slightly longer connect time on the rare occasions when the primary is down; the operational benefit is that the outbound dialler keeps running through a carrier outage.

The cost of the second trunk is typically minimal — most UK carriers will sell a low-volume secondary for under £20/month. The benefit is the ability to honestly tell a board "yes, we have carrier-level failover" rather than the more common "yes, we have monitoring that will tell us when we're broken".

Stuck on a SIP-trunk configuration that should be working and isn't? Tell Telebyte what you're seeing — Telebyte handles configurations like this as a one-hour fixed-price diagnostic.

voiptalkvicidialsipasteriskuk-telephony
← Back to all articles

Want help applying this to your own stack?

Tell Telebyte what you’re trying to do. One working day to a straight answer.

Start a conversation