Re: Issue 80: filterParameters

hzRate is kind of silly.  Do you have a better suggestion? Maybe clockRate?

On Jun 9, 2014, at 5:56 PM, "Peter Thatcher" <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

I like preferredPayloadType being there like you put it.  And I think preferredId on RtpHeaderExtension would be fine, too, the more I think about it.

By the way, what's up with "hzRate"?  Isn't that kind of redundant?  It sounds to me like calling it "rateRate" or maybe "poundsWeight".  Is there a deeper meaning that I'm missing?


On Mon, May 19, 2014 at 2:15 PM, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:
Peter said:


"?Now that we've removed ?filterParameters/createParameters, I think we need
to find another way to make the simple use case and simple example work.  I
really don't want our "simple example" to be dependent on a JS library, or
have to choosing ssrcs.   I'd like the simple examples to remain simple.

So what can we do?  Here is an idea:

1.  Allow passing in RtpCapabilities into RtpSender.send and
RtpReceiver.receive.  That way, the signalling could just exchange
capabilities and not have to create RtpParameters for the simple case.

2.  Send and receive with the preferredPayloadType.  The sender just picks
some SSRC, and the receiver automatically locks onto them, as if the JS had
listened to "onunsignalledrtp" and added SSRCs manually.


That doesn't support header extensions (since the receiver wouldn't know
the IDs) or layering or FEC, but that might be OK for the simple use case.


Are there dragons that I'm not thinking of that would make this not work?
"

[BA] Agree that with preferredPayloadType, RTCRtpCodec should have enough info to setup a single stream audio or video call by exchanging capabilities.

Also agree that currently headerExtensions wouldn't work because there are no IDs (would preferredID fix this? Do we care?).

Am wondering how much we can do with features and rtcpFeedback as currently defined.

For example, we should be able to figure out what feedback messages (e.g, PLI, FIR) are available for repair with the single-stream video.



partial interface RTCRtpSender {
    void send (optional RTCRtpParameters parameters, optional RTCRtpCapabilities remoteCapabilities);
}

partial interface RTCRtpReceiver {
    void receive (optional RTCRtpParameters parameters, optional RTCRtpCapabilities remoteCapabilities);
}

dictionary RTCRtpCapabilities {
    sequence<RTCRtpCodec> audioCodecs;
    sequence<RTCRtpCodec> videoCodecs;
    sequence<DOMString>   headerExtensions;
    Capabilities          features;
    Capabilities          rtcpFeedback;
};


dictionary RTCRtpCodec {
    DOMString       name = "";
    unsigned short? hzRate = null;
    unsigned short  preferredPayloadType;
    unsigned short? numChannels = 1;
    Capabilities    formats;
};