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

Jay Beavers jbeavers at microsoft.com
Fri Aug 16 15:31:33 CDT 2002


In our case, our ConferenceAPI uses a lookup interface on a dynamically
loaded assembly in the directory of the application.  For instance in
pseudocode:

RTPListener.OnRTPStreamAdded(rtpStream)
{

// Do we have a CapabilityViewer already loaded for this PayloadType?
// CapabilityViewers is dynamically loaded at startup using .NET
Reflection
foreach (CapabilityViewer cv in CapabilityViewers)
  {
  if (cv.PayloadType == rtpStream.PayloadType)
    {
    cv.Play(rtpStream);
    return;
    }
  }

// if not found locally, look up centrally
cv = VenueServer.DownloadVenueCapability(rtpStream.PayloadType);
DynamicallyLoadedVenueCapabilityViewers.Add(cv);  // Cache for later use
cv.Play(rtpStream);

}

This allows us to not only specify different types of payloads, but also
to add new capabilities to the system dynamically.  We've made it
relatively easy to create these capabilities by providing a high level
RTP API to take away the networking guts, providing a base class for
CapabilityViewer, and providing a ConferenceAPI that allows the UI to
easily deal with new services via polymorphism.  The end result is that
if you have anything you want to do that involves sending byte[]s
between computers and doing something interesting with them, you can
dynamically add it to the system and only have to worry about your
application code that knows how to generate the byte[]s and display the
byte[]s.

Of course the only way we can get away getting this rich functionality
is by assuming we have a standard set of network services to do the
lookup and download (implemented as Web Services in our case) and a way
to download code dynamically and ensure it will execute on the target
environment (implemented as .NET Assemblies on top of the Common
Language Runtime in our case).

 - jcb

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


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
> > 
> 




More information about the ag-tech mailing list