VoIP and SIP recap before your first VICIdial carrier

Start here

Before you configure a real carrier, confirm — on your own build — which transport your SIP stack is actually using and which port it is bound to. Do not assume a fixed number from any guide, including this one.

This lesson is short by design: it is a recap and a gate, not a fresh glossary. If you have not yet read the VoIP-basics and SIP-basics lessons earlier in this path, do that first — the two checks below assume you already know what a transport and a listening port are.

This is also the last lesson before this curriculum's optional carrier stage. Everything up to here has worked with no carrier, no DID, and no real phone number. Once you continue past this lesson, that changes — which is exactly why the two checks below exist as a deliberate pause before that change.

Notice that this stage is optional in this curriculum's own structure, unlike everything before it. Reaching a working VICIdial administration skill set does not require a real carrier at all; connecting one is a separate decision with its own cost, compliance and authorization requirements that this lesson does not attempt to grant.

The first-agent-call lesson earlier in the required path already demonstrated a real, working call using an internal test destination — proof that the dialer stack itself functions end to end. What a carrier adds beyond that is reachability to and from the public telephone network, which is a meaningfully larger commitment than anything asked of you so far.

Nothing in this lesson's two checks depends on which carrier you eventually choose, or whether you choose one at all. They read this build's own configuration, which is exactly why they belong here, at the boundary, rather than inside any specific carrier's own setup lesson.

The idea in plain language

This lesson assumes you already read the VoIP-basics and SIP-basics lessons earlier in this path, which define signaling versus media, codecs, DTMF, trunks and DIDs. Those terms are used here, not re-taught. A carrier configuration fails in confusing ways when someone assumes a port or transport that their particular build does not actually use — which is why the checks below come before any carrier or firewall step, not after.

A carrier provider will typically ask you to state which port and protocol they should expect traffic on, or will tell you which port they expect to receive it from. Getting that number from your own running configuration, rather than from a remembered default, is the difference between a carrier setup that works on the first attempt and one that requires a support ticket to a provider who cannot see your server at all.

It is worth restating plainly why this lesson refuses to print a single fixed port number in its own prose: any number written down here would be true only for the exact build this curriculum happened to check on one particular day. Your own install may differ the moment someone reconfigures PJSIP, applies an update, or follows a different activation guide than this curriculum's demo did.

Confirm your transport

Ask Asterisk directly which PJSIP transport is configured and bound, rather than assuming a number from documentation written for a different build. `pjsip show transports` lists each configured transport by name, its protocol, and the address and port it is bound to — everything a firewall rule or a carrier's own configuration needs, read from the one place that cannot be out of date.

asterisk -rx 'pjsip show transports'

Confirm the listening port from the network side too

Cross-check the previous result against what the operating system itself reports listening, so a firewall rule is based on two independent confirmations rather than one. `ss` reports the kernel's own socket table; filtering it to the asterisk process name confirms not just that a port is open, but that the specific process you care about is the one holding it open.

ss -lnup | grep asterisk

Map your own network path

Confirm the lab's own IP addressing and routing before any SIP configuration. This is diagnostic only. A carrier trunk depends on your server's address being reachable, and its route out being the one you expect — a lab with two network interfaces, or an unexpected default route, is worth understanding before a carrier's signaling starts arriving somewhere you did not plan for.

ip -brief addressip route

Ready for the next lesson

Only after you have approved carrier credentials and authority should you continue to the SIP carrier setup lesson. Bring the transport, port and network-path values you just confirmed — the carrier lesson asks for exactly these three when it builds its first trunk configuration.