Subject: [MMUSIC] Comment on Payload type restriction in draft-ietf-mmusic-sdp-bundle-negotiation-03

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Apr 2013 09:52:54 +0200

WG,

In RTCWEB WG we had a discussion regarding a limitation in BUNDLE. I
think this shall be changed for the reasons that is evident in the
forwarded email.

Magnus Westerlund

Subject: Re: [rtcweb] #15: Section 4.8: SSRC signaling
From: Magnus Westerlund <[email-masked]>
To: "Mo Zanaty (mzanaty)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Wed, 24 Apr 2013 09:50:57 +0200
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>

Thanks,

I fully support this argument, why you can't start using the PT as an
identifier to which purpose or specific negotiated set of constraints
within a common RTP session this SSRC relates to.

I would however note that this discussion would be better to hold on the
MMUSIC list, especially as it does apply to a statement in BUNDLE which
I believe must be changed:

Se Section 7.2 of draft-ietf-mmusic-sdp-bundle-negotiation-03

 o  - The dynamic payload type values used in the "m=" lines MUST NOT
      overlap.

This restriction I think must be changed. I will now forward this email
to MMUSIC as comment on BUNDLE.

Cheers

Magnus

On 2013-04-23 23:03, Mo Zanaty (mzanaty) wrote:
> You can easily exhaust the dynamic payload type number space (96-127)
> with only a few media lines, not 30. Keep in mind the primary purpose
> of payload type is to negotiate codecs, not demux different streams.
> An offer from a highly interoperable product will contain many
> payload types for each stream. It is not uncommon to support 8+
> payload types and 4+ streams, which quickly exhausts the dynamic
> space. Also keep in mind that many codecs have different
> configurations that are expressed as different payload types, so even
> supporting a single audio and video codec can yield many payload
> types if those codecs are highly configurable.
> 
> Consider a very simple product (smartphone) in a very simple use case
> (3-way video chat). It supports several audio codecs (OPUS, AAC-LD,
> AMR-WB, AMR-NB, G.711) and several video codecs (VP8, VP9, H.264,
> H.265). It supports several H.264 profiles (BP, HP, SBP, SHP) and
> packetization modes (0, 1). This already exhausts all 32 dynamic
> payload types, before we even consider things like FEC, scalable or
> simulcast layers sent via MST, screen sharing, multiple cameras,
> etc.
> 
> So I would strongly discourage folks from assuming payload type demux
> is viable in most use cases. It may be viable when there is a single
> audio and video stream, each using a single codec and configuration.
> But it quickly becomes impractical or impossible when the product
> gets more capable or the use case gets more interesting.
> 
> Mo
> 
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Dale R. Worley Sent:
> Tuesday, April 23, 2013 2:58 PM To: [email-masked] Subject: Re:
> [rtcweb] #15: Section 4.8: SSRC signaling
> 
>> From: Martin Thomson <[email-masked]>
>> 
>> On 22 April 2013 15:15, Dale R. Worley <[email-masked]> wrote:
>>> My understanding is that associating an incoming RTP packet with
>>> an m= line is a solved problem -- the transport association on
>>> which the packet arrives determines the bundle, and (within all
>>> of the currently active bundling proposals) the payload type
>>> tells which m= line within the bundle.
>> 
>> Not so.  If you have five PTs on each m= line, and 30 m= lines,
>> you just don't have that many PTs available.  At some point you
>> have to recognize that SSRC is what you have to use.  (Neither
>> number is extraordinary.)
> 
> But why would you use 30 m= lines?  You'd only have 30 streams in a 
> videoconference-type situation, where the streams don't have
> distinct roles and so don't need to be given role labels.  As far as
> I know, current videoconference systems don't put each video stream
> in a separate m= line.
> 
> Dale _______________________________________________ rtcweb mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb 
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Apr 2013 11:01:10 -0400

I agree that this restriction needs to be reconsidered.

But this is just part of the more general issue of how the contents of a 
bundle are demultiplexed. There have been a number of demux mechanisms 
proposed:

- Payload type *has* been proposed as one mechanism.
   In those cases where it is to be used to map an RTP packet to a
   particular m-line then indeed the payload type restriction needs
   to apply.

- SSRC has been proposed as another mechanism.
   When SSRCs are declared in SDP per m-line, then those can be
   used map RTP packets to m-lines. In this case the payload type
   restriction isn't needed. But we then need a restriction that
   an SSRC can only appear in one m-line of the bundle.

- A special new RTP header extension has been proposed as another
   mechanism. To be used to map packets to m-lines it will need to
   be declared somewhere - probably as a new media-level sdp attribute.
   If this is used for the demux then we don't need the PT restriction,
   but we will need a restriction that this new value can only be
   declared in one m-line per-bundle.

- the draft doesn't currently talk at all about including the
   m-line for the SCTP association for data channels in the bundle,
   but people expect it. There is a special mechanism for demuxing
   those packets from RTP. But that mechanism is limited to SCTP
   over DTLS. And it is limited to a single SCTP association in the
   bundle.

ISTM that there must be specification of:
- the demux mechanisms that are available,
- how they work,
- how they do or don't coexist with one another,
- and how they are signaled in SDP.

The list of available demux mechanisms may need to be extensible.
And the bundle mechanism should be designed to accommodate that.

	Thanks,
	Paul

On 4/24/13 3:52 AM, Magnus Westerlund wrote:
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Apr 2013 15:32:42 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

In regard to demultiplexing by payload type (and related tests, that
is, RFC 5764) and demultiplexing by a "shim" or encpapsulation RTP
format, here is a start:
http://tools.ietf.org/html/draft-worley-sdp-bundle-06#section-8

Dale