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

[Magnus Westerlund <[e-mail]>]

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

--- Begin Message ---

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: [e-mail]
> [mailto:[e-mail]] On Behalf Of Dale R. Worley Sent:
> Tuesday, April 23, 2013 2:58 PM To: [e-mail] Subject: Re:
> [rtcweb] #15: Section 4.8: SSRC signaling
> 
>> From: Martin Thomson <[e-mail]>
>> 
>> On 22 April 2013 15:15, Dale R. Worley <[e-mail]> 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 [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb 
> _______________________________________________ rtcweb mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------

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

--- End Message ---