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
Attachment:
packet-rtp.c
Description: application/unknown-content-type-tornadosourcetype
Powered by MHonArc 2.6.10