XSF Discussion - 2022-12-30

Kind reminder on the Summit: https://wiki.xmpp.org/web/Conferences/Summit_25

larma, out of curiosity. what jingle / webrtc things do you want to discuss?

Daniel: mostly a) do we want to continue having that thing called Jingle, when it's nowadays mostly a broken representation of WebRTC SDPs and b) how to fix the broken things (especially those that are already in the wild). Also interested in talking about multiparty calls

larma: I would also add a point to discuss changes/modification of existing Jingle sessions, as those do not include changing bundles/grouping nor modifying ssrcs

larma, are you asking for this ProtoXEP? https://xmpp.org/extensions/inbox/jingle-sdp.html

(btw if you want to call for greater discussion on such topics I am happy to support with advertising a bit for example)

Link Mauve: I think we need _less_ sdp not more

I’m not arguing in favour of it, just mentioning that it exists.

larma: thanks

Daniel, I'm not sure if I would like less sdp or more. Transformations when SDP changes SSRCs for existing calls are problematic at best. Sending full SDP answer/offer every time would be simpler ✏

Andrzej: it is 'simpler' if your backend is webrtc. But it's my understanding that sdp is broken precisely because it always communicates the full description not the change

yes, but every time I need to interact with any backend I'm ending up with generating/parsing SDP anyway

*any backend that uses the sdp model

*any backend I've encountered

I do not mind to keep what we have, but updating SSRCs for existing jingle sessions and bundle changes should be discussed as it is not covered by any existing XEP (at least to my knowledge)

yes certainly an interesting topic

just trying to understand WebRTC a little better. under what conditions would ssrc change?

Andrzej

ie. when you have a connection to SFU and single WebRTC connection handles many streams (with different data) then new streams may be created when someone join existing call

or when someone leaves then stream would be "gone"

when we worked on "Tigase Meet" and used SFU we had to deal with this

Daniel, if I recall SSRC is not changed but list of SSRCs changes AFAIR

so if you add an additional "audio content" the ssrc of the existing audio contents will change?

no, but new SSRC will appear for new audio content

but in that case you could just stick the new ssrc into the description of the new content, no?

let me check one thing

for context i've recently implemented "add-content" for video. (switch from audio only call to a/v call aka add video content) and I did not encounter issues with ssrc. the new video content just had a different set of ssrc then the existing audio content

but I must admit i have only a very rough understanding of what is actually happening under the hood

that's why i'm asking to better understand

Part of why I implemented switch to video was as a training exercise for multi party calls. Because content-add and content-remove are building blocks for that

fwiw I agree that bundle is somewhat underspecified...

basically I had to deal with that in multi party calls in a single WebRTC connection

yes that part i get

(via a sfu)

Why would you need anything in Jingle for that?

I mean, just have an additional SSRC in the existing content

You shouldn't need to announce that via Jingle.

add-content is relevant if you want to add a new kind of content, not because you just want to send more of the same kind. You're also not adding or changing content when changing the resolution of video content.

do you not need add-content when going from 2 to 3 video streams for example?

true, as I dig up (it was a while while I worked on that), it was related to content-modify as SSRC changed for existing content (same content new streams)

But that probably goes back to most using just some WebRTC implementation in the background and thus using the parts of Jingle they need to connect their WebRTC. Which resulted in the current specs being terrible for people that actually implement them.

Daniel, it depends..

Daniel: if you add a video that is meant to be a new kind of video (e.g. a screen share), you should, but you don't strictly need.

but not for when a fourth person joins the call?

weird...

larma, it may had something to do with sending new set of SSRC for existing content (content-modify?) but content-modify should be used only for changing direction of the stream?

basically, in WebRTC you can have each person stream in separate content or you may mix streams of same type (codec) in the same content (new stream)

according to XEP-0166 (7.2.3) > The content-modify action is used to change the direction of an existing content definition through modification of the 'senders' attribute. so adding new SSRC in there is not allowed. So how would I advertise new SSRCs for existing content?

or any other changes for existing content?

that is why I was thinking about an issue with SSRC and their changes

ok thanks Andrzej that helps me to understand the problem

we don’t necessarily need to discuss a solution now; that's what the summit is for I guess.

Andrzej: you can also mix different codecs in a single content.

maybe, I just do not recall details, but generally usage of multiple SSRCs was claimed to be more "optimal" from the resource usage AFAIR

You can even change the codec of existing SSRCs without any Jingle renogitation if the codec was assigned a payload type id before ✏

I know that I had to send new set of SSRCs if they changed (in content-modify which is not allowed by the XEP), to make sure that streams are properly updated

Well, that might've just been an issue with your WebRTC implementation then.

official WebRTC library built from sources..

I do recall it failed to discover new source and notify that source was gone

but maybe it would work with a newer WebRTC version..

WebRTC is supposedly an open standard, thus there is no official WebRTC library. You're probably referring to Google's libwebrtc which makes things even worse: I don't think we want to design our protocols around the features of a single library. That was literally the thing mostly criticised about OMEMO

I'm referring to what is linked from "webrtc.org" web page, if that should work without need for SSRC updates then there is (or was) a bug in that library - whether it is official or not

Happy New Year !

oh wrong date LOL sorry

The ol' off-by-one :)

yeah, let's keep indexing days from `1`, cuz that's totally unconfusing

2022-12-31T00:49+07:00

> 31 yeah, too early to overflow 5 bits

I blame Lua