All things related to multicast

[Hans Kuhn <>]

Marshall,

IP/TV uses a fairly elegant solution. Clients and servers
alike do an HTTP get for the following file:

  http://iptvhost.uoregon.edu/iptvfiles/guide.tvg 

(go ahead, take a look. I'll wait.)

For those who didn't look, it's basically a bunch of SDP
files concatenated together.

The client simply parses this file and displays the contents
to the user. When a user joins a session, the player refers
back to the guide.tvg file to get the group and port, (and
source for SSM).

The server looks for it's IP address in the guide.tvg file
and if it finds a reference to itself, it starts sourcing
the stream according to the information found in the
corresponding SDP file from the guide.tvg file. clever.

I have a piece of semi-working code that someone here at the
UO wrote to take the current guide.tvg file and create a web
page with links you can click on to launch a session with
the client of your choice. NO SAP REQUIRED.

I also believe the IP/TV content manager v3.4 includes a web
page that does a similar function, tho the formatting is not
customizable and thus not very interesting to marketing
types who like to create web pages with their company logo
on it.

Did I answer your question?

Hans

On Tue, 13 Aug 2002, Marshall Eubanks wrote:

:    
:    
:    John Zwiebel wrote:
:    
:    > On 8/7/02 9:43 AM, "Alan Crosswell" 
<>
 wrote:
:    > 
:    > 
:    >>A WWW-based guide is UNICAST.  Bah!
:    >>/a
:    >>
:    >>
:    >>
:    > 
:    > But it provides the information quickly so receives
:    >  know which source to join to.  Why multicast information
:    >  about millions of sources using up network BW when that
:    >  same info can be stored on a disk and retrieved in just
:    >  a few seconds?
:    > 
:    > FWIW, it "sounds like" you think the SDR/SAP application
:    >  is a "good thing". I believe it is very, very broken.
:    >  (And I do mean the application not the protocols)
:    > 
:    > Look at how the IP/TV content manager works.  You get the
:    >  info you need, when you need it because you specifically
:    >  ask for it.  No waiting for an SDR packet to "finally"
:    >  show up.
:    > 
:    > 
:    
:    
:    And is there a published and available protocol describing how this 
works ?
:    
:    
:    
:    

-- 
Hans Kuhn, Academic User Services            office (541) 346-1714
University of Oregon, 237 CC                 fax    (541) 346-4397

Key fingerprint =  1E BC 32 03 AC E9 82 6C  44 4A CD 63 BB 2D 51 89