- 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 <jingle> for each new <description>/<transport> paid
Robot101: *pair
Robot101: which is kinda what the spec says atm
stpeter: yes, right now
Robot101: b) allow multiple <descriptions> over one <transport> 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 <description>/<transport> 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 <description> node, but the schema (and example) show they belong to the <payload-type> 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