Re: [Rmt] FLUTE SDP specification

[<[e-mail]>]

Thanks for the quick response Mike!

'Large time' can be used as an excuse for 'undefined time'. Especially if the application only concerns well (time) bound session a developer may make this artistic interpretation.

Generally speaking, there's not much we can do about badly behaving developers (in the spec), but some kind of 'normalizing' text would help keep some developers away from the dark side - like 'Note, although 'large time' is not precisely defined in this document, a duration in the order of several days is considered good practice'.

The 60 minute suggestion comes from (re)reviewing best practice use of SDP where a 30 minute 'guard interval' is recommended for session description validity. Thus not only session id (TSI + sourceIPaddress) fully and uniquely identifies a session in SDP space, but also start and end time (plus guard interval). So if it's not absolutely essential to have a really long time in some cases, we propose allowing something like SDP best practice in the SDP spec rather than re-educating SDP practitioners or risking the interpetation of a contradiction in approaches (that could encourage 'bad' practice).

It all revolves around the use of t=...

Unbounded end times (value 0) should stick to the 'large time' rule, but well bounded session ends (within a second) could be tighter as per SDP practice.

Make sense?

Cheers, Rod.



----- Original message -----
> One comment below.
>
>
> On 6/23/10 10:29 AM, "Jani. Fi" <[e-mail]<mailto:[e-mail]>> 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
> >
>
> _______________________________________________
> Rmt mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rmt
>