Opened 8 years ago

Closed 8 years ago

#25 closed defect (fixed)

Section 5.1 Conferencing Extensions

Reported by: bernard_aboba@… Owned by: draft-ietf-rtcweb-rtp-usage@…
Priority: major Milestone: milestone1
Component: rtp-usage Version: 1.0
Severity: Active WG Document Keywords:
Cc:

Description

These
central servers can be implemented in a number of ways as discussed
in Appendix A, and in the memo on RTP Topologies
[I-D.westerlund-avtcore-rtp-topologies-update].

[BA] Out-of-date reference; should be to draft-ietf-avtcore-rtp-topologies-update.

o The use of video switching MCUs makes the use of RTCP for

congestion control and quality of service reports problematic(see
Section 3.7 of [I-D.westerlund-avtcore-rtp-topologies-update]).

[BA] In the new document, this is now Section 3.6.2.

o RTP Transport Translators (Topo-Translator) are not of immediate

interest to WebRTC, although the main difference compared topoint
to point is the possibility of seeing multiple different
transport paths in any RTCP feedback.

[BA] "not of immediate interest" might be interpreted as not satisfying the requirement that "these topologies require no special RTP-layer support in the end-point if the RTP features mandated in this memo are implemented". If a browser can handle an undeclared SSRC then wouldn't an RTP translator also satisfy the requirement? For example, Section 11 states: "The API also needs to be capable of handling when new SSRCs are received but not previously signalled by signalling in some fashion."

These
extensions are not necessary for interoperability; an RTP endpoint
that does not implement these extensions will work correctly, but
might offer poor performance.

[BA] I'd argue that not implementing the extensions will also affect aspects such as congestion control, which one might argue is necessary to "work correctly".

Change History (1)

comment:1 Changed 8 years ago by bernard_aboba@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.