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

I think your scenario is not valid, but it is because of the rule that
one PT must represent one configuration within one RTP session.

This is an MMUSIC restriction, from the BUNDLE document.

It is not a concern that the WEBRTC WG can address.


Den 07. mars 2016 21:31, skrev Iñaki Baz Castillo:
> 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.
>

Received on Wednesday, 9 March 2016 19:31:18 UTC