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

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 22 Jun 2014 20:36:47 -0700

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.

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.

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.

*Attribute: a=framerate*
Mux Category: IDENTICAL-PER-PT

*Attribute: a=rtpmap*
Mux Category: IDENTICAL-PER-PT

*Attribute: a=fmtp*
Mux Category: IDENTICAL-PER-PT
Notes:

*Attribute: a=rtcp-fb*
Mux Category: NORMAL
Notes: Since the feedback messages are reported per SSRC, the category of
NORMAL suffices.

*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.

*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

*Attribute: a=ssrc:xyz  cname: ....*
Mux Category: IDENTICAL-PER-SSRC
Notes: RFC5576 defines the identical requirement as it is.

*Attribute: a=imageattr*
Mux Category: IDENTICAL-PER-PT

*Attribute: a=framesize*
Mux Category: IDENTICAL-PER-PT

*Attributes: a=fec-source-flow, a=fec-repair-flow, a=repair-window*
Mux Category: NORMAL

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

Cheers
Suhas Nandakumar

---

From: Bo Burman <[email-masked]>
Date: Thu, 26 Jun 2014 11:17:05 +0000

Suhas, all, please find comments inline below /Bo

From: mmusic [mailto:[email-masked]] 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.

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.

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.

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
[BoB] Makes sense.

Attribute: a=fmtp
[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.

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

"

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

m=video ...

a=rtpmap:98 VP8/90000

[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.

Attribute: a=imageattr
[BoB] OK

Attribute: a=framesize
[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.

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

Cheers
Suhas Nandakumar

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 26 Jun 2014 10:50:51 -0700

Many thanks Bo for the review. Please see comments inline

Cheers
Suhas

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

> *From:* mmusic [mailto:[email-masked]] *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
>
>
>
>
>
> *[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.

> 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).

> *[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*
>
> *[BoB] Makes sense. As above, applies to all PT present in that media
> description.*
>
>
>
> *Attribute: a=rtpmap*
>
> *[BoB] Makes sense. *
> *[BoB] Makes sense.*
> *[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

> *[BoB] Makes sense*
> *[BoB] OK. Relates to my comment on IDENTICAL-PER-PT; the above proposal prioritizes to keep the same definition and thus the rule simple.*
>
>
>
>
>
> *[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*
> *[BoB] OK*
> *[BoB] OK*
> *[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:*
>
> [Suhas ]  Thats true. Let me also think this through. Even if we define
SPECIAL, I am not sure what is the expected behavior though ..

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 30 Jun 2014 13:26:17 +0200

I agree with Bo's analysis concluding that IDENTICAL-PER-SSRC is likely 
not needed, and that situations where one has one SSRC in multiple media 
descriptions are probably a Bad Thing (I can't think of a case where it 
would represent anything but a bug).

IDENTICAL-PER-PT seems like a sensible thing to add.

On 06/23/2014 05:36 AM, Suhas Nandakumar wrote:
> 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.
>
> Packet Streams in a given RTP Session and MUST have identical values 
> when repeated across multiple media description for a given SSRC.
>
> 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)
>
> Notes: For a given codec the audio packetization time must be same if 
> the PT is repeated. This will ensure that the RTP receiver 
> 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.
>
> Thus if the RTP Payload Type used to specify fmtp parameters  is repeated, it MUST representthe same codec configuration.
> example:
> m=video ...
> a=rtpmap:98 VP8/90000
> *
> *
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic