SIP signaling and media reference

Use this reference when agreeing connection requirements with a SIP peer. It describes configured behavior and the checks needed for your deployment. It is not a carrier-certification or complete standards-conformance matrix.

Signaling transports and availability

Availability: SIP-over-TLS is deployment-controlled. TLS_ENABLED defaults to false; the TLS listener is conditional on enabling it. Ask the deployment operator to confirm the effective listener and certificate configuration before selecting TLS for a trunk. A TLS listener alone does not establish media encryption or mutual authentication.

Connection	Configured transport	What to confirm
External SIP edge	UDP and TCP; TLS when enabled	Advertised address, transport and port match the peer configuration and network rules
Private TelPro-to-TelSys connection	UDP	The private address and internal port are reachable on the intended network
TLS peer connection	Depends on effective deployment and trunk settings	Negotiated TLS version, certificate trust/name validation and any required client certificate work with the actual peer

Do not infer transport from a port number. In particular, an internal SIP port can be UDP even when its number is commonly associated with TLS.

The exact cipher set and effective mutual-TLS behavior are not established by this reference. Confirm them against the running deployment and a peer handshake before making them integration requirements. For a failed connection, follow SIP diagnostics.

Request handling and trunk health

An out-of-dialog OPTIONS request reaching the edge's OPTIONS handler receives an OPTIONS response, with a fallback 200 OK. This probe does not run the full call-routing pipeline. A successful OPTIONS response therefore does not verify number routing, downstream call acceptance or two-way media.

The main location pipeline processes INVITE. A non-INVITE request that reaches that stage is rejected with 481 Transaction Does Not Exist; this is not the universal response to non-INVITE methods. In-dialog and transaction-specific handling occurs separately.

Do not use the list of methods visible in SIP capture logs as a supported-method list. When checking an actual call, distinguish its request/response sequence from the platform's termination causes and header limits.

Reliable provisional responses (100rel / PRACK)

SIP_100REL_MODE controls the generated 100rel setting for the TelPro-facing TelSys endpoint. Its default is off.

Canonical environment value	Generated endpoint setting
off	no
peer_supported	peer_supported
yes	yes
required	required

An unrecognized value logs a warning and falls back to peer_supported, rather than the default no. Use an intentional value and inspect the effective configuration. These settings do not certify successful reliable-provisional-response negotiation with every peer; include that exchange in your integration test when required. If observed behavior differs from the intended setting, follow Investigate a 100rel configuration mismatch.

Codecs and DTMF

Scope	Configured behavior	Integration boundary
Internal trunk template	Allows opus, alaw, ulaw and g722	This is not an external carrier codec list or a verified codec preference/transcoding matrix
Typical proxy media offers	Explicitly offer PCMA and telephone-event, with ptime=20	Confirm the actual offer and answer for the call path you use
Transfer path with the internal peer-to-peer media hint	Its initial offer omits the ordinary codec mask	Do not generalize the ordinary offer to every transfer, or infer complete end-to-end passthrough from this exception
Internal DTMF setting	dtmf_mode=rfc4733	Verify negotiated telephone-event and received digits; this does not establish SIP INFO or in-band DTMF support

Test normal calls and your chosen transfer scenario separately. A configured codec allowance or logged DTMF event is not evidence that audio or digits reached the intended destination.

For the flow result, termination key, deadline and retry behavior, use DTMF collection in SIP flows. Protocol negotiation and flow-level input validation are separate checks.

NAT and media addresses

Signaling advertisement and media advertisement have separate configuration:

• A nonempty EXTERNAL_IP selects the SIP NAT mode: the edge binds to PRIVATE_IP and advertises EXTERNAL_IP with the relevant transport port.
• The generated media advertisement selects TELPRO_MEDIA_IP first, then EXTERNAL_IP, then PUBLIC_IP.
• In that NAT mode, the public-facing media interface binds privately while advertising the selected media address.

The audited media routes request IPv4 and remove ICE. Do not substitute browser WebRTC STUN/TURN instructions for carrier SIP/RTP network planning, or assume these address settings solve every NAT topology.

Confirm the addresses in the actual SIP exchange and SDP, then test audio in both directions. For trunk identification and outbound destination selection, use Check SIP routing configuration. For disagreement between configured and observed behavior, use SIP diagnostics.

RTCP and acceptance checks

RTCP-related log parsing does not establish the media path's RTCP capabilities. RTCP port behavior, multiplexing, SRTCP and the quality metrics available for your call path remain to be verified. Their absence from this reference does not mean they are unsupported.

Before accepting an integration, record the deployed component versions and effective configuration, then verify:

1. The selected signaling transport and any required TLS trust/authentication checks.
2. A complete call setup, including 100rel/PRACK if required by the peer.
3. Negotiated codec, packetization and two-way audio across the intended network path.
4. Required DTMF behavior and the specific transfer/hangup scenarios used by the application.
5. Required RTCP/quality-reporting behavior and the evidence used to assess it.

Keep observed results separate from configuration expectations. Use the shared SIP topic to move between this integration reference, administration and operational diagnosis.