This guide follows Yeastar P-Series Software Edition. Appliance and Cloud editions can differ in menus and available features, so use their matching manuals if that is your installation. Start with one extension and one trunk; an existing working office setup should not be replaced with a whole-system template.
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. Choose Register Trunk, not Account Trunk
Open Extension and Trunk → Trunk → Add. Name the connection, enable it and choose the General ITSP template when no verified IllyVoIP-specific template is available. Select Register Trunk for this password-authenticated connection. An Account Trunk serves the opposite direction: another device registers to the Yeastar system. Choosing it will not make Yeastar register to IllyVoIP.
| Field | Value to use |
|---|---|
| Hostname/IP / Port | IllyVoIP SIP server and destination port |
| Username | The line’s SIP username |
| Authentication Name | The line’s SIP authentication identity |
| Password | SIP password |
| Domain | The supplied SIP domain; follow the trunk guide if no separate domain is provided |
| Transport | The supported transport for this connection |
Save and apply the trunk, then inspect its registration state. Add an outbound proxy only when the connection requires one. Do not use the example credentials from the vendor manual. If using an IP-authenticated service instead, that is a separate peer-trunk configuration, not a reason to remove the password from this recipe.
2. Build a controlled outgoing route
Open Call Control → Outbound Route and add a route. Choose the IllyVoIP trunk, the intended number pattern and only the test extension initially. Review the existing default and earlier matching routes; a broad route can take precedence or permit more destinations than you intended.
Pattern chooses which dialed numbers match. Strip removes leading digits, while Prepend adds digits. Write down an example before saving. If users already dial the country code, do not add it again. If an office access digit is used, remove that digit only. After the test, add the staff extensions and destination patterns that are actually authorized.
3. Decide where incoming calls should go
Route the active number in IllyVoIP to this SIP line. Then open Call Control → Inbound Route, select the trunk, match the intended DID identifier and choose a known internal destination. For the first test, use one extension; add office hours or IVR handling after the simple path works.
The DID pattern describes the number being called. The caller-ID pattern describes the person calling it. Do not enter your business number in the caller-ID filter when you mean to select the incoming DID. If a default IVR answers instead of your extension, check existing route matches and time conditions before editing credentials.
4. Check caller-ID overrides in one place at a time
A trunk, route or extension can influence the proposed outgoing caller ID. Begin with the permitted number selected for the IllyVoIP line and avoid adding several competing overrides. An override in Yeastar cannot grant permission that the IllyVoIP account or package does not allow. If the number is wrong, compare the extension, route and trunk choices deliberately rather than replacing the authentication username with a phone number.
5. Handle partial success logically
If the trunk registers but the extension cannot dial, inspect that extension’s route access, the matching pattern and trunk sequence. If calls enter Yeastar but reach the wrong destination, inspect inbound matching and business-hour rules. If a call is rejected by IllyVoIP, record the time and response and compare it with Portal history.
Keep a note of the previous trunk/route settings and test one change at a time. Do not remove a working default route during business hours unless you have accounted for every extension that uses it. A test route and one test extension let you establish the new connection without changing the rest of the office.
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.