Re: FLUTE SDP specification

One comment below.


On 6/23/10 10:29 AM, "Jani. Fi" <[email protected]> wrote:

> Dear RMTers,
> 
> We are currently updating the FLUTE SDP specification and at this point
> we need to clarify three issues:
> 
> 1. Our understanding is that ALC, LCT and FLUTE sessions must
> originate from a single sender and therefore from a single IP address.
> There is some confusing text of discussing ASM/SSM models in the ALC,
> LCT and FLUTE specifications. It is our understanding that ASM/SSM
> discussion only relates to IP level routing and (e.g., IGMP) joining of
> IP multicast groups. Does anyone disagree with this? (And more
> critically is anyone aware of implementation that is incompatible with
> our understanding.)
> 
> 2. FLUTE SDP defines the Composite Session token so that multiple FLUTE
> sessions can be described in a single SDP object/instance/file (for
> efficiency and encapsulation). To enable this the 05-version of the
> specification promotes one media (channel) to be the Primary Media where
> things like source IP address are defined for all media / channel for a
> single FLUTE session. The specification currently says: "The first media
> line declared for a Composite Session group is the Primary Media.".
> However, we propose to change this to: "The first (leftmost) mid value
> declared for a Composite Session group is the Primary Media.". This
> should make reading and writing the SDP simpler and less prone to
> errors. Because of the convention of declaring the group's mid values in
> the same order as the media lines we anticipate no compatibility
> breakages. Does anyone disagree with this?
> 
> 3. ALC, LCT and FLUTE specify: "Each TSI MUST uniquely identify a
> FLUTE session for a given source IP address during the time that the
> session is active and also for a large time before and after the active
> session time.". In SDP, the t-field is mandatory and this field is used
> to specify precise time. We would like to fully specify what is meant by
> large time. We propose 60 minutes. We will also clarify the best
> practise use of SDP session times (especially with unbounded and
> permanent sessions) in MMUSIC working group. Will this make anyone happy
> on unhappy?
I can imagine a session going on for days, and having receivers come in and
out of coverage over hours, so having only a 60 minute buffer on each side
of the session in terms of uniqueness of the TSI seems very dangerous.
Multiple days seems a much safer bet.  Is there any reason to make this a
much smaller time period, i.e., a lack of TSI namespace that makes it
imperative to reuse TSIs very quickly?
> 
> BR,
> 
> Jani Peltotalo
>