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

[Jonathan Lennox <[e-mail]>]

On Jun 22, 2014, at 11:36 PM, Suhas Nandakumar <[e-mail]<mailto:[e-mail]>> wrote:

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.

As a framework, this makes sense to me.

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.

This is a bit complicated by the fact that a=ptime and a=maxptime attributes don’t actually specify PTs.  Does this mean that if two m-lines share *any* PTs, then their a=ptime and a=maxptime values must match?

That’s fine, but it’s a somewhat different semantic than for attributes that explicitly list their PT values.

I wonder if we need to have a separate IDENTICAL-IF-SHARED-PT mix category?

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

Similar, IDENTICAL-IF-SHARED-PT, I think.

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

Yes.


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

Yes.

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

Yes.

In this, I disagree with Bo.  I think it may be reasonable to have two streams, one of which supports NACK (say), and another one which does not.

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.

Yes.


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

No, that’s not what that section of RFC 5576 meant.  Since this was pre-BUNDLE, media streams were the same as RTP sessions, so this was just saying that SSRCs in different RTP sessions aren’t related.

The purpose of fmtp as a source attribute was specifically to make it possible to send different attributes of streams even if they have the same PT — the specific motivation was H.264 sprop-* parameters.  So it would make me somewhat sad (as the inventor of fmtp as a source attribute) to make this IDENTICAL-PER-PT — I’d rather have it IDENTICAL-PER-SSRC-AND-PT (which probably actually means SPECIAL).

That said, no work to actually define fmtp source attributes for any media formats has actually gone anywhere — I published draft-lennox-avt-h264-source-fmtp-00 seven years ago, but it didn’t get any traction.  So maybe no one cares, and this should just be deprecated.


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

Yes.

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

Yes.

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

Yes.

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

Don’t know these well enough.