2600hz Hosted RTP Media Servers

Logicwrath · August 16, 2017

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)

Logicwrath · 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.

Josh Robbins · 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?

Logicwrath · 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.

esoare · 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

Darren Schreiber · 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.

esoare · 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...

Darren Schreiber · September 23, 2017

No, I'm quite sure the issue being discussed in this thread is limited to us-east at this point.

esoare · 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.

Logicwrath · 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.

Darren Schreiber · 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.

Darren Schreiber · 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.

Logicwrath · September 25, 2017

Thanks!

Darren Schreiber · 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.

Logicwrath · 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.

Darren Schreiber · 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.

Logicwrath · 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.

Darren Schreiber · 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.

Logicwrath · 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.

Darren Schreiber · 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.

Logicwrath · 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

Logicwrath · 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.

Tuly · 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,

Logicwrath · 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.

Darren Schreiber · 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.

Sign In

2600hz Hosted RTP Media Servers

Recommended Posts

Logicwrath

Logicwrath

Josh Robbins

Logicwrath

esoare

Darren Schreiber

esoare

Darren Schreiber

esoare

Logicwrath

Darren Schreiber

Darren Schreiber

Logicwrath

Darren Schreiber

Logicwrath

Darren Schreiber

Logicwrath

Darren Schreiber

Logicwrath

Darren Schreiber

Logicwrath

Logicwrath

Tuly

Logicwrath

Darren Schreiber

Join the conversation

Community Forums

Products

Support