Re: Use of SAP in a PIM SSM Network

[Ross Finlayson <finlayson@live.com>]

I'm sure that most SSM sessions will end up getting advertised on web 
pages, and launched from web browsers.  This is the technology that most 
people are familiar with, and it scales reasonably well for sessions that 
are long-lasting, and whose information doesn't change frequently (so that 
web caching can take effect, and so that users don't have to keep 
'refreshing' the web page).  (I just hope, though, that people standardize 
on using SDP to describe these sessions - either using data:// URLs 
embedded in web pages, or via links back to a web server.  I'd hate to see 
a proliferation of viewer-specific hacks like we see now with Real or 
Windows Media sessions.)

The main disadvantage of advertising SSM sessions on the web is that the 
announcements will be visible even to those who don't have 
SSM-connectivity.  So be prepared for lots of people asking "Why can't I 
receive this stream after I've launched it from your web site?!"

At the same time, though, I see no reason why *some* SSM sessions - 
especially those that are more ephemeral in nature - can't also be 
advertised within SDP directories, using single-source-SAP as the 
announcement protocol.  This probably makes the most sense for advertising 
multiple sessions that come from the same source (or at least, from the 
same provider); the SDP directory that advertises these sessions can then 
come from the same source (or provider).  However, I don't think there'll 
be much value in trying to have a single large global multicast session 
directory for announcing SSM sessions from independent providers - as we do 
now in the ISM world - because you either have to do this using ISM (which 
not all SSM receivers will have), or else use a SSM source (a single point 
of failure) with some separate unicast protocol needed for announcing 
session description data to that source.

John Crowcroft wrote:
>so no, we dont have resources to do this, but we are happy to roll in
>SSM/igmpv3 changes to the mbone apps if people contrib. them (spritn
>have kindly offered to do some apps) - sdr is a non trivial one in
>that it needs completely re-writing which is outside the scope of a
>university research department's normal activities....

Actually, modifying "sdr" to handle launching SSM sessions - including the 
ability to use arbitrary SSM SDP/SAP directories - should not be all that 
difficult, I think.  The most recent "sdr" version already contains my 
patches to support launching of SDP "directory" sessions[*], so it already 
knows how to handle multiple, arbitrary SDP/SAP directories.  All that's 
needed now is the ability to recognize the special SDP syntax for SSM 
sessions, and the ability to subscribe to a SSM SDP/SAP directories using 
an apropriate IGMPv3 API call.

Needless to say, I'll be making such a change to "multikit" at some point :-)

         Ross.

[*] "sdr" currently supports only an old format for SDP "directory" 
sessions, not the newer format described in 
<draft-ietf-mmusic-sdp-directory-type-01.txt>