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.

[johnf]

Thanks for your suggestions.

My rogers gateway actually is xb8. I don't have a router at hand.

I just setup syslog you mentioned and have captured a sequence of outgoing call messages. I can not post message here as it includes my phone numbers.
I don't know if I can pm it to you, so maybe you can find something from it.

[Liptonbrisk]

My rogers gateway actually is xb8.

Okay. Not that it matters because I strongly suspect the problem is unrelated to UDP timeouts, but since you can't set UDP unreplied and UDP assured timeouts in the XB8, you can't satisfy these conditions, easily:

UDP Unreplied Timeout (in your XB8) < X_KeepAliveExpires (in your Obihai ATA) < UDP Assured Timeout (in your XB8) < RegisterRetryInterval (in your Obihai ATA)

“<“ means less than.

I just setup syslog you mentioned and have captured a sequence of outgoing call messages. I can not post message here as it includes my phone numbers.

I should have probably deleted that response to you after I thought of Fongo Mobile.

Here is my reasoning:

1. Fongo does not offer technical support for Freephoneline--especially not for problems that may be on the user's end (or Rogers'). I initially thought if I could take a look at your syslog and see if something immediately jumps out, I could say, "Okay, here's evidence of the problem." But that's unlikely if the problem is occurring with an upstream or interconnect carrier. The syslog is only going to show the SIP signalling that your ATA receives and sends. I can't see what's going on at the other end (or anywhere else) of the call easily.

Then you would have to report the problem to Fongo in a ticket and provide me with the ticket number. I would try to get someone to take a look. Again, I can't promise that anything will come from doing that though. I don't work for Fongo.

2. Fongo does offer technical support for Fongo Mobile, which is a smartphone app that's free to use. Fongo Mobile uses the same network, basically, as Freephoneline. If you can reproduce the problem using Fongo Mobile, you can just report the problem (without syslogs) directly as I described previously to Fongo: viewtopic.php?p=82817#p82817.

Then you provide me with the ticket number, and I would try to get someone to take a look. Again, I don't work for Fongo, so I'm not sure what will happen.

In both cases, I can't promise anything--except #2 is at least, theoretically, supported by Fongo, since Fongo does provide technical support for Fongo Mobile.

I don't know if I can pm it to you

If the syslog exceeds the file attachment limit, you'd have to upload it somewhere (maybe Google drive, for example), and provide me (PM) with a link if you don't want to post it here. However, I feel option #2 is more likely to produce some sort of response at least from Fongo's customer support staff, and I wouldn't need your syslogs.

By the way, if placing the XB8 in bridge mode (https://www.rogers.com/support/internet ... ty-gateway) and directly connecting the ATA to the XB8 via ethernet cable (and disconnecting all other devices from the back of the XB8) resolves the problem, then it's an issue with some router function in the XB8 (local queuing with other devices taking priority, NAT, or, less likely, SIP ALG). After testing, you can factory reset the XB8 so that bridge mode is disabled again. Bridge mode turns the XB8 into a pure modem (and disables potential router and firewall features that could possibly be interfering; that test also removes the possibility of other devices hogging bandwidth or being given priority over the OBi200). Keep in mind that bridge mode leaves your ATA unprotected from the XB8's firewall, so use bridge mode briefly for testing purposes only. If you need help with enabling and disabling bridge mode, contact Rogers.

I suspect the problem is an inter-connect (or upstream) carrier issue, but I'm not positive.

[Liptonbrisk]

Okay, I took a look at the syslog you PMed me.

Although SIP signalling looks normal, the final X‑RTP‑Stat line proves the media (RTP audio stream) was in terrible shape. Nothing in the syslog shows a codec/negotiation error or a mid‑call re‑INVITE, and the SDP points to G.711 u‑law (audio codec) being used on both sides. So the failure is in RTP timing/transport, not SIP setup.

INVITE --> 401 (auth) --> INVITE with auth --> 100 Trying--> 180 Ringing --> 200 OK--> ACK. That’s a clean SIP handshake with no re‑INVITE/UPDATE, and there's no SDP mismatch.

For media negotiation, your ATA offers both G.711u/a and G.729 for the telephone‑event; the 200 OK answers with G.711u (PCMU), ptime 20 ms. That’s a simple, normal audio setup.

“RTP:Start->d0xxxxxxx:xxxxx(80 160)” indicates the OBi200 begins sending/expecting RTP to 208.xx.xxx.xxx:xxxxx as per SDP (Session Description Protocol).

I replaced stuff with x's, for safety.

The following is terrible. The media/stream stats at hang-up are awful: “X‑RTP‑Stat: PS=737, OS=126764, PR=407, OR=70004, PL=0, JI=1408, DU=14, EN=G711U, DE=G711U, MOS=1.10”.


PR vs. PS

- far fewer packets received (PR) than sent (PS) from the far end’s point of view, or vice‑versa depending on vendor field order; combined with MOS=1.10 is just . . . really bad.

PL=0

- network‑level packet loss inferred by sequence numbers is zero. So packets weren’t lost.

JI=1408

- interarrival jitter is approximately 1.4 seconds, which is incredibly (orders of magnitude) higher than any reasonable playout buffer.

DU=14

- jitter buffer underruns were recorded

MOS=1.10

- confirms horrific, unusable audio quality

There's no mid‑call SIP re‑INVITE/UPDATE or second SDP that shows a media re‑anchor/re-negotiation. That doesn’t rule out path or queuing changes upstream; this only indicates the endpoint (your ATA) didn’t receive a signalling change during the portion of the syslog you sent me. (The lack of a re‑INVITE/UPDATE means the IP/port your ATA uses for the RTP audio stream didn’t change, so a re‑anchoring that changes your ATA’s remote media address is very unlikely. However, the carrier can still reroute or re‑anchor media inside its own network behind the SBC without signalling the ATA, and that can change jitter/delay even though your SDP never changes.)

SIP and SDP appear normal. The call failed at the RTP (media/audio stream) layer due to extreme delay variation: packets arrived far too late. Consequently, the OBi200 dropped them at playout time (PL=0 but MOS is 1.1 along with massive jitter). This matches the earlier OBi call‑status counters (huge late/dropped packets, high PLC, underruns) and explains why audio works briefly and then fails.

So . . .

1. If placing the XB8 in bridge mode (https://www.rogers.com/support/internet ... ty-gateway) and directly connecting the ATA to the XB8 via ethernet cable (and disconnecting all other devices from the back of the XB8) resolves the problem, then it's an issue with some router function in the XB8 (local queuing with other devices taking priority, NAT, or, less likely, SIP ALG). After testing, you can factory reset the XB8 so that bridge mode is disabled again. Bridge mode turns the XB8 into a pure modem (and disables potential router and firewall features that could possibly be interfering; that test also removes the possibility of other devices hogging bandwidth or being given priority over the OBi200). Keep in mind that bridge mode leaves your ATA unprotected from the XB8's firewall, so use bridge mode briefly for testing purposes only. If you need help with enabling and disabling bridge mode, contact Rogers.

Using bridge mode and testing helps to rule out a problem on your end.

and

2. Report everything 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. You need to provide that call information 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. I don't work for Fongo.

3. Additionally, if you can reproduce the problem using Fongo Mobile and submit a ticket, you should eventually get a response. PM me the ticket number as well if you pursue trying Fongo Mobile. I don't know that you'll like the response, but you should receive one since Fongo Mobile is officially supported, whereas Freephoneline isn't.

Again, I lean towards the problem being an inter-connect (or upstream) carrier issue, but I'm not 100% positive. Most of what I can see from the client-side points in that direction.

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