This guide is for administrators of a directly managed Asterisk system using res_pjsip. It does not use the older chan_sip syntax. If FreePBX or another interface generates your configuration, use that interface instead of editing generated files; see our FreePBX guide. Check your installed Asterisk version and its matching documentation before applying configuration.
Before you begin
This walkthrough uses an IllyVoIP line with password authentication. In SIP Lines, obtain the SIP username, SIP password, server, destination port and transport for your connection. Do not use your Portal email or login password. If the existing line uses IP authentication, do not switch it without checking the devices that depend on it.
You need administrator access to the PBX, a private configuration backup and a working internal extension for testing. An IllyVoIP SIP line connects the PBX to IllyVoIP; an extension connects a staff phone to the PBX. They are not the same account.
Start with one test extension and a destination you control. Do not move the whole office to the new trunk immediately. If the PBX already carries calls, keep the existing route available until the test is complete.
1. Build the trunk as related objects
In PJSIP, a registration is only one part of a trunk. Give the objects recognizable names, such as illy-auth, illy-registration, illy-aor and illy-endpoint. The names link the objects; they are not credentials. The exact files depend on your existing includes and configuration management.
| Field | Value to use |
|---|---|
| auth | type=auth; auth_type=userpass; username and password from the IllyVoIP line |
| registration | outbound_auth points to auth; server_uri is the server SIP URI; client_uri identifies your SIP user at that server |
| aor | Static contact points to the IllyVoIP server SIP URI used for outgoing calls |
| endpoint | aors points to aor; outbound_auth points to auth; context names a restricted incoming dialplan |
| transport | Reference your correctly configured transport; do not invent a second listener on an occupied address/port |
| identify | Map only approved incoming SIP source addresses to this endpoint when using IP-based endpoint identification |
2. Link authentication in both places
Use the line’s SIP username and SIP password in the auth object. Reference it from both registration and the outbound endpoint. A registration can succeed while outgoing calls fail if only the registration references credentials. For the registration, the general URI shape is sip:SIP_USERNAME@SIP_SERVER for client_uri and sip:SIP_SERVER for server_uri, with the required port/transport for your connection. Replace the labels with your own values; they are not literal settings.
Keep the existing transport unless a change is actually required. Some transport changes need more than a normal configuration reload. Do not restart a working PBX solely because a new account object is wrong. Make a backup and use your deployment procedure for the installed release.
3. Keep incoming calls out of the outgoing context
Create a dedicated incoming context, for example from-illyvoip, that sends only expected called identifiers to a known extension, ring group or IVR. Do not include an unrestricted internal/outbound context there. With source-IP identification, obtain the current approved signaling sources first; a registrar hostname alone is not proof of every possible incoming source.
Before writing a DID match, inspect what the PBX receives for a controlled incoming call. It may use a registration contact identifier rather than the displayed phone number. Match the observed, intended identifier instead of adding a catch-all that can dial arbitrary external numbers.
4. Add a narrow outgoing test route
In the context available only to your test extension, match the specific destination you intend to call and send it through the configured endpoint. The dial target shape is PJSIP/NUMBER@illy-endpoint. NUMBER is the destination after your chosen normalization. Do not place that dialing action in a public incoming context. After a successful test, expand only to the destination patterns and extensions your business needs.
5. Inspect state before changing settings again
At the Asterisk CLI, read pjsip show registrations, pjsip show endpoints and pjsip show aors. Check whether your named objects exist and whether the expected AOR contact is present. A registered status does not test the outbound dialplan. A missing endpoint is a configuration/loading issue, not automatically a rejected password.
If you need SIP logging for one failing test, have an administrator collect a short private trace, then disable the logger. Traces can contain phone numbers and authentication material. Compare the outgoing destination and response with the Portal call record before changing global timers, NAT or codecs.
Audio, caller ID and security
SIP transport and media encryption are separate settings. Match the Portal line’s audio mode to the PBX; Standard RTP, SDES-SRTP and DTLS-SRTP are not interchangeable. Avoid changing transport, codecs and network settings together, because you then lose track of which change fixed or broke the connection.
Use only an outgoing caller ID permitted by your account. Typing a number into the PBX does not verify it. Do not allow anonymous inbound traffic to reach public outbound routes, and do not disable your firewall. If source-IP restrictions are needed, obtain the current permitted addresses for your connection from Support rather than guessing an allowlist.
Acceptance checklist before staff use
- Check trunk registration separately from the test phone’s extension registration.
- Place a call from the chosen extension and confirm which trunk the PBX used. Check balance and rates first; this may be a chargeable test.
- Check two-way audio and the number presented to the recipient. Test keypad digits against a telephone menu you are authorized to use.
- For incoming calls, route an active IllyVoIP number to the PBX SIP line, call it externally and verify the destination inside the PBX.
- Confirm an extension without permission cannot use the test route. Expand staff access only after these checks.
Record the time, timezone, test extension, selected route and public call reference. If something fails, send these details and the PBX model/version to Support. The SIP response-code guide helps describe the failure. Do not post passwords or unredacted logs in public forums.
This guide is based on official documentation and the Portal workflow, not a claim that every PBX version has been tested through a real call. Emergency services and specialist equipment require separate configuration and verification.