XSF Discussion - 2013-05-06

was there any consensus at the last summit about how to go about dealing with jingle and webrtc? i dont remember

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

ah

Lance: interesting topic

Lance: there are several possible approaches

(1) Jingle as-is, with server-side gateway or translation to SDP

(2) a new content-type that would allow us to place SDP directly into a Jingle message (instead of the current payload types)

(3) SIP/SDP over XMPP, a.k.a. SOX (where the SIP headers are probably minimal, what we care about is the SDP)

I'd prefer #2, except SDP combines the content and transport description, so we wouldn't be able to use the normal jingle pattern

right

it gets ugly

#1 isn't bad IF you have access to the raw data

no matter which way you go

but the browser doesn't expose that

i'm probably just going to parse the stuff myself and do the translation

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)

true

but ugh, so ugly

yeah

believe me, I know

and then we're going to want to do data channels over webrtc

so jingle file transfers will have the same problem/solution

data channels as in screen sharing and the like?

as in sharing raw data

ah

ok

bytestreamy things

you can already do screen sharing via video

yes

so if we go with SOX to solve the video problem for now, we've doomed jingle to obsolescence

pretty much, yes :(

which is why I haven't written it up for general consumption yet

on the other hand, you can't exactly say that Jingle has taken the world by storm

and everyone has moved to using SDP, despite the fact that it's icky

in WebRTC etc.

so the question is, what do we do?

server-side gateways and translators have their own challenges

with state management and such

so that leaves us with <jingle> wrappers around SDP, or SoX

#2 does away with most of what is good about Jingle (separation of description from transport)

and leaves only the barest of the state machine

and that state machine might not even really apply very well if the payload of the <jingle/> element is SDP

I haven't worked out that model, but it worries me a bit

I grant that SOX is utterly ugly, but it's pragmatic

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

which is pretty much exactly the pattern in use for webrtc

I lean toward <message/> so it can be forked if needed, but right

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)

but the SIP headers would pretty much be dummied up

would that really be needed in the content going over xmpp? not added by the receiver?

I grant that we might want separate <sip/> and <sdp/> elements under the <sox/> element

or

use shim

well, if we look at SOX as a pure tunneling solution then yes, I think we'd want both SIP and SDP in there

I freely grant that it's even uglier than sending plain SDP :P

I need to think about it a bit more

maybe, but it's already there. depends on how many headers you expect to be adding

^ referring to shim

ah

I admit that I haven't thought about using SHIM here

I think I'd prefer it, just to keep the sip an extra arm length's away

heehee

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?

that's what i'm looking up now

GMTA!

my sense has been the latter

but I haven't researched it

not seeing anything noteworthy in python to process SDP

maybe gstreamer

yeah

I think most libs bundle SIP and SDP together

yep

that's what I saw and heard

which also has led me down the SoX road

the SoX road is paved with good intentions :-)

certainly

unfortunately we know where such roads lead ;-)

but it's just a short step to it being SIMPLEoX

no!

I disagree

SoX for audio/video and XMPP for everything else - messaging, presence, etc.

if we can keep it constrained to that, then great

and that's if you have an XMPP-only endpoint

i just have nightmares of, we're already including these sip headers, just add this other one

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/

IMHO, SOX is only for XMPP-only endpoints

right

Lance: think about it some more and let me know what conclusions you reach

Lance: I might need to write up the SoX idea here soon...

stpeter: do you have any examples for what a typical payload would be for sox?

maybe :-)

sorry, IRL interrupt

ok

where was I? ;-)

Lance, you'd probably have something like this... <message from='romeo@example.net/orchard' to='juliet@example.com'> <sox xmlns='urn:xmpp:sox:0'> INVITE sip:juliet@example..com sip/2.0 Via: SIP/2.0/tcp example.net;branch=z9hG4bK1602341dcb7 From: <sip:romeo@example.net>;tag=0019 To: <sip:juliet@example.com> Contact: <sip:romeo@example.net>;gr=orchard Call-Info: <xmpp:romeo@example.net>;purpose=impp Call-ID: 0019aa04-50550007-660c7034-529a811b Date: Mon, 6 May 2013 21:27:24 GMT User-Agent: foo CSeq: 101 INVITE Max-Forwards: 70 Expires: 180 Allow: ACK,BYE,CANCEL,INVITE Content-Type: application/sdp Content-Length: nnnn v=0 o=<username> <ntp> <ntp> IN IP4 <client_ip> s=SoX Media Setup c=IN IP4 <client_ip> t=0 0 m=audio 9000 RTP/AVP 105 106 121 a=rtpmap:105 opus/48000/2 a=fmtp:105 maxplaybackrate=16000; sprop-maxcapturerate=16000; maxaveragebitrate=24000; stereo=1; useinbandfec=1; usedtx=0 a=rtpmap:106 iLBC/8000 a=ptime:40 a=maxptime:40 a=recv-source 1,2,3 a=rtpmap:121 mix/90000/1 a=fmtp: 121 105/106 a=sendrecv </sox> </message>

thanks!

not sure about the SIP and SDP details

I'll need to review those more carefully

might need to at least write up a document this evening, for my own thinking if nothing else

but for now I need to jet home in time for my next conference call

well, not *literally* jet of course ;-)

have fun!

always! ;-)