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

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:
> 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
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>