[gst-devel] RTP+MJPEG - Sniffing packets with wireshark, How clients join the rtp server

[Marco Ballesio]

Hi,

these are really generic RTP/wireshark specific questions so I might
not be the more appropriate guy on this planet to reply, btw a few
answers below..

On Tue, Dec 21, 2010 at 12:16 PM, Mauro Brenna <malloblenne at gmail.com> wrote:

..snip..

>
>
> Everything works but I would like to ask to this mailinglist a couple
> of questions about the implementation and RTP itself:
>
> 1) I tried to sniff the packets using wireshark. I can see the packets
> that are sent using UDP but not the RTP encapsulation (I see only the
> field data of the UDP packet). Is is a problem of wireshark for RTP
> (RFC 2435) or the gstreamer plug-in is not compliant to the standard?
> I tested the same thing in VLC that streams RTP packets using RFC
> 2250. In wireshark I can see the RTP packet with the correct payload
> type.

It's usually up to a sender/receiver negotiation to agree that an UDP
communication is actually RTP and which are its parameters. Standard
ways to perform such a negotiation are RTSP, SIP/SDP, XMPP, etc. etc.
. Afaik, by no means this negotiation, aka "the session initiation" or
"signaling phase", is described in RFC1889.

As such a negotiation is not mandatory, in case the two ends of the
communication "already know" the basic parameters of the stream
(basically, destination IP and port) the latter can happily occur
without any violation to the standards.

Now, what has Wireshark to do with all of this? Basically, it is a
very smart tool which, other than sniffing the network traffic, also
processes it (maybe you noted it in the lower part of its UI ;) ).
This happens also for the negotiation packets and so, when it
discovers that an UDP stream matches with the parameters of, for
instance, a previous RTSP session initiation (appearing in the network
dump), it's "dissected" as RTP.

This kind of dissection fails in a few cases:

1) No negotiation occurred, as in the pipelines you posted above.
2) The negotiation protocol in unknown to Wireshark. For instance, you
designed and implemented it by yourself: in such a case you'll have to
pay the fee for doing proprietary stuff :).
3) The capture Wireshark is analysing began AFTER a "dissectable"
negotiation, so the tool does not have a clue about its contents.

>
> 2) I do not understand very well how the client (player) join the RTP
> server (streamer). I read the general RFC 1889. In the section about
> RTP Control Protocol, it is not clear how the initialization works.

RTCP is not about session initiation, as RFC1889 says, it is "to allow
monitoring of the data delivery".  Read above for more details.

> I
> mean, when I start the streamer, does it start to send RTP+MJPEG
> packets to the unicast/multicast destination even if nobody is
> listening to it?

Yes, it does. How could it happen without signaling otherwise?

> Or does it start sending packets after the reception
> of a particular packet from the client ? I read about feedbacks
> packets from sender/receiver and about the BYE (Goodbye RTCP packet).
> However, I have not found a sort of JOIN packet.
>

Because -unless you're using means other than RFC1889- there aren't
any. Probably VLC performs a session initiation (I guess RTSP, you
should see it in the network capture). If you need such a feature, on
the GStreamer side you'll need to use the "rtspsrc" element.

Regards

>
> Thanks in advance for the replies,
>
> Mauro
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>