RTP header extensions that are longer than 4 bytes (rtp.ext.len > 1)
get dissected incorrectly. The first 4 bytes of the header extension are
repeated rtp.ext.len times, and the remaining bytes are ignored.
svn path=/trunk/; revision=25184
If a UDP packet is submitted to the RTP heuristic dissector with either odd src
or dst ports, the heuristic will correctly return FALSE. However, that
interferes with the next few lines of code that can potentially treat version 0
RTP packets as either STUN or T38 depending on preference settings.
svn path=/trunk/; revision=25150
In our communication systems, we make use of the RTP header extension to encode
signalling information in the form of a bit mask. To improve our debugging, we
extended the default RTP dissector to call back any subdissector registering
for a particular RTP payload type string. This allows to render the value of
the header extension in a different, more flexible way compared to the default
numeric representation, such as in form of a subtree.
svn path=/trunk/; revision=23943
This patch set provides a an API for out of band signalling protocols to
register flows as SRTP/SRTCP using extended versions of the existing
rt(c)p_add_address functions. At present the encrypted portions of the payloads
are simply skipped, and the auth tags etc added as fields.
svn path=/trunk/; revision=22562
find attached several trivial diffs for viewing RTP SSRC values in Hex
rather than Dec at various places in the UI.
Also includes change from BASE_DEC to BASE_HEX_DEC for corresponding RTP
and RTCP dissector header fields.
svn path=/trunk/; revision=22017
When dissecting RTP packets with a H.263 payload, the "Mark" flag runs into the Mode A/B flag in the info column.
From me abriviate Payload type to PT.
svn path=/trunk/; revision=20899
Along with this bug, identified by Mark, there is another problem, in that one of the chunks of my earlier patch seemed to get missed off when Anders committed it. This won't break anything yet, as the H.223-over-RTP dissection hasn't landed on trunk yet, but it will cause all sorts of nasties when it does.
Here is a new patch, against current trunk, which should fix Mark's bug, my bug, and a comment typo.
And a patch wich improves the general robustness of the h.223 dissector (making it less likely to crash on malformed data).
Hopefully this also fixes a bug raised by Fabio Sguanci a few weeks ago.
Fabio: I think a better way to fix the problem is to stop the dissector crashing when it finds a malformed PDU, so that it just treats the first pdu as malformed; there is then no need to special-case it.
svn path=/trunk/; revision=20898
Here's a patch which adds an option enabling subdissectors to request defragmentation of packets over RTP streams, using the
pinfo->desegment_{len,offset} API.
svn path=/trunk/; revision=20891
directory to the epan directory. Some of them should perhaps ultimately
be moved to epan/dissectors, if they pertain only to stuff exported by a
particular dissector.
Fix Gerald's e-mail address in files we're moving.
svn path=/trunk/; revision=15844
Find attached a patch for SDP sessions to:
- Dissect Dynamic payload types in RTP packets
- Add the dynamic payload type description in RTP packets
- Add RTP dynamic payload types description in the Voip Calls Graph, in the RTP and SDP.
svn path=/trunk/; revision=13942
Use the same code to handle payload types in sessions set up by SDP and
sessions set up by other protocols, rather than duplicating that code.
svn path=/trunk/; revision=13775
of 0 to be dissected as STUN packets, to support dissecting of
application that follow the ICE methodology described in
draft-ietf-mmusic-ice-03.
Remove some extra spaces at the end of tags for preferences.
svn path=/trunk/; revision=13356
1) Added a setup_frame parameter to conversation_t
2) Used the conversation_t next to maintain a list of conversations with the
same src/dest tuple but different setup_frame number.
3) Changed the signature of find_conversation() and conversation_new() to pass
in the frame number.
4) Adjusted packet-sdp to select RTP conversation if both m=audio and m=image
are present, and T.38 conversation if only m=image is present. I expect that
RTP/T.38 dissecting to be better, but I don't have a way to generate T.38
packets.
svn path=/trunk/; revision=13243
Anders Broman