> 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.
==> Yes because all decoding from CSRC to end of packet was done inside
"if (tree)". I.e. tap would be called right only for packet displayed in
the tree window. As you can see it was necesaary to decode all RTP in
any case and put into "if (tree)" only "tree" commands.
Tom
>
> 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
> >>
> >>
> >
> >
> >