Subject: Re: [rtcweb] Working Group Last Call for draft-ietf-rtcweb-rtp-usage-13

From: Magnus Westerlund <[email-masked]>
Date: Fri, 2 May 2014 10:49:59 +0200

WG,

As Author, I really hope you are reviewing this draft. You have another
week to provide comments. I really hope that people reading it provide
some feedback, positive or negative so that we get to know your view on
this.

So go fetch the draft here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/

Me personally really likes the feedback now, as that enables me to
respond to it and discuss it if necessary at the interim. Anything that
comes later, I will be unable to answer, at least until early next year.

Cheers

Magnus

On 2014-04-24 17:13, Ted Hardie wrote:
> This begins a working group last call on draft-ietf-rtcweb-rtp-usage-13;
> please review the document and provide comments to the list by May 9, 2014.
> 
> thanks,
> 
> Ted, Cullen, Sean
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 

-- 

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 5 May 2014 11:52:27 +0200

On 02 May 2014, at 10:49, Magnus Westerlund <[email-masked]> wrote:

> WG,
> 
> As Author, I really hope you are reviewing this draft.
I have reviewed the draft and sent some typos and other minor issues directly
to the authors. 

I think it is a very good overview and learned a lot from reading it in detail. It pointed
me to a large series of other documents that is now on my "must read" list :-)

I encourage everyone on the list to read it. RTP in WebRTC is according to this
document far away from your typical SIP phone with a ten-year old RTP stack. 
The document mentions interop with legacy devices, but I think it's mostly to
have a nice attitude. It's going to be hard, unless they upgrade. Which is 
about time.

/O

> You have another

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 7 May 2014 13:32:58 +0000

If you have reviewed this draft and have no comments, please let us know the chairs know that you reviewed it. Thanks

On Apr 24, 2014, at 9:13 AM, Ted Hardie <[email-masked]> wrote:

> This begins a working group last call on draft-ietf-rtcweb-rtp-usage-13; please review the document and provide comments to the list by May 9, 2014.
> 
> thanks,
> 
> Ted, Cullen, Sean

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 9 May 2014 08:41:52 -0600

Overall the document looks in excellent shape. I do have a bunch of comments but they are all pretty easy to deal with. 

Page 5
I think that draft-ietf-avtcore-rtp-multi-stream-optimisation should be MAY not a MUST. We don’t loose significant interoperability by not having it a MUST. 

Page
Sending correct sync information should be MUST not SHOULD. We can’t make lip sync work without this and I think the flows I have seen already send it. Note people don’t have to deal with correctly implementing lip sync on the receiving end, they just have to send enough information to make it possible that receivers that want to can. 

Has the text "support for RTCP timer reconsideration." but I don’t know what this means or how to implement it - suspect we just need a ref or bit more text. 

I’d refer to see "reduced minimum RTCP reporting interval" be a MUST and I could live with MAY but SHOULD is just lame for this. 

Page 8 

It has the text 

An end-point that has signalled support for multiple RTP payload formats SHOULD be able to accept data in any of those payload formats at any time, unless it has previously signalled limitations on its decoding capability.

I think that has to be a MUST not a SHOULD or else this will not work. 

Page 18

This has RTX (RFC4588) and MUST. RTX has turned out to be close to useless in interactive communications systems because the RTT is just too high to make this viable. You need to set your jitter buffer to be larger than the RTT for this work and I am aware of any significant internet collaborations system that sets the jitter buffer size that high. I think this should be MAY not MUST but that said, I can easily live with MUST, it just seems useless at a time where we are trying to reduce the complexity of the system. 

Page 19

It says FEC is not required. I’m OK with this but my notes have it as the WG previously agreed on this being required. It might be worth putting this up on a slide in the May meeting and checking the WG is good with no FEC. Perhaps my notes are all wrong - I did not try and go back throughout minutes. It’s possible the WG decided different things and different times. 

Page 20

Has the text 

  signalled bandwidth limits SHOULD be used to limit traffic 

I might be reading this the wrong way but given the weak congestion control in general, I feel pretty strongly that the browser can’t ignore signaled bandwidth limits and this needs to say something more like the "MUST not exceed signaled bandwidth"

Page 20-22, 

Section 7.2 - I felt like this section was supposed to convince me it was all OK but the more I read it the more confused I was. What does one do if sending video on says a 768 kbps link? Send every 5 frames? 

I think part of the confusion stemmed from the implication that to do good congestion control, you needed a report once ever say RTT but in RTP we could not do that so we would fall back to a far less frequent reporting of once ever frame. But ever frame is less than the RTT in most internet case so I was just confused by the whole section. 

I don’t think this section is going to help implementors much as it is - perhaps it could just be refactored a bit to help implementers understand how often to send RTCP and why. 

Page 24

Has 

All WebRTC implementations MUST be prepared to receive RTP XR report packets, whether or not they were signaled.

I disagree with this - we are in a non multicast environment with RTP inside DTLS/SRTP. One should not be getting reports for extensions that were not negotiated. 

Similarly on page 25 the text has

The RTP extensions to be used SHOULD be agreed upon, 

I think this needs to be a MUST. 

Page 27 

I think it would be best to just remove the line 

 This document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to map unknown source packet stream SSRCs to MediaStreamTracks and MediaStreams.

as that is not key to this spec. 

Page 36 - 37 

Section 12.2.2. 

So if I read this right, it says you MUST resolve SSRC collisions but RFC 5576 has no way to do that. What are implementors supposed to do ?

Even ignoring 5576 - it’s just not clear to me how one detects and resolves SSRC collisions. 

Cullen with my individual contributor hat on.

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 9 May 2014 16:36:40 -0700

Thanks Magnus and all for this work. I liked the way the document has
turned out to be.

Apologies for the last minute response, I am been wanting  to read this
spec and finally got some time late in this week.

I have listed down few points that reflect my notes when i read the
document from a RTP implementor and WebRTC developer perspectives.

*Comments*

2. Handling of documents from AVTCore related to MultiStream,
MultiStreamOptimization, MultiMediaRTPSession that are normatively
referenced. It was not clear if all these should be normatively referenced.

3. RTP Taxonomy usage. This comment is applicable to the RTP documents
referred by this document which dont follow the Taxonomy. This caused lot
of concept mapping in my mind to go between the different usages to
understand the implications. I would strongly recommend alignment with the
Taxonomy for these dependent documents and I volunteer to do some of it If
needed.

4. trr-int of 4 seconds has be recommended in couples of places. But i dont
see a reference to the choice of 4 seconds and the reason why it was chosen
that way. I am not sure if we want to specify this detail in this document.

5. Section 4.1 says,

   - Support for multiple end-points in a single RTP session, and for
   scaling the RTCP transmission interval according to the number of
   participants in the session; support for randomised RTCP transmission
   intervals to avoid synchronisation of RTCP reports; support for RTCP timer
   reconsideration.

All these MUST requirements need references. If some of these belong to
RFC3550, then we need to say that.

6. Section 4.2
     Not sure if the side note for trr-int fits in this section

7. Section 4.3 Para 2
      - I felt this Para was getting too busy in laying out the cases of PT
Reuse combinations. Can we break it , if possible ?
      - We can probably delete the note referring to BUNDLE spec since we
refer to it again in Section 4.4 where it contextually makes more sense.

8. Section 4.3 Para 3
   An end-point that has signalled support for multiple RTP payload formats
SHOULD be able to accept data in any of those payload formats at any time,
unless it has previously signalled limitations on its decoding capability.

Shouldn't the SHOULD be MUST above. If not, I think we fail interoperability

9.Nit ..  Section 4.4 Para 3 says
Further discussion about the suitability of different RTP session
structures and multiplexing methods to different scenarios are suitable can
be found in [I-D.ietf-avtcore-multiplex-guidelines]<http://tools.ietf.org/id/draft-ietf-rtcweb-rtp-usage-13.html#I-D.ietf-avtcore-multiplex-guidelines>
.

How about rewording it to,
Further discussion about the suitability of different RTP session
structures and multiplexing methods to different scenarios can be found in
[I-D.ietf-avtcore-multiplex-guidelines]<http://tools.ietf.org/id/draft-ietf-rtcweb-rtp-usage-13.html#I-D.ietf-avtcore-multiplex-guidelines>
.

10.  Section 5.1 ( Topology Recommendations)
       - Nit .. Adding reference to RTCPeerConnections might be useful
       - I dont think this document should make recommendations against
applicability of a particular topology for a given context. Specifically,
the pointers to carrying out congestion control mechanisms are still under
development and denying a topology based on it might not be a good idea. I
would prefer this section referring to the Topo document as an informative
reference and implications of each topology under various scenarios should
be moved in there, if needed.

11. Section 5.1.2
      Should we add the requirement for the WebRTC end-point sending PLI
messages?

12. Section 10
     - Nit - Reference to ICE is needed

13. Section 11 Para 3
       Not sure, if this is needed altogether. Probably saying a given
Media Source might end up in several RTP Packet Streams  with their
associated SSRC following WebRTC API mechanisms defined in <ref>

 14. Section 11 says
 Note: this doesn't result in a tracking issue, since the creation of
matching CNAMEs depends on existing tracking.

  We need bit more context here explaining the tracking or remove it
altogether

15. Section 8
      There is no requirement that the data contained in such reports be
used, or exposed to the Javascript application, however.
  Do we need this sentence ?

16. Section 11 has,
The above will currently force a WebRTC end-point that receives an
MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing on any
RTCPeerConnection to perform resynchronisation of the stream. This, as the
sending party needs to change the CNAME, which implies that it has to use a
locally available system clock as timebase for the synchronisation. Thus,
the relative relation between the timebase of the incoming stream and the
system sending out needs to defined. This relation also needs monitoring
for clock drift and likely adjustments of the synchronisation. The sending
entity is also responsible for congestion control for its the sent streams.
In cases of packet loss the loss of incoming data also needs to be handled.
This leads to the observation that the method that is least likely to cause
issues or interruptions in the outgoing source packet stream is a model of
full decoding, including repair etc followed by encoding of the media again
into the outgoing packet stream. Optimisations of this method is clearly
possible and implementation specific.

Probably,I am missing the context here, but I don't see the need for this
para in this document since it is very application specific

17 Section 12
    - Not sure if we really need the topology details in here. But I am
fine going with it one way or the other.

18. Section 12.1.3
     Should this be moved out as a separate section, since, it is more than
just implementation guidelines

19. SSRC Collision
     It is not clear what implementation guidelines that is being provided.

Cheers
Suhas

On Fri, May 9, 2014 at 7:41 AM, Cullen Jennings <[email-masked]> wrote:

>
> Overall the document looks in excellent shape. I do have a bunch of
> comments but they are all pretty easy to deal with.
>
> Page 5
> I think that draft-ietf-avtcore-rtp-multi-stream-optimisation should be
> MAY not a MUST. We don’t loose significant interoperability by not having
> it a MUST.
>
> Page
> Sending correct sync information should be MUST not SHOULD. We can’t make
> lip sync work without this and I think the flows I have seen already send
> it. Note people don’t have to deal with correctly implementing lip sync on
> the receiving end, they just have to send enough information to make it
> possible that receivers that want to can.
>
> Has the text "support for RTCP timer reconsideration." but I don’t know
> what this means or how to implement it - suspect we just need a ref or bit
> more text.
>
> I’d refer to see "reduced minimum RTCP reporting interval" be a MUST and I
> could live with MAY but SHOULD is just lame for this.
>
>
> Page 8
>
> It has the text
>
> An end-point that has signalled support for multiple RTP payload formats
> SHOULD be able to accept data in any of those payload formats at any time,
> unless it has previously signalled limitations on its decoding capability.
>
> This has RTX (RFC4588) and MUST. RTX has turned out to be close to useless
> in interactive communications systems because the RTT is just too high to
> make this viable. You need to set your jitter buffer to be larger than the
> RTT for this work and I am aware of any significant internet collaborations
> system that sets the jitter buffer size that high. I think this should be
> MAY not MUST but that said, I can easily live with MUST, it just seems
> useless at a time where we are trying to reduce the complexity of the
> system.
>
>
> Page 19
>
> It says FEC is not required. I’m OK with this but my notes have it as the
> WG previously agreed on this being required. It might be worth putting this
> up on a slide in the May meeting and checking the WG is good with no FEC.
> Perhaps my notes are all wrong - I did not try and go back throughout
> minutes. It’s possible the WG decided different things and different times.
>
>
> Page 20
>
> Has the text
>
> I might be reading this the wrong way but given the weak congestion
> control in general, I feel pretty strongly that the browser can’t ignore
> signaled bandwidth limits and this needs to say something more like the
> "MUST not exceed signaled bandwidth"
>
>
> Page 20-22,
>
> Section 7.2 - I felt like this section was supposed to convince me it was
> all OK but the more I read it the more confused I was. What does one do if
> sending video on says a 768 kbps link? Send every 5 frames?
>
> I think part of the confusion stemmed from the implication that to do good
> congestion control, you needed a report once ever say RTT but in RTP we
> could not do that so we would fall back to a far less frequent reporting of
> once ever frame. But ever frame is less than the RTT in most internet case
> so I was just confused by the whole section.
>
> I don’t think this section is going to help implementors much as it is -
> perhaps it could just be refactored a bit to help implementers understand
> how often to send RTCP and why.
>
>
> Page 24
>
> Has
>
> All WebRTC implementations MUST be prepared to receive RTP XR report
> packets, whether or not they were signaled.
>
> I disagree with this - we are in a non multicast environment with RTP
> inside DTLS/SRTP. One should not be getting reports for extensions that
> were not negotiated.
>
>  This document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to
> map unknown source packet stream SSRCs to MediaStreamTracks and
> MediaStreams.
>
> So if I read this right, it says you MUST resolve SSRC collisions but RFC
> 5576 has no way to do that. What are implementors supposed to do ?
>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 9 May 2014 16:47:19 -0700

Cullen said:

"This has RTX (RFC4588) and MUST. RTX has turned out to be close to useless
in interactive communications systems because the RTT is just too high to
make this viable. "

[BA] Where temporal scaling is used, RTX can be useful in protecting the
base layer.  So it's not universally useless.  I do agree that MUST is too
strict, though.

"It says FEC is not required. I’m OK with this but my notes have it as the
WG previously agreed on this being required. "

[BA] Yeah, I wondered about that, too.

---

From: Colin Perkins <[email-masked]>
Date: Sat, 10 May 2014 16:56:31 +0100

Thanks for the comments. I just have a quick response now; a full response to the other points is coming later.

On 10 May 2014, at 00:47, Bernard Aboba <[email-masked]> wrote:
> Cullen said:
> 
> "This has RTX (RFC4588) and MUST. RTX has turned out to be close to useless in interactive communications systems because the RTT is just too high to make this viable. "
> 
> [BA] Where temporal scaling is used, RTX can be useful in protecting the base layer.  So it's not universally useless.  I do agree that MUST is too strict, though.

What the draft says is (Section 6.1):

   Receivers are REQUIRED to implement support for RTP retransmission
   packets [RFC4588].  Senders MAY send RTP retransmission packets in
   response to NACKs if the RTP retransmission payload format has been
   negotiated for the session, and if the sender believes it is useful
   to send a retransmission of the packet(s) referenced in the NACK.  An
   RTP sender does not need to retransmit every NACKed packet.

This is a little more nuanced than simply “MUST”.

> "It says FEC is not required. I’m OK with this but my notes have it as the WG previously agreed on this being required. "
> 

The key passage from Section 6.2 of the draft is:

   There are several block-based FEC schemes that are designed for use
   with RTP independent of the chosen RTP payload format.  At the time
   of this writing there is no consensus on which, if any, of these FEC
   schemes is appropriate for use in the WebRTC context.  Accordingly,
   this memo makes no recommendation on the choice of block-based FEC
   for WebRTC use.

If this is wrong, and there is consensus on a particular FEC scheme that works with bundled media, then we can reference it.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Roni Even" <[email-masked]>
Date: Sun, 11 May 2014 17:01:26 +0300

Hi,

Just nits

1.       Section 8 last paragraph “RTP XR” should be “RTCP XR”
 
2.       The last sentence in the paragraph after figure 1 “it it believed”
 
3.       In section 12.2.2 bullet 4 “While is is clearly”. BTW: this case can be a self-view in the mixer case which may be a feature and not a bug. It may also be a loop-back.

Roni

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: 24 April, 2014 6:13 PM
To: [email-masked]; Cullen Jennings; Sean Turner
Subject: [rtcweb] Working Group Last Call for draft-ietf-rtcweb-rtp-usage-13

thanks,

Ted, Cullen, Sean

---

From: Alex Eleftheriadis <[email-masked]>
Date: Mon, 12 May 2014 06:48:45 +0000

> [BA] Where temporal scaling is used, RTX can be useful in protecting the base layer.  So it's not universally useless.  I do agree that MUST is too strict, though.

Let's make sure that this point is clearly understood, because it keeps re-appearing in discussions. 

When temporal scalability is used, the lowest temporal level frames are far enough apart that retransmission can be used. This is already deployed in products, and is supported by all RTP payload formats for video codecs that support temporal scalability (H.264 SVC, VP8, HEVC). 

Regards,

--Alex

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 May 2014 13:40:32 +0200

Hi,

Thanks for the feedback, I will work with my co-authors to propose text
changes where so is appropriate and see inline for comments or response.

On 2014-05-09 16:41, Cullen Jennings wrote:
> Page 5 I think that draft-ietf-avtcore-rtp-multi-stream-optimisation
> should be MAY not a MUST. We don’t loose significant interoperability
> by not having it a MUST.

It is not a MUST:

"Support for the RTCP
      optimisations for multi-SSRC sessions defined in
      [I-D.ietf-avtcore-rtp-multi-stream-optimisation] is RECOMMENDED."

And it is recommended for a good reason. Although this is a new spec it
provides a significant improvement in RTCP efficiency compared to
without it.

Below you find the statistical simulation results for the intervals
between regular RTCP packets achieved over 10000 RTCP packets in an
WebRTC like situation with X number of SSRCs per endpoint between two
endpoints, all SSRC are active senders. The RTCP bandwidths are
configured as RR: 15000 bps, RS: 10000 bps and T-rr-int = 0

AVPF is base line AVPF
AVPF-AGG-ADJ is the scheduling aggregation that is being specified in
draft-ietf-avtcore-rtp-multi-stream
AVPF-RG-AGG is with the report group extension and the removal of cross
reporting specified in draft-ietf-avtcore-rtp-multi-stream-optimisation

Average transmission interval from using the different solutions:

SSRCs         1        2        3        4        5

AVPF          1.043879 1.126795 1.246220 1.410738 1.599270
AVPF-AGG-ADJ  1.041918 1.110367 1.217367 1.362500 1.549829
AVPF-RG-AGG   1.051294 1.080191 1.113448 1.150983 1.187954

Gain from using the different solutions:

SSRCs         1         2         3         4         5

AVPF-AGG-ADJ  -0.001879 -0.014579 -0.023152 -0.034193 -0.030915
AVPF-RG-AGG    0.007103 -0.041360 -0.106540 -0.184127 -0.257190

As can be seen the significant gain is for the report group extension,
especially as the SSRCs per end point increases.

> 
> Page Sending correct sync information should be MUST not SHOULD. We
> can’t make lip sync work without this and I think the flows I have
> seen already send it. Note people don’t have to deal with correctly
> implementing lip sync on the receiving end, they just have to send
> enough information to make it possible that receivers that want to
> can.

You have misread this:

   o  Sending correct synchronisation information in the RTCP Sender
      Reports, to allow receivers to implement lip-synchronisation;
      support for the rapid RTP synchronisation extensions (see
      Section 5.2.1) is RECOMMENDED.

The first part "Sending correct synchronisation information in the RTCP
Sender Reports, to allow receivers to implement lip-synchronisation;"
is MUST, the second part is providing a recommendation.

we had an comment from Olle about this and propose to reformulated this
to be:

   o  Sending correct synchronisation information in the RTCP Sender
      Reports, to allow receivers to implement lip-synchronisation; see
      Section 5.2.1 regarding support for the rapid RTP synchronisation
      extensions.

> 
> Has the text "support for RTCP timer reconsideration." but I don’t
> know what this means or how to implement it - suspect we just need a
> ref or bit more text.

Okay, we can add a reference to Section 6.3 of RFC 3550 where this is
discussed and defined.

> 
> I’d refer to see "reduced minimum RTCP reporting interval" be a MUST
> and I could live with MAY but SHOULD is just lame for this.

You will not get a protest from me to make this a MUST. Does anyone else
protests?

> 
> 
> Page 8
> 
> It has the text
> 
> An end-point that has signalled support for multiple RTP payload
> formats SHOULD be able to accept data in any of those payload formats
> at any time, unless it has previously signalled limitations on its
> decoding capability.
> 

Yes, you are correct this really needs to be a MUST to get the desired
effect. Otherwise you will have media failures when the sender does this
and the receiver isn't capable.

> 
> Page 18
> 
> This has RTX (RFC4588) and MUST. RTX has turned out to be close to
> useless in interactive communications systems because the RTT is just
> too high to make this viable. You need to set your jitter buffer to
> be larger than the RTT for this work and I am aware of any
> significant internet collaborations system that sets the jitter
> buffer size that high. I think this should be MAY not MUST but that
> said, I can easily live with MUST, it just seems useless at a time
> where we are trying to reduce the complexity of the system.

I want to really protest about this Retransmission being useless. The
experiences we have had when deploying RTP retransmission in a video
conference system has been good. The only case where we had real issues
have been on intercontinental distances, for example between Stockholm
and San Jose where the RTT is large enough to actually cause issues that
the user notices. But on short distances like Stockholm to Germany or
Finland it works in excellent. This is a system I use almost daily and
have been in internal usage for several years.

But, yes there are implementation choices regarding the buffering
strategies here that do matters. One actually don't have to let the
jitter buffer always have one or more RTT extra depth, the alternative
is to delay the playout on the occurrences when retransmission is required.

As noted by Colin, the MUST is more subtle than requiring RTP
retransmission. I think what is in the draft represents the conclusions
of the discussion in Stockholm interim as well as on the mailing list
after.

> 
> 
> Page 19
> 
> It says FEC is not required. I’m OK with this but my notes have it as
> the WG previously agreed on this being required. It might be worth
> putting this up on a slide in the May meeting and checking the WG is
> good with no FEC. Perhaps my notes are all wrong - I did not try and
> go back throughout minutes. It’s possible the WG decided different
> things and different times.

My recollection has also been that the WG has been positive towards FEC,
but none has made a suggestion for a specific FEC scheme and RTP
encapsulation of it to include at any implementation level. Thus, the
formulation that is present in the draft.

> control in general, I feel pretty strongly that the browser can’t
> ignore signaled bandwidth limits and this needs to say something more
> like the "MUST not exceed signaled bandwidth"

Lets quote the sentence before the one you partially references:

   In addition, the signalling
   channel can establish maximum media bit-rate boundaries using the SDP
   "b=AS:" or "b=CT:" lines, and the RTP/AVPF Temporary Maximum Media
   Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of this memo).

Looking at the full sentence you refer to:

   The combination of media codec choice and signalled bandwidth limits
   SHOULD be used to limit traffic based on known bandwidth limitations,
   for example the capacity of the edge links, to the extent possible.

My personal interpretation of this text has been that:

1. You follow the limitations the peer signals
2. You SHOULD set these values your self based on known limitations and
code configurations.

But, looking at the text, we probably needs to make these two
distinctions clearer. Adding a MUST statement for the first thing I
support.

> 
> 
> Page 20-22,
> 
> Section 7.2 - I felt like this section was supposed to convince me it
> was all OK but the more I read it the more confused I was. What does
> one do if sending video on says a 768 kbps link? Send every 5 frames?
> 
> 
> I think part of the confusion stemmed from the implication that to do
> good congestion control, you needed a report once ever say RTT but in
> RTP we could not do that so we would fall back to a far less frequent
> reporting of once ever frame. But ever frame is less than the RTT in
> most internet case so I was just confused by the whole section.
> 
> I don’t think this section is going to help implementors much as it
> is - perhaps it could just be refactored a bit to help implementers
> understand how often to send RTCP and why.

I will have to come back regarding this, I believe I understand the
issues you see, but I need to consider further what to do about them.

> inside DTLS/SRTP. One should not be getting reports for extensions
> that were not negotiated.

I think it is important that RTP stack implementations can ignore
unknown or none supported features. At the same time I agree with you
that you should normally not get sent features that you don't support
and can not use. That is just wasting RTCP bandwidth and processing.

I can see that detailed control of this may be limited in certain
multi-party cases or gateways with legacy where controlling the legacy
might be an issue.

>From my point of view this should be:

1. MUST NOT send unless agreed on.
2. MUST be able to receive and discard options not asked for.

Are you fine with such a clarification?

> This document [I-D.ietf-mmusic-msid] also defines, in section 4.1,
> how to map unknown source packet stream SSRCs to MediaStreamTracks
> and MediaStreams.
> 

The reason that is included is that it can be an important aspect of
handling legacy interop where you don't require the media plane
information to be included in the signalling message the signalling
gateway creates.

> 
> 
> Page 36 - 37
> 
> Section 12.2.2.
> 
> So if I read this right, it says you MUST resolve SSRC collisions but
> RFC 5576 has no way to do that. What are implementors supposed to do
> ?

Sorry, what are you referring to? Section 5 of RFC 5576 is very clear on
what actions needs to happen after an SSRC collision has occurred.

Basically, choose new SSRC, signal it and include previous-SSRC
attribute to inform about your previous SSRC that you where forced to
abandon due to collision.

> resolves SSRC collisions.

Please see RFC 3550 Section 8.2

Thanks for your review.

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Tue, 13 May 2014 23:06:29 +0100

Hi Roni,

On 11 May 2014, at 15:01, Roni Even <[email-masked]> wrote:
> 3.       In section 12.2.2 bullet 4 “While is is clearly”.

Fixed, thanks.

> BTW: this case can be a self-view in the mixer case which may be a feature and not a bug. It may also be a loop-back.

In cases where the loop-back/self-view is desired, won’t a different SSRC be used to distinguish from an accidental loop?

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 May 2014 09:21:24 +0200

On 2014-05-14 00:06, Colin Perkins wrote:
>> BTW: this case can be a self-view in the mixer case which may be a
>> feature and not a bug. It may also be a loop-back.
> 
> In cases where the loop-back/self-view is desired, won’t a different
> SSRC be used to distinguish from an accidental loop?
> 

First of all I expect a self-view to simply take the local
mediaStreamTrack and display that, rather than loop it through the RTP
mixer.

If this occurs deliberately, to get it to work it will need to be
provided as a MST that the mixer offer the WebRTC endpoint, thus
originates deliberately under its own SSRC. See discussion of media
forwarding in Section 12.1.2.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Wed, 14 May 2014 23:14:28 +0100

Hi,

Some comments inline.

> Okay, we can add a reference to Section 6.3 of RFC 3550 where this is

Added.

> You will not get a protest from me to make this a MUST. Does anyone else

Added, along with some clarifications on how this affects RTCP source timeout intervals. 

> and the receiver isn’t capable.

Fixed.

> have been in internal usage for several years.

Agree. The RTTs I see for calls around the UK are often in the range where retransmission is entirely feasible. 

> issues you see, but I need to consider further what to do about them.

The text in the draft is perhaps better suited to giving guidelines for designers of congestion control algorithms than for browser implementers.

>> I think this needs to be a MUST.

For both this, and the previous, I think SHOULD is correct, along with some recommendations about being robust when receiving unexpected packets. We do not want WebRTC implementations to fall over when sent something novel that hasn’t been signalled. 

> what actions needs to happen after an SSRC collision has occurred.

I think this was a typo in our draft. I changed “The Source-Specific SDP Attributes [RFC5576] contains no mechanism to resolve SSRC collisions” to “contains a mechanism to resolve”, since as you point out, it does.

> Please see RFC 3550 Section 8.2

I added a reference to this.

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 May 2014 16:12:49 +0200

Hi Suhas,

Thanks, for your review, please see comments and answers inline.

> referenced. It was not clear if all these should be normatively referenced. 

Yes, they are most definitely normative references here.
- Multi-stream is the general clarification on handling multi-stream.
>From my perspective these clarifications are definitely needed.

- MultiStreamOptimization we RECOMMEND due to the significant gain it
provides as soon as each endpoint have multiple SSRCs.

- MultiMediaRTPSession is a requirement to allow for audio and video in
the same RTP session.

> referred by this document which dont follow the Taxonomy. This caused
> lot of concept mapping in my mind to go between the different usages to
> understand the implications. I would strongly recommend alignment with
> the Taxonomy for these dependent documents and I volunteer to do some of
> it If needed.

Yes, but that has to happen for each document individually. I think this
document is pretty well aligned with the current Taxonomy draft.

> 
> 4. trr-int of 4 seconds has be recommended in couples of places. But i
> dont see a reference to the choice of 4 seconds and the reason why it
> was chosen that way. I am not sure if we want to specify this detail in
> this document.

Yes, the motivation behind this value is from the attached presentation.
Please see slide 11, where you can see the curves for how many actual
reporting intervals will occur before an AVP and AVPF respectively will
on average time out the other profile type based on different values for
t-rr-int. A t-rr-int=4 s optimizes the number of reporting interval for
well configured RTP sessions. The well configured is meant to avoid the
AVPF bad behaviour when Td becomes close to T-rr-int. The first part of
the presentation discusses that issue and can be worth reading through
also.

> 
> 5. Section 4.1 says,
> 
>   * Support for multiple end-points in a single RTP session, and for
>     participants in the session; support for randomised RTCP
>     transmission intervals to avoid synchronisation of RTCP reports;
>     support for RTCP timer reconsideration.
> 

We propose:

   o  Support for multiple end-points in a single RTP session, and for
      scaling the RTCP transmission interval according to the number of
      participants in the session; support for randomised RTCP
      transmission intervals to avoid synchronisation of RTCP reports;
      support for RTCP timer reconsideration (Section 6.3.6 of
      [RFC3550]) and reverse reconsideration (Section 6.3.4 of
      [RFC3550]).

>      Not sure if the side note for trr-int fits in this section

I think it fits well enough. The section discusses the profiles, and a
relevant consideration is the legacy interop with AVP/SAVP senders. Do
you have a suggestion where it should be placed instead?

> 
> 7. Section 4.3 Para 2
>       - I felt this Para was getting too busy in laying out the cases of
> PT Reuse combinations. Can we break it , if possible ?

Is this better?

   End-points can signal support for multiple RTP payload formats, or
   multiple configurations of a single RTP payload format, as long as
   each unique RTP payload format configuration uses a different RTP
   payload type number.  As outlined in Section 4.8, the RTP payload
   type number is sometimes used to associate an RTP packet stream with
   a signalling context.  This association is possible provided unique
   RTP payload type numbers are used in each context.  For example, an
   RTP packet stream can be associated with an SDP "m=" line by
   comparing the RTP payload type numbers used by the RTP packet stream
   with payload types signalled in the "a=rtpmap:" lines in the media
   sections of the SDP.  This leads to the following considerations:

      If RTP packet streams are being associated with signalling
      contexts based on the RTP payload type, then the assignment of RTP
      payload type numbers MUST be unique across signalling contexts.

      If the same RTP payload format configuration is used in multiple
      contexts, then a different RTP payload type number has to be
      assigned in each context to ensure uniqueness.

      If the RTP payload type number is not being used to associate RTP
      packet streams with a signalling context, then the same RTP
      payload type number can be used to indicate the exact same RTP
      payload format configuration in multiple contexts.

   A single RTP payload type number MUST NOT be assigned to different
   RTP payload formats, or different configurations of the same RTP
   payload format, within a single RTP session.

>       - We can probably delete the note referring to BUNDLE spec since
> we refer to it again in Section 4.4 where it contextually makes more sense.

Ok, I do think it works to remove this:

	(note that the different
   "m=" lines in an SDP bundle group
   [I-D.ietf-mmusic-sdp-bundle-negotiation] form a single RTP session)

> formats SHOULD be able to accept data in any of those payload formats at
> any time, unless it has previously signalled limitations on its decoding
> capability.
> 

Yes, will be included in the next version.

> structures and multiplexing methods to different scenarios are suitable
> can be found in [I-D.ietf-avtcore-multiplex-guidelines]
> <http://tools.ietf.org/id/draft-ietf-rtcweb-rtp-usage-13.html#I-D.ietf-avtcore-multiplex-guidelines>.
> 
> structures and multiplexing methods to different scenarios can be found
> in [I-D.ietf-avtcore-multiplex-guidelines]
> <http://tools.ietf.org/id/draft-ietf-rtcweb-rtp-usage-13.html#I-D.ietf-avtcore-multiplex-guidelines>.
> 

Sounds better, will incorporate.

>        - Nit .. Adding reference to RTCPeerConnections might be useful

Sure, will add.

> applicability of a particular topology for a given context.
> Specifically, the pointers to carrying out congestion control mechanisms
> are still under development and denying a topology based on it might not
> be a good idea. I would prefer this section referring to the Topo
> document as an informative reference and implications of each topology
> under various scenarios should be moved in there, if needed.

That would also have been my preference. However, when this was
discussed in detail at the Stockholm RTCWEB Interim 2 years ago, people
has strong view that they where not willing to deal with the
implications of these topologies.

The issue with Transport relay as well as an Any Source Multicast group
is that each participating endpoint are required to handle multiple
congestion control loops, one to each receiving endpoint and act on the
full set of different path with a common appropriately selected
response. These type of topologies are explicitly outside of the charter
of RMCAT.

The Video switching MCU as defined in the topologies draft cause
breakage and inconsistencies in the RTP packet streams that are
difficult to handle and can result in strange congestion control
responses. That is why this is SHOULD NOT.

Please note that I started this effort with an intention of avoiding to
make the WebRTC endpoint limited in their deployment. With that in mind
I do see this set of limitations as a reasonable limitations.

>       Should we add the requirement for the WebRTC end-point sending PLI

Sorry, I am uncertain what you request here. The current section
requires an WebRTC RTP (video) sender to support PLI. The transmission
of PLI from the RTP receiving endpoint is a MAY. Do you want to change
this MAY to something else? A MUST? Please clarify your request.

>      - Nit - Reference to ICE is needed

Okay, will include.

> associated SSRC following WebRTC API mechanisms defined in <ref>

I disagree. The following sentence did take some discussion to arrive at:

"As different sets of constraints or other parameters can be applied to
the MediaStreamTrack, each MediaStreamTrack instance added to a
RTCPeerConnection SHALL result in an independent source packet stream,
with its own set of associated packet streams, and thus different SSRC(s)."

Yes, it is in the grey zone between W3C and IETF. However, in this case
we have worked for a WG consensus on that this is needed guidance to
W3C. Because there are different choices here and leaving it unspecified
is bad. Leaving it to W3C soley could result in ignoring the media
framework implications of what the API allows.

>   We need bit more context here explaining the tracking or remove it

So the sentence in the prior paragraph is not sufficient reference to
what it is?

   Having two
   communication sessions with the same CNAME could enable tracking of a
   user or device across different services (see Section 4.4.1 of
   [I-D.ietf-rtcweb-security] for details).

>   Do we need this sentence ?

With the current formulation I would say yes. It makes it clear that
unless you have explicitly negotiated its use, you are not required to
handle them in any form other than ignoring such XR reports.

I have started a discussion with my co-author about that last paragraph
and to see if we can resolve it differently. Thus, this may be changed
but, we like to consider the most appropriate action to take care also
of Cullen's comment.

> MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing on
> any RTCPeerConnection to perform resynchronisation of the stream. This,
> as the sending party needs to change the CNAME, which implies that it
> has to use a locally available system clock as timebase for the
> synchronisation. Thus, the relative relation between the timebase of the
> incoming stream and the system sending out needs to defined. This
> relation also needs monitoring for clock drift and likely adjustments of
> the synchronisation. The sending entity is also responsible for
> congestion control for its the sent streams. In cases of packet loss the
> loss of incoming data also needs to be handled. This leads to the
> observation that the method that is least likely to cause issues or
> interruptions in the outgoing source packet stream is a model of full
> decoding, including repair etc followed by encoding of the media again
> Probably,I am missing the context here, but I don't see the need for
> this para in this document since it is very application specific

Actually this is not application specific. It something that is way to
easy to do in the API to add an stream that is incoming over one
peerConnection and add it as outgoing on another. The WG has discussed
this and come to the consensus that we what is required by the WebRTC
implementations are to do what is described in the above text. Thus this
is something all WebRTC endpoints that supports the API will need to
handle.

I propose no change.

> fine going with it one way or the other.

As you say you have no issue, I would leave it in. You probably have a
good understanding what is written here. I think for a significant
number of people this will provide important information and understanding.

I propose no change.

> 
> 18. Section 12.1.3
>      Should this be moved out as a separate section, since, it is more
> than just implementation guidelines

This section is placed where it is as it provides information on why the
RTP session configuration does matter for QoS.

I propose no change.

>      It is not clear what implementation guidelines that is being

With the clarification of the first bullet, one clear implementation
guideline is provided. In addition it motivates why it matters and also
what its limitations are. Both things worth considering.

I propose no change.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Fri, 16 May 2014 11:36:07 +0100

One small comment inline, but in general I agree with Magnus’ response.
Colin

>   [I-D.ietf-mmusic-sdp-bundle-negotiation] form a single RTP session)

I’d prefer to keep this, since this issue has been a source of confusion in the past.

> <AVPF vs AVP RTCP Intevals.pptx>_______________________________________________
> rtcweb mailing list
> [email-masked]

-- 
Colin Perkins
http://csperkins.org/