SIP signaling and media reference

Use this reference when you agree connection requirements with a SIP peer. It owns the platform's protocol behavior: transports, TLS, methods, edge responses, timers, codecs, SDP, number format and NAT. It is not a carrier certification.

Availability: This reference describes the SIP edge, the media proxy and the internal telephony service as delivered in 0.9.18. A deployment can override listeners, certificates and trunk settings. Confirm the deployed release with your operator before you turn a statement into a contractual requirement.

Your question	Section
Which transports, TLS versions and certificate checks apply?	Signaling transports, TLS
Which SIP methods are handled, and how?	SIP methods
Which responses does the platform edge generate itself?	Responses generated by the edge
Which timers and retransmission intervals are configured?	Timers
Which codecs, DTMF method and SDP changes apply?	Codecs and DTMF, SDP and media security
In which format must the called number arrive?	Called-number format
Which transfer methods exist, and what does each send?	Call transfer methods
Which SIP headers can I add, and which are limited or protected?	Header limits, Header rules
Which specifications does this behavior rely on, and what are its limits?	Specifications, Limits

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.

TLS versions, cipher suites and certificate checks

These statements apply only when the deployment has enabled the TLS listener.

Aspect	Configured behavior	What to verify
Protocol version	The listener and the client profiles set the minimum to TLS 1.2 (TLSv1.2+). Older protocol versions are not offered.	Whether a higher version is negotiated depends on the TLS library in the delivered image and the peer.
Cipher suites	The TLS profile that the edge regenerates from stored TLS material at start, and again when that material changes, sets no cipher list. The suites offered are then the defaults of the TLS library in the delivered image.	See Supported SIP TLS cipher suites for the reference 0.9.18 values; deployment restrictions and peer compatibility still apply.
Server certificate	The edge presents the deployment's listener certificate.	Subject and chain match what the peer validates.
Peer certificate, inbound	Off by default. A trunk can require a verified peer certificate or a client certificate. When at least one trunk does, the listener requests a client certificate without making it mandatory at the handshake, and the edge rejects the call at SIP level when the peer is unverified.	A peer without a valid certificate receives 403, not a handshake failure.
Peer name, inbound	Optional per trunk. The edge compares the certificate common name with the configured remote subject name. Subject alternative names are not compared.	The peer certificate carries the agreed common name.
Certificate trust, inbound	CA certificates of all trunks that supply one are combined into one bundle for the listener. Trust is not isolated per trunk.	The bundle contains only CAs you intend to trust for SIP peers.
Certificate checks, outbound	Not verified. The default client profile does not verify the carrier certificate. Confirm with a handshake on the deployment whether a trunk's verification setting, CA and client certificate apply to its connection.	Handshake result toward the carrier, including the certificate the edge presents and whether an untrusted carrier certificate is refused.

A packaged static profile lists six AES-GCM and AES-CBC suites with RSA key exchange or ECDHE-RSA. Do not quote that list as the effective configuration: it applies only until the edge writes the regenerated profile, which happens at start when TLS is enabled.

The trunk fields behind these checks are described in TLS and media. For a failed connection, follow SIP diagnostics.

Supported SIP TLS cipher suites in 0.9.18

The following values are supported by the reference TelPro TLS runtime: OpenSSL 3.5.7, with the generated server/client profiles setting TLSv1.2+ and no explicit cipher restriction. The list is bound to the 0.9.18 runtime, not to every historical image or customer override. A connection also needs a compatible certificate, key exchange and peer policy; an RSA certificate cannot negotiate an ECDSA-authenticated suite. TLS 1.0 and 1.1 remain disabled even where a suite was originally defined for an older protocol.

TLS 1.3

IANA suite name	OpenSSL name
TLS_AES_256_GCM_SHA384	TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256	TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256	TLS_AES_128_GCM_SHA256

TLS 1.2

IANA suite name	OpenSSL name
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384	ECDHE-ECDSA-AES256-GCM-SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	ECDHE-RSA-AES256-GCM-SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384	DHE-RSA-AES256-GCM-SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256	ECDHE-ECDSA-CHACHA20-POLY1305
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256	ECDHE-RSA-CHACHA20-POLY1305
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256	DHE-RSA-CHACHA20-POLY1305
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256	ECDHE-ECDSA-AES128-GCM-SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	ECDHE-RSA-AES128-GCM-SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256	DHE-RSA-AES128-GCM-SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384	ECDHE-ECDSA-AES256-SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384	ECDHE-RSA-AES256-SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256	DHE-RSA-AES256-SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256	ECDHE-ECDSA-AES128-SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	ECDHE-RSA-AES128-SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256	DHE-RSA-AES128-SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA	ECDHE-ECDSA-AES256-SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA	ECDHE-RSA-AES256-SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA	DHE-RSA-AES256-SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA	ECDHE-ECDSA-AES128-SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA	ECDHE-RSA-AES128-SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA	DHE-RSA-AES128-SHA
TLS_RSA_WITH_AES_256_GCM_SHA384	AES256-GCM-SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256	AES128-GCM-SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256	AES256-SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256	AES128-SHA256
TLS_RSA_WITH_AES_256_CBC_SHA	AES256-SHA
TLS_RSA_WITH_AES_128_CBC_SHA	AES128-SHA

These are the runtime's enabled suite candidates under its default policy. Negotiation selects one compatible value; the table does not certify every suite with every certificate or carrier. DHE suites additionally require usable DH parameters. Deployment-level restrictions can reduce this set. The image's repository TLS template contains a narrower RSA cipher list, but the normal TLS-material generation replaces that template; the effective generated profile is the relevant policy.

This list applies to SIP signaling on TelPro. HTTPS termination at Caddy or a load balancer and internal TLS endpoints have separate policies. SRTP/SDES and DTLS-SRTP media profiles are not TLS cipher suites; see SDP and media security.

Suite naming and protocol separation follow the OpenSSL cipher reference. The runtime inventory was checked on 8 October 2026. Changes to the TelPro image, TLS library or generated policy require a new version-specific inventory.

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.

SIP methods

The edge is a proxy. It decides how a request is routed; the internal telephony service or the far end answers most in-dialog requests. "Relayed" below means forwarded along the dialog's recorded route. It does not mean that the receiving side accepts the request.

Method	New request outside a dialog	Request inside an established dialog
INVITE	Runs trunk identification, trunk policy and authentication, number lookup and server selection. 100 Trying is sent automatically.	Relayed (re-INVITE).
ACK	Matched to its transaction.	Relayed. An ACK without a matching transaction is absorbed without a response.
CANCEL	Matched to the pending INVITE. A cancelled call releases its media session and its reserved call slot.	Not applicable: a CANCEL belongs to the pending INVITE transaction.
BYE	Not a valid initial request; see 481 below.	Relayed; ends accounting and releases the media session.
OPTIONS	Answered by the edge with 200 OK, without call routing.	Relayed.
PRACK	Not a valid initial request.	Relayed. Whether reliable provisional responses are used depends on the 100rel setting.
UPDATE, INFO	Not a valid initial request.	Relayed. How the receiving side acts on them is not verified.
REFER	Not a valid initial request.	Relayed. For a transfer that the platform sends toward a carrier, the edge first rewrites the Refer-To target into a carrier-valid form and adds Referred-By.
NOTIFY	Not a valid initial request.	Relayed with a Record-Route header, for example for transfer progress.
SUBSCRIBE, MESSAGE, PUBLISH	Not routed. A request that reaches the routing stage receives 481 Transaction Does Not Exist. The internal endpoint does not accept subscriptions.	Relayed if the peer sends one; no platform function depends on it.

An in-dialog request must follow the route set recorded during call setup. A request with a To tag that does not carry that route receives 404 Not here, except for ACK.

Peers are identified by configuration. Registration toward the edge is not a documented trunk interface; when a carrier requires the platform to register, that is configured on the outbound trunk.

Responses generated by the edge

The edge generates the responses below itself. Any other final response, including most 4xx, 5xx and 6xx results of a connected call attempt, comes from the internal telephony service or from the far end and is relayed. A carrier response with the same code is not the platform branch described here.

Response	Condition in the configured edge
100 Trying	Sent automatically for an accepted INVITE transaction.
200 OK to OPTIONS	Out-of-dialog reachability probe.
407 Proxy Authentication Required	Digest challenge for a trunk using digest or IP-and-digest authentication. It is repeated when the username or password is wrong.
403 Forbidden - Unknown Trunk	No configured trunk matched the request.
403 Forbidden - TLS Required	The trunk requires TLS, or peer-name checking is enabled, and the request used another transport.
403 Forbidden - TLS Certificate Verification Failed	The trunk requires a verified peer or client certificate and the TLS peer is not verified.
403 Forbidden - TLS Peer Name Mismatch	The peer certificate's common name differs from the trunk's remote subject name.
403 Forbidden - TLS Not Available	The trunk requires certificate or peer-name checks and the deployment has no TLS listener.
403 Forbidden - Source IP Not Allowed	IP-and-digest authentication and the source address is not in the trunk's allowed list.
403 Forbidden - Invalid Call Token	The trunk is configured to accept only calls that carry a valid platform call token, and the request has none.
403 Forbidden - Not a TelSys Server	An outbound or transfer request on an internal trunk arrived from an address that is not a registered internal telephony server.
403 Service Not Available	The called number exists and is disabled.
403 Team Not Available	The team addressed by a platform call token is disabled.
404 Number Not Found	The called number matches no configured number or number pattern.
404 Not here	In-dialog request without the recorded route set.
404 No Outbound Route, 404 No Outbound Identity	An outbound call has no usable route context, or the route has no base-number identity.
481 Transaction Does Not Exist	A request other than INVITE reached the routing stage without a matching transaction or dialog.
483 Too Many Hops	The Max-Forwards value is exhausted.
486 Busy Here	The concurrent-call limit of the called number, or of its server group, is reached.
500 Inbound Auth Misconfiguration	The trunk uses digest authentication and its credentials are missing.
500 Egress TLS Misconfiguration	An outbound trunk requests certificate verification or mutual TLS and its transport is not TLS.
500 Egress Failover Relay Failed	Relaying to the next member of an outbound pool failed.
503 Service Unavailable	The TelPro instance is draining, no internal server is available or selectable, or the selected server is at its call limit.
Trunk's configured response (default 503 Service Unavailable)	From 0.9.18: a new INVITE identified as a trunk in maintenance mode. A code other than 503 uses the reason phrase Maintenance.
503 Routing Error	A routing-data lookup for an outbound call failed.

A message that fails basic syntax checks is dropped without a response. Retransmissions of a request already in progress are absorbed.

On an outbound call, the edge answers one 401 or 407 challenge from the carrier with the trunk's configured credentials. For an outbound pool, a 408 or any 5xx result moves the attempt to the next pool member until every member has been tried once.

For the next step after one of these responses, use Identify a routing response first. Hangup causes and Reason headers chosen by the platform are a separate subject: see the SIP termination reference.

Timers and retransmission

Setting	Configured value	Effect
Wait for a response	45 seconds	A forwarded INVITE without any response, or another forwarded request without a final response, fails after this time.
Wait for a final response to an INVITE	120 seconds	After a provisional response, an unanswered INVITE fails after this time.
Request retransmission over UDP	500 ms to 4 s	The interval starts at 500 ms and doubles to at most 4 seconds.
Dialog lifetime	6 hours	Default lifetime of the edge's dialog state for one call. Whether a longer call is ended at this limit is not verified.
Max-Forwards	10 when absent	The edge adds the header with value 10 when a request has none, and decrements an existing value.

The edge configuration contains no session-timer settings. Do not assume that the platform refreshes a session on a negotiated interval; check the actual INVITE and 200 OK if your peer requires one. The internal SIP endpoint's RTP timeout is disabled and it sends an RTP keepalive every 15 seconds, so missing RTP alone does not end a call at that layer. Timeouts configured in a flow are separate.

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

On an ordinary call, the media proxy hides the codecs of the incoming offer and offers PCMA with telephone-event to the other side. The platform's internal leg therefore uses G.711 A-law. On an inbound call, the media proxy answers the peer from the peer's own offer and transcodes when the selected codec is not PCMA. Which codecs the delivered image can transcode, and which offered codec is selected, are not verified. On an outbound call, the carrier is offered PCMA and telephone-event only. Include PCMA and telephone-event in your offer to avoid depending on transcoding.

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.

SDP and media security

The media proxy rewrites the SDP of every call it handles. Media flows between the peer and the media proxy, not directly to an internal service.

SDP aspect	Configured behavior
Origin and address	The origin and connection addresses are replaced with the media proxy's advertised address.
Address family	IPv4 is requested for every leg.
ICE	ICE attributes are removed on SIP trunk legs.
Direction	The original sendrecv, sendonly, recvonly or inactive attribute is kept.
Packetization	ptime=20 is set on the offer of an ordinary call.
Late offer	An ACK that carries SDP is passed to the media proxy.
Media profile	Follows the inbound trunk's SRTP mode: plain RTP/AVP; SDES accepted alongside plain RTP; or RTP/SAVP with SDES required.
Outbound TLS trunks	A call sent to a carrier over TLS offers RTP/SAVP with SDES.
Encryption boundary	SRTP ends at the media proxy. The internal leg uses plain RTP. This is not end-to-end encryption.

SDES carries the SRTP keys in the SDP, so use it only with TLS signaling. DTLS-SRTP on SIP trunk legs is not verified.

Called-number format

For an inbound call, the edge looks up the user part of the Request-URI exactly as received. It does not add or remove +, 00, a country code or a national prefix before that lookup. When there is no exact match, it tries the deployment's configured number patterns; otherwise the call receives 404 Number Not Found.

The administration UI stores a number as + followed by digits. Input that starts with + or 00 keeps its country code. Other input is prefixed with the default country code, 49, without removing a leading national 0. Enter numbers in international form to avoid an unintended result.

Agree with the carrier that the Request-URI user part arrives in the stored form, for example + followed by country code and number, and confirm it with a test call. How extensions of a base number are matched is not verified. For outbound calls, the number format follows the configured route and carrier: see outbound selection.

NAT and media addresses

Signaling advertisement and media advertisement have separate configuration. The TelPro variables and bootstrap variables list each address setting.

• 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 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 Configure SIP trunks and routing. For disagreement between configured and observed behavior, use SIP diagnostics.

Call transfer methods

Each transfer action names one method. The method decides which SIP request the platform sends and whether the platform stays in the call afterwards.

Method	What the platform sends	Platform after the transfer
sip_refer	A REFER inside the existing dialog. The edge relays it to the peer. Default outcome mode: Blind.	Leaves signaling and media; if the bot leg is kept, after up to 60 s
sip_refer_replace	The same REFER as sip_refer. Only the default outcome mode differs: Notify.	Leaves signaling and media; if the bot leg is kept, after up to 60 s
sip_invite, sip_invite_bridge	A new INVITE to the target. The platform bridges the caller with the new leg.	Stays in signaling and media
sip_invite_reinvite_p2p	A new INVITE to the target, bridged with a best-effort peer-to-peer media hint. Whether RTP actually bypasses the platform depends on the SIP edge configuration; with the default configuration, media still passes through Delphi.	Stays in signaling
sip_bye	No new call. The caller's dialog ends with a BYE that carries the configured Reason and headers. The carrier uses them to route the caller onward.	Leaves the call

REFER outcome mode. Blind sends Refer-Sub: false and counts the transfer as done once the REFER is sent, unless a failure result arrives first. Notify sends Refer-Sub: true, waits for the transfer result and reports a failure when none is observed, so use it only with a peer that sends NOTIFY results. You can set the outcome mode per action; the method only sets its default.

Attended transfer. Neither REFER method creates a consultation leg, so the platform sends no Replaces dialog, even when the selected label reads "attended" or "consultative". For an attended transfer, use an INVITE method: the bridge runs attended when the action plays a message to the target or asks the target to accept the transfer before the caller is connected. The label "SIP INVITE bridge (attended)" does not by itself make the transfer attended. An attended bridge that plays a message needs a realtime attended provider when the flow's main provider is modular; otherwise the transfer fails with attended_provider_required.

Browser voice calls. A REFER method is rejected for a WebRTC call before anything is sent. The conversation log shows transfer_blocked with code webrtc_refer_unsupported. Use sip_invite or sip_invite_bridge.

Target restrictions. Your team's transfer restrictions apply to every method that dials a target. They do not apply to sip_bye, which has no target.

Which methods you can pick depends on where you configure the transfer: the Transfer node, final call actions and entry-point readiness each offer their own list. To choose a method and its outcome mode for a flow, use call transfer. To check what a transfer actually sent, follow the transfer method and the new leg.

Specifications the configured behavior relies on

This list names the specifications behind the behavior described above. It is not a conformance statement.

Specification	Where it applies
RFC 3261	Core SIP: transactions, dialogs, record routing, digest authentication, TLS
RFC 3262	Reliable provisional responses (100rel, PRACK), when enabled
RFC 3264	SDP offer/answer
RFC 3311	UPDATE relayed inside a dialog
RFC 3515	REFER for transfers
RFC 6665	NOTIFY inside a dialog
RFC 3325	P-Asserted-Identity on an outbound call, where the route sets it
RFC 3326	Reason header on termination; see the termination reference
RFC 3550	RTP media
RFC 3551	G.711 A-law (PCMA) payload
RFC 4733	DTMF as telephone-event
RFC 3711, RFC 4568	SRTP with SDES key exchange, when the trunk's SRTP mode uses it

Limits

Item	Status
IPv6 signaling or media	Not configured. DNS lookups and media use IPv4.
ICE, STUN or TURN on SIP trunk legs	Not used. ICE attributes are removed.
DTMF as SIP INFO or in-band audio	Not verified. The configured method is telephone-event.
SUBSCRIBE, MESSAGE, PUBLISH as new requests	Not routed; see SIP methods.
Session timers	Not configured at the edge.
Peer-name validation against subject alternative names	Not performed. Only the common name is compared.
Negotiated cipher suite and TLS 1.3	Depend on the delivered image and the peer; verify by handshake.
RTCP port behavior, multiplexing, SRTCP	Not verified; see RTCP.
Codecs other than PCMA on the peer side	Not verified. Transcoding capability depends on the delivered image.
Carrier certificate verification on outbound TLS	Not verified; see TLS.
Extension matching for the called number	Not verified.
Attended transfer by REFER with Replaces	Not supported. The REFER path creates no consultation leg; see transfer methods.
Cancellation of a ringing call across both legs	Not verified. Include it in the acceptance test.

An item that is not listed here is not verified; test it with your peer before you rely on it.

RTCP and acceptance checks

The edge's instructions to the media proxy contain no RTCP-specific option on SIP trunk legs. RTCP port assignment, multiplexing on the RTP port and SRTCP therefore follow the defaults of the media proxy in the delivered image. They are not verified.

In the reference deployment, the SIP edge host turns the media proxy's end-of-call statistics into one rtpengine_call_stats log record and one trace span per call:

Values	When present
Codec, duration, packet and byte counters per direction	Always. in means received by the media proxy.
rtp.mos.average, rtp.mos.lowest, rtp.mos.highest	Only when the media proxy reported a MOS value.
Jitter, round-trip time and packet loss (rtp.jitter.avg_ms, …)	Only when the media proxy reported them.
Record level warn below an average MOS of 3.6, error below 3.0	Only with a reported MOS; otherwise the level is info.

A record without quality values is therefore not evidence of good audio. Which reports the peer must send for these values to appear is not verified. Treat the record as evidence of what the media proxy counted, not of the peer's RTCP behavior.

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, including a caller who hangs up while the call is still ringing.
5. Required RTCP/quality-reporting behavior and the evidence used to assess it.

Keep observed results separate from configuration expectations.

Related

• Configure SIP trunks and routing — to set the trunk, transport and number configuration agreed with the peer
• SIP termination causes and header limits — to interpret causes and optional-header budgets on the same calls
• Diagnose SIP routing and termination — to investigate a call that differs from this reference
• SIP and call handling — to move between integration, administration and diagnosis