Subject: [avtext] comments on draft-xia-avtext-splicing-for-rtp-00

From: Magnus Westerlund <[email-masked]>
Date: Mon, 28 Mar 2011 11:01:50 +0200

Hi,

I have reviewed this document and have some comments.

1. Structure of the document issues:
a. I am missing an applicability statement that discusses which cases of
topologies the splicer functions in.

b. Not clear separation of section 3 and 4, both appears to contain
normative statements on how things should function in both. If the
intention is requirements and specification, then I think it needs to be
clearer separation.

2. I am also missing a discussion on the RTP timestamp handling issues.
That clearly also needs to be covered to ensure that the receiver gets a
consistent stream.

3. I also see a clear issue for a translator to deal with the RTCP
translations towards the main source. My understanding is that the
splicer will need to translate any RTCP Report blocks coming from down
stream to the splicer, even when the substitute content is being
forwarded by the splicer. I can see how this can be made to work if
there are no media adaptation happening. But if the media streams are
being adapted then this becomes problematic. This as any feedback
relates to the stream actually being sent. So the translated RTCP needs
to report to the main stream how the main stream would fair down stream
of the splicer, without actually having sent it. I don't see how this
can be done in a reasonable and robust way.

For example if the substitute stream is higher bandwidth than the main
stream and that stream is being reported as causing congestion. Then
what does one report to the main stream sender? Because one can't know
if that stream would cause congestion. Can someone please explain how to
support this case.

I starting to think that a mixer model might be better. Yes, that
separates the flows. And for adaptation there might actually be need for
support of special mechanism to provide upstream information, like TMMBR
to cap the bandwidth.

4.  Section 3, requirement comments:

REQ-1: Splicer MUST operate in either unicast or multicast session
      environment.

Shouldn't this be worded as:
      Splicer MUST be able operate in both unicast or multicast session
      environment.

REQ-2: The RTP packets whose payloads are replaced by substitutive
      content are required to keep their RTP header information to be
      consistent with those of main RTP packets whose payloads are
      unaltered.

I think "Keep" is the wrong word here. I think resulting in a consistent
stream.

REQ-2:  "The value of SSRC field in RTP header MUST be same as the value
         of corresponding field in main content RTP header, while the
         value of payload type field SHOULD be same as the value of
         corresponding field in main content RTP header.  Note that in
         some cases, it may be necessary to transcode the substitutive
         content to ensure the payload type is the same, and that this
         may be prohibitively expensive, so it might be acceptable to
         leave the payload untranscoded."

First, I think this isn't requirements, they are how one should
implement it.  I also think, one could clarify that if one has signalled
the different RTP payload types then one can actually switch between
them. IF that is supported by client depends on the usage.

REQ-4: Splicer MUST be backward compatible with basic characteristics of
      [RFC3550], e.g., SSRC identifier collision resolution and loop
      detection.

Shouldn't this also include certain RTP extensions also?

REQ-5: Splicer MUST have the capability to correctly handle any packet
      loss events regardless of whether the lost content is main content
      or substitutive content.

Would it be better to formulate this as "not add extra impact of any
packet loss events regardless of whether the lost content is main
content or substitutive content

Section 5, first paragraph on page 8. I would consider writing some
psudo code for these translation cases.

Section 6. "Even if no new substitutive content will be inserted,
   the Translator still needs to modify the main RTP packets, and to
   recalculate the UDP/IP checksum until the main RTP session ends. If
   Translator serves multiple main RTP streams simultaneously, this may
   lead to large overhead on the Translator."

I don't think this translation is any form of extreme case of burden.
Yes, you will need to update both some RTP header fields. Well, you
anyway would need to update the address fields and that is part of the
pseudo header anyway. So you can't do relaying without paying this cost.
And there are hardware off-loading for UDP checksums.

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: Jinwei Xia <[email-masked]>
Date: Tue, 29 Mar 2011 00:32:12 +0800

Hi Magus,

Thanky your valuable comments, please see my comments inline.

----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: <[email-masked]>; "Jinwei Xia" <[email-masked]>
Sent: Monday, March 28, 2011 5:01 PM
Subject: comments on draft-xia-avtext-splicing-for-rtp-00

> topologies the splicer functions in.

We once gave the target advertisement insertion use case in which the splicicing is mainly used in previous problem statement draft. I can add the use case content in next version.

> intention is requirements and specification, then I think it needs to be

hmm, in section 4, I just tried to emphasize that translator has the capability to satisfiy the the requirements listed in section 3, and give the exact guidance how translator works in section 5. Indeed, section 3 and section 4 have tight relationship which easily causes confusing, thus I will combine them in single requirement setcion in next version.

> That clearly also needs to be covered to ensure that the receiver gets a

Very good question, the timestamp of main stream RTP packet is keep intact, the timestamp of substitutive RTP packet is calculated by Translator based on how many substitutive packets are outputted to user during specific time. I will add related description in next version.

> if that stream would cause congestion. Can someone please explain how to

When detecting the ECN notification message during splicing period, translator intercepts them, discards the feedback messages or remove XR parts in RR because it knows the congestion is caused by substitutive content rather than main content. how does the translator execute media adaptation is inner implementation. 

Discarding ECN feedback message indeed is a additional requirement for translator. Can translator execute above approach? Is the approach reasonable and robust?

>      Splicer MUST be able operate in both unicast or multicast session

Accept.

> I think "Keep" is the wrong word here. I think resulting in a consistent

how about:  " The current RTP stream received by user may contain main content or substitutive content, but user can not find which kind of content the RTP stream convey from current RTP header information."

> them. IF that is supported by client depends on the usage.

OK, so how about to delete the content "Note that~~~~"? the deleted content will be remove to section 5 with the description about reaction of user on different codec.

> Shouldn't this also include certain RTP extensions also?

how about:   "Splicer MUST be backward compatible with RTP/RTCP protocols with its associated profiles, and extensions to those protocols"

> content or substitutive content

Accept.

> psudo code for these translation cases.

I once wrote some ones which is in raw status and needed to be elaborated, your input is very appreciated.

> And there are hardware off-loading for UDP checksums.

OK, we just need to mention implentation consideration that translator needs to process the lower layers. 

how about:  "When Translator is used to handle RTP splicing, RTP receiver does not need any RTP/RTCP extension for splicing.  As a trade-off, Translator must process RTP and lower layers compared to just forwarding the main RTP stream, since Translator must coordinate the switch between main content and substitutive content, and generate its own RTCP reports.  Even if no new substitutive content will be inserted, the Translator still needs to modify the main RTP packets, and to recalculate the UDP/IP checksum until the main RTP session ends."

Thank you very much again.

Jinwei