Jonathan is concerned about implementations and maturity of applications before we get to WGLC.
Bernard is pointing out the elephant. The RTP document has not appeared in AVTCORE. There is a possibility that this could be DOA on that basis. You gotta have something there.
Richard has a sunnier perspective. We do have applications that use this, so there is some maturity in applications. But those haven't dealt with a full and proper RTP/SDP integration. That creates risk.
Bernard says SFrame encrypts frames and also SPacket, which are two different things. You need to know which of the two you are doing. The RTP draft would be talking about SPacket. Frames is better for other stuff like WebTransport/MOQ.
Richard agree that this needs to be tied down, but the hack here is that these two are the same encryption piece. It is inapt to call it SFrame, we might need to rename it.
Bernard says that the RTP stuff is holding this back. Most of that isn't needed, because the details are far more complex than is implied.
...e.g., in RTP/QUIC, the payload has infinite MTU is this a large payload, or is a frame in a frame format. I think you need to know.
Richard: the sender and receiver need to agree, but this encryption stuff doesn't care
Jonathan does the SFU need to know? Maybe it doesn't need to.
Bernard: the SFU probably won't care.
Jonathan the SFU might care about being able to partially drop things that span multiple packets.
(Richard observes that AVTCORE have their work cut out for them.)
Jonathan : regarding non-RTP, where would we do that?
Martin: probably MOQ if we are sufficiently clear about application-level requirements; we aren't chartered for that
Richard: clearly we need a better set of application requirements
Very early May set up a time for a call.
Jonathan is concerned about implementations and maturity of applications before we get to WGLC.
Bernard is pointing out the elephant. The RTP document has not appeared in AVTCORE. There is a possibility that this could be DOA on that basis. You gotta have something there.
Richard has a sunnier perspective. We do have applications that use this, so there is some maturity in applications. But those haven't dealt with a full and proper RTP/SDP integration. That creates risk.
Bernard says SFrame encrypts frames and also SPacket, which are two different things. You need to know which of the two you are doing. The RTP draft would be talking about SPacket. Frames is better for other stuff like WebTransport/MOQ.
Richard agree that this needs to be tied down, but the hack here is that these two are the same encryption piece. It is inapt to call it SFrame, we might need to rename it.
Bernard says that the RTP stuff is holding this back. Most of that isn't needed, because the details are far more complex than is implied. ...e.g., in RTP/QUIC, the payload has infinite MTU is this a large payload, or is a frame in a frame format. I think you need to know.
Richard: the sender and receiver need to agree, but this encryption stuff doesn't care
Jonathan does the SFU need to know? Maybe it doesn't need to.
Bernard: the SFU probably won't care.
Jonathan the SFU might care about being able to partially drop things that span multiple packets.
(Richard observes that AVTCORE have their work cut out for them.)
Jonathan : regarding non-RTP, where would we do that?
Martin: probably MOQ if we are sufficiently clear about application-level requirements; we aren't chartered for that
Richard: clearly we need a better set of application requirements