Subject: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05

From: Magnus Westerlund <[email-masked]>
Date: Fri, 30 Jan 2015 16:39:27 +0100

Hi,

I have just reviewed draft-ietf-avtext-rtp-grouping-taxonomy-05 and
think it is in good shape. However, I do have some few comments and
reflections for the WG to consider.

1. The case when there are no source RTP stream, only redundancy RTP
streams. This relates to two different sections:

2.1.12.  Redundancy RTP Stream

   A RTP Stream (Section 2.1.10) that contains no original source data,
   only redundant data that may be combined with one or more Received
   RTP Stream (Section 2.1.19) to produce Repaired RTP Streams
   (Section 2.1.22).

2.1.21.  RTP-based Repair

   RTP-based Repair is a Transformation that takes as input one or more
   Received RTP Streams (Section 2.1.19) and Received Redundancy RTP
   Streams (Section 2.1.20), and produces one or more Repaired RTP
   Streams (Section 2.1.22) that are as close to the corresponding sent
   Source RTP Streams (Section 2.1.10) as possible, using different RTP-
   based repair methods, for example the ones referred in RTP-based
   Redundancy (Section 2.1.11).

I think the formulation is likely to allow for this case when one
applies a FEC transform that results in no source RTP stream only
redundancy symbols that are encoded into a Redundancy RTP stream.

In 2.1.12 the important part is: ... only redundant data that may be
combined with one or more Received RTP Stream (Section 2.1.19) ...
The "may" here allows the case for no other stream to combine it with.

In 2.1.21 the text I react to is: "... that takes as input one or more
   Received RTP Streams (Section 2.1.19) and Received Redundancy RTP
   Streams (Section 2.1.20), ..."

This text is not super clear that what we are talking about are
1*(Recevied_RTP_Stream | Received_Redundancy_RTP_Stream)

It is not that the case for no source stream is ruled out, but it also
not clear and thus easily missed that this may occur. So either some
informative sentence about this case, or maybe clarifying in 2.1.21 that
it is zero or more Received RTP Streams and 1 or more Received
Redundancy RTP to create a Repaired RTP stream.

2. Figure 6:

      +------------------------------------------------------------+
      | Communication Session                                      |
      |                                                            |
      | +----------------+                      +----------------+ |
      | | Participant A  |    +------------+    | Participant B  | |
      | |                |    | Multimedia |    |                | |
      | | +-------------+|<==>| Session    |<==>|+-------------+ | |
      | | | Endpoint A  ||    |            |    || Endpoint B  | | |
      | | |             ||    +------------+    ||             | | |
      | | | +-----------++----------------------++-----------+ | | |
      | | | |            |                      |            | | | |
      | | | | RTP Session|---Media Transport--->|            | | | |
      | | | | Audio      |<---Media Transport---|            | | | |
      | | | |            |          ^           |            | | | |
      | | | +-----------++----------|-----------++-----------+ | | |
      | | |             ||          v           ||             | | |
      | | |             || +-----------------+  ||             | | |
      | | |             || | Synchronization |  ||             | | |
      | | |             || |     Context     |  ||             | | |
      | | |             || +-----------------+  ||             | | |
      | | |             ||          ^           ||             | | |
      | | | +-----------++----------|-----------++-----------+ | | |
      | | | |            |          v           |            | | | |
      | | | | RTP Session|<---Media Transport---|            | | | |
      | | | | Video      |---Media Transport--->|            | | | |
      | | | |            |                      |            | | | |
      | | | +-----------++----------------------++-----------+ | | |
      | | +-------------+|                      |+-------------+ | |
      | +----------------+                      +----------------+ |
      +------------------------------------------------------------+

What I am reacting to is that the Media Transports are terminated
against the Participant line rather than the endpoint line. I would
prefer that they would terminate at that level.

This could look like this:

      +------------------------------------------------------------+
      | Communication Session                                      |
      |                                                            |
      | +----------------+                      +----------------+ |
      | | Participant A  |    +------------+    | Participant B  | |
      | |                |    | Multimedia |    |                | |
      | | +-------------+|<==>| Session    |<==>|+-------------+ | |
      | | | Endpoint A  ||    |            |    || Endpoint B  | | |
      | | |             ||    +------------+    ||             | | |
      | | | +-----------++----------------------++-----------+ | | |
      | | | |           ||                      ||           | | | |
      | | | |RTP Session|----Media Transport---->|           | | | |
      | | | |Audio      |<---Media Transport-----|           | | | |
      | | | |           ||          ^           ||           | | | |
      | | | +-----------++----------|-----------++-----------+ | | |
      | | |             ||          v           ||             | | |
      | | |             || +-----------------+  ||             | | |
      | | |             || | Synchronization |  ||             | | |
      | | |             || |     Context     |  ||             | | |
      | | |             || +-----------------+  ||             | | |
      | | |             ||          ^           ||             | | |
      | | | +-----------++----------|-----------++-----------+ | | |
      | | | |           ||          v           ||           | | | |
      | | | |RTP Session|<---Media Transport-----|           | | | |
      | | | |Video      |----Media Transport---->|           | | | |
      | | | |           ||                      ||           | | | |
      | | | +-----------++----------------------++-----------+ | | |
      | | +-------------+|                      |+-------------+ | |
      | +----------------+                      +----------------+ |
      +------------------------------------------------------------+

3. Section 2.2.1

   o  An Endpoint can be associated with at most one Participant
      (Section 2.2.3) at any single point in time.

   o  In some contexts, an Endpoint would typically correspond to a
      single "host", for example a computer using a single network
      interface and being used by a single human user.

I think we might need to clarify how one should consider endpoints in
the following scenario.

A multi-user host, where two participants are communicating with each
other using T.140 text (To avoid i/o issues of multi-user environments).
The first bullet above requires then this host two have two endpoints. I
think the current intuitive feeling for endpoint is that is it can be
identified by an network address. However, if the above case are two
endpoints they may actually have the same network address.

I believe the most simple solution going forward would be to make it
clear that in some cases there be multiple endpoints at a single host. I
would propose to add to the second bullet above the following:

    In other contexts, a single 'host' can serve multiple Participants,
    in which case each Participant's Endpoint may share properties, for
    the IP address part of a transport address.

4. section 3.5:

   2.  In Multi-Session Transmission (MST), the SVC Media Encoder sends
       Encoded Streams and Dependent Streams distributed across multiple
       RTP Streams in one or more RTP Sessions.

and

   MST denotes one or more RTP Streams (SSRC) per Media Source
   in each of multiple RTP Sessions.

Is these two sentence really consistent. It is less than clear that
"multiple" is equivalent to "one or more".

5. section 3.5:

I wonder if we should at this stage create a special version of MRMT
which has one and only one RTP stream per Media Source and media
transport? The reason for such a one is exactly the discussion held in
Section 3.8 about using the same SSRC value in multiple RTP sessions.

6. Section 3.7:

As MDC is used in three places only, I think a reference is needed for
the occurrence here in Section 3.7 back to Section 2.1.6.

I will be away next week, so I will follow up on this after the 8th of
February.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------