Re: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis

[Suhas Nandakumar <[e-mail]>]

Many thanks Bo for the review. Please see comments inline

Cheers
Suhas


On Thu, Jun 26, 2014 at 4:17 AM, Bo Burman <[e-mail]> wrote:

>  Suhas, all, please find comments inline below /Bo
>
>
>
> *From:* mmusic [mailto:[e-mail]] *On Behalf Of *Suhas
> Nandakumar
> *Sent:* den 23 juni 2014 05:37
> *To:* mmusic WG
> *Subject:* [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type
> Analysis
>
>
>
> Hello All
>
>
>
>
>
>    Continuing the discussions from London on analyzing multiplexing
> behavior for SDP attributes that are defined per  Payload Type, I was
> thinking on making following changes to the
> draft-ietf-mmusic-sdp-mux-attributes-01.
>
>
>
> 1. Add new category called IDENTICAL-PER-PT to the SDP Attribute analysis
> framework in Section 4 which is defined as
>
>
>
> IDENTICAL-PER-PT: Attributes that define the RTP payload configuration on
> per Payload Type basis and MUST have identical values across all the media
> descriptions for a given RTP Payload Type when repeated.
>
> *[BoB] I believe this requirement for consistency is good, straightforward
> and simple. Note that as a consequence, if any single one of the bundled
> media descriptions has a payload-specific attribute listed as
> IDENTICAL-PER-PT using ‘*’, that attribute has to be identical for all PT
> across all bundled media descriptions.*
>
>
>

[ Suhas ] Agreed.


>  *Apologies if you already discussed and settled this, but it does not
> seem to be strictly technically necessary IF a receiver can relate a stream
> to a certain media description, which is possible for example in the
> presence of a=ssrc (AND IF that SSRC is unique across the SDP), or in the
> presence of a=appId (which has to be unique across the SDP). We may however
> choose to ignore that fact in favor of keeping the rule simple.*
>
>
>

[Suhas] Totally make sense. If there are way to uniquely map the incoming
RTP streams to a m=line the implementation can use it. BUNDLE does specify
this fact.


>   2. Similarly add another category IDENTICAL-PER-SSRC to accommodate
> source level SDP attributes.
>
>
>
> IDENTICAL-PER-SSRC: Attributes that correspond to the individual RTP
> Packet Streams in a given RTP Session and MUST have identical values when
> repeated across multiple media description for a given SSRC.
>
> *[BoB] This rule would only be used whenever the same SSRC value was
> explicitly listed under multiple media descriptions, right? Since the media
> descriptions are bundled, those streams will be in the same RTP session and
> will effectively become part of one and the same stream, sharing the same
> RTP timestamp and sequence number space. Is this really a useful case to
> describe, or is it not rather something that should be avoided? What you
> effectively describe is a single stream that has its configuration spread
> out across multiple media descriptions.*
>
>
>
[Suhas ] Makes sense. We probably dont need a new one and we should assign
the category NORMAL. Since if the SSRC is repeated it is describing the
same source ( as you mentioned).


>   3. For all the attributes that directly/indirectly impact codec
> configuration and packetization of the media, I have attempted to assign a
> SDP MUX category and provide some insights on how such a decision was made
> (wherever applicable)
>
>
>
> *Attribute: a=ptime, a=maxptime*
>
> Mux Category: IDENTICAL-PER-PT
>
> Notes: For a given codec the audio packetization time must be same if the
> PT is repeated. This will ensure that the RTP receiver
> can unambiguously decode the incoming audio packets.
>
> *[BoB] Makes sense. Since those attributes are not payload specific, they
> of course apply and puts restrictions on any PT present in that media
> description.*
>
>
>
>
>
> *Attribute: a=framerate*
>
> Mux Category: IDENTICAL-PER-PT
>
> *[BoB] Makes sense. As above, applies to all PT present in that media
> description.*
>
>
>
> *Attribute: a=rtpmap*
>
> Mux Category: IDENTICAL-PER-PT
>
> *[BoB] Makes sense. *
>
>
>
>
>
> *Attribute: a=fmtp*
>
> Mux Category: IDENTICAL-PER-PT
>
> Notes:
>
> *[BoB] Makes sense.*
>
>
>
> *Attribute: a=rtcp-fb*
>
> Mux Category: NORMAL
>
> Notes: Since the feedback messages are reported per SSRC, the category of
> NORMAL suffices.
>
> *[BoB] I believe IDENTICAL-PER-PT is more appropriate, since per RFC 4585
> RTCP receivers ‘…MUST NOT use other FB messages than those listed in one of
> the “rtcp-fb” attribute lines’, which I think would cause a conflict for
> NORMAL.*
>
>
>
[Suhas] Good catch. I agree this should be IDENTICAL-PER-PT


>   *Attribute: a=depend (RFC5583)*
>
> Mux Category: IDENTICAL-PER-PT
>
> Notes:
>
> Since each dependency identifies a unique RTP packetization  and thus MUST
> be identified via unique Payload Type.
>
> Similarly if the Payload Type is repeated across media descriptions, they
> MUST represent the Identical codec configuration.
>
> *[BoB] Makes sense*
>
>
>
> *Attribute: a=ssrc:xyz  fmtp:<fmt> ... *
>
> Mux Category: IDENTICAL-PER-PT
>
> Notes:
>
> RFC5576 says this :
>
> "
>
> Within a media stream, "ssrc" attributes with the same value of
>
>
>
> <ssrc-id> describe different attributes of the same media sources.
>
> Across media streams, <ssrc-id> values are not correlated (unless
>
> correlation is indicated by media-stream grouping or some other
>
> mechanism) and MAY be repeated.
>
> "
>
>
>
> Thus if the RTP Payload Type used to specify fmtp parameters  is repeated, it MUST represent the same codec configuration.
>
> example:
>
>
>
> m=video ...
>
> a=rtpmap:98 VP8/90000
>
> a=ssrc:12345 fmtp:98max-fr=15; max-fs-1200
>
>
>
>
>
> m=video ...
>
> a=rtpmap:98 VP8/90000
>
>
>
> a=ssrc:56789 fmtp:98 max-fr=15; max-fs-1200
>
>
>
> *[BoB] OK. Relates to my comment on IDENTICAL-PER-PT; the above proposal prioritizes to keep the same definition and thus the rule simple.*
>
>
>
>
>
>  *Attribute: a=ssrc:xyz  cname: ....*
>
> Mux Category: IDENTICAL-PER-SSRC
>
> Notes: RFC5576 defines the identical requirement as it is.
>
> *[BoB] So, maybe not needed and thus NORMAL? As said above, I question the
> usefulness of IDENTICAL-PER-SSRC category.*
>
>
>
> [Suhas] . Agreed


>
>
  *Attribute: a=imageattr*
>
> Mux Category: IDENTICAL-PER-PT
>
> *[BoB] OK*
>
>
>
>
>
> *Attribute: a=framesize*
>
> Mux Category: IDENTICAL-PER-PT
>
> *[BoB] OK*
>
>
>
>
>
> *Attributes: a=fec-source-flow, a=fec-repair-flow, a=repair-window*
>
> Mux Category: NORMAL
>
> *[BoB] I wonder if this is sufficient, or if it has to be SPECIAL? It
> seems to me you need a new ADU identification mechanism. When bundling
> media descriptions, the ADU identification used by RFC 6363 and 6364 makes
> all ADU flows, source and repair alike, effectively become one and the same
> ADU flow. From section 3 of RFC 6363:*
>
>    In this architecture, we assume that the interface to the transport
>
>    layer supports the concepts of data units (referred to here as
>
>    Application Data Units (ADUs)) to be transported and identification
>
>    of ADU flows on which those data units are transported.
>
>
>
> [Suhas ]  Thats true. Let me also think this through. Even if we define
SPECIAL, I am not sure what is the expected behavior though ..


>
>

>
> I believe these cover all PT scoped SDP attributes. Please let me know
> your thoughts and comments.
>
>
>
> Cheers
>
> Suhas Nandakumar
>