youennf
commented
10 months ago Some thoughts:
- In case SFrameTransform is set on sender side, the SFrame packetization format would be automatically selected. What should happen on receiver side though?
It does not make real sense for me to have the SFrameTransform process packets that are not supposed to be encrypted. I would tend to vote for the transform to be a pass-through as a first step. This allows the same receiver to successfully receive encrypted or unencrypted content.
- How should a sending script transform that implements SFrame encryption itself select the SFrame packetization? How should the script transform provide the necessary data to the SFrame packetizer?
There is a need to tell UA that SFrame packetiser is to be used. This can be at transform creation time or at the time a frame gets enqueued, the latter being closer to SFrameTransform being a pass-through some times.
There is also a need for the SFrame packetiser to know the media payload type. The script transform should ideally not need to do anything special there.
- How should SFrame depacketized data be presented to a receiving script transform?
On receiver side, it seems useful to expose to the script transform that the SFrame depacketiser was used for that frame and what the underlying media PT is. Currently, we only have payloadType which cannot be used for both.
Ideally, the receiving and sending APIs would be made symmetric.
Let's assume a UA is implementing the SFrame packetization format. Existing APIs can be used to enable/disable this format during negotiation. Once it is negotiated for a given call, a few questions may need to be studied: