Build your voice network with SIPGPT.

DID / phone number

A public number callers dial. Route it to a SIP user, trunk, IVR, voicemail, AI agent, or external destination.

SIP domain

The registration namespace for your SIP users, such as company.sip.sipgpt.co.

SIP user

A credentialed endpoint used by a softphone, desk phone, application, or contact center agent.

SIP trunk

A connection between SIPGPT and a PBX, carrier, SBC, or voice application, authenticated by IP or credentials.

Origination

Inbound traffic delivered from a phone number or another carrier into SIPGPT.

Termination

Outbound traffic sent from your SIP system through SIPGPT to the telephone network.

ANI

The calling number (caller ID). SIP commonly carries it in From and P-Asserted-Identity.

DNIS

The called number. SIP commonly carries it in the Request-URI and To header.

1. Create a SIP domain

   Open Configure → SIP Domain, choose a unique domain name, and use password authentication.

2. Create a SIP user

   Open Configure → SIP User, select the domain, create a username, and copy the generated password once.

3. Register a SIP client

   Enter the domain, username, password, port, and transport in your client. Confirm the user shows as registered.

4. Buy and route a DID

   Purchase a number, select SIP user as its voice destination, and choose the user you created.

5. Test from the PSTN

   Call the DID from another telephone. If it does not ring, use the call log and troubleshooting checklist below.

Change an existing route

1. Open Phone Numbers and select the DID.
2. Choose Voice routing, select the target type, then select or enter the destination.
3. Configure no-answer or unavailable failover if offered.
4. Save, place a test call, and confirm the selected route in Call Logs.

1. Create an inbound trunk

   Choose IP authentication when your provider publishes stable signaling IPs; otherwise use the supported credential method.

2. Allow the provider

   Add every documented signaling IP or CIDR. Never allow the entire internet unless the trunk has another strong authentication layer.

3. Configure the provider

   Set its primary and backup destinations to the SIPGPT ingress host and port shown on the trunk. Use the agreed UDP, TCP, or TLS transport.

4. Normalize the DID

   Send the called number in E.164 format in the Request-URI unless the route explicitly expects another format.

5. Verify signaling and media

   Confirm ANI, DNIS, P-Asserted-Identity, codecs, DTMF, and RTP source addresses in the call log.

Applies to Zoiper, Linphone, MicroSIP, Bria, Groundwire, Grandstream, Yealink and other standards-based clients.

1. Create a trunk and select Bring your own.
2. Enter a resolvable SIP URI or hostname, port, transport, and authentication.
3. Add a primary destination and, where supported, backup destinations in priority order.
4. Choose codecs, DTMF, number format, and header behavior.
5. Assign a DID, domain route, IVR option, or routing rule to the trunk.
6. Send SIP OPTIONS, place test calls, and verify failover before production.

1. Create a termination route

   Choose credential or source-IP authentication and add only the IPs that will originate traffic.

2. Set guardrails

   Allow required countries only; configure calls per second, channels, spending limits and fraud alerts.

3. Configure your switch

   Send E.164 destinations to the assigned SIPGPT termination hostname using the displayed transport and port.

4. Set an authorized caller ID

   Use a number you control. The ability to sign the call depends on verification and STIR/SHAKEN configuration.

5. Validate billing and quality

   Compare call logs, duration, rate and charge; test failure responses and backup routes.

• Upload or record a concise greeting.
• Configure timeout, invalid input, repeat and operator options.
• Use RFC 4733 DTMF on SIP legs.
• Route each menu option and define a no-answer timeout.
• Configure voicemail notification and message retention.
• Test every path from an external phone.

Normalize numbers to E.164 at the network edge. Change From, P-Asserted-Identity, Diversion, or privacy headers only when your trust and compliance policy permits it.

1. Complete the account and business verification required for calling.
2. Add and verify every caller ID you intend to originate.
3. Choose SipGPT-managed signing or configure your supported signing integration.
4. Where bring-your-own certificates are supported, upload the certificate chain securely and protect the private key.
5. Select the attestation policy permitted for the customer and number relationship.
6. Place test calls and inspect Identity/verification results in call logs.

• Block or allow exact ANI/DNIS values and prefixes.
• Restrict high-risk countries and premium destinations.
• Allowlist trusted source IPs for every IP-authenticated trunk.
• Set per-account and per-trunk CPS, channel and spend limits.
• Block anonymous or malformed traffic when the service does not require it.
• Alert on registration spikes, unusual destinations and rapid spend.
• Keep an emergency procedure to suspend a user, trunk or route.

Model Context Protocol (MCP) lets supported assistants discover and call SIPGPT tools on your behalf. External clients such as Codex, Claude, Cursor, and VS Code connect to the hosted Streamable HTTP endpoint. The built-in SIPGPT chat uses the same account-scoped tool layer through the dashboard API; the browser never calls /mcp directly.

1. Open your profile menu, choose MCP, then open AI Integrations.
2. Select Codex, Claude, Cursor, VS Code, or Other.
3. Review the requested scopes. Start with read-only access and add write access only when required.
4. Choose Connect for an OAuth-capable client, or Copy config for manual setup.
5. Complete the client authorization and run Test connection.
6. Return to the MCP page to review activity, change access, or revoke the connection.

Manual client configuration

{
  "mcpServers": {
    "sipgpt": {
      "url": "https://api.sipgpt.co/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_ONE_TIME_TOKEN"
      }
    }
  }
}

Available scopes

Scopes can only reduce access. Your account role and underlying SIPGPT permissions are always enforced as well.

1. The agent calls a prepare tool.
2. SIPGPT validates account access, pricing, inventory, and requested changes.
3. SIPGPT creates a server-owned pending action and shows an exact summary.
4. You explicitly confirm or cancel it.
5. Only the dedicated confirmation endpoint may execute the mutation.

Use the six quick actions—Buy Phone Number, Bulk Buy Numbers, Build Agent to Answer Calls, Voice Campaign, Ringless Campaign, and Build AI SMS Campaign—or describe the task in the composer. SIPGPT can return number candidates, clarification forms, versioned artifacts, and confirm/cancel cards.

Sessions are scoped to the signed-in account and user. The UI resumes event polling with a cursor, suppresses duplicate runs using clientMessageId, and shows retry state if a request is interrupted. Purchase and routing operations still require explicit confirmation.

MCP troubleshooting

• Unique SIP and API credentials
• Source-IP allowlists
• TLS/SRTP where supported
• Country and destination restrictions
• CPS, channel and spend limits
• Verified outbound caller IDs
• Primary and backup routes tested
• Webhook signatures verified
• Secrets excluded from client code and logs
• Credential rotation and incident owner defined
• Recording consent requirements reviewed
• Emergency calling limitations understood

An MCP session ID is not authentication. SIPGPT derives user and account identity from verified authorization, never from an untrusted x-user-id header. Connection secrets are shown once and stored only as hashes.