|
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 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
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 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 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
|
- References:
- [Wireshark-users] Huge VoIP Problem :(
- From: Mark Jeffers
- Re: [Wireshark-users] Huge VoIP Problem :(
- From: Bob Carlson
- Re: [Wireshark-users] Huge VoIP Problem :(
- From: Mark Jeffers
- Re: [Wireshark-users] Huge VoIP Problem :(
- From: Bob Carlson
- Re: [Wireshark-users] Huge VoIP Problem :(
- From: Mark Jeffers
- [Wireshark-users] Huge VoIP Problem :(
- Prev by Date: Re: [Wireshark-users] Huge VoIP Problem :(
- Next by Date: Re: [Wireshark-users] Huge VoIP Problem :(
- Previous by thread: Re: [Wireshark-users] Huge VoIP Problem :(
- Next by thread: Re: [Wireshark-users] Huge VoIP Problem :(
- Index(es):