Re: [MMUSIC] MMUSIC Virtual Interim Meeting dial in information

[Christer Holmberg <[e-mail]>]

Hi,

>>> 1)	How to demux RTP (and other media types, but RTP is the most critical). This is currently discussed within the "Plan A vs Plan B" context on the RTCWEB list.
>>
>> If we don't end up with the people in the call that are involved wight 
>> he proposals on this, I don't think we will be able to do this. I see 
>> it breaking into two different topics
>>
>> 1a) How to demux SCTP data channel stuff from RTP
>>
>> 1b) How to demux RTP
>
> I would cut this slightly differently:
>
> X) relevant ways of classifying packets received on a 5-tuple
> Y) relevant ways to use those attributes to associate each packet with
>    an m-line in a bundle
> Z) how to signal a choice from (Y) in SDP
>
> For X:
>
> There is one layer of classification that distinguishes DTLS from RTP from ICE.
>
> Then DTLS can further be classified into the stuff used for DTLS/SRTP keying, and DTLS payload packets.
>
> What the DTLS payload packets contain depends on what is layered on top of DTLS. The only case we are considering is SCTP. (But we may need to make provision for the possibility that something else might be.)
>
> SCTP packets can be demuxed by sctp port. (But there seems no interest in this.)
>
> RTP packets can be classified by at least SSRC and PT. We have also been discussed using an RTP extension header to provide another classification attribute.

For Y:

> I guess there is no intent to associate ICE packets with an m-line?

In my opinion there is no need to do so, as the ICE packets are for the whole bundled transport.

> RTP packets can be associated with an m-line based on SSRC *if* an a=ssrc line mentioning that SSRC is present in exactly one m-line of the bundle.

Yes.

> RTP packets can be associated with an m-line based on PT *if* that PT is present on exactly one m-line of the bundle.

Yes.

> RTP packets can be associated with an m-line based on the extension header *if* the value in that header is present in exactly one m-line of the bundle.

Yes.

> If none of the above work, then if some combination of the above is present in exactly one m-line then that can be used to do the association.

Yes. 

> DTLS payload packets can be associated with the collection of m-lines with proto of DTLS/* other than DTLS/SRTP.
>
> If all m-lines in the bundle with a proto of DTLS/* but not DTLS/SRTP are DTLS/SCTP, then they can be associated with a single 
> m-line based on SCTP port *if* there is exactly one m-line bound to that port. (This only works if there is a way to associate an SCTP port with a DTLS/SCTP m-line.

The question is really how flexible we really need to make bundle, when it comes to multiplexing different media types. The main usage is RTP, and from an RTCWEB perspective we also want the data channel, but maybe we can restrict ourselves to that in the core BUNDLE spec?

Then, if people later want to add protocol X to BUNDLE, they will have to specify how the multiplexing is done, which types of other protocols can be used in the same bundle group as X.

Also, I wonder whether it would be good to do things in steps. For example, first we should decide on X, Y and Z for RTP. I believe that is most critical, because even without BUNDLE we will have to do that - at least if we move forward with Plan B.

---------------------------


> For Z:
>
> Mostly implicit above: PT in m-lines, a=ssrc present with m-lines.
>
> We will need a new attribute for the new header value if that is to be supported.
>
> People didn't want to define a way to specify SCTP port with DTLS/SCTP. 
> Without that there can only be one DTLS/SCTP in a bundle. And that is probably fine.
>
> As long as there is only one DTLS/* proto other than DTLS/SRTP then all DTLS payload packets can go there, so it doesn't really need to be specialized for DTLS/SCTP.
>
> Clearly there can't be any UDP or DTLS protos in the bundle, or anything other than the above based on UDP.
>
> No additional SDP is needed to say how to classify *if* some combination of SSRC, PT, and new header value is unique for 
> each m-line. But we may need something else to indicate how to classify any packets that don't match. (E.g., an SSRC that is not 
> mentioned in the SDP.)

Yes.

Whatever we intend to use SSRC for, we need to be clear on:

1) Can we assume that the SSRC value will always be signaled in SDP?

2) Can we assume that the media actually uses the SSRC value that was changed in SDP (read: if the SSRC value changes, will there be an updated offer with the new SSRC value)?

Regards,

Christer