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

From: [email-masked] (Dale R. Worley)
Date: Wed, 17 Apr 2019 21:59:41 -0400

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.

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.

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

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

Dale

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 18 Apr 2019 07:55:01 +0000

Hi Dale,

Thanks for the review.

> whether a single transport layer flow can include packets from multiple

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.

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

> or at least, that part of the figure should not mis-label them all as

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.

> rephrased.  I think it is supposed to mean "a specific encoding of a

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-masked]
----------------------------------------------------------------------