Logicwrath Posted August 16, 2017 Report Share Posted August 16, 2017 (edited) Hello, On the hosted platform are there RTP media servers in all three locations East, Central, and West? I am troubleshooting audio issues and it seems like we only ever get 8.30.x.x or 8.36.x.x when specifying the outbound proxy as either us-central.p.zswitch.net or us-east.p.zswitch.net. When the outbound proxy is configured as us-central.p.zswitch.net the RTP media is typically 8.30.x.x which is high latency with packet loss. When the outbound proxy is configured as us-east.p.zswitch.net the RTP media is typically 8.36.x.x which is performs better. I was hoping and wondering if there are any RTP media servers in ORD. If there are I am trying to figure out why they never get chosen. Additionally, if there are only 2 sets of RTP media servers I am going to have to start specifying US-EAST because using the media from 8.30.x.x is not working out at all. When I look at the 2600hz SRV records I see references to ORD and EWR for US-CENTRAL. SJC only gets referenced in US-WEST. Please advise. *edit* Just to clarify, this is when using Yealink DNS-NAPTR with port 0 for server host and outbound proxy. Edited August 16, 2017 by Logicwrath (see edit history) Quote Link to comment Share on other sites More sharing options...
Logicwrath Posted August 16, 2017 Author Report Share Posted August 16, 2017 Just to clarify further in case this is hard to follow. When using SRV/NAPTR and selecting us-central.p.zswitch.net as the outbound proxy the phones are using SJC for their media servers in the 8.30.x.x range. We are now having to update all of our configs to use US-EAST until this gets reviewed and resolved. Quote Link to comment Share on other sites More sharing options...
Josh Robbins Posted September 8, 2017 Report Share Posted September 8, 2017 Logicwrath - Did you ever get anywhere on this? I have a lot of phones pointing at us-central so if there are RTP issues I'd love to know if I should redirect to east. Also how are you determining that us-central has high latency and packet loss for the RTP media? Quote Link to comment Share on other sites More sharing options...
Logicwrath Posted September 8, 2017 Author Report Share Posted September 8, 2017 I have not re-visited this since I made the original posting. I was hoping to get some kind of official response. We use Yealink phones. You can logon to the phones web interface, and then go to the Status -> RTP Status page. From here you will see what the "Remote IP" is for the current or previous call. I found that when using US-CENTRAL it is using RTP media from SJC which is on the west coast. I have not tested this again since I posted it. I suspect it is still doing it. I moved all of my phones over to US-EAST for now until this gets some review. Are there media servers in Chicago or only in US-EAST and US-WEST? We see packet loss and poor audio from using SJC media servers as we are in Michigan near Chicago. Quote Link to comment Share on other sites More sharing options...
esoare Posted September 8, 2017 Report Share Posted September 8, 2017 45 minutes ago, Logicwrath said: I have not re-visited this since I made the original posting. I was hoping to get some kind of official response. We use Yealink phones. You can logon to the phones web interface, and then go to the Status -> RTP Status page. From here you will see what the "Remote IP" is for the current or previous call. I found that when using US-CENTRAL it is using RTP media from SJC which is on the west coast. I have not tested this again since I posted it. I suspect it is still doing it. I moved all of my phones over to US-EAST for now until this gets some review. Are there media servers in Chicago or only in US-EAST and US-WEST? We see packet loss and poor audio from using SJC media servers as we are in Michigan near Chicago. Tested Central/West and East, and I see what you see. us-central.p.xxxxxx.net uses RTP IP of 8.3x.x.x which is a west coast Media server (from the little I know.:) ) ... Good question on the Media Servers in Central. I am facing issues with packet loss and poor audio on west coast, but IT is PROBABLY the Comcast/Cox providers../local equipment...At least that is what I am thinkin... Interesting... esoare Quote Link to comment Share on other sites More sharing options...
Administrators Darren Schreiber Posted September 23, 2017 Administrators Report Share Posted September 23, 2017 The media servers in ORD are 8.45.131.x . However there is a packet fragmentation problem in ORD when the packets are sourced from Rackspace servers, so we had temporarily disabled them. We will be restoring them this weekend, so you should start seeing that source IP as of Monday. Quote Link to comment Share on other sites More sharing options...
esoare Posted September 23, 2017 Report Share Posted September 23, 2017 10 hours ago, Darren Schreiber said: The media servers in ORD are 8.45.131.x . However there is a packet fragmentation problem in ORD when the packets are sourced from Rackspace servers, so we had temporarily disabled them. We will be restoring them this weekend, so you should start seeing that source IP as of Monday. What you mentioned above...would it affect the phones I point to us-west.p.zswitch.net? Just troubleshooting some issues with new customers... Quote Link to comment Share on other sites More sharing options...
Administrators Darren Schreiber Posted September 23, 2017 Administrators Report Share Posted September 23, 2017 No, I'm quite sure the issue being discussed in this thread is limited to us-east at this point. Quote Link to comment Share on other sites More sharing options...
esoare Posted September 23, 2017 Report Share Posted September 23, 2017 6 minutes ago, Darren Schreiber said: No, I'm quite sure the issue being discussed in this thread is limited to us-east at this point. Thanks for the confirm. Quote Link to comment Share on other sites More sharing options...
Logicwrath Posted September 25, 2017 Author Report Share Posted September 25, 2017 When I ping 8.45.131.1 our latency is ~50-70 ms. We typically see 18-30 ms to Chicago from Detroit. Quote Link to comment Share on other sites More sharing options...
Administrators Darren Schreiber Posted September 25, 2017 Administrators Report Share Posted September 25, 2017 Not sure where you're pinging from, but that round-trip is a direct connect via Level3 to Chicago and is looking just fine. There is no issue or slowdown there. So I'd have to see a full traceroute to even comment further. Quote Link to comment Share on other sites More sharing options...
Administrators Darren Schreiber Posted September 25, 2017 Administrators Report Share Posted September 25, 2017 Logicwrath, in your case, I looked up your IPs. You have one on Comcast that's all over the map but seems to be an issue on your side, and one via WideOpenWest that seems just fine. # ping 74.94.X.X PING 74.94.X.X (74.94.X.X) 56(84) bytes of data. 64 bytes from 74.94.X.X: icmp_seq=1 ttl=58 time=59.6 ms 64 bytes from 74.94.X.X: icmp_seq=2 ttl=58 time=38.0 ms 64 bytes from 74.94.X.X: icmp_seq=3 ttl=58 time=25.3 ms 64 bytes from 74.94.X.X: icmp_seq=4 ttl=58 time=40.7 ms 64 bytes from 74.94.X.X: icmp_seq=5 ttl=58 time=21.0 ms 64 bytes from 74.94.X.X: icmp_seq=6 ttl=58 time=64.3 ms 64 bytes from 74.94.X.X: icmp_seq=7 ttl=58 time=56.4 ms 64 bytes from 74.94.X.X: icmp_seq=8 ttl=58 time=51.8 ms 64 bytes from 74.94.X.X: icmp_seq=9 ttl=58 time=32.0 ms 64 bytes from 74.94.X.X: icmp_seq=10 ttl=58 time=28.9 ms 64 bytes from 74.94.X.X: icmp_seq=11 ttl=58 time=45.9 ms 64 bytes from 74.94.X.X: icmp_seq=12 ttl=58 time=73.0 ms 64 bytes from 74.94.X.X: icmp_seq=13 ttl=58 time=61.9 ms ^C --- 74.94.X.X ping statistics --- 13 packets transmitted, 13 received, 0% packet loss, time 12016ms rtt min/avg/max/mdev = 21.041/46.103/73.057/15.879 ms [root@fs001 ~]# ping 67.149.X.X PING 67.149.X.X (67.149.X.X) 56(84) bytes of data. 64 bytes from 67.149.X.X: icmp_seq=1 ttl=60 time=17.4 ms 64 bytes from 67.149.X.X: icmp_seq=2 ttl=60 time=16.9 ms 64 bytes from 67.149.X.X: icmp_seq=3 ttl=60 time=16.9 ms 64 bytes from 67.149.X.X: icmp_seq=4 ttl=60 time=16.1 ms 64 bytes from 67.149.X.X: icmp_seq=5 ttl=60 time=20.4 ms 64 bytes from 67.149.X.X: icmp_seq=6 ttl=60 time=18.9 ms 64 bytes from 67.149.X.X: icmp_seq=7 ttl=60 time=15.8 ms 64 bytes from 67.149.X.X: icmp_seq=8 ttl=60 time=17.9 ms 64 bytes from 67.149.X.X: icmp_seq=9 ttl=60 time=17.2 ms ^C --- 67.149.X.X ping statistics --- 9 packets transmitted, 9 received, 0% packet loss, time 8011ms rtt min/avg/max/mdev = 15.842/17.543/20.499/1.367 ms A traceroute to the poor looking route shows that we are at 8.7ms to the handoff point with Comcast in Shelby, MI: 1: no reply 2: ae-7-7.bar1.Detroit1.Level3.net 6.939ms asymm 3 3: Comcast-level3-50G.Detroit1.Level3.net 8.072ms 4: no reply 5: te-5-1-1-cbr02.shelby.mi.michigan.comcast.net 8.764ms 6: no reply So your issue on that Comcast link has to be something in your region or last-mile. You should contact Comcast about that. Quote Link to comment Share on other sites More sharing options...
Logicwrath Posted September 25, 2017 Author Report Share Posted September 25, 2017 Thanks! Quote Link to comment Share on other sites More sharing options...
Administrators Darren Schreiber Posted September 25, 2017 Administrators Report Share Posted September 25, 2017 Also I just checked some of your other customers who are also on TWC, and actually, they get 15-20ms! So seems like it's your site in particular that's having issues. You should definitely go yell at Comcast. Quote Link to comment Share on other sites More sharing options...
Logicwrath Posted September 25, 2017 Author Report Share Posted September 25, 2017 Tracing route to lag-14-172.ear1.chicago2.level3.net [8.45.131.1] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 10.10.0.1 2 * 3 ms 9 ms 7x-x-x-x-michigan.hfc.comcastbusiness.net [7x.x.x.x] 3 14 ms 23 ms 13 ms 96.120.41.65 4 14 ms 13 ms 24 ms te5-5-ur02.shelby.mi.michigan.comcast.net [68.86.140.49] 5 20 ms 13 ms 12 ms te-0-8-0-23-ar02.pontiac.mi.michigan.comcast.net [68.87.190.229] 6 16 ms 29 ms 16 ms ae2.bar1.detroit1.level3.net [4.68.71.33] 7 28 ms 34 ms 42 ms lag-14-172.ear1.chicago2.level3.net [8.45.131.1] Trace complete. Quote Link to comment Share on other sites More sharing options...
Administrators Darren Schreiber Posted September 25, 2017 Administrators Report Share Posted September 25, 2017 Try it from one of your customer/other sites. You'll see it's higher. Although even in what you pasted, that's a high of 42ms, not 50-70ms. But I was 50-70ms going to you when I tested, but again, ONLY to your site. Your customer sites (I tested 3) are fine. Quote Link to comment Share on other sites More sharing options...
Logicwrath Posted September 25, 2017 Author Report Share Posted September 25, 2017 Yes, I am seeing mixed results after I stopped and started the ping multiple times. It is currently running 18-30 now but there were multiple other tests that were much higher. My current latency is 19-40 ms averaging 25 ms which is inline with what i expected. Do routes like this get updated automatically after some data is sent using routing protocols like OSPF? Excuse my ignorance. Maybe we just needed to route their a few times for the routing tables to get updated. Quote Link to comment Share on other sites More sharing options...
Administrators Darren Schreiber Posted September 25, 2017 Administrators Report Share Posted September 25, 2017 Not likely. Seems like you're experiencing congestion frankly on your Comcast link. Especially since your other customers aren't having this issue. Quote Link to comment Share on other sites More sharing options...
Logicwrath Posted September 25, 2017 Author Report Share Posted September 25, 2017 Thank you. I will probably keep my people on EAST since previously on CENTRAL they were failing over to WEST while CENTRAL was down. We certainly want to keep people on CENTRAL or EAST and only use WEST as a last resort. Quote Link to comment Share on other sites More sharing options...
Administrators Darren Schreiber Posted September 25, 2017 Administrators Report Share Posted September 25, 2017 I would not recommend that. You can make your own SRV records, but intentionally routing calls to a server that's not actually the closest to your customers doesn't make a ton of sense. Quote Link to comment Share on other sites More sharing options...
Logicwrath Posted September 25, 2017 Author Report Share Posted September 25, 2017 I switched my Yealink T46S back to US-CENTRAL for testing and I am still getting 8.30.x.x RTP media. The packet loss is very bad. This is on firmware 66.81.0.90. I made 3 test calls and the results were very bad due the amount of packet loss we get to SJC. I am using DNS-NAPTR and the phone is provisioned with the provisioner. Any idea why we are still getting sent to SJC for RTP media? I had reviewed the 2600hz SRV records before I created this thread and it looked like the priorities were set to my expectations. It just seems like the phones are not honoring those records properly. I assume the SRV priorities work like MX records where lower priorities get used first. If that holds true I would expect to get media from CENTRAL first, then EAST, then as a last resort WEST. Additionally, it looks like WEST is not even configured. This is the response we get when querying the SRV records for "_sip._udp.us-central.p.zswitch.net" Non-authoritative answer: _sip._udp.us-central.p.zswitch.net SRV service location: priority = 20 weight = 20 port = 7000 svr hostname = lb001.ewr.p.zswitch.net _sip._udp.us-central.p.zswitch.net SRV service location: priority = 10 weight = 10 port = 7000 svr hostname = lb002.ord.p.zswitch.net lb001.ewr.p.zswitch.net internet address = 8.36.70.3 Quote Link to comment Share on other sites More sharing options...
Logicwrath Posted September 25, 2017 Author Report Share Posted September 25, 2017 It's worth noting that the same RTP media servers are getting used in my Bria configuration as well when selecting US-CENTRAL as the outbound proxy. Quote Link to comment Share on other sites More sharing options...
Tuly Posted September 26, 2017 Report Share Posted September 26, 2017 I do not believe it has anything to do with SRV records, or with model of phone you are using, when you register your SIP signaling to us-central, and you make a call the server (2600HZ) decides what the RTP media server should be, the phone or the SRV record do not and cannot decide, Quote Link to comment Share on other sites More sharing options...
Logicwrath Posted September 26, 2017 Author Report Share Posted September 26, 2017 Could this be an issue with the Kamailio configuration then? The vast majority of our calls when registered to US-CENTRAL are getting RTP media from SJC. When they don't get SJC they get EWR. However, we have not seen any RTP from ORD. We have had to completely stop using US-CENTRAL. Quote Link to comment Share on other sites More sharing options...
Administrators Darren Schreiber Posted October 9, 2017 Administrators Report Share Posted October 9, 2017 On 9/26/2017 at 8:18 AM, Logicwrath said: Could this be an issue with the Kamailio configuration then? The vast majority of our calls when registered to US-CENTRAL are getting RTP media from SJC. When they don't get SJC they get EWR. However, we have not seen any RTP from ORD. We have had to completely stop using US-CENTRAL. us-central should be stable, but we did find a configuration issue where if ORD servers were maxed out they would failover to SJC. However, we also noted in your examples that you seem to be checking the RTP stats on the Yealink but that status screen doesn't update until your call hangs up. Can you detail exactly how you checked this? us-central actually has our newest and best boards and network so it would surprise me if there was a real issue there. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.