Re: [AVTCORE] Last call review of draft-ietf-avtcore-multiplex-guidelines-08

Hi Dale,

Thanks for the review.

On 2019-04-18 03:59, Dale R. Worley wrote:
> I was perusing draft-ietf-avtcore-multiplex-guidelines-08 and noticed
> this sentence in section 3.2.1:
>
>    A single
>    endpoint can have one or more transport flows for the same RTP
>    session, and a single RTP session can span multiple transport layer
>    flows.
>
> The two clauses of this sentence say the same thing:  an RTP session can
> encompass multiple transport layer flows.  But it doesn't clarify
> whether a single transport layer flow can include packets from multiple
> RTP sessions.

The second part was intended to indicate that it may be multiple
transport connections in sequence. If you look at
https://datatracker.ietf.org/doc/rfc7667/ you will get a more complete
picture of what is possible.

And one can not have multiple RTP sessions on the same transport flow
without some additional extension.

>
> Also, the top section of Figure 1 is unclear to me.  The section "RTP
> Session" includes a box named "Socket", but from the box are arrows
> labeled "RTP/RTCP", "STUN", and "SCTP".  But "SCTP" has a different
> protocol number than UDP, and so it has a different socket-number space,
> and an SCTP flow cannot share a socket with RTP, RTCP, or STUN.

This is the RTCWeb Stack where in fact SCTP over DTLS is multiplexed
over the same UDP transport flow as RTP. This demultiplexing is hack but
a working one. It is documented in Section 5 of RFC 5764
(https://datatracker.ietf.org/doc/rfc5764/)  and clarified in RFC 7983
(https://datatracker.ietf.org/doc/rfc7983/).

As a side comment it is actually possible to use SCTP directly on UDP if
one wanted, one simply have to assign the SCTP port numbers so that this
demultiplexing works.

>
> The top level of demultiplexing is by protocol number, which separates
> SCTP from UDP.  Then there is demultiplexing within a protocol based on
> socket number.  And beneath that is separation of "STUN (multiplexed
> using same port)" from "RTP/RTCP", based on the UDP payload contents.
> These three layers of dempltiplexing need to be clearly distinguished,
> or at least, that part of the figure should not mis-label them all as
> functions of "socket".

So, I think what is need is a clarification that Figure 1 depicts an RFC
5764 scenario according to the above and change SCTP to DTLS.


>
> In section 3.2.4 is
>
>    The combination of SSRC and PT therefore identifies a specific RTP
>    stream encoding format.
>
> But the next paragraph makes clear that with an RTP session, the PT
> space is the same for all SSRCs.  So the above sentence should be
> rephrased.  I think it is supposed to mean "a specific encoding of a
> specific RTP stream".

Correct.

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------


_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt