> ## Documentation Index
> Fetch the complete documentation index at: https://docs.threetone.in/llms.txt
> Use this file to discover all available pages before exploring further.

# SIP reference

> Map inbound and outbound SIP fields to a carrier review, and distinguish saved configuration from negotiated call behavior.

Use this reference with the [SIP trunk procedure](/agents-platform/deploy/telephony/sip-trunk). 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

| Direction | Field | Review with the trunk operator |
| - | - | - |
| Inbound | `allowed_addresses` | Source IP addresses or CIDR ranges expected to send calls. |
| Inbound | `allowed_numbers` | Caller numbers allowed by the intended routing policy. |
| Inbound | `remote_domains` | Remote certificate domains for the TLS design. |
| Outbound | `address` | Hostname or IP receiving the SIP INVITE. |
| Outbound | `transport` | `auto`, `udp`, `tcp`, or `tls`. |
| Both | `media_encryption` | `disabled`, `allowed`, or `required`. |
| Both | `credentials` | Optional SIP digest username and password. |
| Outbound | `enabled_codecs` | `G722/8000`, `PCMU/8000`, or `PCMA/8000`. |

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

<Steps>
  <Step title="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.</Step>
  <Step title="Validate the request">Compare the candidate with [Import phone number](/api-reference/agents-platform/import-phone-number). Keep transport, media policy, and codecs separate; selecting TLS does not by itself prove encrypted audio.</Step>
  <Step title="Read back stored configuration">Inspect the routing identity and assignment with [Get phone number](/api-reference/agents-platform/get-phone-number). Credential-presence and trunk flags describe stored state. Import redacts credential metadata; runtime credential delivery still needs verification.</Step>
  <Step title="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.</Step>
</Steps>

For failed signaling or one-way audio, collect a timestamp, direction, redacted call identifier, and the carrier's result. Follow [telephony troubleshooting](/agents-platform/deploy/telephony/troubleshooting).

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does an empty codec list mean no audio?" id="sip-reference-faq-codecs">The schema describes an empty list as offering all supported codecs. Confirm the actual negotiated codec during a supported runtime test.</Accordion>
  <Accordion title="Can I treat has_auth_credentials as a successful login?" id="sip-reference-faq-credentials">No. It is response metadata, not a carrier authentication result or proof that a runtime can retrieve the secret.</Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.