Behavior when calling send() or receive() again

[aboba]

Currently, both the send() and receive() methods allow those methods to be called multiple times with the same RtpSender/RtpReceiver object.

However, the specification is not very clear about the expected behavior. For example, in some situations a discontinuity is likely, others not.

Related WebRTC issue: https://github.com/w3c/webrtc-pc/issues/1207

[ibc]

I think that the problem here is similar to what it happens when receiving a SDP re-offer: the "full re-inspection".

• What happens if send() is called with same SSRC but different clockRate? Would that also reset the sequence number of the stream?
• What if called with a different RTP header extension mapping or RTCP feedback?

This is non deterministic and I'm pretty sure that there won't be two implementations behaving the same way.

My opinion is the following (in order to define something feasible for implementations):

• send() should be called just once (throw if called again) on a RtpSender.
• RtpSender should include more methods to alter specific details of the sending media. For example:
  • rtpSender.enableEncoding(idx): Sets the active flag of the encoding in position idx.
  • rtpSender.disableEncoding(idx)
  • rtpSender.setDegradationPreference(RTCDegradationPreference)

I don't think changing sending stuff other than that would be even feasible for implementations.

• receive() should just be called once (and throw otherwise).

Being able to call send() again with a completely different RTPParameters is terribly error prune, and mimics the worst of SDP land. Not even the spec is clear about it so I just don't want to imagine how vendors will behave.

But if we have a granular API to dynamically change specific sending stuff in runtime, things may work. IMHO this is the only realistic way to go.

[aboba]

@ibc @taylor-b I think you may have a point for send(), absent a well defined algorithm. But if receive() can only be called once, wouldn't it be a hassle to hook up the new receivers to audio/video tags? I am also worried about the impact on a setParameters() shim.

BTW, ORTC lib does allow send and receive to be called more than once.

[ibc]

But if receive() can only be called once, wouldn't it be a hassle to hook up the new receivers to audio/video tags?

May you detail what you mean please?

BTW, ORTC lib does allow send and receive to be called more than once.

But nowhere it's specified how it works, which changes it reacts on, which changes it allows and which ones it ignores. Don't take me wrong, but I cannot buy this argument. It's like saying that both Chrome and Firefox allow mangling the SDP between createOffer and setLocalDescription. And it's true, but who knows which exact parts of the SDP we can mangle in each browser.

[taylor-b]

I don't see why changing parameters is a problem, aside from changes that cause identifiers to be ambiguous (e.g., using one payload type to map to two media formats, or one ID to map to two header extensions). But most anything else is allowed to change with SDP, which JSEP implicitly requires browsers to support, and although current browsers may have bugs, any changes should be possible in theory (or so I thought).

What happens if send() is called with same SSRC but different clockRate? Would that also reset the sequence number of the stream?

I don't see why anything but the payload type would need to change.

RtpSender should include more methods to alter specific details of the sending media

I don't see what advantage this provides. I see having a single method that changes multiple things atomically as a positive (for example, if an application wants to change multiple properties at once, without video frames leaking out with partially-changed properties). The main downside of SDP (in my opinion) is that it ties together send/receive parameters, and multiple layers of the transport stack (ICE/DTLS/RTP), which ORTC avoids.

[aboba]

What happens if send() is called with same SSRC but different clockRate?

From RFC 7160 Section 4.1:

An RTP Sender with RTCP turned on MUST use a different SSRC for each different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST be used if the clock rate switches back to a value already seen in the RTP stream.

[BA] Based on this, I would say that changing the clockRate but not the SSRC would be an error.

[ibc]

Based on this, I would say that changing the clockRate but not the SSRC would be an error.

That's just an use case that is not documented in the ORTC API.

I do not want to be pushy, but I could mention tons of undocumented use cases like that:

• What would happen if I call send() with different RTP header extension mappings?
• or with different codec feedbacks?
• or different rtcp.cname?
• etc etc

I see having a single method that changes multiple things atomically as a positive (for example, if an application wants to change multiple properties at once, without video frames leaking out with partially-changed properties). The main downside of SDP (in my opinion) is that it ties together send/receive parameters, and multiple layers of the transport stack (ICE/DTLS/RTP), which ORTC avoids.

ORTC avoids that if we talk about different layers (ICE, DTLS, RTP). But within RTP there is a single method to change everything so, when calling send()/receive() again, all the parameters must be re-inspected. Still 5000% better than SDP, but it could be much better IMHO.

[taylor-b]

An RTP Sender with RTCP turned on MUST use a different SSRC for each different clock rate.

Ah, I didn't know about this. It makes sense but I don't think we're doing it in Chrome.

Anyway, I agree all these things should be documented, but I still don't see why the API needs to be split apart, or restricted to "you can only call send()/receive() once".