[VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)

[Jim Rodgers]

We just set up a VPN from one of our customers to our data center and the
audio issue is gone as the traffic is going over the VPN. So VPN does
resolve the problem.

Jim

On Fri, Mar 8, 2024 at 07:45 Nathan Anderson via VoiceOps <
voiceops at voiceops.org> wrote:

> Assuming I understood the original problem description accurately, I don't
> see how a lossy trunk somewhere could explain 100% loss of *just* RTP and
> only in *one* specific direction with *zero* impact to any other internet
> traffic.  You'd think that at least some RTP frames would manage to squeak
> by every once in a while, and that these users would have complaints about
> other non-voice-related things also not working as well.
>
>
>
> Of course, the TLS would only make it impossible for the RXing carrier to
> peer into the SIP signalling to see details about the RTP session set-up.
> So if they're doing something more brain-dead to UDP in general, TLSing the
> SIP isn't going to work around that.  Taking one of your affected customers
> and encapsulating the whole enchilada -- SIP, RTP, and all -- within a VPN
> would actually be a pretty interesting experiment...
>
>
>
> -- Nathan
>
>
>
> *From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Jim
> Rodgers via VoiceOps
> *Sent:* Friday, March 8, 2024 7:09 AM
> *To:* Mike Hammett
> *Cc:* voiceops at voiceops.org
> *Subject:* Re: [VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)
>
>
>
> We use SIP TLS. I don't think they're intentionally blocking voice
> traffic, I think there's something broken inside their network that needs
> to be fixed (lossy link somewhere?).
>
>
>
> The issue is getting anyone there to recognize the issue and want to fix
> it.
>
>
>
> Jim
>
>
>
> On Fri, Mar 8, 2024 at 5:32 AM Mike Hammett <voiceops at ics-il.net> wrote:
>
> I don't trust last mile networks to reliably deliver SIP calls. I usually
> end up putting them into VPNs, TLS, etc.
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
>
> ------------------------------
>
> *From: *"Jim Rodgers via VoiceOps" <voiceops at voiceops.org>
> *To: *voiceops at voiceops.org
> *Sent: *Thursday, March 7, 2024 11:16:23 AM
> *Subject: *[VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)
>
> Beginning early yesterday, we're seeing dropped voice rtp traffic to some
> of our business customers in the Los Angeles metro area on Frontier Comm
> broadband fiber. The voice udp stream is leaving our data center and never
> making it to the Frontier fiber customer. It's not all of our customers,
> only random ones. We've sniffed the traffic on our side and see the voice
> rtp stream leave our data center but then sniffing on our customer's side
> the traffic never arrives (multiple Frontier fiber customers with this
> issue, not just one).
>
>
>
> Switching the customer over to an alternate Internet connection resolves
> the issue.
>
>
>
> Frontier frontline customer support doesn’t get it and they just want to
> roll a tech out for an issue that’s deeper inside their network.
>
>
>
> We have packet captures of both sides (our DC and your customer) showing
> the voice rtp stream leaving our DC and never showing up at the fiber
> customer.
>
>
>
> This doesn’t seem to be affecting every fiber customer in the Frontier
> footprint, it just seems to be random customers.
>
>
>
> Anyone else experiencing this issue? Any thoughts on who to contact on the
> Frontier side to get it resolved and/or get some eyes on it?
>
>
>
> Thanks for the help.
>
>
>
> Jim
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20240308/37ce7691/attachment.htm>