was there any consensus at the last summit about how to go about dealing with jingle and webrtc? i dont remember
Lance
i'm remaking conversat.io using stanza.io instead of socket.io, and im at the point of having to parse and translate SDP. ick
Neustradamushas joined
Neustradamushas joined
stpeter
ah
stpeter
Lance: interesting topic
stpeter
Lance: there are several possible approaches
stpeter
(1) Jingle as-is, with server-side gateway or translation to SDP
stpeter
(2) a new content-type that would allow us to place SDP directly into a Jingle message (instead of the current payload types)
stpeter
(3) SIP/SDP over XMPP, a.k.a. SOX (where the SIP headers are probably minimal, what we care about is the SDP)
Lancehas left
Lancehas joined
Lance
I'd prefer #2, except SDP combines the content and transport description, so we wouldn't be able to use the normal jingle pattern
stpeter
right
kevinhas joined
stpeter
it gets ugly
Lance
#1 isn't bad IF you have access to the raw data
stpeter
no matter which way you go
Lance
but the browser doesn't expose that
Lance
i'm probably just going to parse the stuff myself and do the translation
stpeter
I lean toward #3 despite the fact that it's perhaps the ugliest of the bunch, because I think it would work in all cases (just use XMPP as the transport layer for SIP/SDP)
Lance
true
Lance
but ugh, so ugly
stpeter
yeah
stpeter
believe me, I know
Lance
and then we're going to want to do data channels over webrtc
Lance
so jingle file transfers will have the same problem/solution
stpeter
data channels as in screen sharing and the like?
Lance
as in sharing raw data
stpeter
ah
stpeter
ok
stpeter
bytestreamy things
Lance
you can already do screen sharing via video
stpeter
yes
Lance
so if we go with SOX to solve the video problem for now, we've doomed jingle to obsolescence
stpeter
pretty much, yes :(
stpeter
which is why I haven't written it up for general consumption yet
stpeter
on the other hand, you can't exactly say that Jingle has taken the world by storm
stpeter
and everyone has moved to using SDP, despite the fact that it's icky
stpeter
in WebRTC etc.
stpeter
so the question is, what do we do?
stpeter
server-side gateways and translators have their own challenges
stpeter
with state management and such
stpeter
so that leaves us with <jingle> wrappers around SDP, or SoX
stpeter
#2 does away with most of what is good about Jingle (separation of description from transport)
stpeter
and leaves only the barest of the state machine
stpeter
and that state machine might not even really apply very well if the payload of the <jingle/> element is SDP
stpeter
I haven't worked out that model, but it worries me a bit
stpeter
I grant that SOX is utterly ugly, but it's pragmatic
stpetershrugs
Lance
at this point, minting a <sdp /> element sounds reasonable. and just iq set back and forth, leaving the state management to whatever SDP processor is in use
Lance
which is pretty much exactly the pattern in use for webrtc
stpeter
I lean toward <message/> so it can be forked if needed, but right
stpeter
IMHO we might need or want to include some minimal SIP headers (e.g., if there's a gateway or translator in the middle it can add a Via header)
stpeter
but the SIP headers would pretty much be dummied up
Lance
would that really be needed in the content going over xmpp? not added by the receiver?
stpeter
I grant that we might want separate <sip/> and <sdp/> elements under the <sox/> element
Lance
or
Lance
use shim
Neustradamushas joined
stpeter
well, if we look at SOX as a pure tunneling solution then yes, I think we'd want both SIP and SDP in there
stpeter
I freely grant that it's even uglier than sending plain SDP :P
stpeter
I need to think about it a bit more
Lance
maybe, but it's already there. depends on how many headers you expect to be adding
Lance
^ referring to shim
stpeter
ah
stpeter
I admit that I haven't thought about using SHIM here
Lance
I think I'd prefer it, just to keep the sip an extra arm length's away
stpeter
heehee
stpeter
in practice, do folks have a standalone SDP library to call, or would they just hand the SIP/SDP off to an RTC library of some kind?
Lance
that's what i'm looking up now
stpeter
GMTA!
stpeter
my sense has been the latter
stpeter
but I haven't researched it
Lance
not seeing anything noteworthy in python to process SDP
Lance
maybe gstreamer
stpeter
yeah
stpeter
I think most libs bundle SIP and SDP together
Lance
yep
stpeter
that's what I saw and heard
stpeter
which also has led me down the SoX road
stpeter
the SoX road is paved with good intentions :-)
Lance
certainly
stpeter
unfortunately we know where such roads lead ;-)
Lance
but it's just a short step to it being SIMPLEoX
stpeter
no!
stpeter
I disagree
stpeter
SoX for audio/video and XMPP for everything else - messaging, presence, etc.
Lance
if we can keep it constrained to that, then great
stpeter
and that's if you have an XMPP-only endpoint
Lance
i just have nightmares of, we're already including these sip headers, just add this other one
kevinhas joined
stpeter
I see the world going to CUSAX -- combined use of SIP and XMPP, with SIP for audio/video and XMPP for messaging, presence, groupchat, etc. -- that's why I've been working on https://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/
Alexhas joined
stpeter
IMHO, SOX is only for XMPP-only endpoints
Lance
right
Alexhas joined
Neustradamushas joined
stpeter
Lance: think about it some more and let me know what conclusions you reach
stpeter
Lance: I might need to write up the SoX idea here soon...
Lance
stpeter: do you have any examples for what a typical payload would be for sox?