Skip to main content
Use this reference with the SIP trunk procedure. The fields below describe configuration accepted by the phone-number API. They do not establish a runtime ingress address, provision a trunk, or verify media connectivity.

​
Configuration fields

Outbound headers contains literal SIP header values. attributes_to_headers maps dynamic-variable names to header names. Review which information may leave your application before proposing either mapping. Keep credentials out of these headers.

​
Review a candidate

1

Identify each direction

Write down who sends the INVITE, who receives it, and which endpoint supplies media. Carrier terms such as origination and termination must be interpreted from the carrier’s perspective.
2

Validate the request

Compare the candidate with Import phone number. Keep transport, media policy, and codecs separate; selecting TLS does not by itself prove encrypted audio.
3

Read back stored configuration

Inspect the routing identity and assignment with Get phone number. Credential-presence and trunk flags describe stored state. Import redacts credential metadata; runtime credential delivery still needs verification.
4

Define acceptance evidence

Before a supported runtime is released, document the expected SIP response, negotiated codec, two-way audio, disconnect handling, and fallback route. Run those checks only after the deployment is ready.
For failed signaling or one-way audio, collect a timestamp, direction, redacted call identifier, and the carrier’s result. Follow telephony troubleshooting.

​
Frequently asked questions

The schema describes an empty list as offering all supported codecs. Confirm the actual negotiated codec during a supported runtime test.
No. It is response metadata, not a carrier authentication result or proof that a runtime can retrieve the secret.