Hi Richard,

>> Seems to me your last hop network carrier is resetting the RTP SSRC pkt sequence number

Possible but hard to say without seeing some pcaps. I would say that sequence number jumps/gaps in either direction are not necessarily errors or higher level alerts unless accompanied by other errors -- codec, timestamp, audio qualty. Our customers sometimes report loss problems around SSRC handoffs -- the stream changes but is intermittent or has gaps, packet rate is bursty, etc.

Mike your SBC doesn't show anything ?  No codec bad frame errors, no packets "re-timed" due to mismatch in actual arrival and RTP timestamps, no wrong packet rates (e.g. much slower or faster than 20 msec) ? 

-Jeff

Quoting Richard Jobson via VoiceOps <voiceops@voiceops.org>:

Hi Mike

 

An interesting one 

 

Seems to me your last hop network carrier is resetting the RTP SSRC pkt sequence number (don’t know how prevalent this is in todays networks) so no continuous pkt metrics will catch the dropped pkts

 

Ignoring active testing which always has blind spots and does not capture the offending data 

 

NISQA is now an ITU standard for non-referenced ( ie continuous monitoring at the speech layer) so will alert you when speech is bad to end users per channel 

 

Plus codec performance and information on NBv WB

 

Let’s know if you need more information 

Thanks 

Richard 

Sent from my iPhone

On Nov 5, 2026, at 2:17 AM, Jeff Brower via VoiceOps <voiceops@voiceops.org> wrote:

Hi Mike,

Can you send me anonymized pcaps ? I can run them with Mediashark and see what alerts and stats * show. Maybe there are less obvious errors that occur earlier.

-Jeff

packet flow integrity, voice quality, timing, etc

oting Mike Hammett via VoiceOps <voiceops@voiceops.org>:

Hi all,

 

We just chased two weeks of intermittent inbound RTP loss (carrier toward our SBC, business hours only) that nothing we had could see. Our SBC's counters and VoIPmonitor agreed on what arrived; the carrier's egress probe showed zero loss, so the loss was somewhere on the public path between them, and the carrier called it clean. We are also mid-migration from Metaswitch to NetSapiens, so whatever we set up has to make sense on both.

 

Before this, we had VoIPmonitor on a mirror of the SBC traffic and Smokeping and LibreNMS watching our own routers, which told us nothing about the carrier path. What we are putting in now: MOS and loss alerts in VoIPmonitor, Smokeping with call-shaped pings (1 per second, 172 bytes, EF) to every hop toward each carrier that answers, and SIP OPTIONS every minute to the carriers' SBCs (they answer with a 500, which is fine; it is a timed reply over the real path). The gap is anything that measures inbound traffic to us continuously.

 

I am after persistent monitoring people have left running for months, not one-off tests. A few things I would like to hear about:

- Scheduled test calls through the carrier, scored by your passive monitor. Who places them, how often, and did it ever catch something before customers did?

- Carriers that give you ongoing quality data: RTCP from their side, a looking glass, per-trunk stats. Does anyone get this without a fight?

- Measuring one-way loss toward you. A VM near the carrier running irtt or similar? Something a NetSapiens shop already does out of the box?

- OPTIONS to carrier SBCs as a standing probe. Any carrier pushback?

 

The 2023 "troubleshooting RTP loss" thread covered the one-off side (mtr, sized pings, Telchemy). I will summarize the replies and add them to the list.

 

Thanks,
Mike

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com