Subject: [avtext] Comments on draft-ietf-avtext-splicing-for-rtp-04

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Jan 2012 16:18:17 +0100

Hi,

In my role as document shepherd I was reviewing the draft to ensure that
I could personally stand for the content of the document as WG output. I
have however some issues I would like to discuss with the WG if we
shouldn't address prior to requesting publication. I should have brought
these up during the WG last call if I had been able to review it then.
So please consider if these issues should be resolved or not. I hope the
author can provide more complete text changes where he agrees it would
benefit the text to change.

1. Section 4 and forward: CSRC handling in mixer. Yes, CSRC list with
original source are a good debugging tool and a preventer of loops.
However, I don't think any splicer targeted to content delivery will
ever include the CSRC. It is more likely in use cases like conferencing.
Thus I think the document needs to make it clear that CSRC list is an
optional feature that can help in debugging and loop prevention but
otherwise isn't needed.

2. section 4.1:
  "When splicing begins, mixer chooses the substitutive RTP stream as
   input stream at splicing in point, extracts the payload data (i.e.,
   substitutive content), encodes substitutive content and outputs it
   instead of main content in the current media stream.  Moreover, mixer
   inserts the SSRC of substitutive RTP stream into CSRC list in the
   current media stream."

As an mixer can perform media mixing and especially splicing without a
transcoding cycle by simple copy the payload from the incoming packet
and the translate only the RTP header information i think the use of the
word "encode" in the above sentence and also in the pseudo code are
possibly misleading to implementors.

I would suggest that one first explain possible alternative for the
media handling and translation into outgoing RTP packets. Then give that
a term an indicates that in the suitable places in the text.

3. Section 4.2:

  "Based on above RTCP operating mechanism, the media source will see
   the reception quality of its stream received by mixer, and the
   reception quality of spliced stream received by RTP receiver."

Sorry, I don't see how the text before this paragraph leads to the
paragraphs conclusions. One of the confusion is that it doesn't make it
clear which media source is reported or some other assumptions.

First, are you assuming that the splicer sends RRs using the splicers
own SSRC on the received stream in addition to the SSRC of the receiving
client?

If it does, I can understand the above, but I think it must be made clear.

If not, then there is something different missing. Maybe depending or time?

I am assuming the goal is to have the main media source learn the full
paths behavior during period of the main content being delivered and the
path to the splicer during periods when the substitute content is being
delivered.

4. Section 4.3:
   At the splicing in point, mixer can fill the substitutive content up
   receiver's buffer with several seconds earlier than the presentation
   time of substitutive content so that smooth playback can be achieved
   without pauses or stuttering on RTP receiver.

I think there is some language error in this paragraph. Is the goal to
say this?

   At the splicing in point, the mixer can fill up the receiver's
   buffer with substitute content several seconds earlier than the
   presentation time of substitutive content so that smooth playback
   can be achieved without pauses or stuttering on RTP receiver.

If that is the goal I think the splicing needs to keep to a similar
transmission schedule to the main content. In cases of traffic shaping
and advance transmission scheduling this becomes a challenge.

5. Section 4.3:
   The case that insertion
   duration is shorter than the reserved gap time may cause a little
   playback latency of main RTP stream on RTP receiver, but not
   adversely impact the quality of user experience.

The splicer could also have some "filler" content, like an all black
sequence that it can insert.

6. Section 4.3:
However, in case
   that insertion duration is longer than the reserved gap duration,
   there exists an overlap of the substitutive RTP stream and the main
   RTP stream at splicing out point.  In such case, mixer may take a
   ungracefule action, terminating the splicing and switching back to
   main RTP stream even if this may cause media stuttering on receiver

Please note missing ".".

However, I would like to comment on the potentially more graceful
operation of delaying the main content by buffering main content for a
time equal to the time of the overrun. That of course have some impact
on the user also, like when they here the soccer goal before they see it
by the hurrays from their neighbors.

7. Section 4.4
>From above analysis, to reduce the risk of congestion and remain the
   bandwidth consumption stable over time, the substitutive RTP stream
   is RECOMMENDED to be encoded at an appropriate bitrate to match that
   of main RTP stream.

I think this is the first usage of RFC2119 language in the technical
description and guidance on how splicing can be done, i.e. outside of
the requirements. I think this document as being informational should
not use RFC 2119 language unless it quotes other standards track
specifications. So please change this to a lower case.

8. Section 4.5:

   Compared to above user visibility case, the primary difference in
   this case is mixer MUST NOT include CSRC list in outgoing packets
   (i.e., CSRC count field is set to zero and CSRC list fields are
   absent).

another case of RFC 2119 language, I think this is pretty straight
forward to change so that it becomes clear that in case one include the
CSRC list it becomes obvious that a receiver can detect the splice.

9. Section 6:

If any payload internal security mechanisms (e.g., SSH, SSL etc) are
   used, only media source and RTP receiver can learn the security
   keying material generated by such internal security mechanism, any
   middlebox (e.g., mixer) between media source and RTP receiver can't
   get such keying material.

I think the examples of internal security mechanism are all wrong. I
don't either SSH or SSL really are used inside RTP payloads. What is a
reality is ISMAcrypt. I would recommend using that as an example and
include a reference.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Xiajinwei <[email-masked]>
Date: Fri, 27 Jan 2012 05:25:40 +0000

Hi Magnus,

Sorry for my delay, I am in Chinese holiday. Thank your review, your comments all are reasonable for me, please see my answer inline. Hope I can address your concerns.

[snip]

> optional feature that can help in debugging and loop prevention but

How about modify it as following text:

" Moreover, mixer may include the CSRC list in outgoing packets to indicate the source(s) of content in some use cases like conferencing, this facilitates the system debugging and loop detection."

> a term an indicates that in the suitable places in the text.

To eliminate the ambiguity, I would like to use "encapsulate" to replace "encode". Also, I elaborate the description of splicing end, pseudo code as well. For example,

" When splicing begins, mixer chooses the substitutive RTP stream as input stream at splicing in point, and extracts the payload data (i.e., substitutive content). After that, mixer encapsulates substitutive content instead of main content as the payload of the current media stream, and then outputs the current media stream to receiver. Moreover, mixer may insert the SSRC of substitutive RTP stream into CSRC list in the current media stream. During this period, main RTP packets may continuously arrive at mixer, but mixer will not output main content to downstream receiver. "

Is above description acceptable?

> clear which media source is reported or some other assumptions.

How does mixer process RTCP it received and forward is an crucial point in this section. I think I should make it clearer.

> If it does, I can understand the above, but I think it must be made clear.

I would separate RTCP processing into two parts, one is mixer processes and forwards RTCP report sent by receiver (using SSRC of receiver), another is mixer generates its own RTCP report to original media source (using SSRC of mixer). I will revise this section to make it clearer.

> path to the splicer during periods when the substitute content is being

Yes, the media source should learn the situation of spliced stream on receiver when its content is being passed to receiver, and the situation of its stream terminated on mixer. The media source, whose content is not being passed to receiver, will only see the reception quality of its stream received on mixer. I copy the revised section 4.2 as following.

" 4.2.  RTCP Processing in RTP Mixer

   By monitoring available bandwidth and buffer levels and by computing
   network metrics such as packet loss, network jitter, and delay, RTP
   receiver can learn the situation on it and can communicate this
   information to media source via RTCP reception reports.

   According to the description in section 7.3 of [RFC3550], mixer
   divides RTCP flow between media source and receiver into two separate
   RTCP loops, media source probably has no idea about the situation on
   receiver.

   Hence, mixer can use some mechanisms, allowing media source to at
   least some degree to have some knowledge of the situation on receiver
   when its content is being passed to receiver.

   Because splicing is a processing that mixer selects one media stream
   from multiple streams rather than mixing or transcoding them, upon
   receiving a RTCP receiver report from downstream receiver, mixer can
   forward it to original media source with its SSRC identifier intact
   (i.e., the SSRC of downstream receiver).  The number of output
   current RTP packets containing main content or substitutive content
   is equal to the number of input main RTP packets or substitutive RTP
   packets, so it does not need to modify loss packet fields in Receiver
   Report Blocks unless the reporting intervals spans the splicing
   point.  But mixer needs to change the SSRC field in report block to
   the SSRC identifier of original media source and rewrite the extended
   highest sequence number field to the corresponding original extended
   highest sequence number before forwarding the RTCP receiver report to
   original media source.

   When a RTCP receiver report spans the splicing point, it reflects the
   characteristics of the combination of main RTP packets and
   substitutive RTP packets, in which case, mixer needs to divide the
   receiver report into two separated receiver reports and send them to
   their original media sources respectively.  For each separated
   receiver report, mixer also needs to make the corresponding changes
   to the packet loss fields in report block besides the SSRC field and
   the extended highest sequence number field.

   Meanwhile, mixer can also allow media source to learn the situation
   of its stream terminated on mixer since mixer acts as RTP receiver
   for its stream.  Mixer generates RTCP receiver report relating to the
   RTP stream it terminates using its own SSRC, and sends the RTCP
   receiver report towards the media source.

   Based on above RTCP operating mechanism, the media source, whose
   content is being passed to receiver, will see the reception quality
   of its stream received on mixer, and the reception quality of spliced
   stream received on receiver.  The media source, whose content is not
   being passed to receiver, will only see the reception quality of its
   stream received on mixer.

   If the substitutive content comes from local media file storage (
   i.e., mixer can be regarded as the substitutive media source), the
   reception reports received from downstream relate to the substitutive
   content should be terminated on mixer without any further processing. "

>    can be achieved without pauses or stuttering on RTP receiver.

Yes, I will revise it in next version.

> sequence that it can insert.

It is an alternative. I will add one sentence

" One alternative approach is that mixer may pad some blank content (e.g., all black sequence) to fill up the gap. "

>    main RTP stream even if this may cause media stuttering on receiver

Will add it.

> by the hurrays from their neighbors.

I can add this buffering approach as an alternative, but this approach make splicing a bit of complicated compared to directly switch.

" However, in case that insertion duration is longer than the reserved gap duration, there exists an overlap of the substitutive RTP stream and the main RTP stream at splicing out point. One straightforward approach is that mixer takes a ungracefule action, terminating the splicing and switching back to main RTP stream even if this may cause media stuttering on receiver. There is another approach which may be mild but somewhat complex, mixer buffers main content for a while until substitutive content is finished, and then transmits buffered main content to receiver at an acceleated bitrate (as compared to the nominal bitrate of main RTP stream) until its buffer level returns to normal. At this point in time, mixer transmits main content to receiver at an nominal bitrate of main RTP stream. Note that mixer should take into account a variety of parameters, such as available bandwidth between mixer and receiver, mixer buffer level and receiver buffer level, prior to counting the accelerated bitrate value."

> specifications. So please change this to a lower case.

I will replace "RECOMMENDED " with "had better" or "may".

> CSRC list it becomes obvious that a receiver can detect the splice.

I will revise it as following way.

" Mixer will not includes CRSC list in outgoing RTP packets to prevent user from detecting the splicing occurred on RTP level. "

> reality is ISMAcrypt. I would recommend using that as an example and

Agree, it is a obviously inappropriate example. I will change it to ISMACryp and add a reference.

Hope I can address your concerns.

Happy Chinese New Year!

Jinwei