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).

[johnf]

Thank you for your information, Loptonbrisk!

I just followed your suggestions as below:

1) WinMTR tested both IPs.
208.85.218.149 502/502/23/29/28/26
208.85.218.150 502/502/23/30/42/29
It looks fine.

Screen shot call status of obi200 while on the call. But I can not post picture here.

For outgoing call at 24s
Interarrival jitter: 0
Packets late/dropped: 580
Packets interpolated/PLC: 2089
Jitter buffer underruns/overruns:580/0
Packet drop rate: 94%
Packet loss rate and sequence discontinuities: 0/0
Out‑of‑order packets: 0
MOS:1.28

For incoming call at 17s
Interarrival jitter: 1200ms
Packets late/dropped: 112
Packets interpolated/PLC: 214
Jitter buffer underruns/overruns:112/0
Packet drop rate: 45%
Packet loss rate and sequence discontinuities: 0/0
Out‑of‑order packets: 0
MOS:1.19

Lots of Rx packets dropped.


2) keep-alives was set to 20s before above test

3) proxy server was set to voip4.freephoneline.ca:6060 before above test

4) X_UserAgentPort was 55000 before above test.

5) Has set all UDP timeout followed instructions in Step 25.


Incoming and outgoing call to Bell cellphone(Iphone) are going well without issue.

Is this issue related to transcoding gateway of carrier? Either Telus or FPL/ FPL is using G711, Volte is using different codec.

[Liptonbrisk]

For outgoing call at 24s
Interarrival jitter: 0
Packets late/dropped: 580
Packets interpolated/PLC: 2089
Jitter buffer underruns/overruns:580/0
Packet drop rate: 94%
Packet loss rate and sequence discontinuities: 0/0
Out‑of‑order packets: 0
MOS:1.28

For incoming call at 17s
Interarrival jitter: 1200ms
Packets late/dropped: 112
Packets interpolated/PLC: 214
Jitter buffer underruns/overruns:112/0
Packet drop rate: 45%
Packet loss rate and sequence discontinuities: 0/0
Out‑of‑order packets: 0
MOS:1.19

Lots of Rx packets dropped.

Wow, that's pretty bad.

5) Has set all UDP timeout followed instructions in Step 25.

Your modem is an XB7 (a modem/router combo). By itself, those instructions can't be followed.

Do you also have your own router? If so, what brand and model is it?

Is this issue related to transcoding gateway of carrier?

VoLTE calls are commonly transcoded to G.711 at interconnects. If there's a transcoding issue occurring at an interconnect, then it's possible (but unlikely). Transcoding at interconnects (AMR‑WB/EVS to G.711) is normal and usually adds only a small processing delay. A 1.2 s interarrival (how unevenly packets show up . . . large values mean packets bunch up or spread out too much for smooth playback) jitter with huge late drops pattern matches timing/queuing and media steering, not codec conversion alone. That is, transcoding at interconnects (AMR‑WB/EVS <--> G.711) is common, but the 1.2 s interarrival jitter with huge late drops points to timing/queuing or media steering at/through the IMS/SBC rather than codec conversion delay.

Regardless, I don't know why I can't reproduce the problem while I'm on LTE with Telus and surfing.

(It's possible that VoLTE calls from Telus sometimes change how and where the voice stream flows a few seconds after the call starts, which makes packets show up late at your OBi200, so the ATA could throw them away. Then you hear silence or choppy audio even though the network didn’t loose them. Possibly using a router with with Smart Queue Management (CAKE,for example, but I find CAKE can be slow) may help.)

The call stats with no packet loss but huge late/dropped packets with big PLC (concealment) and jitter‑buffer underruns suggest packets arriving after the play deadline (delay/jitter), which explains why MOS (score) drops despite zero sequence gaps (and packets not being lost in transit). Packets arrive but too late to play, so the ATA discards them or reorders audio, which sounds choppy or results in silence.

The fact that only Telus VoLTE triggers this, while Bell works fine, strongly suggests something about Telus' IMS/SBC path. But without a packet/syslog capture showing a re-INVITE, media IP change, or timing spike at the failure moment, I'm mostly guessing.

One of the hardest things to configure with the Obihai ATAs is the jitter buffer. I know how to make adjustments on a per call basis, but that's not really useful if you want an all-encompassing solution for all calls: viewtopic.php?p=75415#p75415

Do blufferboat tests show anything abnormal on your end? https://www.bufferbloat.net/projects/bl ... fferbloat/
If they do, try sticking the XB7 in bridge mode and connect the OBi200 very briefly just for testing purposes. Try another Telus VoLTE call, and see if there's any change. Afterwards, revert from bridge mode so the ATA is protected again (if you don’t have your own separate router).

[Liptonbrisk]

I'm uncertain that escalating this potential interconnect carrier problem to Fongo would result in a fix because the problem just involves Telus VoLTE calls, and given that I can't reproduce the problem using an OBi202, not all of them are affected.

Anyway, the idea would be to try to capture a syslog (viewtopic.php?p=80667#p80667) or Wireshark packet capture that shows a readable media change in conjunction with re‑INVITE/UPDATE with the SDP media lines (c=/m=). Theoretically, even if there's no re‑INVITE/UPDATE but RTP timing spikes or stalls are seen at your end, that still suggests a transport/timing problem along the path to you.

Then you would report everything, along with the syslog and/or packet capture in a "my account inquiry" ticket: https://support.fongo.com/hc/requests/new

Login at https://www.freephoneline.ca/callLogs. Provide the time, date, and numbers involved in your ticket.

Then when you get a ticket number, private message it to me. Again, I can't promise anyone at Fongo will care enough to investigate though.

--
General Info


You can check your ticket status by logging in at
https://support.fongo.com/hc/requests. That's an account for tickets
(zendesk) only and is completely separate from your Freephoneline account or
any other Fongo account you may have. If you don't have a zendesk account yet, click "Sign Up" after visiting the link.
Use the same email address that you use to submit tickets. Do not use the same password as your Freephoneline
account. Again, these accounts are unrelated.

If your ticket is closed, you can submit another ticket: https://support.fongo.com/hc/requests/new (Choose "My Account Inquiry" for the final issue type.)

This is the escalation process: https://support.fongo.com/hc/articles/2 ... -Complaint.




Support staff does not respond to tickets on weekends or Canadian holidays.
Support hours are 9 a.m. until 4 p.m. EST.

Fongo does have https://twitter.com/Fongo_Support. I'm not sure if anyone
there responds to direct messages.

Similarly, they appear to be on Facebook:
https://www.facebook.com/FongoMobile/. I don't know whether they'll respond to you there.

[Liptonbrisk]

An easier, alternative method, for requesting help from Fongo would be try to see whether you can reproduce the problem between the specific Telus number(s) (while on VoLTE calls) and Fongo Mobile: https://www.fongo.com/services/fongo-mobile/.

If you can reproduce the problem using Fongo Mobile (test using both Fongo Mobile while on cellular data and then again on WiFi on your LAN using a smartphone), log into https://account.fongo.com/admin/reports/call-logs/. Select the current month, and click "submit" to get call log info.

Explain the problem (and that it only happens with Telus VoLTE calls and not from Bell) in a ticket. I would suggest mentioning (provided you can reproduce the problem using Fongo Mobile) that the problem may be an interconnect carrier issue. Provide the call log entries (provide the Date, From, To, Location, and Duration info) in a technical support ticket, as a Fongo Mobile user: https://support.fongo.com/hc/requests/new.

Afterwards, private message me with the ticket number: ucp.php?i=pm&mode=compose&u=1229.



You can check your ticket status by logging in at
https://support.fongo.com/hc/requests. That's an account for tickets
(zendesk) only and is completely separate from your Fongo Mobile account or
any other Fongo account you may have. If you don't have a zendesk account yet, click "Sign Up" after visiting the link.
Use the same email address that you use to submit tickets. Do not use the same password as your Fongo Mobile
account. Again, these two accounts are unrelated.

Support staff does not respond to tickets on weekends or Canadian holidays.
Support hours are 9 a.m. until 4 p.m. EST. They are not obligated to respond
on the these user-to-user forums.