On Fri, 31 Jul 2015, Christopher Morrow wrote:
On Fri, Jul 31, 2015 at 8:07 AM, John Kristoff <jtk@cymru.com> wrote:
On Thu, 30 Jul 2015 21:18:10 -0500 Jason Baugher <jason@thebaughers.com> wrote:
In one case, when we were having an issue with a SIP trunk, we re-numbered our end to another IP in the same subnet. Same path from A to Z, but the packet loss mysteriously disappeared using the new IP. It sure seems like they are throttling somewhere.
Not knowing how you evaluated the two paths, but if MPLS was not considered, it may have perhaps been due in part to ECMP behavior. While not ruling out UDP limits, it is plausible that the changed source IP address resulted in a less congested path to be chosen.
ding! this sounds like the most plausible answer... I wouldn't expect L3 to limit udp/5060/6061/SIP traffic, as a common carrier that also runs a SIP trunking service they:
Jason said it was the RTP traffic that was lossy over L3...so that's not UDP/5060, but [at least commonly] UDP/10000:20000. i.e. to a network engineer trying to harden the network against DDoS attacks, just random UDP traffic. Someone writing a stateless UDP filter/policer not thinking about RTP might easily implement a filter that doesn't allow all RTP packets to pass. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________