Mitel - Voice AI Escalation Checklist – Talkative

Pre-Escalation Debug Checklist — Talkative SIP Integration

Overview

This checklist must be completed in full before raising a support escalation with Talkative. All evidence listed must be gathered and attached to your escalation submission.

⚠️

Important: Talkative is a SIP trunk endpoint. The vast majority of integration issues originate in the telephony infrastructure — MBG, MiVB, firewall, or network — rather than the Talkative platform itself. Incomplete submissions will be returned to the submitting partner without investigation.

Before You Begin

Confirm and document the following before proceeding:

Partner / organisation name

Engineer completing this checklist

Customer name

Talkative account / Twilio SIP domain (format: {uuid}.sip.twilio.com)

MBG version

MiVB version

Full architecture — every device in the call path must be documented, for example: GSM Gateway → MBG → MiVB → MBG → Talkative/Twilio. Include which partner is responsible for each device.

Clear description of the issue — what was expected and what actually happened

Section 1 — MBG Configuration

Network Profile

MBG is running in gateway mode — not LAN mode or custom mode. Confirm by navigating to the MBG status page and checking the Network Profile field reads Gateway mode or Gateway mode behind NAT

WAN interface is populated with a publicly routable IP address. A blank WAN interface means Contact headers will not be rewritten and internal IP addresses will leak to external parties

Streaming Set-side address reflects the correct public IP — this must match the IP Twilio will see as the source of SIP traffic

MBG service has been restarted after any configuration changes

⚠️

Required evidence: Screenshot of the MBG status page clearly showing the Network Profile, LAN interface, WAN interface, and Streaming addresses all populated. Submissions without this screenshot will be returned.

SIP Trunk Configuration

SIP trunk is configured per Talkative documentation

Remote trunk endpoint address is set to the correct Twilio SIP domain — format: {uuid}.sip.twilio.com or regionalised equivalent

Transport protocol matches the trunk configuration (UDP for standard, TLS for encrypted)

Options keepalives are set to Never — keepalives have been observed to cause inconsistent behaviour and call failures

Trunk rules are configured with a matching rule for incoming traffic — at minimum a wildcard rule on Request URI must be present

ICP is correctly assigned in the trunk rule

Section 2 — Network & Firewall

SIP ALG is disabled on all upstream routers and firewalls. SIP ALG is a common cause of Contact header mangling and call failures. It must be explicitly disabled — do not assume it is off by default

Port 5060 UDP (or 5061 TCP for TLS) is open outbound from the MBG WAN interface

RTP media ports are open outbound from the MBG WAN interface — check the MBG configuration for the configured RTP port range

All Twilio signalling IPs are whitelisted on the firewall. There are 4 IPs per region for resiliency — full list available at twilio.com/docs/sip-trunking/ip-addresses

MBG WAN IP is confirmed reachable from the public internet — verify from an external network, not from within the same LAN

Section 3 — SIP Trace Evidence

This section is mandatory. Escalations submitted without pcap evidence will be returned.

A Wireshark / pcap capture has been taken from the MBG WAN interface showing the full failing call flow

Contact headers in the capture show the public WAN IP — not an internal RFC 1918 address (10.x.x.x, 172.16–31.x.x, or 192.168.x.x). If internal addresses are present in Contact headers, the MBG is not rewriting headers correctly — resolve the MBG configuration before escalating

SDP headers show a publicly routable media address — check the o= and c= lines in the SDP body

ACKs are being sent to and received from public IP addresses

Captures have been taken from both sides of the MBG — internal and external — to confirm header rewriting is occurring

Captures should show evidence that the failure is between the MBG and Talkative, and not a configuration issue between the MBG and PBX

⚠️

Required evidence: Raw capture files are required — do not paste SIP traces as text.

Section 4 — Issue Type Specific Checks

Complete the section relevant to the issue being escalated.

4a — SIP REFER / Transfer Issues

The call is fully established (200 OK / ACK complete) before the REFER is attempted

The REFER is receiving a final response (200 OK) and not looping on 100 Trying. Repeated REFER retries with only 100 Trying responses and no final answer indicates the REFER target is unreachable — this is typically caused by an internal IP address in the Contact header and must be resolved before escalating

The Refer-To: URI contains a routable address — the host portion must be a publicly routable IP or resolvable FQDN

The pcap does not show a 408 Request Timeout following repeated REFER attempts. A 408 after repeated REFERs confirms the target was unreachable — resolve Contact header rewriting before escalating

4b — SIP Dial / Voice AI Conference Issues

The SIP Dial address is correctly formatted. The SIP Dial address is a free text field — incorrect formatting is a common cause of failure. The correct format is:

The transport= parameter is present in the SIP URI and matches the configured transport. A missing transport parameter is one of the most common causes of SIP Dial failure — it must always be explicitly included

If using TLS, the URI scheme is sips: (if configured) and the transport parameter is transport=tls

SRTP/RTP configuration on the trunk matches what Talkative expects — a mismatch will result in one-way or no audio on the conferenced leg

Firewall permits RTP/SRTP media ports for the additional conference leg. SIP Dial creates a new media leg requiring its own RTP path — confirm ports are open for this leg specifically

SIP ALG is confirmed disabled — SIP ALG will mangle the SIP Dial URI in transit even if it is correctly formatted at source

4c — Inbound Call Routing Issues

The inbound DID is assigned to the correct SIP trunk on the MBG — confirm it is mapped to the Talkative trunk and not another trunk on the same MBG

The trunk rule on the MBG matches the inbound DID format — confirm whether the DID is arriving with or without country code and that the rule accounts for this

The ARS route on MiVB is correctly pointing to the Talkative trunk

The inbound DID has been provisioned correctly in the Talkative / Twilio account

Section 5 — Declaration

By submitting this escalation the engineer confirms:

All items above have been checked and evidenced

The pcap captures attached show public IP addresses in Contact and SDP headers

This issue cannot be resolved by correcting the MBG, firewall, or network configuration

All required screenshots and pcap files are attached to this submission

⚠️

Additional notes: Include any additional context, things already tried, or relevant background information in your escalation email to Talkative support.