Setting Up an AI Phone Assistant with Netgsm and Verimor SIP Trunks

For businesses, the phone line is one of the most important points of customer trust and warm sales. Yet when it comes to connecting an existing 0850 or landline number to an AI call center, many teams hesitate because of carrier incompatibilities, SIP settings that change by accident, or calls dropped when they are transferred to a live agent.

Yanitly runs on its own voice infrastructure rather than a third-party voice middleman: a call from your carrier reaches Yanitly's edge PBX nodes, is answered by a real-time voice model, and is transferred to your team when needed. This guide explains how to connect Netgsm, Verimor, and other business SIP trunks without porting numbers, why your settings do not change by accident, and how carrier rules are respected during transfers.

In business voice infrastructure, re-saving an existing number must never change its working SIP server unless that change is explicitly requested; configuration safety rests on server-side rules, not assumptions.

Connecting 0850 and Landline Numbers Without Porting

Changing an 0850 or area-code number that has been on your signs, website, and contracts for years is an operational risk. Yanitly's voice infrastructure answers your number over a SIP trunk without disturbing your subscription with your current carrier. No number porting is needed; the connection is made with the SIP credentials from your carrier.

If your carrier requires IP authorization, you add the SIP ingress address that the Yanitly team gives you during setup to the allow-list in your carrier's panel. Both inbound and outbound SIP traffic flow through that address. We share it directly during setup rather than in public documentation.

Redundant SIP Ingress

Carriers often accept only a single destination address for a SIP account. Yanitly meets this constraint by running more than one edge node behind a single ingress address. During planned maintenance, the ingress address can be moved to the standby node. The move completes quickly, but calls in progress at that moment may be affected, so these moves are done in a controlled way at low-traffic hours.

Explicit Carrier Selection and Protected Settings

In environments with many lines, a common accident is the SIP server behind a number being changed to a default value while someone updates the assistant settings or working hours. A line running on Verimor, for example, can quietly switch to another carrier's server during a form save and lose its registration.

Yanitly closes this risk on the server. In the panel, the carrier is never preselected; the panel may suggest one based on your existing lines, but you make the choice. The options are Verimor, Netgsm, and custom SIP.

The server also enforces these rules:

1. 1.The existing server is kept: An older client that sends no carrier, or a request that only changes assistant settings, cannot change the registered SIP server; the event is noted in the audit log.
2. 2.New credentials for a new server: When moving to a server other than the known carriers, the username and password are both required; a stored password is never carried over to a new server.
3. 3.Unsupported servers are rejected: If the address is not among the servers the edge nodes support, the request is rejected without saving anything.
4. 4.The old registration returns on rejection: If the edge node definitively rejects the new registration, the previous working SIP registration is restored automatically.

One Line's Error Does Not Affect the Others

Every SIP registration is handled separately on the edge nodes. A single line with wrong credentials does not stop the other lines on the same node from syncing.

Privacy Between Businesses

The list of supported servers shown to a business contains only known carrier addresses and that business's own lines; another business's private PBX address never appears in any response. SIP passwords are stored encrypted and are not included in responses to the panel.

Carrier Rules and Caller Numbers on Live Transfers

When the voice AI assistant understands a caller's request and transfers the call to an agent on the sales or support team or to the company's cloud PBX, a strict telecom rule applies: caller number verification. If the customer's mobile number is presented as the calling number on the transfer leg, carriers may treat the call as coming from a number the business does not own and reject it with Q.850 cause code 21.

The Transfer Leg Leaves with Your Business Number

Yanitly is therefore designed to present your business's own number as the calling number on the transfer leg. The customer's number travels in the display name field, so on PBXs that show it, the agent can see the customer's number when the call rings. Turkish numbers are shown in a familiar format; if the caller hid their number, the display name stays empty, and the raw display name of the incoming call is never carried onto the transfer leg.

For this to work, your carrier must have enabled outbound calling for the number used in transfers. A test call to the transfer line is made during setup. A successful test call does not prove that every live transfer will succeed, so we also watch the first real transfers together with you.

Blind and Warm Transfer Scenarios

In a blind transfer, the assistant hands the call straight to the target number. In a warm transfer, the agent is called first and the call is then connected to them, so the agent is ready to greet the customer. In both cases, the transfer leg leaves with your business number and the customer's number appears in the display name on PBXs that support it.

If they wish, your agents can call the customer back from the company number after the conversation, as described in our guide to calling customers from your business number with the Web Call Desk and mobile app.

Bringing a Netgsm or Verimor Line Online, Step by Step

To connect a new business line to Yanitly's voice infrastructure, follow these steps:

1. 1.Prepare in your carrier panel: Get the SIP username and password for the number from your Netgsm or Verimor panel; if IP authorization is required, add the SIP ingress address provided during setup to the allow-list, and check outbound calling permission for the number used in transfers.
2. 2.Choose the carrier in Yanitly: On the voice channel screen under My Numbers or Channels, explicitly choose Verimor, Netgsm, or custom SIP.
3. 3.Register and check status: Save your credentials and confirm that the line shows as active.
4. 4.Transfer and hours rules: Configure your transfer lines and the after-hours routing and callback flow, then open the line to live traffic.

Monitoring in Production

Once the line is live, check these points regularly during the first days:

• Registration status: Confirm that the line shows as active in the panel and that the registration does not drop on the carrier side.
• Transfer results: Check that the first real transfers reach the agent and that the agent sees the customer's number.
• After-hours flow: Watch that calls arriving outside working hours turn into callback requests and reach your team. If a carrier rejects a transfer, the most common cause is outbound permission for the number used in transfers; check that permission with your carrier. If you are curious about choppy audio and latency in real-time voice, see our article on choppy audio and RTP pacing in voice AI.