Lancewas there any consensus at the last summit about how to go about dealing with jingle and webrtc? i dont remember
Lancei'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
stpeterah
stpeterLance: interesting topic
stpeterLance: 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
LanceI'd prefer #2, except SDP combines the content and transport description, so we wouldn't be able to use the normal jingle pattern
stpeterright
kevinhas joined
stpeterit gets ugly
Lance#1 isn't bad IF you have access to the raw data
stpeterno matter which way you go
Lancebut the browser doesn't expose that
Lancei'm probably just going to parse the stuff myself and do the translation
stpeterI 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)
Lancetrue
Lancebut ugh, so ugly
stpeteryeah
stpeterbelieve me, I know
Lanceand then we're going to want to do data channels over webrtc
Lanceso jingle file transfers will have the same problem/solution
stpeterdata channels as in screen sharing and the like?
Lanceas in sharing raw data
stpeterah
stpeterok
stpeterbytestreamy things
Lanceyou can already do screen sharing via video
stpeteryes
Lanceso if we go with SOX to solve the video problem for now, we've doomed jingle to obsolescence
stpeterpretty much, yes :(
stpeterwhich is why I haven't written it up for general consumption yet
stpeteron the other hand, you can't exactly say that Jingle has taken the world by storm
stpeterand everyone has moved to using SDP, despite the fact that it's icky
stpeterin WebRTC etc.
stpeterso the question is, what do we do?
stpeterserver-side gateways and translators have their own challenges
stpeterwith state management and such
stpeterso 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)
stpeterand leaves only the barest of the state machine
stpeterand that state machine might not even really apply very well if the payload of the <jingle/> element is SDP
stpeterI haven't worked out that model, but it worries me a bit
stpeterI grant that SOX is utterly ugly, but it's pragmatic
stpetershrugs
Lanceat 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
Lancewhich is pretty much exactly the pattern in use for webrtc
stpeterI lean toward <message/> so it can be forked if needed, but right
stpeterIMHO 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)
stpeterbut the SIP headers would pretty much be dummied up
Lancewould that really be needed in the content going over xmpp? not added by the receiver?
stpeterI grant that we might want separate <sip/> and <sdp/> elements under the <sox/> element
Lanceor
Lanceuse shim
Neustradamushas joined
stpeterwell, if we look at SOX as a pure tunneling solution then yes, I think we'd want both SIP and SDP in there
stpeterI freely grant that it's even uglier than sending plain SDP :P
stpeterI need to think about it a bit more
Lancemaybe, but it's already there. depends on how many headers you expect to be adding
Lance^ referring to shim
stpeterah
stpeterI admit that I haven't thought about using SHIM here
LanceI think I'd prefer it, just to keep the sip an extra arm length's away
stpeterheehee
stpeterin 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?
Lancethat's what i'm looking up now
stpeterGMTA!
stpetermy sense has been the latter
stpeterbut I haven't researched it
Lancenot seeing anything noteworthy in python to process SDP
Lancemaybe gstreamer
stpeteryeah
stpeterI think most libs bundle SIP and SDP together
Lanceyep
stpeterthat's what I saw and heard
stpeterwhich also has led me down the SoX road
stpeterthe SoX road is paved with good intentions :-)
Lancecertainly
stpeterunfortunately we know where such roads lead ;-)
Lancebut it's just a short step to it being SIMPLEoX
stpeterno!
stpeterI disagree
stpeterSoX for audio/video and XMPP for everything else - messaging, presence, etc.
Lanceif we can keep it constrained to that, then great
stpeterand that's if you have an XMPP-only endpoint
Lancei just have nightmares of, we're already including these sip headers, just add this other one
kevinhas joined
stpeterI 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
stpeterIMHO, SOX is only for XMPP-only endpoints
Lanceright
Alexhas joined
Neustradamushas joined
stpeterLance: think about it some more and let me know what conclusions you reach
stpeterLance: I might need to write up the SoX idea here soon...
Lancestpeter: do you have any examples for what a typical payload would be for sox?