About BUNDLE with same payload-type values in different m= lines

Hi,

According to https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation:



   Multiple bundled "m=" lines might represent RTP based media.  As all
   RTP based media associated with a BUNDLE group belong to the same RTP
   session, in order for a given payload type value to be used inside
   more than one bundled "m=" line, all codecs associated with the
   payload type number MUST share an identical codec configuration.
   This means that the codecs MUST share the same media type, encoding
   name, clock rate and any parameter that can affect the codec
   configuration and packetization.
   [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
   attribute values must be identical for all codecs that use the same
   payload type value.



So, imagine a SFU scenario in which Alice and Bob sends H264 with same
payload type (100) and different codec parameters (packetization,
etc). And Carol wants to receive both video stream (from Alice and
Bob) over the same ICE/DTLS transport.

This means that the SDP received by Carol would have two m=video
lines, both with same payload type 100, same codec H264, and different
codec parameters.

This seems just loadable. Why not? Each m=video line represents, in
this case, a "RtpReceiver", and it indicates the proper a=mid and ssrc
values so the receiver (Carol) can demux them.

But AFAIU the above text stats that this scenario is not valid, do I
understand it correctly? If so... why?

I expected that the aim of Bundle was to remove the absurd requirement
of legacy SDP by which each "media track" needs a separate ICE/DTLS
transport. We have SSRC for demultiplexing. Why do we need artificial
constraints in the values of payload types within **different** media
sections?


If all this is true, then a SFU should override certain payload types
(in both SDP and RTP packets) which IMHO sholdn't be needed at all.

Do I miss something?

Thanks a lot.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Monday, 7 March 2016 20:32:51 UTC