Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED

Fredrik Bergholtz <> Wed, 13 August 2014 11:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9ED6A1A086A for <>; Wed, 13 Aug 2014 04:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.551
X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7rknU7w3BSQq for <>; Wed, 13 Aug 2014 04:40:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26C4D1A0464 for <>; Wed, 13 Aug 2014 04:40:57 -0700 (PDT)
X-Halon-ID: 2b03aade-22de-11e4-a0f2-000c2976599e
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=sverigesradio; h=cc:x-halon-id:received:received:from:to:subject:thread-topic:thread-index: date:message-id:references:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:content-type:content-transfer-encoding: mime-version; bh=UQmby13U/k4UX0/toGC8Nqz3mmRfj7hdDKG/omdBQyQ=; b=Sr+SM9DlADcixc0fizFNRFdvxNNB+2EeuZm0ko4jtKgOUirzRqTH1xK4jwSuL6Qg/sjcK7VyDJLd9 6d5IGJGr1rNJmqoXN13GgIt7lKbm4T9qAy+kE8fJG8o64UEW+ijdT6ELxmM+WUvGxVpBiJavxRByc+ I7024BerhHnrPxxg=
Received: from (unknown []) by (Halon Mail Gateway) with ESMTPS; Wed, 13 Aug 2014 13:37:12 +0200 (CEST)
Received: from ([fe80::3ca4:10d1:e63f:5b7f]) by ([fe80::d59a:f815:3925:e9c8%13]) with mapi id 14.03.0181.006; Wed, 13 Aug 2014 13:37:48 +0200
From: Fredrik Bergholtz <>
To: Paul Kyzivat <>, "" <>
Thread-Topic: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED
Thread-Index: AQHPtbEQGum7dNrLIEqp0Jhju2ac+ZvNAbWAgAFe75A=
Date: Wed, 13 Aug 2014 11:37:47 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, sv-SE, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Aug 2014 11:41:00 -0000

Good job.

I wonder if it would be wrong or bad to change

    fmtp-value = fmt SP format-specific-params


    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.

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

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.

Best regards
Fredrik Bergholtz
Swedish Radio

> -----Original Message-----
> From: mmusic [] On Behalf Of Paul Kyzivat
> Sent: den 12 augusti 2014 18:06
> To:
> 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
> >
> >
> >