XSF Discussion - 2013-05-06


  1. Neustradamus has left

  2. stpeter has joined

  3. Jef has left

  4. Jef has joined

  5. Lance has joined

  6. Jef has left

  7. stpeter has left

  8. Lance has left

  9. bear has joined

  10. J.T has joined

  11. J.T has left

  12. bear has left

  13. bear has joined

  14. bear has left

  15. Alex has joined

  16. Nÿco has joined

  17. Nÿco has left

  18. Neustradamus has joined

  19. Neustradamus has left

  20. Neustradamus has joined

  21. jabberjocke has joined

  22. jabberjocke has left

  23. jabberjocke has joined

  24. jabberjocke has left

  25. Nÿco has joined

  26. Nÿco has left

  27. kevin has joined

  28. kevin has left

  29. kevin has joined

  30. kevin has left

  31. jabberjocke has left

  32. jabberjocke has joined

  33. kevin has joined

  34. jabberjocke has left

  35. kevin has left

  36. stpeter has joined

  37. kevin has joined

  38. Alex has left

  39. Ashley has joined

  40. Lance has joined

  41. Ashley has left

  42. Lance has left

  43. Lance has joined

  44. Lance has joined

  45. stpeter has left

  46. stpeter has joined

  47. Lance has joined

  48. Lloyd has joined

  49. jabberjocke has joined

  50. Lloyd has left

  51. Neustradamus has joined

  52. jabberjocke has joined

  53. Lance

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

  54. 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

  55. Neustradamus has joined

  56. Neustradamus has joined

  57. stpeter

    ah

  58. stpeter

    Lance: interesting topic

  59. stpeter

    Lance: there are several possible approaches

  60. stpeter

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

  61. stpeter

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

  62. stpeter

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

  63. Lance has left

  64. Lance has joined

  65. 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

  66. stpeter

    right

  67. stpeter

    it gets ugly

  68. Lance

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

  69. stpeter

    no matter which way you go

  70. Lance

    but the browser doesn't expose that

  71. Lance

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

  72. 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)

  73. Lance

    true

  74. Lance

    but ugh, so ugly

  75. stpeter

    yeah

  76. stpeter

    believe me, I know

  77. Lance

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

  78. Lance

    so jingle file transfers will have the same problem/solution

  79. stpeter

    data channels as in screen sharing and the like?

  80. Lance

    as in sharing raw data

  81. stpeter

    ah

  82. stpeter

    ok

  83. stpeter

    bytestreamy things

  84. Lance

    you can already do screen sharing via video

  85. stpeter

    yes

  86. Lance

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

  87. stpeter

    pretty much, yes :(

  88. stpeter

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

  89. stpeter

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

  90. stpeter

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

  91. stpeter

    in WebRTC etc.

  92. stpeter

    so the question is, what do we do?

  93. stpeter

    server-side gateways and translators have their own challenges

  94. stpeter

    with state management and such

  95. stpeter

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

  96. stpeter

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

  97. stpeter

    and leaves only the barest of the state machine

  98. stpeter

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

  99. stpeter

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

  100. stpeter

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

  101. stpeter shrugs

  102. 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

  103. Lance

    which is pretty much exactly the pattern in use for webrtc

  104. stpeter

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

  105. 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)

  106. stpeter

    but the SIP headers would pretty much be dummied up

  107. Lance

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

  108. stpeter

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

  109. Lance

    or

  110. Lance

    use shim

  111. Neustradamus has joined

  112. 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

  113. stpeter

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

  114. stpeter

    I need to think about it a bit more

  115. Lance

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

  116. Lance

    ^ referring to shim

  117. stpeter

    ah

  118. stpeter

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

  119. Lance

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

  120. stpeter

    heehee

  121. 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?

  122. Lance

    that's what i'm looking up now

  123. stpeter

    GMTA!

  124. stpeter

    my sense has been the latter

  125. stpeter

    but I haven't researched it

  126. Lance

    not seeing anything noteworthy in python to process SDP

  127. Lance

    maybe gstreamer

  128. stpeter

    yeah

  129. stpeter

    I think most libs bundle SIP and SDP together

  130. Lance

    yep

  131. stpeter

    that's what I saw and heard

  132. stpeter

    which also has led me down the SoX road

  133. stpeter

    the SoX road is paved with good intentions :-)

  134. Lance

    certainly

  135. stpeter

    unfortunately we know where such roads lead ;-)

  136. Lance

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

  137. stpeter

    no!

  138. stpeter

    I disagree

  139. stpeter

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

  140. Lance

    if we can keep it constrained to that, then great

  141. stpeter

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

  142. Lance

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

  143. 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/

  144. Alex has joined

  145. stpeter

    IMHO, SOX is only for XMPP-only endpoints

  146. Lance

    right

  147. Alex has joined

  148. Neustradamus has joined

  149. stpeter

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

  150. stpeter

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

  151. Lance

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

  152. stpeter

    maybe :-)

  153. stpeter fishes around

  154. stpeter

    sorry, IRL interrupt

  155. stpeter

    ok

  156. stpeter

    where was I? ;-)

  157. stpeter

    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>

  158. Lance

    thanks!

  159. stpeter

    not sure about the SIP and SDP details

  160. stpeter

    I'll need to review those more carefully

  161. stpeter

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

  162. stpeter

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

  163. stpeter

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

  164. Lance

    have fun!

  165. stpeter

    always! ;-)

  166. stpeter disappears in a puff of smoke

  167. stpeter has left

  168. Jef has joined

  169. Lance has left