Before you begin
Collect the trunk IDs, number assignment, SIP domain, and authentication details from the Plivo administrator. Zentrunk separates inbound and outbound trunks. Its trunk API reference identifies an inbound primary URI and optional fallback URI; outbound trunks use IP access controls, credentials, or both.Review both directions
1
Identify the inbound destination
Record the primary URI and any fallback URI attached to the inbound trunk. Keep their priority and expected behavior in the release plan. Do not replace them with an assumed Threetone address.
2
Identify outbound authentication
Record the outbound trunk domain and the associated credential or IP access-control configuration. The source address must match the future deployed runtime, not a developer laptop.
3
Map the accepted fields
Compare transport, media policy, credentials, and codecs with the SIP reference. Keep Plivo management credentials separate from SIP username and password.
4
Prepare acceptance and rollback
Wait for a released runtime destination and credential handoff. Then test each direction independently and verify the provider’s configured fallback behavior before expanding traffic.
Failure handling
An outbound authentication error and an unreachable inbound URI require different fixes. Capture the trunk direction, provider call identifier, timestamp, and SIP result. If fallback is unexpectedly used, investigate the primary destination before removing the fallback. See Plivo’s Zentrunk documentation for provider-side configuration.Frequently asked questions
Does an inbound trunk prove outbound calling works?
Does an inbound trunk prove outbound calling works?
No. Zentrunk’s inbound and outbound objects have different destinations and authentication requirements.
Will Threetone create the primary and fallback URIs?
Will Threetone create the primary and fallback URIs?
No. Import does not provision provider resources. The deployment must supply and verify its actual supported runtime destinations.