[AG-TECH] IGMPv3, Source Specific Multicast, fully supported in Windows XP

[Jay Beavers]

RTP carries metadata about each stream in the protocol.  In the RTP
packets themselves, this is a simple PayloadType.  In the past this has
well-known-mapped to details (such as h.261), etc. though the trend now
is to use this as a simple value that is application specific or is an
enum to an out of band description mechanism.  At least that's what I've
been advised when talking about this question with RTP experts.

RTCP has the ability to carry whatever application specific extensions
you need.  This could be the out of band signaling mechanism if you
like.  I'm tending towards using PayloadType as a simple int that can be
used to query a web service table of media types.  I'm wondering if this
lookup table should be venue specific and dynamically determined by
participants registering their medias as they enter the venue (another
suggestion by those with more RTP experience than I).  I don't do that
now because there are ~7 bits to play with in PayloadType and I only
have about 12 different media types in use in our system to date, so
hardcoding the enum is more than sufficient to date.

 - jcb

-----Original Message-----
From: Ivan R. Judson [mailto:judson at mcs.anl.gov] 
Sent: Friday, August 16, 2002 12:16 PM
To: 'Bill Nickless'
Cc: Jay Beavers; ag-tech at accessgrid.org
Subject: RE: [AG-TECH] IGMPv3, Source Specific Multicast, fully
supported in Windows XP


I don't have a problem with that answer (it fits my model of 2.0), but
we still have to have something to argue about.  So how do I tell others
what I "can" do?

--Ivan

..........
Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
Futures Laboratory .~.  630 252 0920
Argonne National Laboratory .~. 630 252 6424 Fax
 

> -----Original Message-----
> From: Bill Nickless [mailto:nickless at mcs.anl.gov] 
> Sent: Friday, August 16, 2002 2:00 PM
> To: judson at mcs.anl.gov
> Cc: 'Bill Nickless'; 'Jay Beavers'; ag-tech at accessgrid.org
> Subject: RE: [AG-TECH] IGMPv3, Source Specific Multicast, 
> fully supported in Windows XP
> 
> 
> At 01:31 PM 8/16/2002 -0500, Ivan R. Judson wrote:
> >This is something that I have a hard time thinking about.  
> My concern 
> >is mostly based around the fact that these seem to be things that AG 
> >Nodes/Users need to have in the technology portfolio.  Ie, 
> can the user 
> >send more than one stream?  What format? What quality?  If 
> not, who's 
> >doing it for them?  Is this a network service?  Does it need to be 
> >advertised?
> 
> It seems to me that the best place to code a video stream 
> into multiple 
> formats is at the sender.
> 
>   - The sender has the raw, uncompressed video available by virtue of
>     the direct connection to the camera.  This eliminates the need for
>     decoding a compressed stream and re-encoding it somewhere else.
> 
>   - In the multicast transport model, the incoming traffic level is
>     generally much larger than the outgoing traffic.  Thus, there is
>     usually plento of bandwidth available for multiple 
> outgoing streams
>     at the sender.
> 
>   - The receiver knows best which streams are "interesting".  By
>     choosing which (S,G)s to join, the receiver can help the network
>     deliver only the traffic that is necessary for the displays
>     currently visible at the local site.  Generally, bandwidth
>     limitations are closer to the edge than the core of the Internet.
> 
> 
> ===
> Bill Nickless    http://www.mcs.anl.gov/people/nickless      
> +1 630 252 7390
> PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     
> nickless at mcs.anl.gov
>