Cisco switch

[kevnich2]

I currently am utilizing a 48 port gigabit L3 switch from Dell. We're having some odd issues with our VOIP server that I'm not sure what is causing the issue yet. Our VOIP vendor is pointing fingers at the switch and switch is pointing it at the VOIP server. I know Dell is not the best switch to have when it comes to L3 routing capabilities but there was a cost factor involved, obviously.

I am interested in seeing what is out there for a comparable Cisco switch either 24 or 48 port, gigabit with VLAN and Layer 3 routing capabilities. What are some model numbers from Cisco that I can take a look at to see what we'd be looking at for price wise and what not?

Thanks in advance!

 

[drebo]

Catalyst 4948s are great. They have long queues and dual power supplies.

They're readily available on the grey market as well.

That would be my recommendation.

I would not recommend Dell in any way.

Also, it's unlikely that a switch is causing issues with VoIP, unless the issues are functional, rather than quality (which you didn't really specify.)

 

[sactwnguy]

Keep in mind the 4948's are going eol so you might want to go 4948e which unfortunately pushes the price up some. If the 4948e costs too much you can look at the 3750v2 or 3750x models.

 

[drebo]

If you're going "brand new", I'd suggest the 3560X instead of the 3750X. The only thing the 3750 gets you over the 3560 is the ability to stack. Just remember that the IP Services license is stupid expensive.

However, the 4948 is cheap enough to buy two used and still come out ahead.

 

[sactwnguy]

I guess i am just getting too used to being in the enterprise. I went 3750 because of its ability to stack for future expansion and yes you can buy the 4948 cheap used but end of software support is less than a year away. With requirements to keep up on security updates this would concern me.

 

[drebo]

Sure, I can understand that. However, I would take a used, EOL Cisco Catalyst switch over a Dell switch any day.

 

[cmetz]

I currently am utilizing a 48 port gigabit L3 switch from Dell. We're having some odd issues with our VOIP server that I'm not sure what is causing the issue yet. Our VOIP vendor is pointing fingers at the switch and switch is pointing it at the VOIP server. I know Dell is not the best switch to have when it comes to L3 routing capabilities but there was a cost factor involved, obviously.

I'm assuming that you have the Dell 6xxx switches. They've got problems, yes they do. But nine out of ten times I hear a story like yours, I immediately think that the vendor is pointing the finger at the switch because it's a convenient excuse rather than actually dig into the problem.

Has the vendor offered you a coherent explanation as to why they are certain that the switch is the issue?

Will the vendor agree to demonstrate on-site (e.g., through a loaner) that replacing the switch WILL fix your problem?

Can you hold the vendor financially accountable if you buy a whole new switch and it does not fix the problem?

Based on the question you're asking, I'm assuming that you're a small business with a small network. You probably aren't using any features on the switch beyond basic static-route L3 forwarding. As far as I know, that much does work okay on those Dell switches.

 

[kevnich2]

Cmetz - Correct, we're a small business and our switch, on the L3 side is only using basic static and vlan routing (3 VLANs). I'm not at all convinced the issue is actually with the switch. Audio itself on calls through the phones has not a single hiccup, crystal clear. The phone's voicemail app feature is giving us alot of headaches and yes, the vendor is pointing fingers at the network.

I've been in support positions myself, I know how the game works. I also like having all my options. We did do a packet capture on our VOIP server and a phone and they're stance is that since we were seeing TCP reset packets being sent, it's a network problem. I'm also seeing the same tcp reset packets being sent from a phone that is directly connected to a small 5 port switch and just the server. This doesn't tell me where the issue is yet but I'm not convinced yet it's the switch.

 

[Comblues]

Cmetz - Correct, we're a small business and our switch, on the L3 side is only using basic static and vlan routing (3 VLANs). I'm not at all convinced the issue is actually with the switch. Audio itself on calls through the phones has not a single hiccup, crystal clear. The phone's voicemail app feature is giving us alot of headaches and yes, the vendor is pointing fingers at the network.

I've been in support positions myself, I know how the game works. I also like having all my options. We did do a packet capture on our VOIP server and a phone and they're stance is that since we were seeing TCP reset packets being sent, it's a network problem. I'm also seeing the same tcp reset packets being sent from a phone that is directly connected to a small 5 port switch and just the server. This doesn't tell me where the issue is yet but I'm not convinced yet it's the switch.

TCP Resets? - Interesting.

VoIP usually uses UDP Packets.

So...

Probably not the same issue.

The issue probably comes down to queuing and prioritization.

It sounds like you are missing a feature in the Cisco world known as LLQ - or Low Latency Queuing.

Voice Packets are UDP and only 300 bytes at that. That's it.

So... You don't need a big switch per say but you do need a smart switch that is configured to respect VoIP packets and VoIP Signalling so that VoIP does not drop or is not subject to delay in the network.

Comblues

 

[kevnich2]

In this case the voice itself is actually fine. The phones and server are both same vendor (switchvox). This allows the phone to have some more special features like a visual voicemail app and things. It's these special features we are having the issue with and they all communicate with the server through tcpip. The UDP SIP traffic is perfectly fine from what i can see. Phones make and receive calls, audio is crystal clear, no issues on that part. This is part of the reason I am hesitant pointing blame at the switch. But I am certainly not a network engineer.

Ironic - UDP which has no checks to ensure data arrives is just fine but the features that ride with tcpip are the ones having issues.

 

[drebo]

You're using Digium phones?

The visual voicemail component of those phones is indeed SIP-based. I'm not sure what the actual media transport is but I'd wager it's simply RTP.

I've started using Digium phones pretty extensively lately and there are some quirks and major bugs with some versions of the DPMA module. Could you expand on what specific issues you're having?

Are the apps just plain not functioning or are you seeing quality issues with the voicemails as they play?

Are the phones and the PBX in the same VLAN?

 

[kevnich2]

You're using Digium phones?

The visual voicemail component of those phones is indeed SIP-based. I'm not sure what the actual media transport is but I'd wager it's simply RTP.

I've started using Digium phones pretty extensively lately and there are some quirks and major bugs with some versions of the DPMA module. Could you expand on what specific issues you're having?

Are the apps just plain not functioning or are you seeing quality issues with the voicemails as they play?

Are the phones and the PBX in the same VLAN?

The visual voicemail transport is rtp. The initiation of the server delivering the voicemail to the phone and phone playing it seems to involve several packets of TCPIP and TLS. What we are experiencing is that when we choose messages, choose a voicemail and push play, it will say fetching voicemail for a second or two, then the progress bar will sart moving but no audio for anywhere from .5 seconds to 15 seconds. Then near the end, itncus the ending of the voicemail off because I assume it assumes its reached end of the voicemail.

In the packet traces, it looks like a bunch of tcpip and TLS packets, then rtp for about 20 packets (I assume the dead air audio), then a tcp reset is sent from the phone to the switchvox, then a much longer rtp stream (which I assume is the actual audio playing) then it's done.

I tested with a single phone hooked to a small physically separate switch and the switchvox. Voicemails seem to play ok until we played about 6 voicemails then started delaying a bit again. In packet capture, every voicemail we played showed a tcp reset packet, even ones that seem to play fine, which left me a bit confused

As far as topology, the server itself is in a different vlan than the phones. We are actually utilizing one server with phones spread through several offices running 20mb/s fiber. Each location on its own vlan subnet. This is all connected via Cisco switches from our carrier provider and gives us average of 8ms latency to all office locations.

When we did initial testing, the system worked fine, no issues until we actually went live and added the phones to each of the offices, the delays got worse and worse, even though each location is again on its own vlan.

 

[drebo]

Does this happen at all the sites?

I've used these phones and visual voicemail pretty extensively and never seen this issue. It sounds like the switchvox is sending SIP over TCP with TLS, which is fine...however, for debugging sake, I wonder if it'd be possible to turn that off and have SIP use UDP. The protocol that DPMA uses to talk to Digium phones is extremely chatty and I've noticed that most Asterisk-based PBX "appliances" are extremely underspecced.

Definitely a weird issue, though.

 

[ScottMac]

What other apps run through this switch?

Anything that multicasts? Are there any massive downloads (ala BitTorrent)
Do you have any/many "many-to-one" client-to-resource situations?

Have you monitored a/some ports with WireShark or similar analyzer?

 

[kevnich2]

Does this happen at all the sites?

I've used these phones and visual voicemail pretty extensively and never seen this issue. It sounds like the switchvox is sending SIP over TCP with TLS, which is fine...however, for debugging sake, I wonder if it'd be possible to turn that off and have SIP use UDP. The protocol that DPMA uses to talk to Digium phones is extremely chatty and I've noticed that most Asterisk-based PBX "appliances" are extremely underspecced.

Definitely a weird issue, though.

This issue yes is ocurring at all sites. The SIP itself looks to be coming over UDP but there is some TCP and TLS thrown in there from the voicemail app for some type of encryption. I have two different packet captures, one from when a test phone was connected directly to our pbx and another from a phone on the network that gives the typical amount of long delay with voicemail. The major thing I'm seeing is 2-3x more TCP and TLS frames being sent between the switchvox and the digium phone before the RTP audio frames start transmitting in the packet capture of the instance where voicemails are delaying several seconds.

I have no idea what this means, I assume it's a bunch of data from the DPMA but it's all encrypted over port 443 between server and phone. I do know the phone is sending all the frames to the server and the server is sending all ACK frames back, continuously over what looks like a 3-4 second period.

 

[drebo]

That's weird. My Digium phones don't do anything over TCP port 443. In fact, I have that port firewalled off.

 

[Enigma102083]

You need to have the vendor disable the TCP/TLS and do the visual voice mail via UDP. This will at least give you visibility on what is actually happening, or quite possibly fix it entirely.

 

[kevnich2]

That's weird. My Digium phones don't do anything over TCP port 443. In fact, I have that port firewalled off.

Can you check your phone networks configuration on your server and see if you have direct port access enabled? I am curious if this setting is what causes some communication to go over 443?

 

[drebo]

Can you check your phone networks configuration on your server and see if you have direct port access enabled? I am curious if this setting is what causes some communication to go over 443?

These are the typical configs I use in res_digium_phone.conf:

[general]
mdns_address=x.x.x.x
globalpin=xxxx
userlist_auth=globalpin
config_auth=pin
service_name=Phone Config Server
firmware_package_directory=/var/www/html/digium
file_directory=/var/www/html/digium
message_context=dpma_message_context
service_discovery_enabled=no

[AllNetworks]
type=network
alias=All Networks
cidr=0.0.0.0/0
registration_address=x.x.x.x
registration_port=5060
file_url_prefix=http://x.x.x.x/digium
ntp_server=x.x.x.x
network_vlan_id=10
pc_vlan_id=30
network_vlan_discovery_mode=MANUAL

[firmware-D50_1_3]
type=firmware
model=D50
version=1_3_2_0_54993
file=1_3_2_0_54993_D50_firmware.eff

[phone10]
type=phone
network=AllNetworks
pin=xxxx
line=10
line=10
full_name=Phone 10
timezone=America/Los_Angeles
ntp_resync=600
parking_exten=700
parking_transfer_type=blind
web_ui_enabled=yes
login_password=xxxx
accept_local_calls=host
dim_backlight=no
contact=ext10contacts.xml
blf_contact_group=ext-blf
blf_unused_linekeys=yes
firmware=firmware-D40_1_3
firmware=firmware-D50_1_3
firmware=firmware-D70_1_3

[10]
type=line
exten=10
line_label=10
mailbox=10@default
outboundproxy_address=x.x.x.x
outboundproxy_port=5060
secret=xxxx
reregistration_timeout=300
registration_retry_interval=25
registration_max_retries=5
registration_max_retries=5

The bulk of my Digium phones are hosted in remote locations across slow Internet connections and through NAT.

 

[kevnich2]

You need to have the vendor disable the TCP/TLS and do the visual voice mail via UDP. This will at least give you visibility on what is actually happening, or quite possibly fix it entirely.

Any idea where in the Admin panel this would be to change it?

 

[kevnich2]

That's weird. My Digium phones don't do anything over TCP port 443. In fact, I have that port firewalled off.

Are you using your phones with a switchvox system or something different?

 

[Enigma102083]

Any idea where in the Admin panel this would be to change it?

I don't, which is why you might want to contact the vendor.

 

[drebo]

Are you using your phones with a switchvox system or something different?

Switchvox is simply Asterisk, but Digium's prepackaged commercial version.

I use raw Asterisk.

 

[kevnich2]

Switchvox is simply Asterisk, but Digium's prepackaged commercial version.

I use raw Asterisk.

I'm curious though if the switchvox specific version does for some reason use 443 for alot of the dpma functions, hmm...

 

[malcolmd]

...and major bugs with some versions of the DPMA module.

Howdy,

Are there bugs or quirks you're currently experiencing?

Inquiring minds at Digium want to know, so that we can make sure we're working to correct them.

Cheers