- Robot101 has set the topic: Jingle multiple streams Robot101: hey stpeter: hey! daf: hi! Robot101: daf's another Collabora guy who's been working on our XMPP backend and streaming stuff stpeter: cool beans * Robot101 prods Sean stpeter: heh stpeter: daf or dgh? stpeter: maybe I can see his real JID since I have admin privs daf: dgh are initials daf: daf is what everyone calls me stpeter: heh stpeter: ok Robot101: (I have no idea, MUC's insane) Robot101: stpeter: MUC is great, some impls are not Robot101: basically the options are: Robot101: a) require a new for each new / paid Robot101: *pair Robot101: which is kinda what the spec says atm stpeter: yes, right now Robot101: b) allow multiple over one somehow, which imposes odd restrictions about what those descriptions and transports can be (not everything can mux/demux) daf: the downside to (a) is that we'd like to be able to associate streams together daf: e.g. for synchonising voice and video streams stpeter: yeah Robot101: yeah, run the streams on the same clock - 19:09 - stpeter: sean and I chatted about that about 10 days ago Robot101: the muxing/demuxing pretty much sucks I think, we'd like to be able to do stuff other than just voice/video over RTP daf: I think (b) basically involves making streams first-class entities within sessions daf: divorcing stream negotiation from session negotiation stpeter: aha daf: oh * stpeter ponders daf: sorrry, not (b) daf: (c) Robot101: daf is thinking of (c) which I havn't spoken about stpeter: hey, not fair! stpeter: go easy on me, I'm easily confused Robot101: (b) sucks (muxing at RTP level) because it's not possible to gate that to SIP without relaying. SIP will signal two RTP sessions for a voice and video call Robot101: it's kinda not how its done in general Robot101: if the payload type switches mid-RTP stream, it means that the codec for the same stream has changed, not that it's a different stream on the same RTP channel Robot101: so (b) is pretty mad, and doesn't account for file sharing or whatever Robot101: (c) is we need to work out some way of having multiple / pairs inside a jingle session Robot101: this is good because we know they're all related (present them in the same window, run them on the same clock, etc) daf: it's quite a large change Robot101: and ideally, we need some way to add/remove these pairs daf: it also breaks the notion of a session's content type somewhat stpeter: yes, we started to go down that path until Sean convinced me otherwise daf: e.g. if you initially negotiate a voice call daf: and then later you decide to add video stpeter: but I remain convincable regarding (c) daf: the content type isn't really indicative of the state of the session daf: though perhaps that's not so bad stpeter: sorry, brb, keep talking if desired - 19:15 - Robot101: hm, would be good if sean could join Robot101: on a side note, we spotted a bug in JEP-180, it says the attributes belong to the node, but the schema (and example) show they belong to the nodes - 19:21 - stpeter: ok, I'll look at the bug, thanks for the report stpeter: hrm, no sign of sean? Robot101: not as yet Robot101: I need to head off soonish, but maybe we could try again tomorrow stpeter: hmm, ok Robot101: we've got some RTP gurus as well who could probably help stpeter: I just poked him, not sure if he's around right now stpeter: gurus are good Robot101: he was about half an hour ago but disappeared roughly at the same time I thought it would be a good idea to discuss this in a group stpeter: heh Robot101: I think the key thing is we'd like to be able to add/remove description/transport pairs within an existing jingle session Robot101: so that we can make a voice call and then add video later, and then choose to transfer a file, kinda thing - 19:26 - stpeter: yes, we've had that thought before -- I was thinking of something (c)-ish previously but sean was concerned about the demuxing stpeter: hi sean