SIP routing methods#

The routing method determines how DIDWW locates the customer SIP endpoint for an inbound call. An inbound SIP trunk uses either Static Endpoint or Dynamic Registration. Both methods deliver standard SIP call signaling. They differ in how the destination is supplied and maintained.

Routing method comparison#

Characteristic

Static Endpoint

Dynamic Registration

Destination source

Host and optional port configured on the DIDWW trunk.

Contact address supplied by the customer system in SIP REGISTER.

Customer address

Normally stable and publicly reachable by DIDWW.

May change between successful registrations.

Authentication direction

DIDWW can optionally authenticate to the customer endpoint with SIP digest credentials.

The customer system authenticates its registration to DIDWW with the credentials generated for the trunk.

Destination maintenance

Updated in the User Panel or resolved from the configured hostname.

Refreshed by the customer system through repeated registration.

Multiple destinations

Supported through DNS SRV or by placing multiple trunks in a Trunk Group.

Up to 10 simultaneous registrations are supported for one trunk.

Common use

PBX, SBC, or application with a fixed IP address or DNS hostname.

PBX or endpoint with a dynamic address, NAT, or registration-based connectivity.

Static Endpoint routing#

With Static Endpoint, DIDWW constructs a SIP Request-URI from the trunk’s configured user part, host, and optional port. DIDWW then resolves the host as needed and sends a SIP INVITE to that destination.

        %%{init: { "theme": "base", "themeVariables": { "actorBkg": "#e6f7ff", "actorBorder": "#1890ff", "noteBkgColor": "#fff7e6", "noteBorderColor": "#fa8c16" }}}%%
sequenceDiagram

   participant Caller as 📞 Caller
   participant DIDWW as DIDWW
   participant Endpoint as 🖥️ SIP endpoint
   Caller->>DIDWW: Calls the DID number
   DIDWW->>DIDWW: Select assigned trunk and resolve host
   DIDWW->>Endpoint: INVITE to configured destination
   Endpoint-->>DIDWW: SIP response
   DIDWW-->>Caller: Call proceeds or fails

Destination construction#

The Static Endpoint destination is the SIP Request-URI DIDWW places in the outbound INVITE, built from these values:

  • User Part of R-URI — Identifies the called resource. The {DID} placeholder inserts the called DID number in E.164 format. The resulting value appears before @ in the SIP Request-URI.

  • Host — The public IP address or DNS hostname of the receiving SIP system.

  • Port — The destination signaling port. When present, DIDWW sends the call to that port after resolving the host. When empty, DIDWW performs DNS SRV discovery.

For example, a user part of {DID}, a host of sip.example.com, and a port of 5060 produce a destination in this form:

sip:{DID}@sip.example.com:5060

The endpoint must be reachable on the selected transport and port and must accept signaling from the relevant DIDWW SIP signaling addresses. These fields are configured under the trunk’s Static Endpoint settings.

DNS resolution and multiple destinations#

When a port is configured, DIDWW resolves a hostname through DNS address records and sends the request to the resulting address. When the port is empty, DIDWW uses DNS SRV records to discover multiple targets behind one host, with failover between them within the same call attempt. For the SRV records, target selection, and fallback behavior, see DNS SRV failover.

Static Endpoint is appropriate when the receiving service has a stable public address or a DNS name maintained by the customer. If the endpoint cannot be reached reliably at a single configured destination, use Dynamic Registration or place multiple trunks in a Trunk Group for failover.

Preferred Server routing examples#

The trunk’s Preferred Server determines which DIDWW Point of Presence delivers calls to the Static Endpoint. See Preferred Server values for the available settings.

Specific Preferred Server#

If you select a specific Preferred Server on a trunk, DIDWW delivers the call through that Point of Presence even when another DIDWW location initially receives the call. In the following example, the call reaches the Hong Kong location and is forwarded through Frankfurt because the trunk uses FRA.

Inbound call received in Hong Kong and routed through the preferred Frankfurt Point of Presence

Fig. 1. Routing through a specific preferred server#

Auto#

With Auto, calls can be delivered from the DIDWW Point of Presence that received them without being forwarded through a different location. DIDWW can use an alternative Point of Presence when one becomes unavailable.

Inbound call delivered automatically through the DIDWW Point of Presence that received it

Fig. 2. Routing with Preferred Server set to Auto#

Dynamic Registration routing#

With Dynamic Registration, the customer SIP system sends authenticated SIP REGISTER requests to a DIDWW registrar. DIDWW stores the current Contact address and uses it as the destination for calls assigned to that trunk. SIP registration behavior is defined by RFC 3261.

        %%{init: { "theme": "base", "themeVariables": { "actorBkg": "#e6f7ff", "actorBorder": "#1890ff", "noteBkgColor": "#fff7e6", "noteBorderColor": "#fa8c16" }}}%%
sequenceDiagram

   participant Caller as 📞 Caller
   participant DIDWW as DIDWW
   participant Endpoint as 🖥️ SIP endpoint
   Endpoint->>DIDWW: REGISTER with credentials and Contact
   DIDWW-->>Endpoint: 200 OK
   Caller->>DIDWW: Calls the DID number
   DIDWW->>DIDWW: Select assigned trunk and active Contact
   DIDWW->>Endpoint: INVITE to registered Contact
   Endpoint-->>DIDWW: SIP response

Registration and contact selection#

The customer system registers using the username and password generated for the inbound trunk. See View SIP registration credentials. It may use the global sip.didww.com registrar for automatic DNS-based load balancing between locations or a documented regional registrar. See SIP Registrars for the full list of registrar hostnames. The system must refresh the registration before it expires so that the Contact remains available for inbound routing. You can confirm active registrations in the Registration History.

A trunk supports up to 10 simultaneous registrations. This permits more than one active Contact to be associated with the trunk. DIDWW uses the active registration state when selecting where to deliver a call. The customer systems are responsible for maintaining their own registrations.

When Use DID in R-URI is enabled, DIDWW replaces the registered Contact’s user part with the called DID number in the inbound INVITE. This helps the receiving system distinguish calls for different DID numbers that share the same registered trunk. This setting is configured under the trunk’s Dynamic Registration settings.

Dynamic Registration is appropriate when the customer endpoint has a dynamic public address, operates behind NAT, or is designed to receive calls through a registration. If no valid registration is available, DIDWW has no current Contact to which it can deliver the call through that trunk.

Choosing a routing method#

Choose Static Endpoint when:

  • The receiving SIP system has a stable public IP address or DNS hostname.

  • You want DIDWW to route to a destination explicitly configured on the trunk.

  • You want to use customer-managed DNS SRV records for endpoint discovery, priority, and weight.

Choose Dynamic Registration when:

  • The receiving system’s public address can change.

  • The system is behind NAT and maintains outbound registrations.

  • Registration is the endpoint’s normal method for receiving SIP calls.

Choose one method per trunk. To provide failover between different trunks or between SIP and PSTN destinations, place those trunks in a Trunk Group rather than treating the routing methods as simultaneous settings on one trunk.