We're now a non-profit! Support open source packet analysis by making a donation.

Wireshark-users: Re: [Wireshark-users] VoIP analysis and assessment

From: Andreas Fink <[email protected]>
Date: Thu, 28 Sep 2006 16:22:03 +0200
did you verify if the calls work fine from the ISDN to a phone connected to the PBX too?
This is to verify that you dont have a clocking issue on the 2Mbps ISDN trunk..

On 28.09.2006, at 01:18, Chris Swinney wrote:

Hi all,


We have the following scenario: -


Scenario. There are three remote sites in UK. Each has their own Alcatel PBX and is connected to the Internet via an RADSL (ADSL Max) line (8MB down, 832kbps up). Each ADSL line is connected via a ZyXEL 660 to a ZyXEL ZyWALL 35. The Alcatel PBX’s are connected directly to a LAN port on the ZyWALL. The ZyWALL’s also connect to a data network that shares the same subnet range as the Alcatel PBX’s. Each site is connected to each other via an IPSEC VPN. Bandwidth Management rules on the ZyWALL’s prioritize traffic to and from the PBX’s, through the VPN’s.


There is one site that is the head office and the other two are branches. All calls are received via PSTN (ISDN 30) at the head office and are then transferred using a SIP trunk to the remote branch offices (Alcatel PBX to Alcatel PBX) via the VPN.


Known limitations. The system has been specified so that no more than 8 simultaneous calls from the head office to the branch office would be allowed. The Alcatel PBX’s only support a limited number of Codecs – namely G711, G723.1, G729a. Call quality is an issue with anything other than G711. This codec gives 64kbps per call, but with TCP overheads we are looking at around 80-90kbps. 8 calls then equates to around 720kbps – which is close to the upper limit of our bandwidth. IPSEC VPN translation will also add a bandwidth consideration and could push this to 115 kpbs. This would flood the network. In addition, although the Bandwidth is managed by the edge of network routers and VoIP traffic is prioritised across the VPN, the actual VPN packet is not marked for QoS as it travels across the Internet.


Caveats. It is unlikely that 8 calls will be placed at any one time. In fact the issues that are being seen with just one call in place. Bandwidth limitation are know and potentially being addressed. A second DSL line maybe installed at the main office so that one circuit will carry voice and the other will carry data. The ZyWALL 35 will handle this segregation through its dual WAN ports. However, we may still find bandwidth issues if the pipe is not sufficiently large considering the amount of concurrent calls required. This may require a limitation of the number of concurrent calls. SNMP logs have been taken to look various router parameters (such as bandwidth usage, CPU utilisation etc) on the ZyWALL’s, particularly looking at the managed bandwidth OUT of the router on the egress to the WAN. These show that maximum bandwidth usage can spike to the managed level occasionally, although VoIP issues also appear to not necessarily coincide with these spikes, Internet connectivity at all sites is handled through one ISP (Griffin). They have lower contention ratios and an uncongested network. This also keeps hops and latency minimal between sites (2-4 hops, 50 ms).


Areas of Concern. The users are experiencing what they describe as a “buzzing” on the line. This appears to be only in one directly (i.e. callers cannot hear a noise but the workers in the office can). It also appears to be intermittent and of differing magnitude – sometimes it is bearable, other times it makes the call inaudible.  Users have also reported a number of dropped calls.


Plan of action. First and foremost, we need to identify the area/s that is causing call quality issues and to do that we need to identify what is the exact nature of the problem (i.e. what is this “buzzing”).  Is this purely a bandwidth issue, or is there some other issue and where does this issue lay? Once the problem is identified we need to put forward a resolution then retest once this has been implemented.


Really what I need to do now is a packet trace. Ideally I would like to get a packet dump from the ZyWALL itself but I have not managed to do this. Failing that I will insert a hub before the ZyWALL and plug the network and PBX into that, then hook the hub up to the ZyWALL. I should then be able to plug into the hub with a sniffer and monitor all traffic going to the ZyWALL. I can’t monitor upstream of the ZyWALL as this packets will be encrypted within IPSEC packets.


Ideally I need a piece of software that can reconstruct VoIP call activity and give my quality scores (MOS), potential issues (jitter, packet loss) and suggested resolutions. We’ve looked at Observer Suite from NI but this is a hefty £4000. I am looking at Wireshark/Ethereal but I’m not sure if it will do all that is needed – or at least my skills set may not be able to get the required info.


Can Wireshark be used to get the necessary information required? If not, are there any developer add-ons that could help in my quest?





-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
27 September 2006 23:14
To: [email protected]
Subject: Wireshark-users Digest, Vol 4, Issue 35


Send Wireshark-users mailing list submissions to

      [email protected]


To subscribe or unsubscribe via the World Wide Web, visit


or, via email, send a message with subject or body 'help' to

      [email protected]


You can reach the person managing the list at

      [email protected]


When replying, please edit your Subject line so it is more specific

than "Re: Contents of Wireshark-users digest..."

Wireshark-users mailing list