Call with Telus cell phone using Volte

[johnf]

The call between my FPL number and Telus cell phone has problem that FPL side can only hear very short time voice, and then voice delayed, can not be heard. Cell phone side can hear voice. This happens on both incoming and outgoing call , and cellphone side using VoLTE. Does anybody here has similar experience? What is possible reason?

[Liptonbrisk]

I forced an iPhone on Telus to LTE and started surfing while on a call. I can't reproduce the problem.

If the problem only occurs with VoLTE calls then it's possible Telus' VoLTE is introducing mid‑call events, such as re‑INVITEs, media re‑anchoring, or silence‑suppression (DTX) that can change RTP source/port. However, I'm not seeing any of that occurring in my syslog while testing. And I feel it would be odd for those events to be occurring so quickly during a call, regardless.

1) Downstream congestion and intermittent packet loss/ISP issue on Rogers' side would be a likely source. Refer to the WinMTR test from step 23: viewtopic.php?p=80553#p80553. You want to test to the RTP IPs: 208.85.218.149 and 208.85.218.150 (about 500 pings each with WinMTR, while checking the last hop, specifically).

a) While on an active call, navigate to your OBihai ATA's call status screen.

Dial ***1. Enter the IP address you hear into a web browser if you want to use your Obihai device's web interface instead of Obitalk.com. Login. Default username and password are “admin” without the quotation marks.

Navigate to Status-->Call Status (keep refreshing the screen for updated stats)

Check for packets dropped, late, lost, etc. Those indicate a problem, likely with Rogers or your LAN.


Important information includes interarrival jitter, late/dropped and interpolated packets, jitter buffer underruns/overruns, packet loss and sequence discontinuities, out‑of‑order counts, and MOS (Mean Opinion Score) as a call quality indicator. Together they can indicate whether the Telus→FPL RTP media stream is being delayed, reordered, or lost.

Interarrival jitter: Measures variation in packet arrival and rises when queuing/bufferbloat increase. Sustained values beyond roughly 20–30 ms tend to break real‑time audio (unless the jitter buffer grows).

​Packets late/dropped: Late arrivals beyond the playout deadline are discarded and sound like gaps (breaks in audio).

​
Packets interpolated/PLC: Interpolated frames mean packet loss concealment is being invoked. Spikes here track periods where loss/jitter exceeded what the jitter buffer could mask.


Jitter buffer underruns/overruns: Both are equivalent to lost audio at the ear and are counted as impairment in quality models. Underruns imply packets aren’t arriving in time, and overruns imply jitter exceeds buffer capacity.

​
Packet loss rate and sequence discontinuities: Loss and gaps in RTP sequence numbers show network loss or severe reordering. Even a few percent loss can audibly degrade speech with G.711 audio codec.


Out‑of‑order packets: Moderate reordering can be corrected, but persistent problems increase jitter and late packet discards. So an increasing number does indicate problems.


MOS provides a single‑number quality roll‑up (G.107/E‑model), where G.711 tops out near 4.2–4.42 in ideal conditions. A falling MOS score alongside rising jitter and late or discarded packets confirms call degradation.

​



2) Another problem could be not having your OBi200 configured properly: keep-alives need to be sent every 20 seconds to keep NAT holes and associations active/open: refer to step 15 from viewtopic.php?p=80553.



3) Although your problem is unlikely to be a SIP ALG issue if audio is heard initially, since an XB7 is being used with no way to disable SIP ALG, I would suggest switching proxy server to voip4.freephoneline.ca:6060 while troubleshooting. That's step 14A from viewtopic.php?p=80553.

4) Although your problem is unlikely to be a SIP ALG issue, I also suggest doing this:

Navigate to Voice Services-->SP used for FPL Service-->_UserAgentPort

a) X_UserAgentPort should be a random UDP port number between 30000 and 60000. Just pick a port number in that range.
If you already have a random number in that range, simply enter a new one in that range.
By using a high random port you help to thwart SIP scanners/hackers. This may also help with potential SIP ALG issues.

Do not use the same X_UserAgentPort for any other SP. Pick a different X_UserAgentPort in the same range for other SPs.

Never use UDP 5060 for X_UserAgentPort.

5) Read through step 25 from viewtopic.php?p=80553#p80553 (for general UDP timeout info).