Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 3087] New: Wrong call flow with simultaneous bidirectional

Date: Wed, 26 Nov 2008 06:56:22 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3087

           Summary: Wrong call flow with simultaneous bidirectional SIP
                    calls.
           Product: Wireshark
           Version: 1.0.4
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: antoinepouchot@xxxxxxxxx
                CC: antoinepouchot@xxxxxxxxx


Created an attachment (id=2524)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2524)
Network trace of 2 simultaneous bidirectional G711a SIP calls.

Build Information:
Version 1.0.4 (SVN Rev 26501)

Copyright 1998-2008 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.12.8, with GLib 2.14.6, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with ADNS, with Lua 5.1, with GnuTLS 2.3.8, with Gcrypt 1.4.1, with MIT
Kerberos, with PortAudio V19-devel, with AirPcap.

Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, without
AirPcap.

Built using Microsoft Visual C++ 6.0 build 8804

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
The call flow in Wireshark (accessed from 'Statistics' menu, 'VoIP Calls', then
select one of the calls and click the 'Graph' button) does not provide the
correct flow of information when more than one SIP VoIP call are generated at
the same time, for instance 2 or more simulteanous SIP calls. The issue does
not occur when only one SIP call is being generated at a time.

I have attached a trace where I created 2 simultaneous bidirectional G711a SIP
calls. Below are the call flows for call 1 and 2 as shown by Wireshark:

Call 1:
=======

192.168.0.3                 192.168.0.2

                INVITE SDP ( g711A)
(5060)   ------------------>  (5060)
                180 Ringing
(5060)   <------------------  (5060)
                200 OK SDP ( g711U)
(5060)   <------------------  (5060)
                ACK
(5060)   ------------------>  (5060)
                RTP (g711A)
(6000)   <------------------  (6000)
                RTP (telephone-event) DTMF One 1
(6000)   <------------------  (6000)
                BYE
(5060)   ------------------>  (5060)
                200 OK
(5060)   <------------------  (5060)

- Call 2:
=========

192.168.0.3                 192.168.0.2

                INVITE SDP ( g711A)
(5060)   ------------------>  (5060)
                180 Ringing
(5060)   <------------------  (5060)
                200 OK SDP ( g711U)
(5060)   <------------------  (5060)
                RTP (g711A)
(6008)   ------------------>  (6000)
                ACK
(5060)   ------------------>  (5060)
                RTP (g711A)
(6012)   <------------------  (6000)
                RTP (101) DTMF One 1
(6008)   ------------------>  (6000)
                RTP (telephone-event) DTMF One 1
(6012)   <------------------  (6000)
                BYE
(5060)   ------------------>  (5060)
                200 OK
(5060)   <------------------  (5060)


However according to the packet flow, the correct call flow for each of the
above calls should be shown as:

192.168.0.3                 192.168.0.2

            INVITE SDP ( g711A)
(5060)   ------------------>  (5060)
            180 Ringing
(5060)   <------------------  (5060)
            200 OK SDP ( g711U)
(5060)   <------------------  (5060)
            ACK
(5060)   ------------------>  (5060)
            RTP (g711A)
(6016)   ------------------>  (6000)
            RTP (g711A)
(6016)   <------------------  (6000)
            RTP (telephone-event) DTMF One 1
(6016)   <------------------  (6000)
            BYE
(5060)   ------------------>  (5060)
            200 OK
(5060)   <------------------  (5060)


If I filter only the packets from the first call and save the new trace, then
the call flow in Wireshark is being shown properly for call 1 (and vice versa
for call 2).


- Workaround:
=============

The 'Flow Graph...' option available from the 'Statistics' menu seems to
provide the correct overall call flow for all calls, however it is a bit messy
as it is not possible to select the call flow for a specific call.


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.