Ethereal-dev: Re: [Ethereal-dev] RTP analysis. Same SSRC for several streams causes problems

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Tomas Kukosa <tomas.kukosa@xxxxxxxxxxx>
Date: Tue, 11 Mar 2003 07:18:31 +0100
Hi,

> 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 think, the source address should be enough because the SSRC is
chosen on the source side.

  Tom



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.
> 
>   ------------------------------------------------------------------------
>                     Name: rtperror.pcap
>    rtperror.pcap    Type: unspecified type (application/octet-stream)
>                 Encoding: base64