Hi Tomas,
thanks for help!
I'm aware of problem with extension and padding (but overlooked that
CSRC can add some extra fields). I already tried to pass the exact
position where the RTP data begins and the length without padding but
didn't succed, because the tvb_length_remaining() returned different
values if the condition "if (tree)" was true when the RTP display filter
was on. Because I didn't find the solution I decided to cancel saving if
padding bits appeared.
So if,
rtp_info.info_payload_offset = ...
rtp_info.info_payload_len = ...
now always return the offset where the data begins and the length of
useful RTP data, then this solves also the problem with padding. I'll
try to fix this.
Regards, Miha
Tomas Kukosa wrote:
Hi, Miha!
maybe, I blinked something but it seems that you do not support CSCR
identifiers, header extension and padding.
I think it would be better to put into the rtp_info structure members
info_payload_offset and info_payload_len. Thay should be filled in at
the same points where the dissect_rtp_data() is called.
Draft proposal is attached (neither compilable nor tested).
Regards,
Tom
Miha Jemec wrote:
Hi !
I found a sample that causes me problem using the tap system.
It is the second packet in attached file, which is actually an ICMP port
unreacheable message to the previous RTP packet. The ICMP was sent
because the port was closed and it contains some bytes from the previos
packet: IP header, UDP header, RTP header and 24 bytes from RTP data.
The problem is, that this packet seems to be handled as RTP even it is a
plain ICMP message. So I get the tap event for it and it even passes the
RTP display filter.
Since this is not a RTP packet but an ICMP packet with the information
which packet caused this error (in our case previous RTP packet) I think
that it shouldn't be passed to the tap listener for rtp packets and
should be filtered out by RTP display filter.
Miha.
------------------------------------------------------------------------
Name: icmp_rtp.raw
icmp_rtp.raw Type: unspecified type (application/octet-stream)
Encoding: base64
