Re: How to describe SSM sessions in SDP?

[Toerless Eckert <eckert@cisco.com>]

> Isn't the need for a source address (aka, a "filter") implicit 
> to the *Source Specific* Multicast address range?  

Right, but so far i am not persuaded that everyone agress that 
all future applications, stacks and protocols should just hardcode
232/8 to be SSM and only that range to SSM. And of couorse we already
have customers who ask for multicast outside this range to (ab)use
scoping for access control.

So i guess as of today we don't know if a group is SSM or not by just
looking on the group address, and as long as we have this, it owuld
really be help full if we could try to convey this information a bit
better than we try to do it now (like we convey it not).

> Current Multicast protocols and APIs are no better.  When you
> join any ISM group, there's no feedback from local routers or
> APIs to notify an application when they won't receive anything
> (e.g., when the local router isn't forwarding multicast traffic).

True, but with SSM we're adding another layer of uncertainty, which is
about the source address being option or not.

> So, if we're going to improve the API and IGMP for SSM, why not 
> improve it for ISM too, while we're at it?  A new API and IGMP
> message for both would be very nice.  Something that would actually
> query the local router(s) for IGMP version and an indication of
> whether they have a multicast routing protocol enabled would be
> much appreciated by multicast application developers (and their 
> users).

Well as far as ISM is concerned, the host stack does already know if
there's a router and which version the router has. It's just the API 
that never wanted to deliver this information to the host. As long as there
was only ISM, i think the mayority of reasons was in favor of not doing
this signalling, but today i'm concerned about applications that may
for example get two session announcements, one which is low-bandwidth
ISM, and the other is high-bandwidth SSM and then i'd like the application
to be able to differentiate a bit better if a session is one or the other.

Cheers
	Toerless