From #24936 * To Content.I.Media: * Add a way to signal supported RTCP Extended Report blocks (aka RTCP XR from RFC 3611). As set of a{ss} LocalRtcpXr and RemoteRtcpXr on the Content. To be set with SetLocalRtcpXr(a{ss}) and notified by RemoteRtcpXr changed signals. That said, I haven't look at every details of RTCP XR, so I'm not 100% sure how this should look.
I think that jonny's branch is almost the right shape, but needs updating to match the style of MediaDescriptions. I did that and pushed to http://git.collabora.co.uk/?p=user/tester/telepathy-spec.git;a=shortlog;h=refs/heads/rtcp-xr I also added an as for extensibility. If you think that's taking it a bit too far then I'll happily squash that commit. Note that the last commit of alsuren/rtcp-fb-mediadesc-ftfy still needs reviewing (as part of #28687).
I think you mean http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/rtcp-xr I'm sure if having one property per type of report is good or not, since this is extension (and we only have the basic ones int here).
(In reply to comment #2) > I think you mean > http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/rtcp-xr > > I'm sure if having one property per type of report is good or not, since this > is extension (and we only have the basic ones int here). This is why I have added the "as" property "ExtendedFormats". I would prefer it if the streaming implementation could avoid having to do SDP parsing (because it makes life hard for other protocols). Since ExtendedFormats is defined to always contain all sdp strings not defined in the core XR RFC 3611 for sip, we have the following upgrade path: 1) Implement it in farstream without changing rakia 2) Implement a new property in rakia without changing farstream ("ExtendedFormats" still contains the unparsed string for backwards compatibility) 3) Use the new property in farstream 4) Implement the new property in gabble 5) Take over the world. We should probably define what a CM should do if a client calls Accept() with a property that it doesn't understand though. Should Accept return a list of invalid fully-qualified property names on error or something?
That looks like a really complicated process. I wouldn't mind if we said that the CM just doesnt pass through any line it does not understand. So we could get rid of ExtendedFormats and for the spec to be updated for further formats...
last two commits of: http://cgit.collabora.com/git/user/alsuren/telepathy-spec.git/log/?h=rtcp-xr-28686 ? (will squash the revert commit into its parent before merging)
++
Merged to alsuren/call
merged to master
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.