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

From: Jonathan Lennox <[email-masked]>
Date: Tue, 1 Jul 2014 14:57:39 +0000

On Jun 22, 2014, at 11:36 PM, Suhas Nandakumar <[email-masked]<mailto:[email-masked]>> 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.

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 1 Jul 2014 15:07:24 +0000

On Jun 30, 2014, at 7:26 AM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:

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

The use case for it, I think, would be a scenario where a single RTP packet stream can satisfy the intended semantics of more than one media description.

My usual example is when I am in a conference, viewing both the current loudest speaker and also a specific person (say, my boss, or the customer).  I send two separate media descriptions requesting both those items.

During those times when that specific person is the loudest speaker, the server can save bandwidth by sending the single RTP packet stream carrying that person’s video only once.  It sends the same SSRC in both media descriptions to indicate that that packet stream is intended to be consumed by both of them.

Now, maybe we don’t want to support this use case, or maybe we want to support it in some way other than SDP-based signaling (as being too heavyweight for moving SSRCs around on the timescale of loudest-speaker timescale switching).  But we should make that decision explicitly.

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

On 06/23/2014 05:36 AM, Suhas Nandakumar wrote:
Hello All

Attribute: a=framerate

Attribute: a=rtpmap

Attribute: a=fmtp

Attribute: a=rtcp-fb
Mux Category: NORMAL

"

example:

m=video ...

a=rtpmap:98 VP8/90000

m=video ...

a=rtpmap:98 VP8/90000

Attribute: a=imageattr

Attribute: a=framesize

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

Cheers
Suhas Nandakumar

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 01 Jul 2014 17:38:25 +0200

On 07/01/2014 05:07 PM, Jonathan Lennox wrote:
>> 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).
>
> The use case for it, I think, would be a scenario where a single RTP 
> packet stream can satisfy the intended semantics of more than one 
> media description.
>
> My usual example is when I am in a conference, viewing both the 
> current loudest speaker and also a specific person (say, my boss, or 
> the customer).  I send two separate media descriptions requesting both 
> those items.
>
> During those times when that specific person is the loudest speaker, 
> the server can save bandwidth by sending the single RTP packet stream 
> carrying that person’s video only once.  It sends the same SSRC in 
> both media descriptions to indicate that that packet stream is 
> intended to be consumed by both of them.
>
> Now, maybe we don’t want to support this use case, or maybe we want to 
> support it in some way other than SDP-based signaling (as being too 
> heavyweight for moving SSRCs around on the timescale of 
> loudest-speaker timescale switching).  But we should make that 
> decision explicitly.

If we want to support that scenario, we also need to make the app-id 
token used for association between an RTP packet and an m-line 
multivalued. It seems to me that we've so far just assumed that it's 
single-valued.

I can see the logic in wanting to support such a scenario, but I am 
afraid of finding that there are more places than I can think of where 
we've implicitly made the opposite assumption (app-id was only the first 
one I could think of).