Hi, Miha!
I have another notice. I think it would be more proper to get data
from current tvb_buf instead of cfile.pd because it can be different
(e.g. encapsulated IP, fargmented IP, ... ).
As tvb_buf is not passed to the tap listener one of the possible
solution is to put tvb pointer into _rtp_info structure:
rtp_info.info_rtp_tvb = tvb;
or to put data pointer into _rtp_info structure:
rtp_info.info_rtp_ptr = tvb_get_ptr(tvb, 0, tvb_reported_length(tvb));
Regards,
Tom
Miha Jemec wrote:
>
> Hi!
>
> Well, the IP checking can be included as well. Till know I didn't do it
> because I thought that possibility that two different RTP streams would
> have the same SSRC values is rather small. But there will remain some
> exceptions even with IP checking, that can still cause problems: if you
> act as a router or do the middle in the man attack and you receive and
> resend the packets on the same interface. In this case for each packet
> received you will send another one with same SSRC, IP and port values.
> In this case you still get the wrong sequence number error. The solution
> here would be to add the MAC checking. But even with this one there are
> some exceptions possible. In such cases the user can react with the
> display filter.
>
> Maybe it is smart to include the IP checking so I will add it.
>
> I'll try to do it together with modifications that Tomas proposed and
> would check if the RTP frame has extra padding bits, extension field or
> CSRC field and to extract the RTP data even in this case. I hope
> tomorrow will this fix be ready.
>
> Regards, Miha
>
> Martin Regner wrote:
>
> >Hi,
> >
> >I got some strange result when using RTP Analysis on one capture file with several different RTP streams
> >between different ip-addresses. The RTP Analysis complained about wrong sequence numbers.
> >When I looked closer I noticed that when there are more than one RTP streams using the same SSRC value then the RTP Analysis will handle all RTP packets with that SSRC value as belonging to the same RTP stream.
> >I think that there should be a check not just for SSRC value but also source address, destination address, source
> >port number and destination port number to identify what packets are belonging to the same stream.
> >
> >I have enclosed a sample that I prepared with text2pcap to illustrate the current behaviour.
> >
> > No. Bytes Time Source S_port Destination D_port Protocol Info
> > 1 94 0.000000 10.10.10.10 20480 10.10.10.11 16384 RTP Payload type=ITU-T G.729, SSRC=2864447487, Seq=637, Time=278800, Mark
> > 2 94 0.000000 10.10.10.12 20736 10.10.10.13 16640 RTP Payload type=ITU-T G.729, SSRC=2864447487, Seq=1022, Time=278800, Mark
> > 3 94 0.000000 10.10.10.10 20480 10.10.10.11 16384 RTP Payload type=ITU-T G.729, SSRC=2864447487, Seq=638, Time=278800, Mark
> > 4 94 0.000000 10.10.10.13 16640 10.10.10.12 20736 RTP Payload type=ITU-T G.729, SSRC=2864434397, Seq=2047, Time=278800, Mark
> > 5 94 0.000000 10.10.10.10 20480 10.10.10.11 16384 RTP Payload type=ITU-T G.729, SSRC=2864447487, Seq=639, Time=278800, Mark
> > 6 94 0.000000 10.10.10.10 20480 10.10.10.11 16384 RTP Payload type=ITU-T G.729, SSRC=2864447487, Seq=640, Time=278800, Mark
> > 7 94 0.000000 10.10.10.12 20736 10.10.10.13 16640 RTP Payload type=ITU-T G.729, SSRC=2864447487, Seq=1024, Time=278800, Mark
> >
> >When I mark packet 1 and use RTP analysis then I will get packet 1, 2, 3, 5, 6 and 7 in forward direction and none i backward
> >direction, but actually these packets are belonging to two different streams 10.10.10.10:20480-->10.10.10.11:16384
> >(packet 1, 3, 5 and 6) respectively 10.10.10.12:20736-->10.10.10.13:16640 (packet 2 and 7).
> >
> >When I mark packet 2 and use RTP analysis then I wil get packet 1, 2, 3, 5, 6 and 7 in forward direction and packet 4 in backward direction.
> >
> >When I mark packet 3 and use RTP analysis then I will get packet 4 in forward direction and 1, 2, 3, 5, 6 and 7 in backward direction.
> >
> >I also noticed that the first packet does not have "Marker = SET" in RTP Analysis even if marker bit really is set in that packet.
> >
> >
> >
> >
> >
