From owner-freebsd-multimedia Sat Feb 13 18:38:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA05201 for freebsd-multimedia-outgoing; Sat, 13 Feb 1999 18:38:28 -0800 (PST) (envelope-from owner-freebsd-multimedia@FreeBSD.ORG) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA05173 for ; Sat, 13 Feb 1999 18:38:22 -0800 (PST) (envelope-from O.Hodson@cs.ucl.ac.uk) Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 13 Feb 1999 22:49:55 +0000 To: Luigi Rizzo cc: multimedia@FreeBSD.ORG Subject: Re: good or bad idea ? (vat-related...) In-reply-to: Your message of "Sat, 13 Feb 1999 19:51:15 +0100." <199902131851.TAA26875@labinfo.iet.unipi.it> Date: Sat, 13 Feb 1999 22:49:54 +0100 Message-ID: <1337.918946194@cs.ucl.ac.uk> From: Orion Hodson Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org <199902131851.TAA26875@labinfo.iet.unipi.it>Luigi Rizzo writes: > Ok the thing is the following: i was shown that realvideo streams can > contain "annotations" that during playback send a > > netscape -remote openURL(xyz) > > command. A four-line change to vat (file source.cc) can be used to do > the same when say the "Name:" or "Note:" field of the sender > (transmitted using RTCP) is used to carry the URL to open (or we > can add a new SDES field for this purpose, assuming one does not > already exist). > > It's a dirty hack, ok. I think is useful, though, because many times > (e.g. during a lecture) what you really need are audio and slides, > not really a video of a dancing speaker. So, any objections to > having this in our vat port ? This is an interesting feature, but as you say it is a dirty hack. You are proposing to bastardize RTP/RTCP and so a better place to discuss this is in the IETF AVT working group (rem-conf@es.net) where it comes from. A lot of effort has gone into keeping RTP clean and this goes against that philosophy. This info would be better sent as side information on a separate multicast group rather than incorporated as a quick and dirty hack into the audio stream of one audio tool. You are also assuming everybody in a session is running VAT on FreeBSD and running netscape...and a few people don't. Multicasting URL's in this way could be v. bad for web servers if implementation is naive and group size is not small. This functionality already exists outside of VAT in tools like WebCanal, mash, and mMosaic. I am only first hand familiar with Webcanal and that is just a proxy that listens to mcast groups and would be fairly straightforward to port. WebCanal multicasts the web pages and does a form of RM. What more could you ask for? (Ok, it lacks congestion control, but you know a lot more about this area than most). SSRC spoofing is totally trivial outside of encrypted sessions. Unless you add ssrc _and_ ip src address filtering into the decode path there will be attacks that put up dubious material into sessions. I don't think VAT does this currently and it isn't hard, but do you really want to do this? cheers - Orion To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message