Support

Hello team,

Domain: parkmyphone.cloudonix.net
Subscriber: 13368713755
Softphone: Ringotel (calls arrive via Ringotel Shell Server 54.144.152.6:5060, UDP)
Outbound trunk: "testing" (ID 2602) → Bandwidth cloudonixdev-ef6517.auth.bandwidth.com:5006
Affected sessions:

• 76f959924a4d45ab98b85174fb34a8ca
• ca7e01eb897346c9b79171705c1f4469 (Call-ID ad4508769397ad5c9ac3f9311c2ec4, 2026-10-15 18:42:34 UTC, to 15412926666, outbound leg Call-ID 85640bd9-cf0f-46c8-99f8-3d0a0794fabe)

Problem
Subscriber 13368713755 makes outbound calls from the Ringotel app and the calls connect, but the called party can't hear the subscriber. We're seeing this on both Android (Pixel 7) and iOS (iPhone 15 Pro Max). Signalling looks normal: the call is answered, stays up, and ends with a normal BYE.

What we see in the session logs (ca7e01eb…)
The QoS data appears to show the subscriber's media reaching your platform and being sent on to the carrier:

• Subscriber leg (from Ringotel): 1,613 packets received, 0 loss, jitter ≤ 0.6 ms, MOS 4.4
• Carrier leg (to Bandwidth): 1,382 packets sent, 0 transmit loss, MOS 4.4
• Carrier leg (from Bandwidth): 935 packets received against about 1,430 expected for about 28.6 s of talk time. That's roughly 10 s short, although the loss counters are near zero.
• The subscriber leg shows RTT = 0, meaning no RTCP feedback.

Packet counts and MOS can't tell us whether the forwarded packets contained real audio or silence, or whether they reached the right destination. So we need your help to find where the subscriber's audio is being lost.

Ringotel SDP offer
c=IN IP4 54.144.152.6, m=audio RTP/AVP 8 0 101 (PCMA, PCMU, telephone-event), ptime 20, sendrecv

Questions

1. Which codec was agreed on each leg, Ringotel ↔ Cloudonix and Cloudonix ↔ Bandwidth? Was any transcoding done (e.g. PCMA ↔ PCMU)?
2. Was media anchored on your media server? What IP:port did you send RTP to on the Bandwidth leg, and does it match the SDP answer from Bandwidth?
3. Do the packets you received from Ringotel contain real audio, or silence/comfort noise? If you have a pcap or debug recording of these sessions, could you check it?
4. Why did you receive about 500 fewer packets from Bandwidth than the call length implies on ca7e01eb…? Did Bandwidth stop sending, or change SSRC or port mid-call?
5. Is anything in our domain or trunk configuration (symmetric RTP, NAT handling, subscribers-auto-progress, early media) likely to cause one-way audio with Ringotel?
6. If you need a reproduction, can you turn on debug-stream-dumps or session recording for this domain temporarily, so we can place a test call and you can capture the media?

We can place test calls at a time that suits you.

Thanks in advance
Sharath Murali