Time for a new modem haha ---- On Fri, 08 Mar 2024 11:48:40
-0500 [email protected]<[email protected]> wrote ----
div.zm_7208056706780523974_parse_3217461976481657867 p.MsoNormal,
div.zm_7208056706780523974_parse_3217461976481657867 li.MsoNormal,
div.zm_7208056706780523974_parse_3217461976481657867 div.MsoNormal { margin:
0in; font-size: 12pt; font-family: "Times New Roman", serif }
div.zm_7208056706780523974_parse_3217461976481657867 a:link,
div.zm_7208056706780523974_parse_3217461976481657867
span.x_1296020992MsoHyperlink { color: blue; text-decoration: underline }
div.zm_7208056706780523974_parse_3217461976481657867
span.x_1296020992EmailStyle23 { font-family: "Calibri", sans-serif; color:
windowtext }
div.zm_7208056706780523974_parse_3217461976481657867 .x_1296020992MsoChpDefault
{ font-size: 10pt }
div.zm_7208056706780523974_parse_3217461976481657867
div.x_1296020992WordSection1 { } From: VoiceOps
<[email protected]> On Behalf Of Nathan Anderson via VoiceOpsSent:
Friday, March 8, 2024 11:47 AMTo: [email protected]: Re: [VoiceOps]
One Way Audio - Frontier Comm (Los Angeles area) "but I did get TCP rejections
to my inbound UDP packets" ? Did you mean you got ICMP messages back from some
router on their network in response to the UDP transmissions you were sending?
Not TCP, surely... -- Nathan From: VoiceOps
[mailto:[email protected]] On Behalf Of Kent A via VoiceOpsSent:
Friday, March 8, 2024 7:55 AMTo: [email protected]: Re: [VoiceOps]
One Way Audio - Frontier Comm (Los Angeles area) I too have a customer in the
same area with the same exact problem. However they are doing SIP over UDP, and
initially inbound SIP packets from my server headed to the client at frontier
were getting rejections. I could see their SIP packets, but they never got
mine, but I did get TCP rejections to my inbound UDP packets. Frontier rolled a
truck, the tech said there was nothing he could do and he would escalate to
Tier II. As soon as his truck left the parking lot, SIP was working in both
directions, but this new RTP situation was now present. Never received a
callback from Tier II, but it’s clear they were able to “unblock” SIP packets
that they suddenly started blocking. Would love to know if a VPN gets around
this whole mess. -Kent From: VoiceOps <[email protected]> On
Behalf Of Nathan Anderson via VoiceOpsSent: Friday, March 8, 2024 10:45 AMTo:
[email protected]: Re: [VoiceOps] One Way Audio - Frontier Comm (Los
Angeles area) 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:[email protected]] On Behalf Of Jim Rodgers via
VoiceOpsSent: Friday, March 8, 2024 7:09 AMTo: Mike HammettCc:
[email protected]: 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 <[email protected]> wrote:I don't trust last mile networks to
reliably deliver SIP calls. I usually end up putting them into VPNs, TLS,
etc.-----Mike HammettIntelligent Computing
Solutionshttp://www.ics-il.comMidwest Internet
Exchangehttp://www.midwest-ix.com From: "Jim Rodgers via VoiceOps"
<[email protected]>To: [email protected]: Thursday, March 7, 2024
11:16:23 AMSubject: [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
[email protected]https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list
[email protected] https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
