Support for abs-send-time (willing to contribute) about sipsorcery HOT 2 CLOSED

Thanks for the offer and I for one would certainly welcome any improvements around bandwidth estimation. Although might be worth noting that in my experiments the dotnet managed video pipline struggles at 1080p @ 30fps. The bottleneck will typically be CPU rather than bandwidth. But if you do have a specific sceanrio where bw is a problem it will defintiely help to be able to get a good estimate and lower the frame rate.

Should I specify the header extension in SDP at all times, or should it be opt-in (opt-out?), e.g. using a new bool in RTCOfferOptions?

I think so, yes. Receivers can ignoe extensions they don't recognise.

There's a RTPHeaderExtensionData class which currently is used only for parsing byte buffers - should I use it to build a "model" of the data and only then serialise it to bytes?

I'd say use if it helps but don't feel obliged. It's a generic way to get data from unrecognisd extensions. In your case the extension will be recognised.

(related to above two) - how do I go about adding this header extension to RTP packets - should it be added conditionally (when option is specified), and do I need to use the RTPHeaderExtension... constructs to build the rtpPacket.Header ?

Whatever makes most sense. You could add an overload to the RTPHeader class but my immediate insticnt would be to add a new method to RTPHeader along the lines of AddRembExtension.

unit tests - I haven't seen any relating to RTPHeader serialisation, should I add create such for the above?

Ideally yes, even one or two unit tests are very helpful.

from sipsorcery.

Thanks for the answers.

As for the bottlenecks - my use case is desktop sharing, so it's less "dynamic" and therefore I am able to get reasonable results with 3440x1440 at variable frame rate ~20.

The REMB itself is not ideal though (even with the abs-send-time extension) - from my experiments it seems it can often trap itself in a "local minimum" and underestimate the available bandwidth - for example when I throttle frame rate, it then doesn't "probe" for more bandwidth and gets satisfied with lowered bitrate.
Possibly TWCC would yield better results, but requires a bit more effort to implement on the sender side - and I need to make a trade-off due to limited time.

I'll work on the PR and submit it soon.

from sipsorcery.