TGW Gateway for SIP Trunking: Registration, Routing, and Failover

Treating a cellular gateway as a SIP trunk endpoint is a configuration exercise with three variables: which side registers, how numbers are presented, and what happens when the endpoint becomes unavailable. Getting the first two right produces a working call; getting the third right produces a service.

This guide covers the configuration sequence for using a TGW chassis as a SIP endpoint: the registration model to choose, how numbers and routes are defined, how failover should behave, and how to cut over without discovering the failure behaviour in production.

Which side should register?

Decide it explicitly, because the default is not consistent.

Registration direction is the first decision and the one that causes the most configuration time when it is left implicit.

Two models exist. Where the gateway registers to the platform, the gateway initiates and maintains the session, and the platform treats it as a client. Where the platform registers to the gateway, the direction is reversed. Both work; the failure appears when one side assumes a model the other does not implement, and the symptom is repeated authentication attempts with no successful session.

Platform support should drive the choice. Where the platform documents a model for gateway endpoints, follow it rather than configuring the gateway freely, because the platform’s own templates encode the parameters it expects. Where the platform is open source, the documentation for Asterisk or FreeSWITCH describes how registration and failover are handled, and aligning the gateway with the behaviour the platform already implements is faster than adapting the platform.

The signalling itself is defined by RFC 3261, with the message sequences platforms expect described in RFC 3665. Both are worth consulting when a vendor claims compatibility without describing the model.

How should numbers and routes be defined?

Decide the presented format once, then write routes.

Most inbound routing failures are a mismatch between the number the gateway presents and the pattern the route expects.

Three decisions have to be made once and applied consistently. The presentation format the gateway uses for inbound calls, whether national or international. The translation point, which is either the gateway or the platform but not both, since converting in two places produces a number neither side expects. And the default destination for calls that match no route, which should exist even if it is only an announcement, because a call that matches nothing otherwise disappears without a record.

Read the inbound invitation from the platform log before writing routes. That single step converts a guessing exercise into a configuration task, because the log shows the exact value the gateway presented rather than the value someone assumed it would. The international format that the presented number should follow is defined by the ITU E.164 numbering plan.

How should failover behave?

Define the condition and destination in advance.

Failover configuration that is not tested is an assumption rather than a capability.

Three conditions need defined behaviour. Where the gateway loses its cellular registration, calls should route to an alternative trunk rather than failing. Where the SIP session drops but the radios are registered, the behaviour depends on your platform, and it should be confirmed rather than inferred. Where the platform itself is unavailable, the gateway’s behaviour determines whether callers receive a rejection or silence, and the first is preferable because it produces a record.

Two design decisions follow. The alternative path should be a real trunk rather than an aspiration, because failover to nothing is not failover. And the condition that triggers the change should be measurable by the platform, since a condition the platform cannot observe cannot trigger anything.

What should be verified before cutover?

Registration, both call directions, and the failure paths.

A cutover test that confirms only a successful call leaves the failure behaviour unknown.

1. Registration. Confirm the session establishes and survives an idle period.
2. Outbound call. Confirm the presented number matches the documented format and the call reaches the destination.
3. Inbound call. Confirm the number presented by the gateway matches a route and reaches the intended destination.
4. Audio both directions. Confirm audio flows in both directions, which is a separate check from signalling.
5. Cellular registration loss. Remove a SIM from service and confirm calls route to the alternative path as documented.
6. Session drop. Sever the SIP session and confirm recovery, and confirm what happened to calls in the interval.

Items five and six determine whether the deployment has failover or merely a configuration that describes it. Running them before cutover converts an unknown into a documented behaviour, and it is the difference between an integration and a service.

How should the cutover be staged?

Run both paths in parallel and move traffic in steps.

A cutover that replaces the existing path in one step removes the fallback at the moment it is most useful, and it makes any unexpected behaviour ambiguous.

A workable sequence has four stages. In the first, the gateway registers and carries a test number that nobody depends on, which validates registration and routing without exposing real traffic. In the second, a small group of low-consequence numbers moves across, and the same call tests are repeated on live traffic. In the third, the remaining numbers move in groups, with the previous path retained for each group until its calls have been verified. In the fourth, the previous path is withdrawn or retained deliberately as a fallback, which is a decision rather than a default.

Two practices make the sequence safe. Keep the previous configuration recorded so that reverting a group is a configuration change rather than a reconstruction exercise. And confirm after each stage that the failure paths still behave as designed, because a cutover that adds configuration can change failover behaviour without changing the parts that were tested.

Where the platform is open source, the documentation for Asterisk or FreeSWITCH describes how trunk failover is triggered, and reading the one you run is what confirms whether the staging plan exercises the behaviour you depend on.

The number format deserves one final check before cutover, because it is the most common source of a call that connects and reaches nothing. Confirm the exact value the gateway presents on an inbound call by reading the platform log, and confirm that the routes are written against that value rather than against the format the specification described.

Where the deployment serves several markets, keep the presented format and the translation point recorded per market. A single global convention is simpler to operate, but markets differ in what they expect, and a format that is correct in one market may be rejected or misrouted in another. Recording the decision per market is what prevents a later change in one market from affecting the others.

Where the requirement is voice alone, the SK VOIP Gateway range provides the same endpoint model on a dedicated device, which removes the channel contention question entirely.

How should the deployment be handed over to operations?

With a configuration record and test results.

A cutover that leaves no record of what was configured turns every later incident into a reconstruction exercise.

The handover should include the registration model and the credentials, the number format used on each side of the trunk and the single point at which translation happens, the routing table with its default destination, and the failover condition with the alternative path it selects. Each of those is a decision that was made during configuration, and a later engineer who does not know the decision will infer it from behaviour rather than from documentation.

Record the acceptance results alongside the configuration, including the failure-path tests. A results sheet that states what happened when registration was lost is what allows a later behaviour change to be recognised as a change rather than as an undocumented characteristic of the deployment.

Where the routing table will be maintained by someone else, name the person who owns it and the change process that applies. A routing table that is edited without a record becomes a source of inbound call failures that are difficult to attribute, because the symptom is a call that reaches the wrong destination rather than a call that fails.

Conclusion

Using a cellular chassis as a SIP trunk endpoint comes down to three decisions made explicitly: the registration model, which the platform should drive; the number format and the single point at which translation happens; and the failover condition, which must be measurable by the platform and must route to a real alternative. Leaving any of the three implicit produces a deployment that works until it does not.

Verification should include the failure paths rather than only a successful call, because registration loss and session drops are the conditions the configuration exists to handle. The published TGW-SMS Gateway 64-64 at $1,715.00 provides 64 ports and 64 SIM slots for deployments that need both voice and messaging on one chassis, and where the requirement is voice alone, the SK VOIP Gateway range from $260.00 upward provides the same SIP endpoint model on a device dedicated to voice.