Wireshark-users: Re: [Wireshark-users] Wireshark doesnt recognize RTP packets when i decode

From: "Martin Mathieson" <martin.r.mathieson@xxxxxxxxxxxxxx>
Date: Thu, 6 Mar 2008 14:29:15 +0000
In order to help get this implemented, could you please create an enhancement request at http://bugs.wireshark.org and attach a sample trace showing the problem?
I don't know how soon I or someone else might find time to work on this, so I would suggest pursuing the UDP/RTP route, if possible


On Thu, Mar 6, 2008 at 11:54 AM, Fabiana moreno <fvmoreno@xxxxxxxxx> wrote:
Thanks!! i do think i need that!


On 06/03/2008, Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> wrote:
When we set up RTP streams (including passing information about dynamic payload types), we assume that its over UDP.  It would be good to fix this.

But in the meantime, can't you configure your RTSP server or client to use UDP/RTP transport for the media?


On Thu, Mar 6, 2008 at 11:10 AM, Fabiana moreno <fvmoreno@xxxxxxxxx> wrote:
When i decode to udp and hence to rtp to analyse the jitter, and the delays then i get that problem of unknowns that i mentioned....


On 06/03/2008, Fabiana moreno <fvmoreno@xxxxxxxxx> wrote:
If you dont want to open any attachment..then this is a sample of what i see when im capturing

94 0.695962    192.168.123.100       192.168.123.101       TCP      Interleaved channel 0x00, 1356 bytes
     95 0.696016    192.168.123.101       192.168.123.100       TCP      bcs-broker > rtsp [ACK] Seq=1 Ack=69353 Win=51200 Len=0
     96 0.706464    192.168.123.100       192.168.123.101       TCP      Interleaved channel 0x00, 118 bytes
     97 0.712661    192.168.123.100       192.168.123.101       TCP      Interleaved channel 0x00, 1262 bytes
     98 0.712699    192.168.123.101       192.168.123.100       TCP      bcs-broker > rtsp [ACK] Seq=1 Ack=70741 Win=50853 Len=0
     99 0.720359    192.168.123.100       192.168.123.101       TCP      Interleaved channel 0x00, 1218 bytes
    100 0.738111    192.168.123.100       192.168.123.101       TCP      [TCP Previous segment lost] Interleaved channel 0x00, 898 bytes
    101 0.738162    192.168.123.101       192.168.123.100       TCP      bcs-broker > rtsp [ACK] Seq=1 Ack=71963 Win=51200 Len=0 SLE=72979 SRE=73881
    102 0.740297    192.168.123.101       192.168.123.100       RTSP     Continuation
    103 0.742967    192.168.123.100       192.168.123.101       TCP      Interleaved channel 0x00, 797 bytes
    104 0.743031    192.168.123.101       192.168.123.100       TCP      [TCP Dup ACK 101#1] bcs-broker > rtsp [ACK] Seq=1 Ack=71963 Win=51200 Len=0 SLE=72979 SRE=74682
    105 0.756244    192.168.123.100       192.168.123.101       TCP      Interleaved channel 0x00, 107 bytes
    106 0.756283    192.168.123.101       192.168.123.100       TCP      [TCP Dup ACK 101#2] bcs-broker > rtsp [ACK] Seq=1 Ack=71963 Win=51200 Len=0 SLE=72979 SRE=74793
    107 0.768215    192.168.123.100       192.168.123.101       TCP      [TCP segment of a reassembled PDU]
    108 0.768269    192.168.123.101       192.168.123.100       TCP      [TCP Dup ACK 101#3] bcs-broker > rtsp [ACK] Seq=1 Ack=71963 Win=51200 Len=0 SLE=72979 SRE=76253
    109 0.770532    192.168.123.100       192.168.123.101       TCP      Interleaved channel 0x00, 1472 bytes
    110 0.770548    192.168.123.101       192.168.123.100       TCP      [TCP Dup ACK 101#4] bcs-broker > rtsp [ACK] Seq=1 Ack=71963 Win=51200 Len=0 SLE=72979 SRE=76269
    111 0.777225    192.168.123.100       192.168.123.101       TCP      Interleaved channel 0x00, 425 bytes
    112 0.777280    192.168.123.101       192.168.123.100       TCP      [TCP Dup ACK 101#5] bcs-broker > rtsp [ACK] Seq=1 Ack=71963 Win=51200 Len=0 SLE=72979 SRE=76698
    113 0.797305    192.168.123.100       192.168.123.101       TCP      Interleaved channel 0x00, 1420 bytes
    114 0.797378    192.168.123.101       192.168.123.100       TCP      [TCP Dup ACK 101#6] bcs-broker > rtsp [ACK] Seq=1 Ack=71963 Win=51200 Len=0 SLE=72979 SRE=78122
    115 0.798265    192.168.123.100       192.168.123.101       TCP      rtsp > slingshot [ACK] Seq=1 Ack=657 Win=652 Len=0
    116 0.800536    192.168.123.100       192.168.123.101       RTSP     Reply: RTSP/1.0 200 OK
    117 0.800567    192.168.123.101       192.168.123.100       TCP      [TCP Dup ACK 101#7] bcs-broker > rtsp [ACK] Seq=1 Ack=71963 Win=51200 Len=0 SLE=72979 SRE=78261
    118 0.815779    192.168.123.100       192.168.123.101       TCP      [TCP Fast Retransmission] Interleaved channel 0x00, 1012 bytes
    119 0.815863    192.168.123.101       192.168.123.100       TCP      bcs-broker > rtsp [ACK] Seq=1 Ack=78261 Win=51200 Len=0
    120 0.828061    192.168.123.100       192.168.123.101       TCP      Interleaved channel 0x00, 749 bytes
    121 0.833133    192.168.123.100       192.168.123.101       TCP      Interleaved channel 0x00, 971 bytes
    122 0.833169    192.168.123.101       192.168.123.100       TCP      bcs-broker > rtsp [ACK] Seq=1 Ack=79989 Win=51200 Len=0


On 06/03/2008, Fabiana moreno <fvmoreno@xxxxxxxxx> wrote:
That´s is the thing... i am not seeing any udp packets in my capture. just tcp and rtsp.
Attached are the capture files(one .pcap and the other in text form) that includes RTSP signalling





On 06/03/2008, Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> wrote:
Could you possibly post a capture file that includes the RTSP signalling?
We should be configuring the RTP stream with the dynamic payload type so that it can be displayed properly...



On Wed, Mar 5, 2008 at 11:08 PM, Fabiana moreno <fvmoreno@xxxxxxxxx> wrote:
Well it's my final year project and i need to analyse the QoS parameters when streaming over wireless lan.
I'm streaming an mpeg4 video from a server to my client (the last one is the one where wireshark is installed)
So im trying to to capture all the packets im getting when streaming.
My server supports rtcp/rtp and i think (correct me if im wrong) that the best way to analyse all these packets are to decode them to udp and then to rtp but im getting the problem mentioned before.
 
But is there some way i can fix this?

 
On 05/03/2008, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
Well, I dont' really understand what you do, but the PT=unknown is from the
fact that this packet type is dynamically assigned, negotiated between
parties. If Wireshark doesn't see the negotiations, it can't make out which
codec goes with PT 96. So yes, it can happen you see this.

Thanx,
Jaap


Fabiana moreno wrote:
> hello!!!
> I'm streaming an mpeg4 video with darwin streamer server trhough my
> WLAN. I'm using wireshark to analyse the packets im receiving.
> I see TCP/RTSP packets but when i decode to UDP and then to RTP to
> anlyse it, wireshark shows the following in all the packets, here a sample:
>
> 34    0.253327    192.168.123.100 <http://192.168.123.100/>
> 192.168.123.101 <http://192.168.123.101/>    RTP    PT=Unknown (96),
> SSRC=0x4B6C00C, Seq=65416, Time=1531529067
>
> is this what i suppose to see? any suggestions in how to analyse packets
> im receiving while streaming? please help!! im new
>
>

_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users

 

_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users



_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users





 

_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users



_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users



_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users