| Bug ID |
11601
|
| Summary |
"Telephony -> VoIP calls" does not show SIP calls if their SIP messages contain malformed "application/qsig" body
|
| Product |
Wireshark
|
| Version |
1.12.8
|
| Hardware |
x86
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 13914 [details]
signalling of two SIP calls, one of them affected by the bug
Build Information:
Version 1.12.8 (v1.12.8-0-g5b6e543 from master-1.12)
Compiled (64-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15, with Gcrypt 1.6.2,
without Kerberos, with GeoIP, with PortAudio V19-devel (built Oct 14 2015),
with
AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 3.2.15, Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, with 8141MB of physical
memory.
Built using Microsoft Visual C++ 10.0 build 40219
--
If SIP messages (maybe only the initial INVITE?) contain malformed
application/qsig body, the respective call is not detected in Telephony -> VoIP
calls at all (while if an INVITE message carries a properly encoded
application/qsig body, it spawns two calls, one between two IP addresses and
one between an IP address and "PSTN").
However, in case of multi-part bodies and if the SDP comes before the
application/qsig part, the SDP is analysed so the RTP packets belonging to the
call are shown in packet list as RTP, not just UDP.
In the particular case of the attached trace, the malformation of the qsig body
comes from Cisco's systematic bug in encoding where the binary Q.931 data are
followed by CRLF which the q931 dissector decodes as "unknown information
element 0xd, length 10".
Even if stripping the two last bytes of the application/qsig body before
handing it over to the q931 dissector if "^User-Agent: *[Cc]isco.*$" line is
found among SIP headers would be considered unreliable or too
collaborationistic ;-) , the message should still be considered a valid SIP one
as the SIP part itself as well as the SDP are correct.
The attached trace intentionally does not contain RTP packets in order to
reduce size. It intentionally contains a plain SIP call to illustrate that
there is no other cause of the issue.
You are receiving this mail because:
- You are watching all bug changes.