Interesting, not sure. We will have to retest with one of our customers. We
failed them over to their back up connection or put them on VPN, so they’re
all working now regardless.
Jim
On Fri, Mar 8, 2024 at 15:20 Nathan Anderson wrote:
> Kemt mentioned that it has since cleared up for him.
Kemt mentioned that it has since cleared up for him. Are the rest of your
customers also now working, without the VPN workaround?
-- Nathan
From: Jim Rodgers [mailto:jrodg...@telexent.com]
Sent: Friday, March 8, 2024 9:14 AM
To: Nathan Anderson
Cc: voiceops@voiceops.org
Subject: Re:
I'm working on a project to analyze traffic to unassigned numbers,
including previously assigned numbers that are still receiving traffic
post-aging. Of specific interest are residential and mobile carriers,
and LATA or rate centers outside the footprint of the major VoIP
carriers, especially
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@voiceops.org> wrote:
> Assuming I understood the original
In this age of AI, why would we be surprised when the machines try to talk to
us... :-)
-Original Message-
From: Brian :: [mailto:b...@iptel.co]
Sent: Friday, March 8, 2024 9:06 AM
To: Nathan Anderson
Cc: voiceops@voiceops.org
Subject: Re: [VoiceOps] One Way Audio - Frontier Comm (Los
Never send a human to do a machine's job.
> On 8 Mar 2024, at 17:01, Nathan Anderson via VoiceOps
> wrote:
>
> Or there was an actual payload inside with an English text string?
___
VoiceOps mailing list
VoiceOps@voiceops.org
Wh...?
Do you mean that, in response to inbound UDP traffic, something was sending
back, like, TCP RST? Or there was an actual payload inside with an English
text string?
Was the source IP just the same as the IP you were targeting, or seemingly some
carrier router in the middle?
ICMP I would have noticed right away. I thought we were screaming into the void
until at last I found those packets. Something was clearly consuming my UDP,
and replying with a rejection message in TCP, not ICMP. It made zero sense.
Interestingly, the client just called and said all
Time for a new modem haha On Fri, 08 Mar 2024 11:48:40
-0500 voiceops@voiceops.org wrote
div.zm_7208056706780523974_parse_3217461976481657867 p.MsoNormal,
div.zm_7208056706780523974_parse_3217461976481657867 li.MsoNormal,
From: VoiceOps On Behalf Of Nathan Anderson via
VoiceOps
Sent: Friday, March 8, 2024 11:47 AM
To: voiceops@voiceops.org
Subject: 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
"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:voiceops-boun...@voiceops.org] On Behalf
Hi David-
I second. Although encapsulation can have its own issues, one we see
often is RTP packet rates not matching timestamps, sometimes up to 10%
off (media/announcement servers are typical offenders). But that can
be unraveled and is not a config issue.
-Jeff
Quoting "Hiers, David
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
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
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
> On 8 Mar 2024, at 08:49, Hiers, David wrote:
>
> Well... yeah, kinda-sometimes maybe.
>
> If any network device has any code that is SIP/RTP aware, that code can be
> poorly configured or make a mistake. Hiding SIP/RTP inside anything else is
> one way to avoid being seen by bad configs
> On 8 Mar 2024, at 08:44, Mike Hammett wrote:
>
> In my experience, yes. Well, at least the reliable delivery of my voice
> traffic. Whether intentional or mistake (I'm hoping the latter), I've had
> random reliability on some major last mile networks. Never a problem when one
> of the
Well... yeah, kinda-sometimes maybe.
If any network device has any code that is SIP/RTP aware, that code can be
poorly configured or make a mistake. Hiding SIP/RTP inside anything else is
one way to avoid being seen by bad configs or buggy code.
A VPN can't prevent backhoe drivers from
In my experience, yes. Well, at least the reliable delivery of my voice
traffic. Whether intentional or mistake (I'm hoping the latter), I've had
random reliability on some major last mile networks. Never a problem when one
of the previous is done.
-
Mike Hammett
Intelligent
> On 8 Mar 2024, at 08:32, Mike Hammett via VoiceOps
> wrote:
>
> I don't trust last mile networks to reliably deliver SIP calls. I usually end
> up putting them into VPNs, TLS, etc.
VPNs and TLS make last-mile networks more reliable? :-)
-- Alex
--
Alex Balashov
Principal Consultant
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
- Original Message -
From: "Jim
21 matches
Mail list logo
