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

On 5/21/13 10:22 AM, Cullen Jennings (fluffy) wrote:
>
> On May 21, 2013, at 8:00 AM, Ari Keränen <ari.keranen@ericsson.com> wrote:
>
>>
>> 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?

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.

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.

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.

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.

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.

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.)

	Thanks,
	Paul

> Cullen (and to be clear all my emails on this list are in my individual contributor role)
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>