Re: [MMUSIC] BUNDLE: no reason por payload type to be unique within bundled m= lines

[Iñaki Baz Castillo <[e-mail]>]

Thanks Magnus, some comments inline:


2016-03-08 14:44 GMT+01:00 Magnus Westerlund <[e-mail]>:
> And this is not only a specification issue. If you look at the RTCP
> processing one there are certain calculations that requires one to know the
> RTP payload type and things like the RTP clock rate to correctly process.
> The RTP specifications have been written under the assumption that these
> values are set on RTP session scope, rather than specific SSRCs.
>
> I would also note that there are in existence RTP based applications that
> really utilize the fact that PT values are configured on RTP session level,
> enabling new SSRCs to be used without prior signalling.
>
> From my perspective, the SIP/SDP usages of RTP prior to WebRTC and CLUE has
> been so constrained that this fact that PTs are set on RTP Session level has
> not mattered at all, as one has had basically one RTP stream per direction
> and RTP session. Now we have multiple RTP streams per direction and RTP
> session and it does matter.

While I understand the good rationale you provide, I think we should
evolve. WebRTC is no longer "bidirectional 1-to-1 audio streams".


> I don't see that we can change this without large amount of work. There are
> both specification assumptions as well as implementation assumptions on that
> PT are set on RTP session level. In addition such a change would make some
> existing RTP usages impossible. Resulting in that a change have significant
> implications, which requires both consideration and need for liaison with
> affected user groups.

OK, just please let me a simple question:


If 100 participants join the same SFU conference and all of them send
VP8 codec with payload 100 and same parameters, then each participant
will be provided with a SDP containing 100 (or 101) m=video sections
with a=sendonly, and each m=video MUST have a different payload type
(rewritten by the SFU) for the VP8 codec (for the same rationale given
above, as they belong to different video streams from different
participants).

...but there are just 96-127 dynamic payload values.

So in case of participants sending audio and video, should we state
that a WebRTC SFU conference can just handle (127-96+1)/2 = 16
participants?



-- 
Iñaki Baz Castillo
<[e-mail]>