[MMUSIC] 4566bis

Ah. I did not consider the reality of other transport than RTP, thanks for reminding me. :-)

I understand the backwards compatibility risk of the ptime route taken in AES67. I have been working with another possible future extension that has some theoretical overlap with AES67. In this we used a different approach of extending ptime functionality by introducing a completely new attribute. This work is being done by a subgroup of the ACIP working group of the European Broadcasting Union (EBU). The EBU work is just about ready as a first draft to be agreed upon within EBU. The actual path of getting this or the AES work approved by IETF has not yet begun, but it is likely that feedback such as this will cause changes in both the AES standard and the coming EBU standard. 

I agree that range constraints would have to be carefully thought through. In light of this I think that I change my vote to not having any such constraints at all. Of course, I don't have the full understanding of all attributes and there may be some that I am unaware of that would benefit from this. So I suppose that I didn't really help answering the questions.

Thanks,
Fredrik Bergholtz
Swedish Radio

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: den 13 augusti 2014 16:48
> To: Fredrik Bergholtz; mmusic@ietf.org
> Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED
> 
> On 8/13/14 7:37 AM, Fredrik Bergholtz wrote:
> > Good job.
> >
> > I wonder if it would be wrong or bad to change
> >
> >      fmtp-value = fmt SP format-specific-params
> >
> > to
> >
> >      fmtp-value = payload-type SP format-specific-params
> >
> > thus using the definition of payload-type from a=rtpmap rather than 
> > adding a
> new definition of fmt that would, as I understand it, be essentially the same.
> 
> That would be wrong.
> 
> The definition of each <proto> gets to constrain the syntax of the 
> <fmt> values allowed with it. The RTP family of <proto> values require 
> that the <fmt> values be integers. So when those same values show up 
> in rtpmap, they are still constrained to be integers, because rtpmap is only used in those cases.
> 
> OTOH, fmtmap may be used with any <proto> type, so it must allow the 
> more general value.
> 
> > Another issue is that I know of one "extension" that would become 
> > invalid if
> this syntax for a=ptime is introduced. This extension is not yet an 
> official extension of SDP but the standard is accepted as of 2013 
> within Audio Engineering Society (AES). Section 8.1 of AES67-2013 states:
> >
> >      8.1 Packet time
> >      Packet time is described with two SDP attributes defined in RFC 4566.
> >
> >          a=ptime <milliseconds>[.<milliseconds decimal>]
> >          a=maxptime <milliseconds>[.<milliseconds decimal>]
> >
> >      Signaled packet time multiplied by sampling frequency rounded 
> > to the
> nearest integer indicates the number of
> >      samples in each packet. The packet time descriptions shall be 
> > given with
> error less than half a sample period so
> >      that the calculated number of samples per packet rounds to the 
> > intended
> integer value. In many cases, this
> >      requires the inclusion of the <milliseconds decimal> in the description.
> >
> > If SDP is to allow that kind of usage, the type for ptime, and 
> > possibly also
> maxptime, should be the positive-real-number definition as used in a=framerate:
> >
> >      packet-time = positive-real-number
> 
> If this is being proposed as an *extension*, what provision is being 
> made for backward compatibility? I suspect many implementations won't 
> accept a fractional value.
> 
> > Concerning the questions about adding range limits on values, I 
> > think that only
> if the value references something that is range- limited by 
> specification, such as RTP payload type, should the SDP specify a 
> matching range limitation. This means that the integer of the 
> payload-type should be limited to a seven bit, unsigned integer. The 
> other class of values would be values that are limited only by 
> implementation. Among these I count packet times, clock rates, frame rates etc. For these values I would prefer that SDP does not limit the ranges.
> 
> I'm not inclined to impose the range in *syntax*.
> We can specify it as a semantic constraint, but should probably be 
> careful about when we do this. So I'm looking for opinions about when 
> it is important to specify this and when it is not - on a case by case basis.
> 
> 	Thanks,
> 	Paul
> 
> > Best regards
> > Fredrik Bergholtz
> > Swedish Radio
> >
> >
> >> -----Original Message-----
> >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul 
> >> Kyzivat
> >> Sent: den 12 augusti 2014 18:06
> >> To: mmusic@ietf.org
> >> Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK 
> >> REQUESTED
> >>
> >> I made some corrections based on offline comments from Christian Groves.
> >> Revised version attached.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >> On 8/11/14 6:10 PM, Paul Kyzivat wrote:
> >>> I took an action item to make a proposal for the syntax of 
> >>> attributes in 4566bis.
> >>>
> >>> I've *started* on it, and have enough that I would like to get 
> >>> some feedback before going further.
> >>>
> >>> Attached is a snippet from section 6 of 4566bis (SDP Attributes) 
> >>> to which I have added some ABNF syntax for just the values. (Each 
> >>> addition starts with "Syntax:")
> >>>
> >>> This isn't necessarily the *form* it will take when done. For now 
> >>> what I'm looking for is feedback on the substance.
> >>>
> >>> Of particular concern - when the format has text values, should 
> >>> those be case-sensitive (the default for SDP), or case-insensitive?
> >>> I think we need to sort this out by what the common usage is.
> >>>
> >>>       Thanks,
> >>>       Paul
> >>>
> >>>
> >>> _______________________________________________
> >>> mmusic mailing list
> >>> mmusic@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/mmusic
> >>>
> >
> >