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

[Bo Burman <[e-mail]>]

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.

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

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.


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.




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

Cheers
Suhas Nandakumar