Re: other features

I was not sure if SVC was going to be in scope of 1.0 finally or we were 
just advancing work for next chapter, anyway I just wanted it to be on 
the agenda (the sooner we have it the better).

Re. UDP-datachannels, ignore it, I haven't checked implementations in a 
while, and I was wrong on my assumptions.

About the control protocol, yes we a number of issues regarding 
muting/unmuting on current spec, but AFAIK (and correct me if I am again 
wrong), they only apply to the local side of the media track. What I 
would like is to be able to have events on the remote side 
(PC/receiver/track) when something happen on the local side without 
having to renegotiate.

I have already proposed a couple of times to use rfc7728 paused 
indication for that, but have not been successful yet ;)

IMHO it is unnecessary to have to do a renegotiation to change the 
direction of the SDP attributes or adding or removing a new track. We 
should be able once a PeerConnection has been established to be able to 
addTrack and the an ontrack on the remote PC without doing anything. We 
are currently able to something similar by using RTCP BYE when closing a 
rtp stream, and could do the same for muting, just mute the local track 
and an onmute event will be fired on the remote track automatically.

One of the issues we need to solve (appart of the IPR claim on the 
rfc7228) is that RTCP is not reliable (quite estrange for a "control 
protocol") but that could be solved either at RTCP level (with a generic 
rtx-like for rtcp) or a per method basic (requesting an rtcp ack for the 
stream notification for example).

Not sure how feasible is, but from a web developer point of view 
(specially from someone used to have this mechanism in flash) would be 
very helpful and easy to work with.

Regards
Sergio

On 25/01/2018 9:10, Bernard Aboba wrote:
> Sergio said:
>
> "On a lower level of priority I also think that the following items would
> make sense:
>
>    * SVC support
>    * UDP-like datagram datachannels with proper api  (regardless of the
>      technology underneath)
>    * Control protocol for rtp stream related stuff which would allow
>      avoiding having to signal certain events like new streams, mutes and
>      stream termination. That could be done using RTCP (BYE is a good
>      example) with a few additions."
>
> [BA]  We have a number of open issues relating to events such as muting/unmuting in WebRTC 1.0;  hopefully we can work through those in the normal course of work.
>
> If there's something in particular that's bothering you, please file an Issue.
>
> At TPAC, we discussed how SVC support could be added to WebRTC 1.0.
>
> Is this something that you'd like to see done as an extension to 1.0 or only as part of "NV"?
>
> At various points, multiple applications (and even one browser) have shipped a UDP/RTP data-channel.
>
> Typically the data-channel is allocated a fraction of the bandwidth available between the peers, so that the implementations I'm familiar with have incorporated congestion control.
>
> However, such an approach would not handle the full range of scenarios that SCTP (or eventually, QUIC) data exchange could, and it would be unlikely to complete IETF standardization before QUIC.
>
>
>

Received on Thursday, 25 January 2018 09:49:07 UTC