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

[Ivan R. Judson]

Right, this is along the same lines as what I was thinking, however, I
was worried that we missed the "How do I tell someone I can do that?"
This detail is lower than worrying about user resources or capabilities
at a general level.  There are a lot of issues in the "How do users
agree to share format X?"

These are cool and fun.  Your methods make sense to me, I think the
question is what are the best mechanisms for negotiating multiple
capabilities.

-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: Jay Beavers [mailto:jbeavers at microsoft.com] 
> Sent: Friday, August 16, 2002 3:05 PM
> To: judson at mcs.anl.gov; Bill Nickless
> Cc: ag-tech at accessgrid.org
> Subject: RE: [AG-TECH] IGMPv3, Source Specific Multicast, 
> fully supported in Windows XP
> 
> 
> 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
> > 
>