Lifetime of outbound-rtp should start BEFORE first packet is sent

[henbos]

This issue is not arguing to change when inbound-rtp is created, because in that case the SSRC is in theory not known until the first packet is received, and we don't know useful things like which codec is used etc until we've gotten something to decode.

But this story is very different for outbound-rtp. As soon as you've negotiated, the RTCRtpSender knows:

• Which ssrcs and rids to use.
• How many simulcast layers to use and which ones are active or not.
• Which codec (codecId) is configured and its scalabilityMode.

The argument for exposing outbound-rtp early is that a) the information is know, and b) it's super confusing in simulcast if we delay creating an RTP stream until the first packet is sent on that SSRC. If you call getStats() after negotiating but before BW has had a chance to ramp up, you might only see one (or two) outbound-rtps.

Most browsers already expose outbound-rtp early so its better to update the spec to make more sense than to update the implementations to make less sense.

[henbos]

@jan-ivar Are you open to the idea to only delaying inbound-rtp creation, not outbound-rtp creation? I'd hate for a 3 layer simulcast stream to show up as singlecast in getStats until BW has ramped up

[fippo]

Didn't we agree on that already in #667?

[henbos]

We did?? Spec currently says:

The lifetime of all RTP monitored objects starts when the RTP stream is first used: When the first RTP packet is sent or received on the SSRC it represents, or when the first RTCP packet is sent or received that refers to the SSRC of the RTP stream.

I would argue that "RTP stream is first used" should not be clarified as first packet sent but that the sender was configured, but I am OK with the inbound side being "first used" as first packet received...