["Ryan Zuidema" <ryan.zuidema@xxxxxxxxxxx>]

Running computers through the phones is entirely normal, the point of VoIP is to have a 1 wire office. That said most VoIP installs I have seen still run separate lines. The reasoning is that it’s easier to maintain and the cost difference is small to run two wires as opposed to one.

 

It’s not surprising that the server doesn’t tag. It’s reasonable to assume that ALL traffic to that port would be on the phone VLAN and high priority. The only reason your endpoints need to tag is if they have multiple QoS requirements.

 

Ryan

 

From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Mark Jeffers
Sent: Friday, June 19, 2009 6:40 AM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Huge VoIP Problem :(

 

The phones actually act as a level 2 switch themselves.   They tag their own packets for VLAN9 (the voice VLAN on my network) and tag the packets of the PC attached to them (if there is one) as VLAN1.

 

Attaching a phone and a pc to the same switch port has made me nervous from day one, but the vendor swore up and down it would work no problem. 

 

Also, one thing that has me shaking my head in disbelief is that while Allworx built their phones with VLAN tagging abilities, their main phone server can't tag its own packets.

 

But anyway, I was of course suspicious of the pc/phone combo, but some of my most problematic phones have no pc attached to them.  Plus, I figured building the VLANs would solve any problem related to that.   Perhaps I was wrong?

 

Cheers,

mj

 

 

On Thu, Jun 18, 2009 at 9:21 PM, Bob Carlson <bob@xxxxxxxxxxxxx> wrote:

If there is a circular path, I believe ARP caching could be causing the on again/off again nature of the problem. When the ARP cache gets the “right” path, it works, when it gets the wrong path, packets go to the bit bucket. ARP caching would just be obscuring the problem.

 

VLANs can be thought of as broadcast domains. Think carefully about whether some switch might be configured in a way that links two VLANs in a way that they shouldn’t.

 

Are the phones sending VLAN tagged packets? Or does the phone’s switch port default to the VOICE VLAN?

 

If RTP packets are routed through a firewall, the firewall might be configured to allow only a range of UDP ports. The ranges used by the SIP phones might overlap the allowed range. In range it would work, out of range it wouldn’t. That symptom would probably be pretty clear though.

 

Cheers, Bob

 

Bob Carlson | +1 719 571 9228 (office)  | +1 541 521 9525 (mobile)

bob@xxxxxxxxxxxxx  | rjcarlson49 (aim or skype)

 

From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Mark Jeffers

Sent: Thursday, June 18, 2009 3:45 PM
To: Community support list for Wireshark

Subject: Re: [Wireshark-users] Huge VoIP Problem :(

 

In saying ARP caching could be a factor, are you saying ARP caching could be causing the problem or it could offer some relief?

On the firewall issue, I do have a Fortigate 100A acting as a Level 3 router between the two different VLANs... some of the PCs on VLAN1 use a software call center package and need to talk to the Phone server on the other VLAN.   Since the phones and the phone server are on the same VLAN and are experiencing packet loss, I don't see where the router is coming into play, but I'm willing to look at anything.

Cheers, mj

On Thu, Jun 18, 2009 at 5:03 PM, Bob Carlson <bob@xxxxxxxxxxxxx> wrote:

This is almost certainly a network issue. Given the intermittent nature, you might have a circular path in the LAN. ARP caching could be a factor. If there’s a firewall involved look there too.

 

Cheers, Bob

Eugene, OR - Tucson, AZ

 

From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Mark Jeffers
Sent: Wednesday, June 17, 2009 9:32 AM
To: wireshark-users@xxxxxxxxxxxxx
Subject: [Wireshark-users] Huge VoIP Problem :(

 

We've been having a terrible time with a new VoIP system on our network.

The phone system is manufactured by Allworx - it is tied to the outside world with a standard PRI, so the only IP portion of calls takes place between our LAN phone server and the IP extensions.

 

Several of the extensions are having packet loss problems resulting in echoes, "static", dropped audio, etc.  The problems are intermittent and jump around to different phones on the network.

 

The switches we are using are Dell 3548P PowerConnects.   I've configure the network to use two VLANs - one for phone, one for everything else - and used VLAN tagging and CoS to prioritize VoIP traffic.   I've actually combed through the configs with a Dell engineer, and we're good there.

 

So I'm relatively new to both VoIP and hardcore packet analysis, but I found an excellent article on troubleshooting VoIP using wireshark and followed instructions.

 

I mirrored one of the Trunk ports on the switch to my laptop, configured Wireshark to filter out all but UDP packets and let it run for about an hour. 

The results are horrible... I've attached screenshot images so you guys might be able to help me figure this out.

When I ran an RTP Stream analysis, there were blocks of sessions where several of them had "Max Delta" in the thousands (some in the 9000s), resulting in 90+% packet loss!  See Image1,jpg  

I drilled down into one of the streams to see a bunch of "Wrong Sequence nr" messages - See Image2.jpg

I went to VoIP Calls under the statistics menu, and pulled up the same call shown in Image2 - looked fine to me, but I'm a noob - See Image3.jpg

 

I'm at a loss here.   Obviously severe network issues, or the Phone Switch is bad.   I've tried everything I can think of to no avail.  Anybody have any ideas of what might be wrong, or what further information I should gather to help pinpoint the issue?   I'm going nuts here and any help would be greatly, greatly appreciated.  :)

 

Cheers,

Mark

 

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

 

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe